A Domain-Specific Modeling Language for Production Systems in Early Engineering Phases

Abstract

The development of modern production systems involves numerous interdependent disciplines, heterogeneous data sources, and frequent design iterations, making the conceptual design phase particularly complex and error-prone. Model-Based Systems Engineering (MBSE) provides a promising approach to manage this complexity by enabling consistent and structured system representations. While domain-specific modeling languages (DSMLs) can tailor MBSE methods to specific domains, existing approaches often lack standardized semantics, user guidance, and tool support to ensure consistent model creation and verification. This paper introduces a DSML framework tailored for the conceptual design of production systems, integrating both methodological guidance and standard-based domain knowledge. The approach builds upon the Software Platform Embedded Systems (SPES) framework and extends Systems Modeling Language (SysML) through the Unified Modeling Language (UML) profile mechanism, providing clear modeling constructs, viewpoint-specific diagram types, and automated consistency checks. To enhance comprehensibility and domain alignment, the framework incorporates supplementary DSMLs that capture structures and semantics from established industrial standards. The proposed method is evaluated using an aircraft production case study, demonstrating improved applicability of MBSE for the conceptual design of complex production systems.

1. Introduction

In the conceptual design of production systems, Model-Based Systems Engineering (MBSE) methods are particularly valuable. They support the structured modeling of complex production systems in early engineering phases, enabling a clear representation of system structures and requirements and facilitating interactions across different engineering disciplines [1], which is particularly relevant for modern industrial products such as aircraft that consist of more than 300,000 individual parts, as exemplified by the Airbus A320 [2]. This increasing system scale is reflected in MBSE models through a high number of model elements and interdependencies, which significantly raises the complexity of model creation and maintenance. Empirical studies report that approximately two thirds of practitioners perceive this complexity as a major barrier to MBSE adoption [3].

Dedicated modeling languages and tools enable the efficient and structured modeling of discipline-specific aspects of production systems at an appropriate level of detail [4]. In early engineering phases, this appropriate level of detail often means using abstract, easily modifiable representations rather than complex 3D models, which are cost- and time-intensive to create and frequently require changes [5]. This is especially relevant for the development of production systems, which is inherently complex due to the involvement of multiple engineering disciplines and numerous contextual factors. These include, for example, potentially changing product types or installation constraints that must be anticipated early and may necessitate subsequent system adaptations [6]. To address this, the development of models for production systems should be based on the digital representation of products, production resources, and required processes [7]. These Product-Process-Resource (PPR) aspects must be aligned with intended usage scenarios, functional system objectives, and environmental constraints. Standardization, interoperability, semantic consistency, and the integration of heterogeneous domains are widely recognized challenges in enterprise information systems [8]. These challenges similarly arise in the engineering of complex production systems, where multiple domains, standards, and viewpoints must be consistently aligned. In this context, it becomes apparent that the practical use of MBSE methods is still limited, as several challenges persist. A central challenge in the practical application of MBSE methods is the lack of methodological and tool-related standardization [9].

While standardized modeling languages such as the Systems Modeling Language (SysML) provide a solid foundation, their application is often perceived as complex and unintuitive, particularly in the context of production systems and other manufacturing-related domains [10]. This perceived complexity does not primarily stem from a lack of expressive capability but rather from the generic and highly flexible nature of SysML, which offers a large number of modeling constructs and degrees of freedom. Without domain-specific restrictions and methodological guidance, this flexibility can lead to heterogeneous modeling styles, reduced semantic consistency, and increased cognitive effort for model creation and interpretation. Therefore, the use of the Unified Modeling Language (UML) profile mechanism to introduce domain-specific extensions is essential to ensure more precise and intuitive modeling within specialized engineering contexts [11]. Empirical studies on MBSE adoption indicate that these challenges manifest clearly in industrial practice. In particular, unclear purpose and scope definition as well as insufficient method definition and extensibility are reported as major barriers. Industrial survey results report that approximately 88% of practitioners identify difficulties in defining the purpose and scope of MBSE application, while around 84% highlight challenges related to method definition, documentation, and extension [3]. In addition, the analysis of interdependencies between MBSE adoption challenges shows that complexity management is most strongly linked to method definition and extension, indicating that inadequate methodological specification directly amplifies perceived complexity, while well-defined and extensible methods can effectively mitigate it [3].

To address these challenges, this work investigates the following research questions:

• RQ1: How can the generic concepts of SysML be specified through the UML profile mechanism to develop a DSML that ensures high applicability for the conceptual design of production systems?
• RQ2: How can information and structures from established industrial standards be incorporated into a DSML to enable the systematic integration of relevant domain knowledge?

While several approaches aim to support the modeling of production systems, their practical applicability is often limited, as they lack systematic references to established standards or widely accepted domain models. As a result, such methods frequently remain methodologically sound but insufficiently anchored in domain-specific knowledge required for industrial application. Conversely, there exist approaches that attempt to integrate standards or established models into SysML; however, these efforts are often limited to isolated aspects and do not comprehensively address the heterogeneous and interdisciplinary nature of production systems. To answer these questions, a dedicated Domain-Specific Modeling Language (DSML) was developed, which builds upon the Software Platform Embedded Systems (SPES) framework [12] and extends it with additional constructs for production systems and their development. To further improve standardization of modeling practices and enhance domain integration, several supplementary DSMLs were integrated based on established industry standards. These extensions support the clear and uniform representation of domain knowledge and promote reusability across system models.

Beyond domain knowledge integration, methodical support is crucial for successful adoption in practice. Therefore, the proposed approach integrates user guidance and verification mechanisms into the modeling process, enabling both structured model creation and early error avoidance and detection [13].

The remainder of this paper is structured as follows:

Section 2 introduces some fundamentals on MBSE modeling languages and SPES. Section 3 presents the requirements defined for this approach, which are then compared with the current state-of-the-art in Section 4. Section 5 introduces the developed DSML and its integration with standardized modeling profiles. Section 6 presents a real-world application example from aircraft production, which is then evaluated in Section 7, with respect to the defined requirements and research questions. Finally, Section 9 summarizes the results and provides an outlook on future research directions.

2. Fundamentals

2.1. MBSE Modeling Languages

UML is a general-purpose modeling language that provides a standardized set of modeling constructs for representing structural, behavioral, and interaction aspects of systems [14]. It is designed to be broadly applicable across domains such as software engineering. While its flexibility enables a wide range of use cases, this generality often leads to overly abstract models that do not align well with the specific terminology or structure of a given domain.

In contrast, DSMLs are developed for a particular application domain or engineering discipline. They provide modeling concepts that directly reflect the domain, resulting in more intuitive, concise, and semantically rich models for domain experts [15,16]. DSMLs aim to close the abstraction gap between domain knowledge and model representation by incorporating concepts, relationships, and constraints that are meaningful within a specific domain.

To adapt UML to specific domains, the UML profile mechanism allows the introduction of domain-specific concepts by extending existing UML metaclasses through so-called stereotypes, tagged values, and constraints [17].

One of the most prominent examples of a UML-based extension is SysML, which is itself defined as a UML profile. SysML extends UML by introducing constructs relevant to systems engineering, such as requirements, blocks, and parametric diagrams [18]. This profile-based extension mechanism provides a powerful and standardized foundation for building modeling languages that remain compatible with UML tools and exchange formats, such as XMI [19].

While SysML already tailors UML toward systems engineering, it remains a relatively generic language that is not directly optimized for specific industrial domains. However, the same UML profile mechanism can be applied to develop even more specialized DSMLs that reflect the terminology, structure, and rules of a particular domain or organization. However, such DSMLs also entail a trade-off: while their higher specificity improves expressiveness and clarity within the target domain, it can reduce accessibility for users outside this domain and limit the reusability of models across different application contexts [20]. Moreover, domain-specific languages typically have a steeper learning curve due to their specialized concepts and notation, but once mastered, they can significantly increase modeling efficiency and domain relevance. To define such DSMLs and support tool-based modeling and verification, the following three components must be specified:

• Abstract syntax: Describes the structure of the language, including the allowed modeling constructs, their properties, and relationships. In UML-based DSMLs, the abstract syntax is defined by extending UML metaclasses through stereotypes and additional attributes.
• Concrete syntax: Specifies how modeling elements are represented visually or textually. This includes shapes, colors, icons, and labels used in diagrams. A well-designed concrete syntax improves the readability and recognizability of domain concepts, especially when visually distinguishing between different elements that stem from the same metaclass [14].
• Semantics: Defines the meaning of modeling constructs and how they relate to domain concepts. Semantics ensure that model elements are interpreted correctly, forming the basis for analysis and communication [15].

While the abstract and concrete syntax describe which elements may exist and how they appear, they do not by themselves ensure that a model is semantically valid. For example, the abstract syntax may define that an element of Stereotype A can be linked to an element of Stereotype B, but it cannot check the semantic rule that every instance of Stereotype A must be connected to at least one instance of Stereotype B. To specify and check such semantic rules and enable formal model verification, additional mechanisms are required.

A widely used solution for specifying such rules is the Object Constraint Language (OCL) [21]. OCL is a textual specification language designed to express invariants, preconditions, postconditions, and derived properties in UML and SysML models. OCL constraints can be attached to model elements to define logical conditions that must be satisfied for a model to be considered correct [22]. These constraints extend the semantics of a DSML beyond syntax, ensuring that models are not only syntactically correct, but also consistent, complete, and meaningful in their domain context.

In UML-based modeling tools, OCL constraints can be evaluated automatically, enabling early detection of modeling errors during model creation. This capability is essential for applying DSMLs in complex system engineering contexts, where formal correctness, traceability, and guidance are critical.

2.2. Software Platform Embedded Systems (SPES)

The SPES Framework was developed in the context of several research projects such as SPES2020 [12] and SPES XT [23]. It aims to provide modeling language-independent methods for designing embedded systems and software systems. The framework is based on a set of guiding principles that structure the system development process:

(i)

the clear distinction between problem and solution space, separating the analysis of system requirements from the design of the technical solution;

(ii)

explicit system decomposition to manage complexity, allowing both functional and structural refinement;

(iii)

continuous model-based documentation, ensuring that all engineering artifacts and their relationships are represented in a consistent modeling framework;

(iv)

a strict separation between logical and technical solutions, facilitating stable architectures that can be implemented using different technologies; and

(v)

the consideration of overarching system properties and interdisciplinary aspects that influence multiple engineering domains throughout all development phases.

As illustrated in Figure 1, SPES organizes the system description along two orthogonal dimensions: abstraction layers and viewpoints. Together, they define a two-dimensional modeling space that structures both the level of abstraction and the perspective on the system under development. The vertical axis represents the abstraction hierarchy, ranging from abstract conceptual models to detailed design artifacts. The horizontal axis is divided into four viewpoints, which are developed iteratively and interlinked by well-defined refinement relations [12].

The Requirements Viewpoint captures and refines stakeholder intentions into system-level requirements, forming the foundation for all subsequent viewpoints. It aims to establish a shared understanding of system goals and constraints, using models such as context, goal, or scenario diagrams.

The Functional Viewpoint defines the system’s intended behavior based on the specified requirements. It describes the system from a black-box perspective and then refines this view into white-box functions that reveal the internal realization and interactions between subfunctions.

Within the Logical Viewpoint, logical components are defined to implement the identified system functions. This viewpoint introduces a technology-independent logical architecture composed of interconnected logical subsystems and interfaces that exchange data in a flow-oriented manner. The logical architecture serves as an intermediate abstraction level that bridges the functional and technical views [12].

Finally, the refines the logical system into a technology-specific solution by allocating logical components to hardware and software elements. This viewpoint describes the concrete implementation architecture, including the interaction of technical components and the realization of software functions on the target platform.

Together, these viewpoints ensure a structured, traceable, and model-based system development process that maintains consistency across abstraction levels and engineering disciplines [12].

3. Requirements

In the context of MBSE, the applicability of modeling methods plays a critical role in ensuring the successful implementation of complex system models. High applicability ensures that models are not only understandable for engineers and domain experts but also practical to create, validate, and refine throughout the development process. Based on findings from the related MBSE literature, the following requirements (R1) to (R4) are derived to ensure the applicability of the modeling method presented in this work.

Comprehensibility (R1): A key aspect of applicability is the comprehensibility of the system model being created. Incomprehensibility has repeatedly been identified as a major barrier to the adoption of MBSE [24,25]. Models that are difficult to interpret due to ambiguous semantics, overly complex notations, or inconsistent representations hinder effective collaboration among stakeholders, particularly those without a modeling background [26]. For the successful adoption of MBSE, it is crucial that the involved engineers and domain experts can interpret the models clearly and unambiguously [3]. To operationalize comprehensibility, R1 is divided into three sub-requirements:

