基于AutomationML的信息物理生產線系統模型驅動開發方法

李 迪，張 柳，張春華，周 楠

（華南理工大學機械與汽車工程學院，廣東 廣州510640）

1 引言

當前，制造業產業鏈布局全球化、消費者需求多樣化以及產品市場周期不斷縮短的趨勢給制造業企業帶來重大挑戰［1］。制造業企業需建立能夠適應多品種、變批量生產模式的制造系統［2］從而滿足大規模個性化定制產品需求。制造系統需要具有一定水平的適應性和魯棒性，以確保同時進行多種產品的混流生產［3］。信息物理系統（Cyber-Physical System，CPS）［4］構建了物理空間與信息空間要素相互映射、適時交互、高效協同的復雜系統，實現系統內資源配置和運行的按需響應、快速迭代、動態優化。通過將CPS集成到制造場景中，形成信息物理生產線系統，可滿足以上需求，實現智能制造［5］。

信息物理生產線系統的開發覆蓋了機械、電氣、網絡等多個領域，所涉及的信息是多視角、多層次的，在不同的問題域內需使用不同工具從不同角度描述系統以進行協同開發。混合異構的工具間信息交互為系統開發與集成帶來重大挑戰。采用模型驅動開發方法［6］，將開發工具的信息模型化，可以有效地降低系統復雜性，提高開發效率。AutomationML（AML）由自動化技術的主要供應商和研究機構提出，是一種國際標準（IEC 62714），用于存儲和交換不同工程領域的工程數據。目前，在生產線系統級別，國內外逐漸集中于圍繞AML相關理念與技術對生產系統的信息模型開發和集成問題進行相關研究。文獻［7］基于AML，通過關注生產系統的資源、工藝、產品三個角度，對螺絲生產線進行信息建模，并對AML在智能制造的數據集成領域的應用前景作了展望。文獻［8］采用AML建立生產系統的設備的數字孿生模型來保存產品全生命周期數據，以便于進行異構系統間的數據交換。文獻［9］采用AML表示CPS資產的AAS模型信息，并進行制造系統的實際驗證。目前雖然基于AML的相關研究取得了一定的成果，但是大部分僅僅面向單一具體應用場景，其展示的建模方法流程適用性不廣；不同工具之間針對同一對象存在重復建模的問題，復用性不強；信息集成環節中自動化程度不高、通用性不強，不能實現面向生產線系統多領域的統一化、自動化開發。

針對現有不足，提出基于AML的信息物理生產線系統模型驅動開發方法及其架構，將面向生產線系統不同領域開發工具的信息模型化；通過模型轉換定義模型映射規則，實現系統開發過程信息集成的自動化。

2 信息物理生產線系統信息集成架構

為保證所提模型驅動方法應用于生產線系統開發過程中的精確性和可信度，遵循模型驅動架構（Model-Driven Architecture，MDA）下模型定義的分層架構，將信息物理生產線系統的信息集成架構分為四層，如圖1所示。

圖1 信息物理生產線系統信息集成架構Fig.1 The Information Integration Architecture of Cyber-Physical Production Line System

在M0層，通過使用M1層中提供的領域模型來描述生產線系統。領域模型應符合在M2層中定義的領域特定建模語言（Domain-specific modeling language，DSML）的語法和語義。在語法及語義定義之前，應進行領域概念分析以確定所要定義的DSML的適用范圍。以AML通用核心概念為指導展開元模型層的構建。所建立的元模型需要遵循在M3層中定義的元元模型。元模型構建采用UML類圖的表達方式，在具體實施過程中采用模型集成計算理論［10］提供的相關領域建模工具鏈［11］。

