AutomationML as an Exchange Format for Tool-Independent Domain-Specific Modeling Language Specifications

Domain-specific modeling languages define how a particular engineering domain can be represented in models. They specify the available modeling concepts and relationships, constrain how these elements may be combined, and provide the semantics required for their consistent interpretation [1]. AutomationML already serves as a standardized, tool-independent exchange format for heterogeneous engineering models [2]. However, it currently focuses on exchanging model instances and engineering data rather than the domain-specific language specifications that govern how such models are created, represented and validated. Consequently, graphical DSLs remain tightly coupled to the proprietary extension formats of individual MBSE tools, requiring equivalent modeling environments to be implemented repeatedly for different platforms.

Graphical domain-specific languages frequently extend their structural metamodel through dedicated notations, diagram types, modeling palettes, validation rules, templates, and prescribed workflow steps [3]. A DSL may therefore describe not only a set of concepts and relations, but a complete domain-specific modeling environment. Although established metamodeling concepts and standards provide a largely tool-independent foundation for defining such languages, their implementation in contemporary MBSE tools remains strongly tool-specific [1][3]. This limits the direct exchange, portability, and reuse of DSL specifications across heterogeneous modeling environments.

This contribution investigates AutomationML as an exchange format for tool-independent DSL and graphical DSL specifications. For this purpose, an AutomationML-based representation is proposed that covers structural metamodel elements as well as constraints, diagram specifications, toolbox definitions, templates, workflow information, and additional supporting resources. The resulting representation provides a neutral specification that can be interpreted or transformed into the proprietary extension mechanisms of different modeling tools, enabling the reconstruction of equivalent modeling environments across platforms.

The approach is demonstrated using a Product-Process-Resource (PPR) domain-specific language as a representative engineering case. PPR was selected because Product, Process, and Resource are established concepts within AutomationML and MBSE [2], hence allowing the proposed DSL representation to build on an existing domain context. The PPR DSL is analyzed with respect to its required concepts, relations, constraints, validation rules, diagrams, toolboxes, templates, workflows, and other external resources. The corresponding modeling mechanisms available in Enterprise Architect MDG technologies and Cameo Systems Modeler are considered as reference points for identifying the information that must be captured independently of a specific modeling tool. These DSL elements are then represented in a tool-independent AutomationML model.

To preserve compatibility with existing AutomationML models, the DSL specification is stored in a separate companion AutomationML file rather than being embedded directly into the engineering model. Applications may therefore use or ignore the language definition depending on their capabilities and use case. The engineering model and its associated DSL specification can be distributed together through the AMLX container format. By extending AutomationML from engineering-data exchange towards portable modeling-language specifications, the proposed approach provides a foundation for improved interoperability and reuse of domain-specific modeling environments across MBSE tools.

Keywords: AutomationML; domain-specific modeling language; graphical DSL; MBSE; PPR; metamodeling; interoperability; AMLX