R1.1 Clear representation: All modeling elements must be clearly named, semantically defined, and visually distinguishable within the system model. A consistent naming convention and the use of domain-specific stereotypes ensure that each element represents a unique concept and can be intuitively interpreted by model users. Even when multiple elements are derived from the same metaclass, they should be differentiated through distinct stereotypes, colors, or symbols to avoid ambiguity and ensure clear semantics [27].

R1.2 Traceability: All elements within the model must be meaningfully related to one another to ensure a coherent overall system description. The modeling language should therefore provide mechanisms to define semantic relationships and dependencies between model elements across viewpoints and abstraction layers. This guarantees that no elements exist in isolation, but that each contributes to the overall traceability and logical consistency of the system model.

R1.3 Domain anchoring through standards: Referencing well-established modeling methods, reference models, or domain standards improves comprehensibility by providing consistent terminology, structures, and modeling conventions [28]. Integrating information from domain-specific standards ensures that models are intuitively interpretable for domain experts and aligned with established engineering practices.

Guidance (R2): Guiding users during the application of a MBSE method ensures its correct application and enhances its applicability. Providing clear instructions and systematic guidelines constitutes an essential form of user support throughout the entire modeling process [13]. This is particularly important for beginners and domain experts without prior modeling experience, as DSML often introduce specialized terminology and notations that can make their initial use challenging [20]. Comprehensive guidance mechanisms therefore help to mitigate the typically steeper learning curve of DSMLs by preventing common modeling errors and enabling users to apply the method correctly from the start [27]. By supporting users during model creation, an MBSE method not only facilitates accessibility and acceptance among non-expert users but also enhances model quality and efficiency in practical applications.

Early verification (R3): Ensuring verification of system models is critical to the successful application of MBSE methods. Created models must accurately represent the system, which necessitates continuous review and verification throughout the entire modeling process [29]. For DSMLs, formal verification plays an even more important role, as their higher degree of specialization can reduce model transferability and make consistency checks across domains more challenging [20]. Automated verification mechanisms therefore help to ensure semantic correctness by enforcing clear, formally defined modeling rules. Identifying modeling errors early significantly reduces the effort needed for their correction [30]. Tools for automated model review and verification can thus assist developers in detecting errors at an early stage and improving the overall correctness, consistency, and transferability of the resulting models.

Reduced modeling effort (R4): One of the key challenges in applying MBSE methods to complex production systems is the high modeling effort involved [18]. This challenge becomes even more pronounced when DSMLs are used, as their higher level of detail and specialization often increases the amount of information that must be modeled explicitly [20]. Redundancy arises in particular when the same aspects have to be represented across different viewpoints. While this is often necessary to maintain model consistency, it can significantly increase workload and engineering costs [26]. To address these issues, mechanisms are needed that enable the automated generation or derivation of model elements across viewpoints [27]. These automation mechanisms not only compensate for the increased modeling effort of DSMLs but also improve model consistency, maintainability, and overall efficiency.

4. State-of-the-Art

Various approaches exist for supporting the conceptual design of production systems using MBSE methods. In the following, selected approaches are presented and analyzed based on the requirements (R1)–(R4) defined in Section 3. This chapter focuses on how existing approaches implement these aspects within SysML- or UML-based modeling environments.

Starting in 2022, a SPES-specific DSML called SPES ML [31,32] has been available for the Magic System of Systems Architect (MSoSA) modeling tool by Dassault Systèmes. It supports the partial implementation of the SPES methodology, with a particular focus on the structural modeling of system components within the four SPES viewpoints. However, the plug-in has some limitations, as it does not fully account for several important aspects of the methodology. For instance, in the Requirements Viewpoint, only requirement elements can be modeled, while related constructs such as scenarios, system context descriptions, or goal models are omitted. Similarly, the Functional Viewpoint supports only structural descriptions of functions, without the ability to model temporal sequences or parallel and alternative flows, an essential capability for representing production processes. Moreover, the semantics defined by SPES ML remain relatively abstract, which limits the comprehensibility of the resulting models for users without prior modeling experience. As a result, model comprehensibility is only partially fulfilled (R1). Regarding guidance of users, it supports, in applying the methodology defined by the SPES Framework and guides model creation by defining which stereotypes can be linked with each other and by providing dedicated diagram types for each SPES layer (R2). Early verification is only partially fulfilled, as some general and Technical Viewpoint-specific modeling rules are documented only in natural language and are not formally implemented within the SPES ML tool (R3). The SPES ML approach does not offer the option of creating elements automatically or deriving them from existing model content. Therefore, R4, which addresses the reduction of modeling effort through automation, is not fulfilled.

Building on the concepts and methods developed in the SPES context, Hayward et al. propose a function-centered modeling approach for collaborative Cyber-Physical-Systems (CPS), implemented using SysML and UML profiles [33,34]. The approach allows for a solution-independent specification of system goals, functional dependencies, roles of subsystems within a system-of-systems, and interactions between CPS during collaboration, without detailing physical resources or interfaces. To support the modeling approach, a UML profile was developed that incorporates selected elements of the SPES vocabulary, although not all aspects of the original framework are covered. Therefore, this approach is not suitable for the complete description of a production system. R1 regarding model comprehensibility is therefore partially addressed. R2 is also partially fulfilled, as the methodology includes a clearly defined sequence for modeling objectives, functions, and system states, which provides structured guidance throughout the modeling process. However, early verification (R3) and reducing modeling effort (R4) are not fulfilled, as no formal verification rules or automation mechanisms are implemented.

The work by Binder et al. [35,36] addresses the modeling and engineering of production systems in the context of Industry 4.0. The Reference Architecture Model Industry 4.0 (RAMI 4.0) provides the methodological framework for the systematic description and development of industrial systems. A central aspect of the work is the development of a model-driven engineering approach that combines MBSE methods with RAMI 4.0. For this purpose, the so-called RAMI Toolbox is developed, a domain-specific modeling environment based on a DSML. This DSML represents the different layers and levels of the RAMI 4.0 model using a UML profile and diagrams [35]. R1 regarding model comprehensibility is therefore partially addressed. In terms of user guidance, the toolbox provides only indirect support through a structured architecture and references to established models, as well as a GUI. Interactive or explicit user guidance, such as mechanisms to exclude invalid element combinations in the model or error messages indicating incorrect modeling, is not provided (R2). There are no mechanisms for early model verification, such as the use of formally defined rules (R3). Further tools enable the exchange of model elements between the RAMI Toolbox and AutomationML, another data format and modeling language for the description of plant engineering information [36]. In addition, preconfigured templates are available. However, mechanisms for the automatic generation of new elements from existing SysML model data are missing. Therefore, R4 is only partially fulfilled.

The SYSMOD framework [37] is structured around a sequence of modeling steps, beginning with the definition of abstract system concepts and goals. These steps are followed by the elicitation of requirements, the description of the system context, and the modeling of use cases. In subsequent phases, the system architecture is incrementally developed from a high-level view down to a detailed specification. To support this modeling workflow, SYSMOD provides a UML profile that introduces additional stereotypes for common system components. These components can be categorized, for example, as software, hardware, or mechatronic elements. However, the framework places relatively little emphasis on the modeling of system functions, which can be limiting in domains such as production system development. To address this, SYSMOD recommends the use of the Functional Architecture for Systems (FAS) method [38], in which functional groups are derived from use case activities. These groups are then connected using SysML Internal Block Diagrams, taking into account both functional and non-functional requirements. While the method enables functional decomposition, the resulting diagrams are often complex. From the perspective of applicability, SYSMOD partially supports model comprehensibility by structuring the development process and offering stereotypes for common system elements. However, it does not reference established domain models or industry standards. Comprehensibility is therefore only partially fulfilled (R1). Guidance is primarily offered in textual form, such as the official SYSMOD documentation, but no tool-integrated support or interactive assistance is available. R2 is therefore also partially addressed. The framework lacks mechanisms for formal model verification, as no modeling rules or automated verification features are included. Similarly, no tools or automation features are provided to reduce the modeling effort. Therefore early verification (R3) and reducing modeling effort (R4) are not fulfilled.

Another approach is the MecPro2 project, which presents a concept for the integrated planning and development of cybertronic products and production systems [39]. To address the heterogeneous needs of different engineering disciplines, the project employs a combination of SysML profiles and ontologies. These are used to represent multiple viewpoints and tailor the modeling environment to discipline-specific requirements [40]. The modeling method draws conceptually on the SPES framework, particularly with respect to architecture modeling and viewpoint structuring. In addition, standard SysML is retained for certain general modeling tasks, resulting in a hybrid modeling approach. This contributes to a degree of model comprehensibility (R1). Although the SysML profile does not implement strict constraints, it provides clearly documented modeling recommendations for specific process roles and diagram types. Modeling is organized through a sequence of predefined diagrams that must be created step by step, but the modeling language itself does not include integrated guidance mechanisms. This contributes to a partially guidance to users (R2). A central element of the approach is the use of an ontology, which formally captures domain knowledge and semantically links information across engineering disciplines. This supports consistency across viewpoints but does not enable formal rule checking or interactive verification. Therefore, no internal model verification mechanisms are implemented, meaning that early verification (R3) is not addressed. A structured library concept, including templates, catalogs, and corresponding stereotypes, improves the reusability of modeling elements. While no automation mechanisms are provided, this concept partially addresses R4 by reducing redundant modeling work.

The MagicGrid Framework [41] was developed by No Magic Inc., a software company providing SysML tools. The SysML-based framework consists of three domains: a Problem Domain, a Solution Domain, and an Implementation Domain. The Problem Domain is further divided into a Black Box and a White Box view. Within both the Problem and Solution Domains, the system is described along five predefined pillars: Requirements, Structure, Behavior, Parameters, and Safety and Reliability. Each of these pillars is modeled using dedicated diagram types to capture the respective aspect of the system. In the Solution Domain, the system is then decomposed using the same five pillars until the desired level of granularity is achieved. Building on this structure, Aleksandraviciene et al. [42] introduced a SysML profile that formalizes the individual elements of the MagicGrid Framework. However, because the profile does not reference any established domain models or standards, R1 is only partially fulfilled. With regard to user guidance, the framework provides a detailed and well-structured modeling procedure in the form of documentation, supporting a consistent modeling flow. Nevertheless, no interactive assistance or tool-integrated support is available to prevent modeling errors or guide users during model creation. Therefore, this requirement is also only partially fulfilled (R2). The framework does not include rules or mechanisms for early model verification, meaning that R3 is not addressed. Similarly, it lacks automation features for generating or deriving model content, and thus does not support a reduction in modeling effort as defined by R4.

All previously analyzed frameworks for system or production system development address R3 and R4 only partially at most. Consequently, additional approaches were considered that effectively address these requirements, even though they were not developed for complete system development or for fulfilling R1 and R2.

Zhong et al. [43] presents a concept that uses natural language processing to automatically extract SysML Block Definition Diagrams, Internal Block Diagrams, and Requirement Diagrams from natural language texts. The author reports accuracies of up to 90 percent for simple models. However, this applies only to basic examples. Complex relationships cannot be reliably represented.

Kulkarni et al. [44] present an approach based on LLMs for the automated generation of SysML models. Through fine-tuning and prompt engineering, they achieve good results for the creation of SysML Block Definition Diagrams and Requirement Diagrams, but again, only for simple examples.

The verification of SysML models has also been addressed in prior work. Luth et al. [45] introduce the concept of a self-verifying system, using SysML for system modeling and OCL for the specification of rules. Other approaches demonstrate that OCL is highly suitable for the verification of UML/SysML profiles, as shown for example by Berkenkotter, who applied OCL to verify a railway domain profile [46], and by Dragomir, who implemented OCL for a UML/SysML profile in the domain of timed safety requirements [47].

Feldmann et al. [29] combine SysML with semantic technologies to enable a systematic analysis of change impacts in complex production systems. The SysML model is transformed into a knowledge graph, which is then queried to assess the compatibility of model elements.

Przigoda et al. [48] apply formal verification techniques to UML models. The models, including OCL-based pre- and postconditions, are transformed into a logical representation that can be analyzed using automated solvers. The OCL preconditions, postconditions, and invariants are encoded as logical constraints. An SMT solver checks whether parallel operations can be executed while satisfying all constraints.