在具體應用中，M1層的領域模型提供了開發人員可直接使用的領域特定建模概念對系統進行直接描述，能夠避免需求與實現的不一致性。將基于AML概念定義的領域建模語言應用于生產線系統的規劃調度問題的功能與性能驗證的具體實現之中。基于此研究問題，開發了相應的模型轉換器，將領域模型分別轉換為：語義推理工具下的本體模型以便進行規劃調度，以及形式化驗證工具下的形式化模型以進行設計時性能驗證。模型轉換器的實現同樣遵循M2層中的語法定義，以領域模型實例作為輸入，通過建立領域模型與本體模型及形式化模型之間的映射規則實現模型轉換。

3 模型構建方法與流程

模型構建包括元模型及領域模型的構建，采用AML實現。采用AML建模主要基于以下核心概念：

（1）角色類（Role Class，RC），用于定義面向特定領域語義層；（2）接口類（Interface Class，IC），用于定義模型元素之間的關系及引用存儲在文件之外的信息；（3）系統單元類（System Unit Class，SUC），定義可重用的系統組件模板；（4）實例層次（Instance Hierarchy，IH），使用內部元素（Internal Element，IE）創建特定應用下的具體實例。

3.1 元模型構建

元模型的構建，即DSML定義，由語法及語義定義組成。在實施過程中，DSML語義通過創建AML角色類庫中的語義層實現［12］。DSML語法定義涵蓋生產線資產分類及描述，分別由產品-工藝-資源（Product-Process-Resource，PPR）和資產管理殼（Asset Administration Shell，AAS）組成。

（1）PPR：PPR是針對生產中規劃和調度等主要生產環節提出的對生產線資產的分類［13］，即“產品”、“工藝”、“資源”，如圖2所示。產品是指在生產過程中被生產的商品，按粒度分為原材料、半成品和成品，由資源處理。工藝是指生產中的特定過程，涉及一個或多個步驟的操作，用于描述所有與機械加工、制造、運輸等方面相關的抽象的工藝及其約束，可以產生產品。工藝按粒度分為動作、操作和特征工藝。例如孔工藝（特征工藝），可由鉆孔工藝或沖孔工藝（操作）實現。其中，鉆孔工藝由移動、旋轉等更小粒度工藝（動作）構成。資源是指在生產過程中提供加工能力并參與實際生產過程的實體，按不同粒度還可以進一步劃分為傳感和執行單元、設備、工作站，負責執行產品所需的工藝流程。

圖2 元模型PPR部分Fig.2 Part of Metamodel：PPR

使用PPR方式進行生產線資產分類，能夠有效地整合生產線系統開發過程中不同工程領域和階段的軟硬件資源、產品、工藝和工程數據，使其能夠被有條理地分析。基于PPR描述生產系統具有通用性，所構建的領域模型復用性高。對于新的應用場景，不需要改變元模型而只需要在領域模型層創建繼承于相應概念的模型實例，而其它工具內相對應的概念則由模型轉換工具自動生成，避免重復定義，提高自動化程度，保證建模過程的精確性和可信度。

（2）AAS：用于生產線資產描述，提供資產信息以供外部訪問。通過將生產線資產抽象成AAS，生產線資產可借由AAS進行交互，以實現生產線系統的信息物理融合。

在AAS規范指導下定義的AAS如圖3所示。AAS由目錄清單（Manifest）和子模型（Submodel）組成。其中，目錄清單是AAS的層次結構索引列表，從功能視角提供資產、AAS及各子模型唯一標識供外部訪問；子模型是資產不同方面特性的聚合表示。結構子模型從結構視角描述資產的組成元素的層次，行為子模型從行為視角描述資產內部組成元素之間的依賴關系。

圖3 元模型AAS部分Fig.3 Part of Metamodel：AAS

3.2 領域模型構建過程

信息物理生產線系統可視為不同層次及不同類型的組件的組合，其領域模型由組件模型和應用模型兩部分組成。組件模型是系統開發階段對組件的抽象；應用模型是特定應用場景下的具體實例，通過對組件模型的重用及組合實現。