The aforementioned approaches have now been explained and evaluated in detail.

Table 1. Comparison of MBSE Literature.

Reference	R1 Comprehensibility	R2 Guidance	R3 Early Verification	R4 Reduced Modeling Effort
SPES ML [31,32]	◗	●	◗	❍
Hayward et al. [33,34]	◗	◗	❍	❍
RAMI 4.0 Toolbox [35,36]	◗	◗	❍	◗
SYSMOD/FAS [37,38]	◗	◗	❍	❍
MecPro2 [39,40]	◗	◗	❍	◗
MagicGrid Framework [41,42]	◗	◗	❍	❍
Zhong et al. [43]	❍	❍	❍	●
Kulkarni al. [44]	❍	❍	❍	●
OCL based verification [45,46,47]	❍	❍	●	❍
OWL based verification [29]	❍	❍	●	❍
OCL + SMT based verification [48]	❍	❍	●	❍

Legend: ● = fully supported; ◗ = partially supported; ❍ = not supported.

provides a summary of the evaluation based on the specified requirements.

Most of the analyzed approaches develop UML or SysML profiles to adapt generic modeling constructs to the specific requirements of their respective domains. This generally improves semantic clarity by aligning modeling elements with domain-specific terminology and reference models. However, only a few methods provide integrated support mechanisms that ensure methodological consistency during model creation. Although several works demonstrate the suitability of OCL for verifying UML/SysML profiles, existing DSML approaches rarely include such formalized rule definitions or automation features. In summary, while existing methods make valuable contributions to domain-specific modeling, they typically lack the integrated combination of guidance, formal verification, and modeling automation.

With respect to the research questions defined in Section 1, the current state-of-the-art only partially addresses RQ1, as existing DSMLs provide domain-oriented modeling capabilities but often remain too generic or lack practical applicability for the conceptual design of production systems. RQ2 is largely unaddressed, since the systematic incorporation of information from industrial standards and the consistent integration of domain knowledge across modeling languages have not yet been demonstrated in existing approaches. Therefore, there remains a clear need for an approach that unifies these aspects within a cohesive DSML framework.

5. Concept

The proposed concept addresses the research questions defined in Section 1. The design of the proposed DSML is guided by a set of explicit design trade-offs. These trade-offs reflect deliberate decisions made to balance methodological rigor, usability, and practical applicability in early engineering phases.

• Specificity vs. Reusability

The design of the proposed DSML reflects a deliberate trade-off between domain specificity and reusability. The introduced stereotypes are specifically tailored to the modeling of production systems, as discussed in Section 5.2. Within this defined application domain, the stereotypes can be reused across different use cases and projects. This level of specification is necessary to explicitly capture domain-specific concepts and to enable the definition of formal rules and constraints. While this reduces general-purpose reusability, it provides clearer semantics and supports systematic verification within the targeted domain.

• Automation vs. User Control

The approach aims to support automation wherever feasible; however, automation is intentionally limited. Model elements are derived rule-based from existing knowledge and previously defined elements, rather than generating new domain knowledge. Consequently, manual input remains necessary at various stages of the modeling process. This design choice is intentional and aligned with the objectives of MBSE, particularly early error detection and controlled model evolution.

• Restricted Modeling vs. Modeling Freedom

A conscious decision was made to restrict modeling freedom in favor of guided and consistent model creation. This restriction primarily supports users who are not modeling experts by limiting the use of certain elements to their intended purposes. While not all modeling scenarios can be expressed exclusively using the proposed profile, the DSML can be seamlessly combined with standard SysML elements to preserve flexibility.

• Early Abstraction vs. Detailed Engineering

The proposed approach is explicitly designed for early engineering phases, in which detailed artifacts such as 3D models or simulation models are typically not yet available. The focus lies on the incremental development of a production system model covering requirements, structure, behavior, and interfaces. Detailed implementation aspects required in later engineering phases are intentionally not addressed.

• Tool Independence vs. Tool Optimization

The following DSML is defined using standard UML/SysML profile and OCL mechanisms and is therefore conceptually independent of a specific modeling tool. Nevertheless, the current implementation including diagram customization, automation scripts, and interactive guidance has been realized in a specific SysML environment. While similar mechanisms are available in other tools, the portability of the implementation has not yet been systematically evaluated and constitutes a relevant topic for future work. These trade-offs provide the conceptual rationale for the DSML design decisions described in the following sections.

Building upon the identified challenges and requirements (R1–R4), it combines structural, methodological, and integrative elements to enable a domain-specific yet standardized modeling approach for production systems:

Section 5.1 addresses RQ1 by specifying the generic concepts of SysML through the UML profile mechanism. The resulting DSML is tailored to the conceptual design of production systems and aims to ensure high applicability by defining clear modeling constructs, viewpoints, and verification mechanisms.

Section 5.2 contributes to the first part of RQ2 by incorporating information and structures from established industrial standards into the DSML. These supplementary DSMLs cover specific sub-aspects of the production system model and refine, in particular, the abstract stereotypes introduced in Section 5.1.

Finally, Section 5.3 addresses the second part of RQ2 by describing how the various DSMLs are systematically integrated into a unified modeling framework. This alignment layer enables consistent and comprehensive system modeling and ensures the coherent representation of relevant domain knowledge across DSML boundaries.

5.1. DSML for Production Systems

The developed DSML for describing production systems is based on the SPES framework. However, since no suitable existing approach was found to fully implement this methodology, a dedicated modeling approach was developed. In addition, it was extended with aspects specific to production systems. The DSML consists of the following components:

• UML/SysML profile: A dedicated profile extends UML and SysML through domain-specific stereotypes that provide the semantic foundation for modeling production systems. Each stereotype fulfills a specific modeling function and contributes distinct information to the system model. Some stereotypes introduce essential domain concepts such as products, processes, resources, or system goals that are required to represent the structure and behavior of production systems. Others enable the derivation of new information or the linkage of related model elements across viewpoints, thereby supporting traceability throughout the engineering process. In addition, several stereotypes are explicitly designed to facilitate model verification by enforcing modeling rules and dependencies between elements. Due to the scope of this paper, not all stereotypes can be discussed in detail; an overview of the most important ones is provided in Appendix A.
• New diagram types: The DSML introduces a set of custom diagram types derived from established UML diagram classes. These diagrams were specifically modified to restrict their applicability to defined modeling purposes rather than allowing generic usage. Each diagram type is therefore associated with a particular modeling viewpoint and supports only those stereotypes that are intended for that specific context. This ensures that models created with the DSML remain consistent, domain-specific, and compliant with the underlying methodology, while preventing the creation of invalid or semantically ambiguous structures. Appendix B lists all introduced diagram types and their respective roles within the modeling process.
• Rule-based model verification: The DSML integrates formal verification mechanisms based on the Object Constraint Language (OCL) to ensure methodological consistency and correctness of the created models. Unlike purely textual modeling guidelines, these rules are directly implemented within the modeling environment and automatically evaluated during model creation. Each rule formally expresses domain- or method-specific constraints, such as valid relationships between stereotypes, mandatory properties, or structural completeness requirements within specific viewpoints. When a violation occurs, the user receives an immediate, descriptive error message that identifies the affected element and the nature of the inconsistency. This approach not only supports early detection of modeling errors but also enforces compliance with the defined modeling methodology and facilitates traceability across different abstraction levels. Due to the scope of this paper, only selected exemplary rules are presented in the following sections; a comprehensive list of all verification rules and corresponding error messages is provided in Appendix C.
• Automation scripts: To reduce manual modeling effort and improve methodological consistency, the DSML incorporates a set of automation scripts that perform repetitive modeling tasks automatically. These scripts were developed to generate model elements, submodels, or relationships based on predefined rules and existing model content. By reusing information already available within the model such as goals, scenarios, or system capabilities the scripts ensure coherence between related viewpoints and minimize redundant manual input. In addition to reducing modeling time, the automated generation of elements helps to prevent user errors and ensures that derived model contents follow the same structural and semantic conventions as manually created elements. An overview of the implemented scripts and their respective purposes is provided in Appendix D.

For readability, we use consistent typographic styles for recurring modeling elements across the remainder of the paper. The notation is summarized in

Table 2. Typographic Conventions Used in This Paper.

Object	Explanation	Notation
Viewpoint	Represents a specific perspective (viewpoint) on the system model to structure concerns and content.	[Logical Viewpoint]
Stereotype	A new defined domain-specific extension of a UML or SysML stereotype defined by the DSML.	«BlackboxFunction»
Metaclass	A generic modeling construct from which stereotypes are derived.	Class
Property	A new defined attribute or relationship that adds semantics to a stereotype.	definesGoal
Diagram	A new defined custom, domain-specific diagram type defined by the DSML.	|System Context Definition Diagram|

.

The developed DSML is based on the four viewpoints established in the SPES methodology: [Requirements Viewpoint], [Functional Viewpoint], [Logical Viewpoint] and [Technical Viewpoint]. Accordingly, it is referred to as the RFLT DSML throughout the remainder of this paper. For each of these viewpoints, a corresponding stereotype of the Package metaclass was defined. These stereotypes serve to clearly assign modeling elements and diagrams to their respective viewpoints and to enable structured organization within the model.

Further stereotypes were introduced to define structuring nested Packages within each viewpoint. These stereotypes specify which types of modeling elements are permitted in which parts of the model. For example, «BlackboxFunction» elements may only be modeled within the «BlackboxPerspectivePackage» of the [Functional Viewpoint], while «System [T]» elements are restricted to the «TechnicalArchitecturePackage» of the [Technical Viewpoint].

The generation of one or more viewpoints including all associated nested Packages is supported by automation scripts. These scripts can be used either to initialize a complete model template or to decompose individual viewpoints at a later stage.

This paper focuses on the description of the DSML itself. A detailed explanation of the modeling workflow for individual elements can be found in [49].

5.1.1. Requirements Viewpoint

The Requirements Viewpoint is introduced to capture the problem space of the production system independently of its technical realization. The stereotypes defined in this viewpoint focus on goals, context interactions, and scenarios, ensuring that stakeholder intentions and environmental constraints are explicitly represented. This separation prevents premature design decisions and supports early validation and traceability across subsequent viewpoints.

Goals: To systematically capture, classify, and link all system goals derived within the [Requirements Viewpoint], the |Goal Diagram| is introduced. It serves as a connecting diagram between the different «Goal» elements and supports both verification and validation of the production system. For this purpose, two specific stereotypes have been defined: «Hardgoal» and «Softgoal». The «Hardgoal» stereotype describes requirements whose complete fulfillment is strictly necessary to ensure the system’s suitability. They form the basis for system verification. A typical example is the requirement that a production system must be able to perform drillings with a certain diameter. If this goal is not achieved, the system is unsuitable for the intended application.

In contrast, «Softgoal» elements represent objectives whose fulfillment is desirable but not strictly required. They often address qualitative or optimization-oriented aspects of system performance and therefore allow for tolerances in their achievement. One example is the targeted cycle time of a production system. Although this metric is quantitatively measurable, it is treated as a soft goal, since different design alternatives can fulfill it to varying degrees rather than through a single strict threshold. During system development, such «Softgoal» elements serve as evaluation criteria for comparing and validating alternative solution concepts.

Goals may influence each other positively or negatively. Such dependencies are modeled using the «influence» stereotype, which is further divided into the stereotypes «positiveInfluence» and «negativeInfluence». Modeling such goal interdependencies supports conflict analysis and trade-off evaluation during requirements engineering.

Stakeholders: To model stakeholders, the |Stakeholder Definition Diagram| is introduced. In this diagram, stakeholders are modeled using either the «InternalStakeholder» or «ExternalStakeholder» stereotype, both derived from the Class metaclass.

«ExternalStakeholder» elements do not have direct access to the system. They define external constraints and requirements that the system must comply with, such as costs, weight, or environmental regulations.

To establish a semantic link between stakeholders and their defined goals, the property definesGoal is introduced. This property allows stakeholders to be connected to their respective «Hardgoal» or «Softgoal» elements.

«ExternalStakeholders» must define at least one goal in order to justify their relevance for the production system. This rule is formally validated using OCL (see Listing 1).

Listing 1: OCL Constraint for External Stakeholders.

1 context ExternalStakeholder inv ExStakeholderDefinesGoal: 2  self.definesGoal->exists(g | g.oclIsKindOf(Hardgoal) or g.oclIsKindOf(Softgoal))