本節以華南理工大學生產線原型平臺［14］為例進行領域模型構建。生產線原型平臺以U盤的打標和木雕的加工工藝為加工任務，能夠模擬多種生產系統實際加工任務場景。具體地，該平臺由上盒模塊、上蓋模塊、回收模塊、上料模塊、CNC加工模塊、激光打標模塊、包裝模塊及運輸模塊組成，如圖4所示。

圖4 生產線原型平臺Fig.4 Production Line Prototype Platform

該生產線原型平臺涉及的所有組件如表1所示。

表1 生產線原型平臺組件Tab.1 The Components of Production Line Prototype Platform

領域模型的構建按如下步驟進行：

第一步：在AML的系統單元類庫中建立上述組件的組件模型，具體定義AAS下子模型實例。例如，對于帶夾爪的機械臂組件，在靜態結構子模型下定義機械臂的靜態信息，如名稱、類型及內部組成等；在動態結構子模型下定義機械臂的動態可變信息，如運行狀態、運行時長、不可用時間等；在行為子模型下定義機械臂的組成部分之間的幾何關系以及機械結構依賴關系，如夾爪需安裝在機械臂的末端。

第二步：在AML的實例層次中將實際場景所涉及的產品組件模型、工藝組件模型及資源組件模型進行重用及組合，為模型的內部元素添加具體的屬性集合，完成應用模型的構建。

4 模型轉換

模型轉換是模型驅動開發中的關鍵技術，通過定義源模型到目標模型的映射規則實現。本節通過定義領域模型到本體模型和形式化模型的映射規則實現模型轉換，從而將規劃調度問題及其驗證過程的信息集成到基于AML的統一模型。

4.1 領域模型到本體模型轉換

本體模型關注生產線系統中產品組件、工藝組件、資源組件的關聯關系并形成結構化知識網絡。語義推理工具依據本體模型進行語義推理，將推理信息提供給規劃調度工具，實現將產品所需的加工內容合理地分配給設備進行生產。采用OWL語言構建本體模型。本體模型構建基于實體（Object），分為兩個層次：實體的類層次和關系層次。實體關系又稱為屬性（Property），分為對象屬性（Object Property）和數據屬性（Data Property），分別定義實體與實體關系及實體與數據關系［15］。定義領域模型到本體模型的映射規則時，領域模型內的組件模型部分對應本體模型的類層次；領域模型內的應用模型部分對應本體模型的實例，其具體映射規則如表2所示。

表2 應用模型與本體模型實例映射規則Tab.2 The Mapping Rules between Application Model and Ontology Model Individuals

本體模型的Object Property和Data Property由應用模型中產品組件、工藝組件、資源組件間的關系定義，如表3所示。

表3 本體模型屬性Tab.3 Ontology Model Properties

4.2 領域模型到形式化模型轉換

基于著色Petri網（Coloured Petri Net，CPN）構建生產線系統的形式化模型。CPN可用于檢驗執行規劃調度命令的生產線邏輯正確性，驗證其功能是否滿足需求并進行性能分析。采用CPN建模主要基于以下概念［16］：庫所（Place），用于定義生產線系統的狀態；變遷（Transition），用于定義使生產線系統狀態發生改變的事件；有向弧（Arc），表示變遷方向；令牌標記（Token），用于表示處于某個Place的對象，Token的顏色代表該對象的屬性值；顏色集（Coloured Set），用于定義屬性值的類型。

進行領域模型到形式化模型的轉換時，主要關注領域模型內的應用模型部分中：（1）工作站級別的資源組件模型；（2）特征工藝級別的工藝組件模型及（3）成品級別的產品組件模型。由此定義應用模型到形式化模型的映射規則，如表4所示。

表4 應用模型到形式化模型的映射規則Tab.4 The Mapping Rules between Application Model and Formal Model

5 集成工具鏈實現