«InternalStakeholder» elements represent actors who are directly involved in the planning, implementation, and operation of the production system. They form a crucial foundation for defining subsequent system functionalities and interfaces, as their roles and responsibilities determine how the system interacts with human and organizational resources. Accordingly, «InternalStakeholder» elements provide the contextual basis for identifying user-related requirements, operational constraints, and functional needs. For «InternalStakeholder» elements, it is required that they are either part of the «ResourceContext» or define at least one «Scenario» from which system goals can subsequently be derived.

System Context: The «SystemContext» stereotype defines the interaction of the system with its environment. To structure the external influences on the system in a standardized way, the modeling approach adopts the PPR principle, which distinguishes between the three fundamental context domains. This structure is commonly used in manufacturing to describe what is produced (Product), how it is produced (Process), and with which technical means it is produced (Resource) [7]. These three types of context must be explicitly represented in the model to ensure completeness and traceability. For this purpose, the |System Context Definition Diagram| is created. Within this diagram, at least one element of each of the following stereotypes must be modeled: «SystemContext», «ProductContext», «ProcessContext», «ResourceContext» and «System [R]». The overarching «SystemContext» stereotype represents the complete external context of the system and groups the three PPR context types. To explicitly link these context elements, a derived property named hasPPRContext was introduced. In SysML, derived properties represent computed or inferred relationships that are not stored directly in the model but are obtained from other model elements or associations. In this case, hasPPRContext dynamically references all context elements of type «ProductContext», «ProcessContext», and «ResourceContext» associated with the «SystemContext». The OCL rule shown in Listing 2 checks that the «SystemContext» element is associated with at least one element of each of the other context stereotypes.

Listing 2: OCL Constraint for PPR Context Validation.

1 context SystemContext inv SystemContexthasPPRContext: 2  self.hasPPRContext->exists(pc | pc.oclIsKindOf(ProductContext)) and 3  self.hasPPRContext->exists(rc | rc.oclIsKindOf(ResourceContext)) and 4  self.hasPPRContext->exists(proc | proc.oclIsKindOf(ProcessContext))

In turn, the three context elements («ProductContext», «ProcessContext», «ResourceContext») are each connected to the «System [R]» stereotype via a directed composition. Since this overarching diagram and its modeled elements always follow the same structure, an automation script was developed to generate them automatically.

System [R]: The «System [R]» and «Subsystem[R]» stereotypes were developed for modeling systems and subsystems. Although SysML already provides the «System» stereotype, it is not sufficient to consistently represent systems across multiple viewpoints. In the [Requirements Viewpoint], the system element is associated with the «SystemContext», a relationship that is also formally validated. In contrast, within the [Logical Viewpoint] and [Technical Viewpoint], the system or subsystem element is used to model the structural components and interfaces of the system under development. For this reason, a separate stereotype is defined for each of the three viewpoints to describe the respective system. For the «SystemContext», this stereotype is called «System [R]» and is derived from the Class metaclass.

Product Context: Within the «ProductContext» derived from metaclass Class, the product to be manufactured by the production system is described. This includes the modeling of all required components, such as individual parts, assemblies, and connecting elements that are necessary for the production of the final product. The structure of the product is represented using the |Product Context Definition Diagram|. This diagram utilizes the «ProductContextPart» stereotype, which is derived from the metaclasses PartProperty. Establishing a detailed product context is essential for traceability between the product and the corresponding manufacturing processes, as product elements can later be linked to the process steps and technical resources required for their realization. If the production system is capable of manufacturing multiple product types, a separate |Product Context Definition Diagram| must be created for each product type to ensure consistent traceability and avoid semantic ambiguity across product variants.

Process Context: The «ProcessContext» describes those processes that influence the production system to be developed but are not executed by the system itself. This includes, for example, preceding, subsequent, or parallel processes. These processes are modeled in the |Process Context Definition Diagram| using the «ProcessContextPart» stereotype.

Resource Context: Within the «ResourceContext» stereotype, the |Resource Context Definition Diagram| is used to model all resources and their interfaces that directly influence the system to be developed. These include, in particular, system interfaces such as power connections available at the intended installation site, as well as interfaces defined by «InternalStakeholder» elements, such as the plant operator. To model these aspects, either elements of the «ResourceContextPart» stereotype or previously created «InternalStakeholder» elements are used.

Context Interaction: The «ContextInteraction» stereotype is used to connect all context elements with the «System [R]» element. It has the Connector and DirectedRelationship metaclasses, which allows a single modeling element to represent both the connection itself and its direction, instead of requiring two separate elements as in standard SysML. The stereotype is further subdivided into «ContextInteractionInput», «ContextInteractionOutput», and «ContextInteractionBidirectional».

These interactions play an important methodological role, as they allow deriving system goals directly from the modeled environment. By explicitly capturing how the system exchanges information, energy, or materials with its context, relevant requirements can be identified in a traceable and systematic manner. Without such interactions, goals would have to be defined purely intuitively, increasing the risk of overlooking important environmental constraints. To formalize this linkage, goals can be derived from every interaction between an element of the «System [R]» or «Subsystem[R]» stereotype and the associated context elements. These goals are modeled directly within the corresponding diagrams and are represented through a «DerivedFromContext» relationship between the interaction and the requirement. This process is supported by the automation script “GoalsDerivedFromResourceContextInteraction”, which scans the entire model and creates a «Goal» element for each «ContextInteraction», using the same name as the corresponding interaction. Additionally, a «DerivedFromContext» stereotype is applied to establish a semantic link between the two elements.

Scenario: To identify functional system goals, the «Scenario» stereotype is applied. It supports a structured description of use cases that the production system under development must fulfill. Modeling is performed in the |Scenario Diagram|, in which «Scenario», and «InternalStakeholder» elements, and their relationships, are formalized.

The central modeling element is the «Scenario» stereotype, which is derived from the UseCase metaclass and describes concrete system usages, such as a production or maintenance scenario. «Scenario» elements are always modeled in the context of a «System [R]» element, which serves as the main reference. To structure complex scenarios, the «hasSubscenario» stereotype is used, which enables hierarchical decomposition.

Each «Scenario» element must be associated with at least one «InternalStakeholder». This is implemented via the «defineScenario» property, which establishes a semantic relationship between stakeholders and the scenarios they initiate or are responsible for.

At least one goal is derived from each «Scenario», which is further specified in the [Functional Viewpoint]. These goals form the conceptual basis for the development of the system functions. In summary, the Requirements Viewpoint provides a structured entry point for early system engineering by explicitly modeling and linking context, goals, and scenarios. This explicit structuring supports early traceability and reduces ambiguity in requirement interpretation across disciplines, thereby establishing a consistent foundation for subsequent functional and architectural modeling activities.

5.1.2. Functional Viewpoint

The Functional Viewpoint is introduced to describe what the production system is intended to do, independently of how these functions are technically realized. The stereotypes defined in this viewpoint focus on system functions, capabilities, and their decomposition, enabling a clear separation between functional intent and structural implementation. This abstraction supports systematic refinement from black-box to white-box functions and facilitates traceability from requirements to later architectural decisions, while avoiding early commitment to specific technical solutions.

Blackbox Function: The «BlackboxFunction» stereotype is used to describe the functional structure of the system, i.e., which functions and sub-functions are required to achieve the defined system «Goal» elements that were derived from the «Scenario» elements in the previous step. These goals are transferred as «BlackboxFunction» elements in the designated |Blackbox Perspective Diagram|, where each function is automatically generated by the dedicated automation script “DerivedBlackboxFunctionFromScenario” based on the goal specification.

Since this initially represents only a structural view, the «BlackboxFunction» stereotype is derived from the Class metaclass. «BlackboxFunction» elements can be further decomposed. For functions that can be subdivided, additional «BlackboxFunction» elements are defined. As soon as a function cannot be further decomposed, the «AtomicBlackboxFunction» stereotype is used, which is likewise derived from Class.

For each «AtomicBlackboxFunction», exactly one «AtomicCapability» must be defined. This constraint is checked by the OCL rule specified in Listing 3. An «AtomicCapability» describes a non-decomposable capability required to implement the corresponding «AtomicBlackboxFunction». The link between both elements is established via the requiresCapability property. A «BlackboxFunction» inherits all «AtomicCapability» elements from its subordinate elements. To implement this, a derivedProperty is defined, which references all requiresCapability properties of the child elements and consolidates them into the requiredCombinedCapability property.

Listing 3: OCL Constraint for Atomic Blackbox Function.

1 context AtomicBlackboxFunction inv AtomicBlackboxRequiresAtomicCapability: 2  self.RequiresAtomicCapability->size() = 1 and 3 self.RequiresAtomicCapability->    forAll(ac | ac.oclIsKindOf(AtomicCapability))

Since a «BlackboxFunction» must consist of at least two subordinate functions, this property always contains at least two elements. This is verified by the rule specified in Listing 4.

Listing 4: OCL Constraint for Blackbox Function.

1 context BlackboxFunction inv BlackboxFunctionRequiresCombinedCapability: 2  self.RequiredCombinedCapability->size() >= 2 and 3  self.RequiredCombinedCapability->    forAll(ac | ac.oclIsKindOf(Capability))

Whitebox Function: For each instance of «BlackboxFunction» a «WhiteboxFunction» (and equivalent for each «AtomicBlackboxFunction» an «AtomicWhiteboxFunction»), must be created. This is done automatically using the dedicated script “Whitebox4Blackbox”, which is explained in detail and presented as pseudocode in Appendix E.

The «WhiteboxFunction» and «AtomicWhiteboxFunction» stereotypes represent the functional behavior and are modeled sequentially within the |Whitebox Perspective Diagram|. They serve to describe the internal logic of a function in detail and to define its interfaces to other functions. Both stereotypes are derived from the Activity and CallBehaviorAction metaclasses.

«WhiteboxFunction» elements are linked to logical components based on their «Capability». To ensure that these capabilities are consistently available within the functional model, each «WhiteboxFunction» includes a derivedProperty that automatically references the corresponding «Capability» elements of its associated «BlackboxFunction». Furthermore, it is ensured that each «WhiteboxFunction» is implemented by at least one «System [L]», which is described in more detail in the following section. This relationship is formally verified using the OCL constraint presented in Listing 5.

Listing 5: OCL Constraint for Whitebox Function Allocation to a Logical System.

1 context WhiteboxFunction inv WhiteboxToLogicalSubsystem: 2 self.functionRealization->    exists(fr | fr.target.oclIsKindOf(LogicalSystem))

The assignment follows an n:m relationship: a «System [L]» may implement multiple «WhiteboxFunctions», if it provides the corresponding «Capability» elements. Each «WhiteboxFunction» requires specific inputs and produces defined outputs. To model these inputs and outputs, additional stereotypes are used: «FunctionalInterface», derived from the ObjectNode metaclass, and «FunctionalInterfaceType», derived from the Class metaclass, which specify the interface, for example, whether data or physical products are exchanged. In summary, the Functional Viewpoint enables a consistent and systematic decomposition from system goals to blackbox and whitebox functions. This structured refinement forms a stable basis for downstream capability and architecture modeling and ensures that functional intent remains explicitly traceable throughout subsequent engineering phases.

5.1.3. Logical Viewpoint

The Logical Viewpoint serves as an intermediate abstraction layer between functional intent and technical realization. The stereotypes defined in this viewpoint describe logical system components and their interactions, allowing functions and capabilities to be allocated without binding them to concrete physical resources. This separation supports architectural reasoning, comparison of alternative system structures, and early consistency checking, while preserving flexibility for subsequent technical design decisions.

Logical (Sub)System: To describe the logical architecture, the stereotypes «System [L]» and «Subsystem[L]» are introduced. Both are derived from the Class metaclass. While «System [L]» represents an abstract, decomposable, technology-independent unit, «Subsystem[L]» elements describe fine-grained, non-decomposable components. A recursive decomposition is enforced, requiring each «System [L]» to be divided into at least two subordinate elements, which may be either «System [L]», «Subsystem[L]», or a combination of both. These elements are defined within the |Logical System Definition Diagram|, which provides a high-level structural view of the logical system hierarchy.

The [Logical Viewpoint] is technology independent and focuses on the realization of the capabilities defined in the [Functional Viewpoint]. For this purpose, «Subsystem[L]» elements are linked to «Capability» elements via the providesCapability property. These describe the functional characteristics provided by the respective subsystem. A derivedProperty at the «System [L]» level automatically aggregates all «Capability» elements of its subordinate «System [L]» or «Subsystem[L]» elements.

The connection between «WhiteboxFunction» elements and «System [L]» elements is established using the FunctionRealization property. An OCL rule (see Listing 6) checks that only «WhiteboxFunction» elements and «System [L]» elements referencing the same «Capability» element can be linked.

Listing 6: OCL Constraint for Capability Matching Between Whitebox Function and Logical System.

1 context LogicalSystem inv MatchingCapability: 2  self.provideCapability.oclIsKindOf(Capability) and 3  self.functionalRealization.requiredCapability.oclIsKindOf(Capability) and 4  self.provideCapability =     self.functionalRealization.requiredCapability

Logical Interfaces: To model the internal system structure, the stereotypes «LogicalInterface» derived from ProxyPort and «LogicalInterfaceType» derived from InterfaceBlock are used. The first describes abstract interfaces of subsystems, while the second specifies the type and direction of the interaction. Both are visualized in the |Internal Logical System Structure Diagram|, where «LogicalSystemPart» and «LogicalSubsystemPart» instances are shown together with their connecting «LogicalInterface» elements. To ensure semantic consistency, only «LogicalInterface» elements that reference the same «LogicalInterfaceType» may be connected. The typing allows classification into «EnergyInterfaces», «MechanicalInterfaces», and «CommunicationInterfaces» without defining concrete technologies.

Logical Behavior: The behavior of «System [L]» and «Subsystem[L]» elements are described using state machines. For this purpose, the |Logical Behavior Diagram| is introduced. Within this diagram, «LogicalStateMachine» elements can be created, which are derived from the StateMachine metaclass. Each «System [L]» may contain one or more state machines that allow modeling of internal processes and reactions to events.

Furthermore, a distinction is made between «ActiveState» and «PassiveState», both derived from the State metaclass. In active states, «WhiteboxFunction» elements are executed, whereas passive states are restricted such that only signal forwarding is possible.

In summary, the Logical Viewpoint bridges functional intent and technical realization by introducing a coherent structure of logical subsystems, interfaces, and capabilities. This intermediate abstraction enables early reasoning about system decomposition, interface responsibilities, and allocation decisions without committing to concrete technologies, thereby reducing premature design decisions and supporting controlled system evolution.

5.1.4. Technical Viewpoint

The Technical Viewpoint is introduced to represent the concrete realization of the production system in terms of technical resources, interfaces, and implementation-relevant constraints. The stereotypes defined in this viewpoint focus on physical components, technical interfaces, and their interconnections, enabling a precise description of the system architecture. By explicitly separating technical realization from functional and logical concerns, the approach supports controlled refinement, traceability of design decisions, and consistency verification across abstraction levels.

Technical (Sub)System In the [Technical Viewpoint], the previously defined, technology-independent architecture from the [Logical Viewpoint] is concretized. For this purpose, two new stereotypes are introduced: «System [T]» and «Subsystem[T]», both derived from the Class metaclass. While the «System [T]» represents a composed system consisting of multiple components, «Subsystem[T]» elements model concrete individual components such as controllers, sensors, or actuators. These stereotypes are used to define the technical structure within the |Technical System Definition Diagram|.

To reflect concrete technologies, the [Technical Viewpoint] also distinguishes between hardware and software aspects. Many logical components can only be implemented through a combination of hardware and software. Therefore, the additional stereotype «SoftwareComponent», also derived from Class, is introduced. «SoftwareComponent» elements are always part of a «System [T]» or «Subsystem[T]», but not the other way around, i.e., a «Subsystem[T]» cannot be part of a «SoftwareComponent». This hierarchy ensures that software is consistently embedded within a physical context.

Each «Subsystem[L]» is linked to one or more «Subsystem[T]» or «SoftwareComponent» elements via the LogicalRealization relationship. To ensure traceability and completeness, it must be verified that all «Capability» elements defined in the [Logical Viewpoint] can be implemented by at least one assigned technical component.

Technical Interfaces: The «LogicalInterface» elements modeled abstractly in the [Logical Viewpoint] are concretized by the «TechnicalInterface» stereotype, which is derived from ProxyPort. Their semantic typing is defined via the «TechnicalInterfaceType» stereotype, which is derived from InterfaceBlock. In contrast to logical interfaces, the modeling here is technology-specific. Instead of a generic interface, the exact technology used by the respective «System [T]» or «SoftwareComponent» is specified.

Analogous to the «System [T]» stereotype, the following also applies: each «LogicalInterface» must be implemented by a corresponding «TechnicalInterface». To support this process, the automation script “TechnicalInterface4LogicalInterface” shown in Appendix F was developed.

Technical Behavior: The behavior of technical (sub)systems can be described in two ways. On the one hand, state machines can be used - analogous to logical behavior. For this purpose, the |Technical Behavior Diagram| is used. Within this diagram, «TechnicalStateMachine» elements can be created, which are derived from the StateMachine metaclass. As in the logical view, the stereotypes «ActiveState» and «PassiveState» are applied.

On the other hand, the exchange of signals between individual «Subsystem[T]» elements can be modeled using the |Technical Sequence Diagram|. For this purpose, the stereotypes «TechnicalSequence» derived from Interaction and «TechnicalCommunicationSignal» derived from Signal have been introduced. The use of sequence diagrams is particularly suitable when the communication between hardware and software components is described at a low level for example, to represent message flows, triggering mechanisms, and temporal sequences between components in a single state of a state machine. To link logical and technical behavior, the property implementsBehavior is introduced.

In summary, the Technical Viewpoint enables the explicit modeling of concrete system components, interfaces, and constraints while maintaining traceability to higher-level functional and logical elements. This makes technical allocations and interface decisions transparent and reviewable already in early phases, reducing the risk that inconsistencies remain unnoticed until later engineering stages.

The key stereotypes and modeling mechanisms of the DSML have thus been introduced. In addition to these core modeling elements, several auxiliary diagram types are provided to improve model readability and support traceability across different diagram layers. For example, the “Whitebox Functions to Logical System Allocation Matrix” visualizes the associations between «WhiteboxFunction» elements and their corresponding «System [L]» elements in a compact, tabular format.

In summary, the developed RFLT DSML fulfills the core methodological requirements (R2–R4) defined in Section 3 and directly contributes to answering Research Question 1 (RQ1). Through structured modeling guidance, integrated verification rules, and automation mechanisms, the DSML enables consistent model creation and efficient application in early engineering phases. Regarding comprehensibility (R1), the RFLT DSML particularly addresses R1.1 (Clear representation) and R1.2 (Traceability) by providing clearly defined stereotypes, viewpoint-specific diagram types, and explicit inter-viewpoint relationships. The sub-requirement R1.3 (Domain anchoring through standards), however, is not yet addressed.

5.2. Industrial Standards Based DSMLs

To address the remaining comprehensibility aspect R1.3 and to answer RQ2, a set of five dedicated DSMLs was developed based on widely recognized industrial standards. These DSMLs extend the RFLT DSML by integrating domain-specific terminology, structures, and rules, thereby enabling the systematic incorporation of relevant domain knowledge. Each standard represents a distinct subdomain covering, for example, product structures, processes, technical resources, and system interfaces and contributes to anchoring the overall modeling framework in established industrial practices.

The standard-based DSMLs introduced in this section are intended to be applied selectively, depending on the characteristics of the production system and the modeling objectives in early design phases. The VDI/VDE 3682–based DSML is particularly suitable for modeling complex or hard-to-overview processes when a shared understanding of system behavior must be established early across disciplines. Its intuitive graphical notation supports rapid modeling and interpretation and facilitates early alignment among stakeholders, thereby reducing the risk of divergent process assumptions in early engineering phases. The OPC UA Robotics Companion Specification–based DSML is applied when the production system includes robotic components, as it enables an early and standardized specification of robotic subsystems, capabilities, and interfaces. This supports early architectural decisions and prevents underspecified or inconsistent assumptions about robotic functionality and integration in later phases. The IEC 61293–based DSML supports the early modeling of electrical interfaces and constraints in systems composed of heterogeneous components with differing voltage or current requirements, allowing inconsistencies in planned power supply concepts to be identified at an early stage. Similarly, the TCP/IP Reference Model–based DSML is used when heterogeneous communication interfaces are involved, enabling the early detection of incompatibilities in planned communication architectures. Finally, the ISO 10303–based DSML is applied when the structure and parameters of the manufactured product significantly influence the design of the production system, supporting the explicit consideration of product–production dependencies during conceptual system design. The following sections describe the five DSMLs and how they refine and extend the RFLT DSML to achieve stronger domain anchoring and enhance comprehensibility.

5.2.1. VDI/VDE 3682

To support a guided and standard-compliant modeling of production processes within the [Functional Viewpoint], a DSML based on the VDI/VDE 3682 standard for Formalized Process Descriptions (FPD) [50,51] was implemented. The standard was chosen because it explicitly links processes to products and resources thereby reflecting the fundamental PPR structure of production systems and provides a simple and intuitive graphical notation for describing technical and non-technical processes, as shown in Figure 2. In this context, a dedicated stereotype was developed for each FPB element type, namely «ProcessOperator» (green square), «Product» (red circle), «Energy» (light blue diamond), «Information» (dark blue hexagon), and «TechnicalResource» (grey oval), which are semantically linked via flows and system boundaries. State-describing symbols («Product», «Energy» and «Information») are connected to a «ProcessOperator». The «ProcessOperator» describes a technology-neutral transformation of a state ante to a state post, which can be implemented using a «TechnicalResource».

Existing tools such as FPB.js [52] support the modeling of processes according to VDI/VDE 3682 but do not enable integration into MBSE workflows or established SysML toolchains. In contrast, the developed VDI/VDE 3682 DSML extends SysML with dedicated stereotypes that directly map to FPD constructs and introduces a specialized diagram type derived from the SysML Activity Diagram, which restricts modeling to FPD-compliant elements only. This approach thus enables clear and unambiguous process modeling directly within SysML. To ensure compliance with the modeling rules defined by the standard, the DSML also integrates constraint mechanisms using OCL. These include rules such as “check that each «ProcessOperator» has both input and output «States»”, since operators are defined as transforming inputs into outputs. Direct connections between «State» elements are disallowed, as they would imply a transformation without an explicitly modeled «ProcessOperator». Such connections cannot be created in the first place, since the applied stereotype CustomizationElement restricts the linking of two «State» stereotypes, thereby promoting consistent and guided model creation. A detailed description of the DSML, including the complete stereotype structure, modeling rules, and implementation details, can be found in [53].

5.2.2. OPC UA Robotics Companion Specification

Within the [Technical Viewpoint], technical systems and subsystems are modeled in detail to describe their structural and interface characteristics. Among the various technical resources encountered in production systems, robotic systems represent a central and increasingly important class of equipment, particularly in discrete manufacturing. To enable their consistent representation, the OPC UA Companion Specification for Robotics (OPC 40010-1) [54] was selected as a basis for one of the developed DSMLs. This specification defines a uniform information model for robotic components and therefore serves as an exemplary standard for the formalized description of technical systems within the proposed framework. In the remainder of this section, this DSML is referred to as the Robotics DSML. The Robotic DSML focuses on structural modeling, as it is intended for the use in early phases of the engineering process. The central stereotype of the profile is «Component», which is derived from the metaclass Class. This stereotype provides a generic representation of all robotic components. It is linked via a generalization relationship to the stereotype «iVendorNameplate», which defines standardized attributes such as Manufacturer or AssetID that can be used to further specify the components.

Furthermore, the «Component» stereotype is decomposed into more specific stereotypes such as «MotionDeviceSystem», «MotionDevice», «Controller», «Drive» and «Axis». The standard also defines rules for valid combinations of these elements. For example, a «MotionDeviceSystem» must contain at least one «MotionDevice» and one «Controller», while a «Powertrain» must consist of at least one «Gear» and one «Motor» element. Like the rules of the other DSMLs, these rules are implemented using OCL. The Robotic DSML has also been extended to include robotic components and attributes that are not covered by the standard. This includes stereotypes such as «EndEffector» or «Sensor». Additional parameters have been introduced, such as “IPClass”, as well as component-specific aspects like “DegreeOfFreedom” and “PayloadCapacity” for «MotionDevices». More information about Robotic DSML can be found at [55,56].

5.2.3. ISO 10303 (STEP)

Within the [Requirement Viewpoint], the product context is modeled. To enable a standardized and semantically precise representation of product information, a DSML was developed that builds upon the ISO 10303 standard (STEP), particularly parts ISO 10303-41 [57] and ISO 10303-44 [58], which define the foundations of product description and structure. In the remainder of this paper, this DSML is referred to as the ISO 10303 DSML.