為實現模型開發驗證流程一體化，提出集建模工具AML Editor、語義推理工具Apache Jena、規劃調度工具、形式化驗證工具CPN Tools、集成開發平臺GME于一體的工具鏈，支持信息物理生產線系統模型驅動開發方法的實現，其工作流程如圖5所示。應用該工具鏈時，遵循模型構建、規劃調度、形式化驗證的基本流程，通過模型轉換實現三個階段的信息交互。

圖5 工具鏈Fig.5 The Toolchain

模型轉換基于通用建模環境（Generic Modeling Environment，GME）。GME是一個可自定義配置的工具集，擁有模塊化、可拓展的架構，并提供了面向第三方工具集成的擴展接口，用于實現各類模型轉換器從而滿足快速工具集成的需求。通過開發面向建模工具的模型轉換器，實現GME下領域模型的集成；開發面向語義推理工具的模型轉換器，可將領域模型轉換為本體模型；開發面向規劃調度工具的模型轉換器，根據規劃調度結果更新GME下領域模型；開發面向形式化驗證工具的模型轉換器，關聯CPN模板文件和領域模型，將領域模型中的規劃調度信息更新到CPN模板文件并將其導出。模板文件預先定義模型的可視化相關的信息，將未知工藝未知產品的模型仿真驗證問題轉換成一組確定的最小化的加工工藝的仿真問題，固定形式化模型的大致結構，降低生成形式化模型的難度。

6 開發實例

本節以木雕產品的加工包裝為例，應用前文提出的基于AML的信息物理生產線系統模型驅動開發方法及工具鏈進行實施。

（1）在AML Editor中，基于已定義的角色類庫及系統單元類庫中的組件模型，定義基于木雕產品加工包裝的生產線系統應用模型，如圖6所示。

圖6 基于木雕產品加工包裝的生產線系統應用模型Fig.6 Production Line System Application Model Based on The Processing and Packaging of Woodcarving Products

（2）集成開發平臺GME界面如圖7所示，紅框區域為插件區，對應模型轉換器的實現。通過GME中的AML Importer插件實現基于AML定義的模型到GME下模型的轉換。

圖7 GME界面Fig.7 GME Interface

（3）通過AML2OWL插件將GME下領域模型轉換為本體模型，以文本形式提供給Apache Jena進行語義推理。

（4）規劃調度工具根據語義推理信息進行規劃調度，將規劃調度結果保存在數據庫中。

（5）通過GME中的PPS2AML插件讀取數據庫中信息，同時更新領域模型。

（6）定義CPN模板文件并通過GME中的CPN Importer插件進行模型轉換，創建CPN模型，并為CPN模型元素和領域模型元素定義映射關系。CPN模板文件與領域模型對應。

（7）通過CPN Exporter插件獲取領域模型中規劃調度信息并更新CPN模型。

（8）將更新后的CPN模型導出到原有的CPN文件中，在CPN Tools中進行驗證，如圖8所示。若驗證結果理想，則可依據規劃調度結果安排產品的生產；若驗證結果不理想，則證明規劃調度結果不合理，需將驗證結果返回給規劃調度工具，重新觸發規劃調度過程，即上述的第4步，并執行后續過程，直到驗證結果滿足需求。

可見，將所提出方法及工具鏈應用于生產線系統開發是可行的，能夠實現由模型構建到規劃調度再到形式化驗證的完整流程，提高了系統開發的自動化程度。

7 結論

這里介紹了基于AML的信息物理生產線系統模型驅動開發方法及其架構。該方法基于AML概念構建元模型，進而構建領域模型；基于定義的模型映射規則實現了領域模型到本體模型及形式化模型的轉換，以便進行生產線系統的規劃調度問題的功能與性能驗證。開發的工具鏈能夠實現生產線開發流程化、模型集成和模型轉換過程的可視化與自動化。基于生產線原型平臺驗證了該方法的合理性及可行性。未來的工作將更多地集中在已開發工具的完善以及對模型轉換過程進行正確性驗證。