The core stereotype introduced in the DSML is the «ProductDefinition», which serves as the abstract representation of a product or product class. It is refined into two distinct subtypes: the «AssemblyDefinition», which describes products that can be hierarchically decomposed into further assemblies or components, and the «ComponentDefinition», which represents non-decomposable parts. Both stereotypes are implemented as extensions of the metaclass Class. To support domain-specific classification, each product element can be linked to a «ProductCategory», which also extends the Class metaclass and allows the inclusion of external categorization schemes, such as Air Transport Association (ATA) chapters in aerospace engineering.

To describe relationships between product elements, two additional stereotypes were introduced. The «ProductDefinitionUsage» stereotype extends the Aggregation metaclass and is used to represent hierarchical part-whole relationships, for example, to model Bill of Materials. In contrast, the «ProductDefinitionAssociation» stereotype, derived from the Association metaclass, serves to express lateral or non-structural connections between product elements. To enrich the product model with shared metadata or auxiliary information, the DSML also defines a «CharacterizedObject» stereotype, again extending Class, which can be used to represent attributes that apply across multiple elements, such as geometric references or common parameters.

The ISO 10303 DSML ensures model consistency and correct stereotype usage through OCL rules that validate product aggregation cardinalities, check unique context assignments, and stereotype compatibility. A complete description of the ISO 10303 DSML elements, their semantics, and instantiation strategies is provided in [56].

5.2.4. TCP/IP Reference Model

The TCP/IP Reference Model is a conceptual framework designed to ensure the standardization and interoperability of communication systems [59]. It consists of four layers, each describing specific networking functions.

The Network Layer describes the physical and data link technologies used for local data transmission, such as Ethernet or IEEE 802.11 (Wi-Fi). The Internet Layer defines mechanisms for addressing and routing data between networks, typically based on the Internet Protocol (IP). The Transport Layer specifies protocols for end-to-end communication between devices, such as TCP, addressing aspects like reliability and ordering. The Application Layer represents the interface between applications and the network, defining protocols for structured data exchange, such as HTTP or OPC UA.

In the context of production systems, technologies like OPC UA typically reside at the application layer. In the remainder of this paper, this DSML is referred to as the TCP/IP Reference Model DSML. An overview of all stereotypes can be seen in Appendix G.

The «TCP/IPCommunicationInterface» stereotype is derived from the ProxyPort metaclass and represents the actual interface that can be used to model communication interfaces of technical components. The «TCP/IPCommunicationInterfaceType» stereotype is used to type the port and is therefore derived from InterfaceBlock. For typing purposes, the four layers are each represented by a dedicated attribute. The values of these attributes can be selected from predefined enumerations specific to each layer. This mechanism ensures that only valid technologies and protocols can be selected per layer.

The «TCP/IPCommunicationInterface» stereotype contains various derivedProperty elements that ensure attributes of both the linked «TCP/IPCommunicationInterfaceType» and the connected «TCP/IPCommunicationInterface» are visible. These attributes are then used to verify the compatibility of communication interfaces. Two «TCP/IPCommunicationInterface» elements are considered compatible only if they have identical values for each layer attribute. Additional rules ensure completeness of the interface definition. For example, if a value is defined for the Application Layer, all subordinate layers (Network, Internet and Transport) must also be defined. If intended interfaces are incompatible, the «CommunicationConverter» stereotype derived from Class and PartProperty, can be used to transform, for instance, OPC UA to MQTT.

5.2.5. DIN EN IEC 61293

The DIN EN IEC 61293 standard [60] deals with the marking of electrical equipment using rated data for power supply purposes. In particular, it defines typical rated values used to describe the electrical inputs and outputs of system components. In the remainder of this paper, this DSML is referred to as the IEC 61293 DSML. Appendix H provides an overview of the stereotypes developed for this purpose and their mapping to normative elements and UML/SysML metaclasses.

The «IEC61293ElectricalInterface» stereotype, derived from the metaclass ProxyPort, models the actual interface used to describe the electrical connections of «System [T]». The stereotype «IEC61293ElectricalInterfaceType», based on the SysML stereotype InterfaceBlock, is used to specify the interface.

For type definition, the standard-relevant attributes such as Voltage, ElectricalCurrent, ElectricalCurrentType, Power, or Frequency are mapped. The «IEC61293ElectricalInterface» stereotype includes several derivedProperty definitions, which provide access to both the attributes of the assigned interface type and the attributes of connected interfaces.

These properties are used to verify interface compatibility using OCL rules. For instance, it is ensured that a source delivers the voltage required by a consumer (cf. Listing 7), that the electrical current provided is sufficient to supply all connected consumers, or that both interfaces use the same current type (AC/DC). If the modeled electrical interfaces are incompatible, the «PowerConverter» stereotype can be used.

Listing 7: OCL Constraint for Voltage Compatibility.

1 context IEC61293ElectricalInterface 2 inv CheckVoltageCompatibility: 3 if self.SourceConsumer.oclAsType( EnumerationLiteral).name = ’SourceUnit’ then 4    (self.Voltage = self.VoltageOfConnectedInterface) or 5    (self.Voltage >= self.LowerVoltageLimitOfConnectedInterface and      self.Voltage <= self.UpperVoltageLimitOfConnectedInterface) 6 else 7    true 8 endif

It covers various device types such as transformers for voltage conversion, rectifiers for converting AC to DC, and frequency converters for frequency adaptation.

In summary, the standard-based DSMLs introduced in Section 5.2 enhance comprehensibility through domain anchoring (R1.3) and contribute to answering RQ2 by incorporating information and structures from established industrial standards. In addition, they address methodological requirements R2 and R3 by providing integrated user guidance and OCL-based verification rules that ensure standard-conformant modeling and early error detection. Since the introduced DSMLs are derived from external industrial standards, versioning considerations play an important role in their long-term applicability. Each standard-based DSML explicitly references the version of the underlying standard it is derived from, thereby ensuring traceability and reproducibility of modeling decisions. When standards evolve, a targeted review and validation of the corresponding DSML profiles and constraints is required to assess the impact of changes.

However, to ensure methodological coherence across domains, these DSMLs must also be consistently integrated into a unified modeling environment.

5.3. DSML Alignment

Building on the standard-based DSMLs introduced in the previous section, this part describes how multiple DSMLs can be integrated into a unified modeling approach through a structured alignment procedure. The alignment ensures consistency and compatibility between the different domain models and extends the coverage of RQ2 by enabling the systematic integration of the incorporated domain knowledge within a single framework. The proposed method builds upon the foundational alignment principles introduced by Espinoza et al. [61] and has been adapted to the specific requirements of production system modeling, including the integration of OCL-based verification rules and rule-based automation scripts within the SPES methodology.

To model complex systems comprehensively, it is often necessary to combine multiple DSMLs that were originally developed for different purposes or domains. This includes not only the DSMLs introduced in this paper but also potential future extensions tailored to specific modeling needs. However, combining DSMLs requires careful alignment to ensure that concepts, structures, and rules remain semantically and syntactically consistent. To support such integration scenarios, our approach provides a structured alignment process that enables the harmonization of multiple DSMLs within a single modeling environment. Based on this, several usage options are available for the DSMLs developed in this work (cf. Figure 3):

• Exclusive use of the RFLT DSML, as described in Section 5.1. This case is only applicable when the modeling is exclusively based on the SPES methodology and production-specific DSMLs introduced in Section 5.2 are not required.
• Use of one or more standard-based DSMLs, as presented in Section 5.2. In this case, the DSMLs are used independently, i.e., without any formal integration mechanisms such as shared constraints, stereotype mappings, or cross-DSML rules, which is meaningful only when applied to distinct areas of the system model.
• Combined use of multiple DSMLs through an additional alignment layer, which relates stereotypes, rules, and automation scripts to enable consistent and rule-compliant integrated modeling.

  (3a)

  Combination of the RFLT DSML with one or more standard-based DSMLs.

  (3b)

  Combination of multiple standard-based DSMLs without using the RFLT DSML.

Figure 3. Utilization Scenarios of the Developed DSMLs.

Figure 3. Utilization Scenarios of the Developed DSMLs.

Prior to integration, the intended use cases must be carefully examined to identify overlapping or complementary domain concepts, differing abstraction levels, and potential conflicts between DSMLs [61]. This analysis forms the basis for selecting appropriate alignment strategies and identifying the required semantic links, stereotype mappings, and verification mechanisms. In our approach, the standard-based DSMLs were explicitly developed as extensions to the RFLT DSML, resulting in two principal combination scenarios:

• Each DSML applies to a separate area of the model without semantic overlap, thus avoiding conflicts by design.
• Multiple DSMLs apply within the same model area but at different abstraction levels, introducing potential overlaps that require alignment.

The alignment process for multiple DSMLs within the same model addresses potential overlaps on three levels: semantics, abstract syntax, and concrete syntax.

At the semantic level, domain concepts from each DSML are analyzed manually to identify shared, complementary, or conflicting meanings. For example, different profiles may define resources or interfaces that refer to similar real-world concepts but use divergent terminologies. Semantic alignment ensures coherent interpretation across DSMLs.

At the abstract syntax level, UML stereotypes are examined for structural compatibility based on their UML metaclasses. Only compatible metaclasses may be generalized or composed across profiles. Additionally, existing constraints must be reviewed and adapted to allow joint usage.

At the concrete syntax level, visual representations are coordinated to ensure model readability when multiple stereotypes apply to a single element. Where standards such as VDI/VDE 3682 provide well-established notations, these are prioritized to enhance comprehensibility.

This multi-level procedure enables formalized, consistent integration of multiple DSMLs into a unified modeling environment. The following paragraph details the alignment process, which is structured into six steps that operationalize the concepts introduced above:

• Semantic linking of domain models: Relevant domain concepts across DSMLs are identified and mapped, focusing on structural similarities and overlapping semantics to establish conceptual correspondence. Since all DSMLs presented in Section 5.2 were specifically developed to refine the stereotypes of the RFLT DSML, no semantic or structural incompatibilities arise at this step. Figure 4 shows an excerpt of the resulting domain model alignment derived from the integration of the DSMLs mentioned above, where the linked elements are highlighted with red frames and connecting arrows.
  In particular, the following semantic relationships were defined:
  • The Robotics DSML specifies the «Subsystem[T]» stereotype of the RFLT DSML.
  • The IEC 61293 DSML and TCP/IP Reference Model DSML specify the «TechnicalInterface» and «TechnicalInterfaceType» stereotypes.
  • The VDI/VDE 3682 DSML specifies the constructs «WhiteboxFunction» and «FunctionalInterface».
  • The ISO 10303 DSML specifies the «ProductContext» and its associated «ProductContextParts».
• Stereotype mapping (abstract syntax): Compatible stereotypes are linked via generalization or composition relationships, provided their UML metaclasses are compatible (e.g., structural and behavioral metaclasses are not mixed). In this case, for example, generalization relationships are established between the stereotypes «IEC61293ElectricalInterface» and «TCP/IPCommunicationInterface» toward the more general «TechnicalInterface», between «IEC61293ElectricalInterfaceType» and «TCP/IPCommunicationInterfaceType» toward «TechnicalInterfaceType», and between «Subsystem[T]» and the superior «Component» stereotype defined in the Robotics DSML.
• Adaptation of customization elements: Domain-specific CustomizationElement constraints are reviewed and adjusted to permit stereotype application within shared contexts. For example, the PossibleOwner property defines the viewpoint in which a stereotype, such as the «Sensor» stereotype from the Robotics DSML, may be applied for instance, within the [Technical Viewpoint]. Similarly, the Category property ensures that the new DSML elements are integrated into the appropriate viewpoint structures of the modeling environment.
• Constraint harmonization (OCL constraints): Existing OCL constraints are checked for compatibility and extended as needed to ensure semantic correctness across combined profiles. New constraints may be introduced to validate cross-DSML relations. For example, the rule shown in Listing 6 checks that only a «WhiteboxFunction» must refer to the same «Capability» as the associated «System [L]» element. Within the alignment, this rule must also be verified for the «ProcessOperator» stereotype. An additional rule resulting from the integration of the DSMLs specifies, for example, that each «ProductDefinition» in the «Product Context» must be linked to at least one «Product» state element from the VDI/VDE 3682 DSML.
• Unified concrete syntax: For elements with multiple applicable stereotypes, visual priority rules are defined to determine which representation governs appearance. The visual notation of the VDI/VDE 3682 DSML was adopted for the integration with [Functional Viewpoint] elements, as it provides a clear and intuitive representation. In other cases, where the underlying standard does not define a graphical notation, the representation of the RFLT DSML was used. This DSML employs color-coded distinctions for each viewpoint ([Requirement Viewpoint]–red, [Functional Viewpoint]–yellow, [Logical Viewpoint]–green, [Technical Viewpoint]–purple), thereby supporting visual separation of model contents.
• Testing through examples: The aligned profiles were validated during development by applying them to representative modeling examples. In these tests, the integrated stereotypes were instantiated in small test models to verify correct linkage and rule consistency. Identified issues were iteratively corrected until full alignment was achieved.

A key characteristic of the proposed alignment approach is that the alignment effort is intended to be incurred once for a given combination of DSMLs. Once the involved profiles have been aligned, the resulting integrated DSML can, in principle, be reused across multiple application cases without requiring a repeated alignment of the same profiles. From a conceptual perspective, this suggests that the alignment effort is limited in relation to the overall modeling effort required for complex production systems, particularly when the same DSML combination is applied in more than one context.

If additional DSMLs are introduced at a later stage either newly developed or integrated from further standards the alignment process is limited to linking the new DSML with the existing combination.

Previously established alignments remain unaffected, which conceptually restricts the required effort to the incremental integration of the new profile. Due to the modular structure of the DSML framework, this incremental alignment effort is expected to remain manageable.

Overall, the modular design of the proposed DSML framework is intended to support scalability and reuse. It provides a conceptual basis for applying the approach across multiple projects and for extending it toward additional domains and application contexts through the integration of further DSMLs. Model evolution and change management are supported conceptually through the alignment mechanism between DSMLs. Standard-based DSML files can be integrated using a read/write import strategy, such that changes to the original DSML e.g., resulting from updates of the underlying standard are propagated to the aligned DSMLs. In this way, model evolution is not handled through duplication, but through explicit references between profiles. If changes in the original DSML conflict with existing alignment rules or constraints, these conflicts become explicit within the alignment specification. This makes the impact of changes visible and enables a targeted review and adaptation of the affected alignment rules, rather than requiring a complete re-alignment.

6. Application Example

The application example is intended to demonstrate how the proposed methodology from Section 5 addresses typical challenges encountered in the conceptual design of complex production systems. While the relevance of these challenges and the corresponding methodological requirements are derived in Section 3, the application example explicitly illustrates how these aspects are addressed in a concrete industrial scenario. The application example originates from automated aircraft production and was developed as part of a joint research project with Airbus Operations GmbH. The resulting production system, referred to as the Modular Automated Track System (MATS), is shown in Figure 5. It is a robotic system installed inside the aircraft fuselage, where it mounts collars onto rivets that have previously been inserted into holes of the fuselage from the outside.

For this model, DSMLs from Section 5.1 and Section 5.2 were used. To enable the combined use of the various DSMLs, steps 1 through 6 from Section 5.3 were carried out. To initialize the model, all viewpoints and their subordinate packages were generated automatically using a script.

Starting with the [Requirements Viewpoint], the system was modeled step by step across all four viewpoints defined in Section 5. Due to the scale of the model, only selected excerpts are presented in this section to illustrate the key concepts and interactions between the viewpoints.

«InternalStakeholder» elements, were identified and are part of the «ResourceContext», as illustrated in Figure 6. The Safety Engineer defines an Emergency Stop Interface through which the system can be stopped if necessary, while the «User» requires an HMI.

In addition, further interactions are specified, such as for the system’s power supply or for connecting to specific communication interfaces. The production environment of the system is also taken into account, as the presence of Dust requires the system to be protected by an appropriate IP class. Each of these «ResourceContext» elements are linked to the system via a «ContextInteraction» stereotype, which is classified as input, output, or bidirectional interaction. Subsequently, a script is used to derive a «Hardgoal» from each «ContextInteraction» and to link it using the «DerivedFromContext» stereotype. By automating these derivation steps, the methodology reduces repetitive manual modeling tasks and ensures methodological consistency across viewpoints. This is particularly relevant in large-scale production system models, where such derivations are otherwise error-prone and time-consuming.

In addition to the «ResourceContext», the «ProductContext» and «ProcessContext» were also modeled in accordance with the OCL constraint presented in Listing 2. The «ProductContext» is specified as shown in Figure 7 using the ISO 10303 DSML. The product to be manufactured in this application example is an aircraft fuselage that is first joined using rivets and subsequently secured by screwing collars onto the rivet ends. Accordingly, the top-level element is represented by the JointAndScrewedFuselage, which is modeled as an «AssemblyDefinition» in compliance with ISO 10303. It consists of the «ComponentDefinition» Elements FuselageSection and 2500 Rivet. For each Rivet, a Collar is installed. Since different types of collars are required depending on the rivet type and diameter both components share the same «CharacterizedObject» element.

Various «Scenarios» were defined by the internal stakeholders. These include, for example, Collar installation, calibration, camera testing, and maintenance tasks. Each of these scenarios was subsequently transferred into a «BlackboxFunction».

Figure 8 illustrates the |Blackbox Perspective Diagram| of the collar installation scenario as an example. It illustrates the functional structure through a decomposition into «BlackboxFunction» and «AtomicBlackboxFunction» elements. Each «AtomicBlackboxFunction» requires an associated «AtomicCapability», as specified in the OCL rule presented in Listing 3. The «Capability» stereotypes ensure that the functional and logical viewpoints are clearly linked and that it is possible to trace which logical systems implement which functions. To demonstrate the functionality of this OCL constraint, the «AtomicBlackboxFunction» Move to z position was intentionally left without an assigned «AtomicCapability». This violation is directly visualized in the diagram by a red border. This example illustrates how formal verification rules transform implicit modeling assumptions into explicit, tool-enforced constraints. In practice, such omissions are often detected only in later engineering phases or remain undocumented when using conventional SysML modeling without formalized rules. Additionally, the violated rule is identified, and the corresponding error message is displayed. By directly indicating which modeling error has occurred, the user is guided through the troubleshooting process. Compared to other approaches, this shortens the troubleshooting time and ensures that the error is corrected in the right way.

The capabilities are inherited by the higher-level «BlackboxFunction» elements, as required by the OCL rule presented in Listing 4. In this way, the overarching «BlackboxFunction» Collar Installation contains all the required capabilities for the complete scenario. Using the script shown in Algorithm A1, a corresponding «WhiteboxFunction» element was automatically generated for each of these functions.

In this application example, the «Whitebox Function» elements are modeled using the VDI/VDE 3682 DSML. Therefore, the «ProcessOperator» stereotype was added in addition to the «WhiteboxFunction». Figure 9 shows the top-level process, which consists of four «WhiteboxFunction» elements. In addition, all inputs and outputs for the individual «ProcessOperator» elements were modeled. Since all process steps are executed automatically, each «ProcessOperator» instance requires ElectricalEnergy as an input. Furthermore, information such as the rivet position or the product Collar is also required as input. Each «State» element that enters the process from the outside and is therefore positioned at the diagram boundary is linked to already modeled elements from the «ProductContext» or «ResourceContext». The «TechnicalResource» elements, depicted as gray ovals, serve as the basis for the subsequent logical architecture. The use of DSML, which is based on standards, makes it easier for users to model domain-specific models, but also to read and understand them. In this example, users can use a familiar standard for process modeling instead of the classic activity diagram. In addition, in contrast to the classic activity diagram, the inputs and outputs of the process steps/«ProcessOperator» can be clearly distinguished from each other by using different colors and shapes. An excerpt of the configured user interface for modeling is shown at the bottom right of the figure. The available modeling elements within the user interface are restricted to the stereotypes explicitly defined for the selected diagram type. This tool-based configuration ensures that users can only select valid stereotypes and relationships, thereby guiding the modeling process in a structured and consistent manner. The same principle is applied across all custom-developed diagram types to enforce consistent usage of the underlying DSMLs.

In the [Logical Viewpoint], the «System [L]» and «Subsystem[L]» elements are defined. The logical system structure is incrementally refined until at least one element has been modeled that fulfills the required «CombinedCapability» of the corresponding «BlackboxFunction», as specified by the OCL constraints presented in Listings 5 and 6. The resulting logical architecture consists of a MovingSystem (provideCapability: Moving), a ReferencingModule (provideCapability: DataRecording, provideCapability: DataProcessing), a CollarDeliverySystem (provideCapability: Storing), and an EndEffector (provideCapability: Screwing). In addition, the required «LogicalInterface» elements were derived. As shown in Figure 9, each «ProcessOperator» requires an ElectricalEnergy input. Accordingly, an «ElectricalInterface» was modeled for each «Subsystem[L]». Since each «ProcessOperator» also uses an «Information» state element either as input or output, corresponding «CommunicationInterface» elements were defined for all «Subsystem[L]» elements. Furthermore, a «MechanicalInterface» was modeled for the CollarDeliverySystem to enable the physical delivery of collars to the system.

For the modeling of the [Technical Viewpoint], the RFLT DSML was used in combination with the Robotics DSML, IEC 61293 DSML and TCP/IP Reference Model DSML for the specification of «Subsystem[T]» and «TechnicalInterface» elements.

All «System [L]» elements were implemented through one or more «Subsystem[T]» elements, which are assigned both the «Subsystem[T]» stereotype and domain-specific stereotypes from the Robotics DSML. For instance, the «System [L]» ReferencingModule was implemented as two separate «Subsystem[T]» elements: a Camera, modeled with the «Sensor» stereotype, mounted on the «EndEffector» and responsible for the DataRecording capability; and an Industrial PC with the «Controller» stereotype, acting as the central control unit. This component provides the DataProcessing capability and manages communication between the subsystems.

The MovingSystem was implemented as an x-Axis, y-Axis, and z-Axis. For clarity, only the z-Axis is shown Figure 10. Each axis is equipped with its own «Controller», a «Motor» and a «Sensor» (Reference Switch) to enable independent control.

The interfaces from the [Logical Viewpoint] were also refined. The «ElectricalInterface» elements were detailed using stereotypes from the IEC 61293 DSML (see Appendix G). The implemented OCL rule from Listing 7 revealed that the «EndEffector» requires a different voltage level than the other components. As a result, an additional «PowerConverter» element was introduced. Without the integration of the IEC 61293 DSML, properties such as nominal voltage and current characteristics would not have been explicitly defined at the modeling language level. In a purely SysML-based model, such information would either remain implicit or need to be added in an ad-hoc manner without formal semantic constraints. Consequently, the incompatibility in voltage levels between the end effector and the remaining components would likely not have been detected during early modeling stages, as no domain-specific verification rules would have been available to identify this inconsistency.

The «CommunicationInterface» elements were specified using the TCP/IP Reference Model DSML. Since each axis and the «EndEffector» is equipped with a dedicated controller, and the motor controllers only support CANopen interfaces, a «CommunicationConverter» element was added to establish the connection to the Industrial PC. Without the TCP/IP Reference Model DSML, such interface incompatibilities would not have been explicitly represented or systematically verified at the modeling language level. In a purely SysML-based model, communication aspects would typically be captured in a highly abstract or informal manner, without explicit differentiation of protocol layers or formal consistency checks. By explicitly modeling the TCP/IP layers and applying domain-specific OCL constraints, incompatible communication configurations could be identified and resolved already in early design phases. This is particularly valuable in domains such as aircraft production, where highly specialized controllers and communication technologies are employed and interface mismatches are not always obvious to identify during conceptual system design.

Finally, all interfaces defined in the «ResourceContext» (see Figure 6) were implemented: The «TechnicalInterface» elements Safety Bumper and E-Stop for fulfilling the«HardGoal» Emergency Stop Interface, a 230V power supply «IEC61293ElectricalInterface» transformed via a 24VDistribution «PowerConverter» element fulfilling «HardGoal» Electrical Energy Interface, a «TechnicalInterface» HMIInterface element fulfilling «Hardgoal» HMI Interface and an «TCP/IPCommunicationInterface» EthernetInterface, provided by the Industrial PC to support communication with the Station SPS to fulfill «Hardgoal» NC Program and with the Outer Robotic System to fulfill «Hardgoal» Communication Interface Outer Robotic System.

7. Application Result

To assess the proposed method with respect to the requirements (R1–R4) defined in Section 3, a demonstrative evaluation was conducted based on the application example presented in the previous section. The evaluation focused on determining to what extent the developed DSML framework fulfilled the defined requirements and, consequently, how it contributed to answering the research questions RQ1 and RQ2.

Comprehensibility (R1) Comprehensibility was evaluated with regard to its three sub-requirements.

(R1.1—Clear representation): Within the RFLT DSML, the visual and semantic distinctiveness of modeling elements was enhanced through clearly defined and consistently applied stereotypes. Each stereotype represented a unique concept within the production system model and could be unambiguously distinguished from others. For example, elements such as «System [R]», «System [L]», and «System [T]» were used to represent the system at different abstraction levels and viewpoints, ensuring that model elements remained conceptually and visually distinct throughout the development process.

(R1.2—Traceability): The defined viewpoints, stereotypes, and inter-stereotype relationships enabled explicit traceability across all abstraction levels and system perspectives. Within the RFLT DSML, this was achieved through dedicated properties and relationships that systematically linked model elements within and across viewpoints. In the presented application example, this resulted in a system model in which no isolated model elements were created, as each element was explicitly connected to at least one other element within the same or a different viewpoint. For example, derivedFromContext connected context interactions and system goals in the [Requirements Viewpoint], requiresCapability and providesCapability established dependencies between functional and logical elements, and LogicalRealization linked logical and technical components. As a result, each model element was explicitly embedded in the overall system model structure, and behavioral, structural, and technical aspects remained consistently connected and traceable throughout the model.

(R1.3—Domain anchoring through standards): The integration of DSMLs derived from industrial standards ensured a high degree of semantic alignment with established engineering practices. This combination of general modeling principles and standard-based domain knowledge significantly improved the interpretability of models and supported interdisciplinary understanding, even for users without extensive MBSE experience.

Guidance (R2) The modeling environment provided multiple levels of guidance. First, element selection within diagrams was guided by restricting the available modeling elements to those defined in the applied DSMLs. This was implemented through tool-based configuration of the modeling interface, ensuring that only valid stereotypes and relationships could be selected by the user. Second, constraints within the CustomizationElements (e.g., PossibleOwner) ensured that stereotypes could only be applied in appropriate contexts. In addition to these preventive design-time restrictions, error messages were systematically integrated into each OCL rule. Whenever a constraint violation occurred during modeling, the user received an immediate and specific explanation indicating the cause of the violation and the necessary corrective action. This mechanism ensured that users were continuously guided toward valid model structures throughout the entire modeling process.

Early Verification (R3) A comprehensive set of OCL constraints was defined to enable early verification of semantic correctness during model creation. In total, 24 constraints were specified for the RFLT DSML and an additional 26 constraints for the five standards-based DSMLs. During the modeling process, several of these constraints triggered violations that were immediately resolved, thereby demonstrating the effectiveness of the integrated verification mechanisms. For instance, constraints from the IEC 61293 DSML detected that the end effector required a distinct voltage level compared to other components, which led to the insertion of an appropriate power converter. Likewise, constraints from the TCP/IP Reference Model DSML revealed interface incompatibilities, necessitating the modeling of communication converters for the CANopen interface.

Reducing Modeling Effort (R4) To reduce modeling effort, several automation scripts were developed. These scripts automatically generated viewpoints, package structures, and dependent model elements. For example, the «WhiteboxFunction» elements were automatically derived from «BlackboxFunction» elements based on a defined script. In the presented application example, 204 elements were created, of which 59 elements were automatically generated via scripting, corresponding to 29% automation. This demonstrated the potential of automation scripts to reduce manual modeling effort and to improve consistency.

Research Question 1: RQ1 investigated how the generic concepts of SysML could be specified through the UML profile mechanism to develop a DSML that ensures high applicability for the conceptual design of production systems. The evaluation demonstrated that the developed RFLT DSML fulfilled this objective by combining viewpoint-specific diagram types, clearly defined stereotypes, and integrated mechanisms for verification and automation. This ensured structured and efficient model creation across early design phases and supported methodological consistency through alignment with the SPES framework.

Nevertheless, the RFLT DSML provided a coherent and practically applicable foundation that balanced domain specificity with general usability, thereby successfully addressing RQ1.

Research Question 2: RQ2 examined how information and structures from established industrial standards could be incorporated into a DSML to enable the systematic integration of relevant domain knowledge. This was achieved through the development of five standard-based DSMLs and their structured alignment with the RFLT DSML. The evaluation confirmed that this integration enhanced comprehensibility, ensured semantic consistency, and supported model verification across viewpoints.

Despite this, the alignment concept proved to be stable and effective, demonstrating that the integration of industrial standards systematically embedded domain knowledge while maintaining consistency within the modeling environment, thereby addressing RQ2.

8. Critical Discussion: Limitations of the Approach and of the Evaluation

While the proposed DSML framework demonstrates methodological feasibility and conceptual coherence, several limitations must be acknowledged with respect to both the approach itself and its evaluation.

The evaluation presented in this work is based on a single, extensive application example from aircraft production and primarily aims to demonstrate feasibility, internal consistency, and methodological applicability. It does not constitute a statistically representative empirical validation. Consequently, claims regarding improvements in comprehensibility, guidance, early verification, or modeling effort reduction are illustrative in nature. Quantitative measures such as error detection rates or automation ratios are reported descriptively and are not intended to generalize across users, organizations, or application contexts. A systematic empirical assessment involving multiple case studies and users with different levels of MBSE experience would be required to substantiate such claims and is considered future work.

In future empirical evaluation, comprehensibility (R1) can be assessed via interviews and questionnaires that consider both users’ ability to actively create models and their ability to understand and interpret pre-existing system models. Comparative studies with alternative approaches or plain SysML can be used to evaluate differences in model understanding. To specifically assess the contribution of standard-based DSMLs, domain experts with varying degrees of familiarity with the underlying standards should be involved, allowing the added value of standards-based modeling constructs to be isolated. Guidance (R2) can be evaluated through user questionnaires and semi-structured interviews focusing on the perceived usefulness of restricted modeling choices, contextual hints, and descriptive error messages provided during constraint violations. Early Verification (R3) can be examined in controlled studies by tracking the number and types of modeling errors introduced with and without activated OCL constraints, as well as the time required to detect and correct these errors. Reducing Modeling Effort (R4) can be assessed by measuring modeling time for identical systems created with the proposed approach and competing methods. To isolate the impact of automation, modeling effort can additionally be compared with automation scripts enabled and disabled, complemented by metrics such as the proportion of automatically generated model elements and the reduction of repetitive manual modeling tasks.

From a methodological perspective, the proposed approach deliberately introduces a high degree of structure through domain-specific stereotypes, viewpoint restrictions, and formal constraints. While this structure is intended to improve semantic clarity, consistency, and early error detection, it inevitably introduces an initial learning overhead. In particular, users unfamiliar with MBSE or DSML concepts may perceive the number of stereotypes and rules as an additional complexity burden. The integrated guidance mechanisms, diagram restrictions, and descriptive error messages are intended to mitigate this burden. However, their effectiveness has not yet been empirically validated and may vary depending on user experience, training, and organizational context.

Although the framework incorporates automation scripts to reduce manual modeling effort, the achievable degree of automation is inherently limited. Automated model generation is strictly rule-based and relies exclusively on information already present in the model. No new domain knowledge is generated automatically. As a result, phases of automated derivation necessarily alternate with manual modeling activities in which new information must be introduced by the user. Automation should therefore be understood as a supportive mechanism that improves consistency and efficiency, rather than as a replacement for expert modeling decisions.

The integration and alignment of multiple DSMLs derived from industrial standards further increase both methodological expressiveness and technical complexity. While the alignment process follows a structured procedure, it currently relies on manual semantic matching and expert judgment. This introduces potential risks regarding long-term maintainability, particularly when underlying standards evolve over time. Although the modular structure of the DSMLs allows changes, noting changes to be localized, the alignment effort remains a non-negligible task and requires modeling expertise. Tool portability is similarly limited, as certain aspects such as diagram configurations, user interface constraints, and usage restrictions depend on tool-specific capabilities and must be reimplemented when transferring the approach to other modeling environments.

Finally, the level of detail and formalization provided by the proposed approach may not be necessary or appropriate for all production system contexts. The framework is primarily intended for complex and highly regulated environments, such as aircraft production, where detailed traceability, early verification, and compliance with normative constraints are mandatory even in early engineering phases. In such contexts, the additional modeling effort and methodological rigor are justified by regulatory requirements and the high cost of late-stage errors. The transferability of the approach to less regulated domains and alternative application contexts remains an open research question and should be investigated in future work.

9. Conclusions and Outlook

The engineering of complex systems is a tedious, error-prone, and difficult task. To support efficient and correct modeling, the presented approach combines an SPES-based RFLT DSML with several DSMLs derived from established industrial standards, including VDI/VDE 3682, OPC UA Robotics Companion Specification, ISO 10303, the TCP/IP reference model, and IEC 61293. The method holistically supports the four SPES viewpoints—Requirements, Functional, Logical, and Technical—and ensures their internal consistency through viewpoint-specific constraints and modeling conventions. To integrate the RFLT DSML with the DSMLs of domain-specific standards, an additional alignment layer is introduced. This layer harmonizes stereotypes, constraints, and customization rules across DSML boundaries, enabling a consistent and standards-compliant modeling environment. The approach was evaluated using an application scenario from aircraft production, in which an automated robotic system is developed and described. The evaluation demonstrates the method’s applicability and practical benefit. Automation scripts were shown to reduce modeling effort, while OCL-based constraints improved semantic consistency and early error detection. However, the achievable degree of automation is inherently limited and should be understood as a supportive mechanism rather than a replacement for expert modeling decisions. By referencing widely accepted standards and providing diagrammatic and structural guidance, the method also improved the comprehensibility of system models and was intended to mitigate the initially increased learning effort resulting from the introduction of domain-specific stereotypes and methodological structure.

Reusability was structurally prepared through stereotype definition and modular modeling, although it remains to be demonstrated in larger contexts. The proposed approach primarily targets domain and system engineers involved in early engineering phases of production systems. These users can directly apply the DSMLs introduced in Section 5.1 and Section 5.2 to create consistent and comprehensible system models, supported by domain-specific stereotypes, guided diagram usage, and integrated verification mechanisms, without requiring in-depth expertise in DSML development. The development of additional DSMLs and their alignment with existing profiles constitutes a different level of expertise. Such tasks are intended for modeling experts, as they require a deep understanding of modeling languages, semantics, and alignment mechanisms. This distinction is intentional and reflects the current state of tool support, as the alignment process is not automated.

To build upon the current findings, future research could address the following directions:

A central research direction is the systematic investigation of model reusability across product and system variant configurations. In early design phases, particular attention should be given to modeling variability in PPR structures. For example, it should be evaluated how changes in rivet types impact process models and required technical resources. By developing multiple model variants and systematically comparing their models, the benefits of stereotype-based modularization can be quantified. In particular, reuse can be assessed by identifying which stereotyped elements, such as functions, capabilities, subsystems, or interfaces, remain unchanged across variants, as well as which derived relationships and automated model artifacts can be reused without modification. Metrics such as the number of reused model elements, the ratio of reused to variant-specific elements, or the stability of stereotype-based structures across variants can be used to quantify the degree of reuse.

Another important avenue concerns the usability of the developed DSMLs in heterogeneous industrial environments. Given the increased methodological structure and the number of defined stereotypes, empirical usability studies involving domain experts with different levels of modeling experience should be conducted. These studies should assess whether the integrated rules, diagram restrictions, and tool-based guidance effectively mitigate the learning effort associated with DSMLs and improve comprehension and model quality in practice. In addition, future work should investigate the transferability of the proposed approach to different SysML-based modeling environments, including the extent to which the defined stereotypes, constraints, and methodological concepts can be reused across tools and which aspects require tool-specific adaptation.

A direct quantitative comparison with alternative modeling approaches constitutes a substantial methodological challenge. A solid study design would require participants with different levels of modeling experience to model the same system using multiple approaches under comparable conditions. Such a setup would be necessary to disentangle the effects of modeling language, tool support, and user expertise. Conducting such a study is highly resource-intensive and exceeds both the temporal and textual scope of the present contribution. Consequently, a systematic comparative evaluation is considered an important direction for future research.

Furthermore, as the integration of multiple DSMLs increases methodological and technical complexity, future research should focus on refining the DSML alignment method presented in Section 5.3. In particular, approaches for automating the alignment and maintenance of DSMLs should be explored to handle evolving standards and to facilitate the integration of additional domain-specific profiles, such as the DSML for planning logic proposed in [62].