EIPPM—The Executable Integrative Product-Production Model ^†

Abstract

In this paper, a combination of graph-based design and simulation-based engineering (SBE) into a new concept called Executable Integrative Product-Production Model (EIPPM) is elaborated. Today, the first collaborative process in engineering for all mechatronic disciplines is the virtual commissioning phase. The authors see a hitherto untapped potential for the earlier, integrated and iterative use of SBE for the development of production systems (PS). Seamless generation of and exchange between Model-, Software- and Hardware-in-the-Loop simulations is necessary. Feedback from simulation results will go into the design decisions after each iteration. The presented approach combines knowledge of the domain “PSs” together with the knowledge of the corresponding “product” using a so called Graph-based Design Language (GBDL). Its central data model, which represents the entire life cycle of product and PS, results of an automatic translation step in a compiler. Since the execution of the GBDL can be repeated as often as desired with modified boundary conditions (e.g., through feedback), a design of experiment is made possible, whereby unconventional solutions are also considered. The novel concept aims at the following advantages: Consistent linking of all mechatronic disciplines through a data model (graph) from the project start, automatic design cycles exploring multiple variants for optimized product-PS combinations, automatic generation of simulation models starting with the planning phase and feedback from simulation-based optimization back into the data model.

1. Introduction

When designing production systems (PS), flexibility with regard to the markets needs (e.g., product variants, production capacity) brings up the need for reconfigurable manufacturing systems [1]. Additionally, the most recent and future challenge for PSs lies within a design process considering energy and overall resource efficiency in the entire life cycle [2]. Requirements from new product variants, which were not foreseen in the first years of operation, and changes in regulations increase the complexity and demand for higher flexibility in the current and future design processes. Due to a lack of knowledge about the effects of changed requirements on today’s PSs, the subsequent adaptations are associated with high efforts and costs. The prevailing design process for most PS manufacturers is still based on the sequential waterfall model, first defined by Royce et al. [3]. This is in contrast to the idea of more parallelization using methods of the digital factory, cf. [4]. The following two general disadvantages can be identified:

• Solution variants must be excluded at an early stage, as parallel development is not economically feasible.
• Decision-making is discipline-specific (mechanics, electronics, software), sequential and involves compromises, but often ignores cross-disciplinary couplings.

Such deficits and problems have been identified in [5]. The main outcome was that a sequential and “first-time-right” design philosophy prevails in the PS industry. Figure 1 shows phases and activities within the life cycle of a customer-specific PS.

Notable is the simultaneous engineering (Definition from [6]: “Parallel processing of different tasks with constant adjustment of the progress made”) of the virtual commissioning (VCOM) phase in parallel to the assembly activity. The pre-drawing of test and optimization steps from the commissioning phase is enabled by a hardware-in-the-loop simulation of the PS, e.g., [7,8]. VCOM allows to increase the quality of the PS right before commissioning and at the same time allows to shorten the remaining time during commissioning by about 75% [9]. VCOM is part of the concept digital factory. The goal of a complete digital factory, as described by the Association of German Engineers (VDI), is to combine product and production engineering using digital methods, models and tools (see [10]). Essentially, the integration of various simulation disciplines will help to design, plan and operate product and production in the vision of the digital factory concept [11].

Derived from the previous work [5], a new Model-Based Systems Engineering (MBSE) approach would be needed to engineer PSs in a more efficient and flexible manner. The motivation behind MBSE in general is to improve productivity [12]. To some extend the complexity of building and reading central data models prevents their adoption in the industry. In research, the concept of digital factories and simulation technology, as an intuitive way to view and execute models, is investigated and approved in numerous ways (e.g., see [13,14,15,16,17,18,19]).

In [20] the connection and also the differences between MBSE and a graph-based design approach are shown. Graphs are mathematically formalized models that can hold information from different kinds of engineering models [21]. In the paper on hand the authors elaborate a combination of graph-based design languages and simulation-based engineering to come up with a new model-based engineering concept that copes with the above-mentioned challenges for PS. For this paper, the authors define the term simulation-based engineering SBE as an engineering approach for product or production engineering that uses simulation models as a basis for verification and validation purposes throughout the life cycle. Each step between phases of the life cycle needs to pass by a quality gate by passing simulation scenarios.

The content of the paper is organized as follows: First the two central concepts, SBE and graph-based design are introduced. This is followed by an overview of the state of the art, which is critically examined against defined criteria. Afterwards, the overall concept will be presented. This paper features foremost the production design aspects of the concept. For a better understanding, the concept is then exercised by means of an application example. The paper closes with a summary and conclusion.

2. Fundamentals and Literature Review

2.1. Methods for Virtual Commissioning of Production Systems

According to the “rule of ten”, late changes during the life cycle of a system or product result in exponentially increasing costs [22]. Early fault detection and frontloading of changes are therefore an important factor to control cost, time and quality in the making of a system or product. In the development process for PS, VCOM is a state-of-the-art simulation method to “reveal and rectify faults originating from the engineering of an automation system” [23]. To be able to reveal faults from engineering at an early stage of the development process, a mapping of the corresponding PS is needed. Therefore, a simulation model of the PS is simultaneously developed with the real system. Within so-called x-in-the-loop environments the simulation model can be coupled with an instance of the automation control: common configurations are model-, software-, or hardware-in-the-loop (MiL, SiL or HiL) [23]. Due to continuous system modeling for x-in-the-loop environments not only logical but also runtime errors in the control can be detected [4]. Depending on the stage of development of the automation system its modeled behavior (MiL), its real code on an emulated hardware (MiL) or the real code and the real hardware (HiL) is coupled with the simulation model. The use of HiL can be seen as the most-accurate method in comparison to the physical PS as it includes the real hardware control, thus it is used for the following tasks [7]:

• The VCOM of control hardware and software
• Testing of the automation software and the human machine interface
• The optimization of the automation software
• Training of operators for the real production system

The simulation model contains the components, the processes and the communication interface of the PS [23]. Further elements of the simulation model may include special (e.g., physics) behavior, material flow, parts of the human-machine interface. Dependent on the industry division the simulation models are created with a different width of the model and level of detail. E.g. within the simulation model of an entire assembly line the material flow between the assembly modules is very important whereas a robot welding cell has its scope on the kinematics of the robot and collision detection. [23] shows a classification of different model types used in simulation models for VCOM.

Up to now, the disadvantage of using VCOM is the upstream additional effort for model generation for the simulation environment. In the future, simultaneous engineering should allow the simulation model to be created as efficiently and quickly as possible in parallel with the entire development using suitable methods [24,25]. Preliminary work exists on low-effort generation by means of creation from a construction kit with defined cyber-physical modules [26]. Further contributions to low-effort model generation, e.g., by reuse-oriented generation [27], on the basis of an existing construction kit [14,28], on the basis of planning data [28,29,30,31,32], by methodical reuse of partial models [31,33] and by means of model-based mapping of the mechatronic data [15,34] are known. None of the approaches can compensate for the disadvantages that result from the sequential “first-time-right” development approach for PS:

• Late time of model generation: Only final information from the individual mechatronic disciplines is included in the simulation models because the intended use is VCOM.
• Low frequency of model generation: The simulation is only generated and used for final acceptance, since data maintenance is still very time-consuming.

2.2. Graph-Based Design Languages based on Principles of Systems Engineering and Model-Based Systems Engineering

Graph-based design languages (GBDLs) [35,36] represent an innovative extension of the MBSE approach, see [37], since, unlike MBSE, the central data model is created automatically. This is achieved by mapping concepts (i.e., the vocabularies) and assembly knowledge (i.e., the rules) into recombinable language modules and operations [36]. In the information representation of a design language, the nodes of a graph serve as abstract placeholders for real objects or processes. Representing the product design, a graph representation (Design Graph) is thus processed by machine. This machine processing expands and modifies the graph dynamically at runtime. The abstract product representation allows easy modularization and scalability and enables consistent integration of discipline-specific models (see Figure 2). The generation of discipline-specific models in the target format (DSL) are realized via interfaces. For a more detailed description of how GBDLs work, please refer to [38,39,40,41,42,43].

According to the systematic design methodology of Pahl and Beitz [44], the requirements are initially mapped to abstract product functions in the product design, then possible solution principles are elicited and finally the appropriate components are selected. This basic approach is also reflected in the common representation of the development process of mechatronic systems as a V-model (see e.g., [6]). In GBDL, the machine creation and processing of the Design Graph provides the possibility to make the design flow of the product—i.e., the V-model itself—executable [38]. After a design language has been created, the development time for a product variant shrinks to the duration of the translation process and is orders of magnitude below the time of a conventional design loop. The main time expenditure is thus shifted far to the front of the development process, while the many individual design and integration loops can be explored in all variants without any significant additional effort. GBDL is based on the Unified Modeling Language (UML) as the data format. This enables a manufacturer-independent and thus reusable representation of knowledge. The formulation of design and manufacturing knowledge in the form of rules and their linear processing enables reuse and makes the increasing complexity in the product life cycle manageable. GBDL thus provides an innovative and powerful engineering framework that fulfills the requirements set out at the beginning, cf. Section 1 a). Also the central characteristics of the “semantics and syntax”, which are worked out in the BITKOM study, which are “an essential basic condition for [...] interoperability of data storage, data communication and data processing” ([45] pp. 38, l. 1–4) are covered and thus the “integrative development of product, process and production system” demanded in the study ([45] pp. 25, l. 7–8) made possible. In the working group “Design Theory and Similarity Mechanics” under the leadership of the co-author Stephan Rudolph, knowledge-based methods for the design of complex systems based on GBDL have been developed for more than 17 years. In the past, GBDLs were used for the design of aircraft [39] and satellites [40,41,46,47,48], as well as for the modeling of digital factories for aircraft panels and engine hoods [42,49]. In [50], the authors present in a joint preliminary work how the successful linkage can work in an example. The preliminary work is limited to a rudimentary realization that is focused on a production engineering module. The development of a complete GBDL for product and suitable production, as well as automatically generated, iterative VCOM, is therefore the task for this application.

GBDLs can map the product design completely digitally. With this type of automated product design, the main effort in terms of time is shifted forward to the creation of the GBDL. In return, the time for design and integration shrinks to the pure running time of the machine translation process. Since the execution of the GBDL with modified boundary conditions (feedback) can be repeated as often as desired, a “scanning” of the design space (DoE) is made possible, whereby also unconventional solutions can be considered. The combination of methods for VCOM and GBDLs thus represents a highly innovative and promising concept for the development of modern PSs. In this work, the software Design Cockpit 43^® is used to execute the GBDL embedded in the EIPPM. For more information about this software please refer to [51].

2.3. Literature Review of Model-Based Engineering for Production Systems

As argued in [5,52,53] the introduction of MBSE in PS engineering is an important step to cope with the ever increasing complexity of PS. Driving motivations are higher product variety and increasing mechatronical interdependencies. However, there is a trade-off between the added value of fully mapped systems and the additional modeling effort [53]. Besides technical improvements the intercommunication of contributors of all disciplines is improved by MBSE methods [52]. The authors are convinced that in the future, model-based, iterative and SBE of PSs will predominate, likewise taking product requirements into account. Due to the sheer volume of publications in the field of design methodology, simulation technology and product-production relations, this work sets focus on contributions from the fields of Model-Based Engineering (MBE) and MBSE for PSs. Both MBE and MBSE are, according to the knowledge of the authors, not used to any significant extent in the PS engineering industry, which is why the topic is still seen as a subject for fundamental research. The authors in [54] identify a high increase in research and publication work on “modeling languages for Industry 4.0 questions” within the last four years of their study (2015–2018). The two main goals of all projects and initiatives can be summarized as (a) using a systems engineering/model-based engineering approach to cope with an ever increasing complexity of PSs, (b) increase the ease of use in creating and using the (central) data models of the PS. The authors see an untapped potential in integrating product requirements with the production requirements, in including variants during the entire development process, in using simulation-based verification and validation in every step of the development and in removing the effort of data model creation. Therefore, the following following requirements are defined, partly formulated in [5], to review state-of-art literature:

/R1/

Model-based description and coupling of a product and its associated PS (semantic interoperability)

/R2/

Automatic derivation of solution variants of the PS from the description

/R3/

Automatic generation of simulation models for the PS

/R4/

Feedback from simulation-based validation into system design

Table 1. Evaluation of the reviewed literature according to the criteria /R1/–/R4/.

Reference	/R1/	/R2/	/R3/	/R4/
MechatronicUML and Pohlmann [55,56]	either of them
Alvarez Cabrera et al. [57]	production
Project AutoVIBN [60]	production
Project IMoMeSA and Hackenberg [58,59]	either of them
Project KitkAdd, Jacob et al. [68,69,70]	both
Project mecPro2 [71]	both
Albers et al. [61,62,63]	product
Bursac [66]	product
Oestersötebier [72]	product
Stoffels et al. [73]	both
Project WieMod and Voß [74,75,76,77]	production

not fulfilled; partly fulfilled; fully fulfilled.

shows the digest of the literature review. As the literature review was carried out with the focus on model-based engineering approaches all of the considered contributions do partly fulfill /R1/. We differentiate between solutions modeling product, production, either of them or both (cf. second column in Table 1). Many contributions focus on model-based generation of software code to automate a mechatronic product or PS, e.g., [55,56,57,58,59]. The modeling language MechatronicUML cf. [55] is able to model mechatronic systems’ composition and behavior. In the work of Pohlmann [56] MechatronicUML is used as a basis and is used to generate simulation models in Modelica for model-in-the-loop simulations of the software design. The work is missing a full virtual validation generation and feedback loop /R3/ and /R4/. Besides, MechatronicUML itself provides a development process that covers the development of mechatronic systems from formal specification of requirements until the generation of platform-specific software code. A full representation of product and production is not achieved /R1/. Further work on model-based generation of software code for mechatronic systems can be found from [57] and [59]. Their concepts aim at model-based generation of the software component for mechatronic systems, partly satisfying /R2/, but not for the entire design of a PS. The authors of [57] are proposing a framework that integrates discipline-specific models and couples them, also allowing the inclusion of simulation and verification models. The verification steps do not allow a predefined feedback into the system design, see /R4/. The work of [59] is based on the project IMoMeSA [58] funded by the German Federal Ministry for Economic Affairs and Energy (BMWi). IMoMeSA is the successor of the project AutoVIBN, cf. [60]. The outcome for AutoVIBN was a functional modeling technique for the modeling and generation of VCOM models. The succeeding project IMoMeSA extended the modeling technique from AutoVIBN by integrating requirements and failure mode and effects analysis. The latter allows the modeling of erroneous behavior of the PS. With the extended model the generation of software code, discipline-specific models like CAD (Computer-Aided Design) and FEM (Finite-Element-Method) is realized. The combined contribution from AutoVIBN and IMoMeSA is not able to model both, product and production with their interdependencies, cf. /R1/, and to include variants in the data model, cf. /R2/.

In product development Albers et al. contributed in several works [61,62,63,64] to enable MBSE approaches and foster re-use of information in multiple ways. Between product generations, knowledge can be transferred using product profiles linked to product functions [64]. For the continuous validation of products, the authors aim at the re-use of knowledge of validation environments by using elements of a reference system [65]. The authors do not go into detail about the creation of Simulation-based validation environments /R3/.

The work of Bursac [66] is a contribution towards a more efficient development of products using construction kits. He combines construction kit-based engineering with the concept of Meta Object Facility^TM (cf. [67]) and the Integrated Product Engineering Model (cf. [63]). Its goal is to promote an iterative product development process. The approach relies heavily on the existence of reference products to create reference models for the construction kit. VCOM does not take place /R3/ and the production matching the product /R1/ is not considered.

Within the project KitkAdd [68], Jacob et al. developed a model-based method to couple product characteristics with production technologies [69,70]. From the models, technology chains can be derived, compared and iteratively improved. Improved parameters can then be followed up to reduce production costs. The approach does not use simulation-based validation /R3/ and is limited to existing solutions of manufacturing units /R2/, not considering all disciplines of the design process.

The systematics resulting from the project mecPro² [71] describes a holistic data model based on SysML (see https://www.omgsysml.org (accessed on 25 March 2021)). Three different dimensions are declared: variability, detailing, concretization. In addition, four levels (context, function, solution principle, component) are identified. The result is an extensive model-based coupling of product design processes, methods and IT. For the administration of data models the authors developed an integration with existing Product Lifecycle Management systems. The data model of mecPro² is only descriptive and not executable /R2/, as the SysML language lacks a semantic. For each addition to the model its semantic must be extended. The mecPro² approach uses models for simulation modeling and linking with native simulation files to enable a simulation-based verification /R3/. SBE is not fully enabled as native simulation files are needed and no X-in-the-Loop environments can be generated.

The approach of Oestersötebier [72] enables a semantic linking of knowledge for the modeling of complex mechatronic systems. However, Oestersötebier derives from the a state of the art analysis, that an automation of the design process does not seem reasonable /R2/ and limits his contribution to the support of the development by: efficient reuse, support of information exchange, both based on a model-based design.

Representative for the research in the field of integrated product and production development at Saarland University is the work of Vielhaber et al. The authors in [73] e.g., specify an integrated selection process that considers production process, material and product in combination. The combinations are generated with the help of a morphological box and subsequently evaluated under consideration of economic, ecological and technical aspects and visually represented in a three-dimensional coordinate system. The approach represents a pure process description which cannot be used for an automated generation of artifacts, not fulfilling /R2/ and /R3/. Other influences, such as the shape or physical effects (e.g., mechanical loads) are not taken into account /R1/.

A contribution aiming at the continuous generation of simulation models throughout the development process /R3/ is the project WieMod, cf. [74,75,76,77]. The main goal for the project was an earlier usage of simulation and a reduced effort in creating the simulation models. Verl et al. [74] reduce the creation effort by adding simulation models with mechatronic units in a construction kit, where every component instantiates its simulation model effortless. Not considered within the solution are product requirements that influence the PS and the creation of the PS variants /R2/.

There is a variety of standardized and quasi-standardized modeling languages to represent PSs in the context of the digital factory. In [78] SysML, MARTE (see https://www.omg.org/omgmarte/ (accessed on 25 March 2021)), CMSD (see ttps://www.sisostds.org (accessed on 25 March 2021)), AutomationML (see https://www.automationml.org (accessed on 25 March 2021)), Modelica (see https://www.modelica.org (accessed on 25 March 2021)), Eclipse Ditto and Vorto (see https://www.eclipse.org/ditto/ and https://www.eclipse.org/vorto/ (accessed on 25 March 2021)), VDI/ VDE 3682 [79] and Project MAYA (see http://www.maya-euproject.com (accessed on 25 March 2021)) are examined. We conclude from the work, that (a) none of the modeling languages is able to represent a PS as a whole system, (b) only some of the modeling languages are suitable for model-to-text transformations to generate simulation models, (c) None of the languages allow a coupling of product and production features.

2.4. Interim Conclusions

The authors did not identify any literature dealing with all four requirements simultaneously. Most contributions focus on a specific way to facilitate the creation and the usage of a (central) data model for MBE/MBSE purposes. The state of the art however shows that the model-based description of either products or PSs has been researched widely. The authors therefore do not see their contribution primarily in the creation of an additional description language, but in the way in which the description language is used. All the referred contributions on MBE and MBSE for PSs fall short on the idea that the data model itself is created manually versus generated in an automated way. This paper focuses on capturing the knowledge of involved disciplines to be able to automate the creation of the central data model. On top of a facilitated model creation, multi-domain discussions are enabled by simulation-based verification and validation.

The use of GBDL and SBE fundamentally changes the distribution of roles in the development process. In the future, design models will be jointly defined by system theoreticians together with engineers from mechanics, electronics and software. The solution variants will be created automatically and without the intervention of an engineer. Only the evaluation and selection of a solution variant is still the responsibility of the engineer. The decision making process will be supported virtually throughout. In the virtual representation, the authors see the optimal form of knowledge representation for all stakeholders involved. In current MBE approaches the representation is usually neglected [54]. The approach presented in this paper is entitled EIPPM—The Executable Integrative Product-Production Model. In order to achieve a real benefit, the authors define the following goals, derived from the requirements /R1/–/R4/, for the EIPPM:

• Formal storage of knowledge in the form of class diagrams and rules for simple know-how reuse
• Full semantic interoperability in the modeling of the product and the associated PS
• Fully automatic derivation of solution variants
• Fully automatic generation of simulation models for continuous virtual verification
• Feedback system of simulation-based validation and optimization back into system design model

Further positive side-effects, partly formulated in [5], are: First, a reduction of the effort for simulation model creation. Second, a consistent connection of the mechanics, electronics, software and simulation disciplines throughout the engineering. Third, generation of simulation models starting with the planning phase.

In the following section, the EIPPM is introduced. The interaction of product and production is achieved via the EIPPM. In addition, the dynamic data model of EIPPM is described and how the simulation models are integrated there.

3. The Executable Integrative Product-Production Model (EIPPM)

The innovation of the EIPPM presented in this paper stems from the fact that all models and artifacts needed during the development process of a PS—taking into account also the interconnection of product and PS—are generated fully automatically. This total design automation involves applying modern modeling principles, procedures and data structures that originate in computer science. GBDLs (see Section 2.2) provide all these prerequisites and are therefore used as a basis here. In the following, the fundamentals of the methodology underlying the EIPPM will be described.

A general and abstract approach to product design is offered by the systematic design methodology according to Pahl and Beitz [44]. Thereby the requirements are initially mapped to abstract product functions, then possible solution principles are determined and finally the suitable components are selected. The components are then assembled into subassemblies, which in turn are finally assembled into the product. This basic approach is also reflected in the common representation of the development process of mechatronic systems as a V-model (see e.g., [80]). In GBDLs, the automatic creation and processing of the Design Graph makes it possible to automate the steps of the V-model [38]. The unique possibility of describing interrelationships of different domains via linked class diagrams (domain ontologies respectively vocabulary) enables a continuous and consistent description of all tangible and intangible elements of the design process. This means that data of conceptually separate domains does not have to be linked manually at a later time (as in most of the approaches presented in the state of the art), but the interlinking is already contained in the “structure” of the modeled class diagrams. Semantic interoperability is thus an inherent feature of the graph-based methodology. Once the required classes have been defined, instances of these classes can be created and combined with each other in rules (in accordance with the dependencies defined in the class diagram). A compiler assembles possible variants of the system according to the defined rules. This process fulfills the condition formulated in /R2/ (see Section 2.3). Since the class diagram restricts the possible combinations, it represents an envelope of all possible designs—the design space. The rules and the translation process in the compiler then serve to “scan” the design space and thus to find the best possible solution as a unique connected instantiation of the vocabulary. The design space defined by the class diagrams is always larger than the meaningful one, since not every possible instance of a class is technically valid: For example a mass attribute or a length may never have a negative value. There are two fundamentally different ways of dealing with this problem. Either the rules are formulated in a way that prevents a “degenerate” design or the “wrong” designs are sorted out in a subsequent step.

After a GBDL has been created, the development time for a product variant shrinks to the duration of the compilation process and is orders of magnitude faster than conventional design loops. The main time effort is now spent on the creation of the GBDL, while the design and integration loops can be explored in all variants without significant additional effort. Figure 3 illustrates how in the EIPPM product and production design are combined into one single design cycle and how the complex relationships can be ensured to be consistent. In this way, requirement /R1/ (see Section 2.3) is fulfilled.

The product design and the production design are shown on two different levels. This is to better illustrate the time sequence, where production planning usually follows product design. Depending on the product being produced, a different PS is required. The structure within both design levels is based on the aforementioned systematic design methodology [44]. Here it is important to emphasize the combination of a well-researched design methodology (Pahl/Beitz) with the innovative possibilities of GBDLs. From a practical point of view, this means that for each level of abstraction—requirements, abstract product functions, solution principles, embodiment, assemblies and product—the required building blocks must first be formulated in the form of a class diagram. This modeling process applies to both product- and production system design. In addition, associations and inheritance are used to define which module (class) can be combined with which other module. For example, the class diagram defines which type of requirement can be implemented with which abstract product function. It is also determined which abstract product function can be realized by which solution principle and so on. The actual instantiation and combination instruction is defined in rules. The compiler will then generate a valid variant for the boundary conditions applied. In this context, “valid” means that the initially defined boundary conditions for the product and the PS can be fulfilled. No statement is made about how well these are met compared to another variant. This must be decided in a downstream evaluation step. In Figure 3 this is indicated in by the filled black circles and the arrows between the stages. White circles are to show that an instance is not valid under the conditions defined by the previous step. The dotted arrows are intended to indicate that the compiler has examined several instantiations. This varying instantiation process is ultimately responsible for the generation of variants and the presence of multiple variants in a single design graph (“150% model”). The blue arrows (between the levels) show mappings between the product and the PS. This means that the specifications for the product can be interpreted as requirements for the production design. In this way, product and production are naturally linked. Semantic interoperability makes it possible to resolve this without further intervention. All that is needed is to formulate appropriate rules for the production design. Building on the decisions already made for the product, the further design of the production can partially be inferred from this. Of course, there are also requirements for the production design independent of the product. This is symbolized in Figure 3 by a requirement not linked to the product design. Finally, the methodology is validated by means of automated simulations.

The integrated generation of simulation models needs to meet certain requirements. As the authors focus on simulation models for VCOM of PS, certain simulation disciplines are of special interest: logical behavior, kinematic behavior, physical behavior, process behavior and material flow. The aspects of all those simulation (model) types must therefore be integrated into the GBDL. The modeling with class diagrams and rules will be able to extend the GBDL with a meta-simulation model to cope with this requirement. Standard VCOM simulation models consist of one behavioral model and a second visualization model. The principal part of information for both models will be handled in the modeling of the design space: The current creation of simulation models uses the same source of information (Mechanics CAD, Electronics CAD, functional specifications, manuals and compendiums, communication specifications and many more) that the GBDL comprises. When advancing with the modeling of the design space a validation of the modeled information is important. In this sense, the requirement /R3/ is fulfilled. From the evolving simulation models it will be clear to see whether errors in form of missing or wrong classes, attributes and constraints are present. The evolution of the system will also be represented in the simulation system’s characteristics. Ranging from MiL simulation with a rather abstract simulation model and a model-based description of the control code to MiL where control code is tested on an emulated control to HiL simulation using the control code and the real hardware control.

The simulation model is to be used from two aspects. First, to verify the design space spanned by vocabulary and rules of the GBDL and the derived Design Graph in the sense of the PS (e.g., scientific laws, signal processing or error behavior). Second, in the sense of requirements from the product and customer (including cycle time, cost, scrap rates, etc.). Both test scenarios lead to feedback into the design of the GBDL thus fulfilling requirement /R4/ (see Section 2.3). How further variants of the product-production system can be evaluated in the EIPPM is explained in the following section.

Iterative Generation of the Product-Production Model, the Simulation Models and the Assessment

The aim of the EIPPM is to transfer the flexibility of product design to the development of production design. This is to be achieved by creating a large number of variants. The prevailing “first-time-right” methodology must be subjected to a paradigm shift [31].

An automated, simulation-based and iterative development philosophy across all disciplines of product-production system development is indispensable for this. The authors see the following four main advantages in such an approach:

• Automated model-based system development for a complete and consistent description of the complex “product-production” system
• Iterative approach by automated expression and analysis of variants of the PS on VCOM simulation models
• Supporting methods for the optimization of the variants or for the optimal selection of a variant
• Simulative identification of weak points in the generated product-production system and transfer into improvement suggestions for the automated design process

To get a better understanding of the EIPPM, the automated run through of a design cycle is schematically shown in Figure 4. As already explained in Figure 3, the phases requirements, abstract product properties, manufacturing principles, machines, cells and PS are traversed. The data model was imaginary “sliced” in Figure 4 at several characteristic stages of the production design. The structure of the slices can be read off at any time with the overall model increasing in size as time goes on, represented by “annual rings”.

Each individual design phase is a closed iteration cycle in itself, which is influenced by the layer directly underneath. For example, the Abstract Product Properties can be generated from the Requirements by iterating over all possible product properties. Once the Abstract Product Properties have been defined, it is possible to move to the next layer—in Figure 4b) the Manufacturing Principles—to initiate the next iteration loop. For the VCOM, as a central element of the EIPPM, three time slices are of particular interest: In addition to the final HiL simulation (Figure 4d)), these are the MiL- (Figure 4c)) and MiL (Figure 4b)) simulations performed at earlier points in time according to [23]. The MiL phase is at a very early stage of the design cycle. The data model is at a rough, descriptive level and includes the Requirements, the Abstract Product Functions and the Manufacturing Principles. From this data, the MiL simulation model can be generated automatically and used to verify the overall data model created to this point. If the model is not executable or only executable to a limited extent, the current run is aborted and a new run with changed boundary conditions is triggered. The generation of MiL simulations is similar, but with a more detailed data model. At the time of HiL simulation, the data model is very detailed (cell level) and includes machine code executable on the hardware (real control, simulated PS). This model can also be generated fully automatically via an interface from the EIPPM. When all iteration loops and associated simulative tests have been successfully run using VCOM, a PS is completely designed. Since the design problem is usually not completely and unambiguously defined, multiple solutions can be expected. This is shown in Figure 4b) by the orbiting slices, each of which represents an individual PS, that still has to go through the further process of verification. The selected variant can then be built.

While Figure 4 explains the design process with the EIPPM, Figure 5 shows the correlation of artifacts in the approach. The levels L0 to L3 are inspired by the levels according to the Meta Object Facility^TM (MOF) by the Object Management Group [67,81]. As described in Section 2.2 the GBDL approach uses UML and thus MOF as the modeling framework, cf. L3. When using the EIPPM, the system design model, on L2, must be defined first using the modeling framework. It contains all permissible variants on type level of the system (the so-called 150% model, cf. [82]). With the instantiation in the virtual world on L1, in the form of the system instance model, a permissible variant on type level is generated from the 150% model. The automation of the instantiation is made possible by applying the set of rules on the ontologies, on L2. The information contained in the system instance model can be transferred to a discipline via interfaces, e.g., generate a simulation model. The simulation model is a model of reality, in this case of a PS. Another interface can generate e.g., CAD data from the system instance model (cf. [83]). L0 represents the objects of the real world—product and PS. The challenge is the feasibility of an automatic generation of meaningful and comprehensive variants for the simulation-based solution selection. The mapping of facts, components and couplings of a product-production relation is non trivial and requires the cooperation of different domain experts.

4. Application Example

In order to illustrate how the EIPPM works, the modeling of an assembly line PS will be described in this section at a basic level. The example assembly line is an Industrial Mechatronic System (IMS) by Lucas-Nülle^®, installed for educational purposes at the Institute for Control Engineering of Machine Tools and Manufacturing Units at the University of Stuttgart. The IMS is built from real industrial actuators, sensors, communication system and control and is capable of building eight product variants from three different parts. All parts and product variants of the example are shown in Figure 6.

To illustrate the interdependencies of product and production a new cover part is introduced with a new functionality of a reflector part, see right hand side of Figure 6. Listed below the new part in the figure are the modifications necessary for product and production.

The IMS assembly line has a ring-shaped topology. Eight straight and two 180°—curved conveyor belts move workpiece carriers around in order to reach the necessary assembly station. Assembly stations consist of the conveyor belt and an assemble module of which three types are used to provide the parts bottom, cover and bolt. A fourth type of station includes a Handling module to remove finished products from the workpiece carrier and the assembly line. Figure 7 shows the entire PS with its seven stations and the conveyor belts.

For each valid product one bottom part (black or white color), one cover part (black or white color) and one bolt part (red or silver color) is selected and sent as an order to the IMS. The control’s task is then to assemble the product as defined in the order. The assembly process begins by moving a workpiece carrier via a conveyor belt into the first station with the appropriate Separate module for the bottom part. On the base plate of the Separate module are two profile rods that serve as part storage. Inside of it, the bottom parts, are stacked to a tower. By a pneumatically actuated rocker arm, the stacked parts are separated from each other and dispensed individually onto the workpiece carrier. Next, the workpiece carrier is transported to the appropriate Assemble module to include the cover part into the product. Except for a diverging geometric of the rocker arm the module’s functionality is the same as the one of the Separate module. The stored cover part is separated through a rocker arm and dropped onto the bottom part. Then, the workpiece carrier is moved to the appropriate Finish module, where a pneumatic cylinder inserts the bolt part by pushing it through the holes in bottom and cover part. Like this, the final product is fastened. Finally, the workpiece carrier is moved beneath the swivel arm of the Handling module. The arm is equipped with a vacuum gripper and can lift up the product through a cavity in the base plate from the pickup position, rotate it by 90° and place it down on the deposit.

4.1. Modeling of the Class Diagram

The modeling process of the EIPPM starts with the definition of the class diagram. Figure 8 shows a simple example class diagram for the IMS to be described in this section (Note: If you are reading this article on screen, you will be able to zoom into the class diagram as it is a vector graphic file). The depicted class diagram does not claim completeness and is only intended to give an impression of how the EIPPM can be implemented. An industrially applicable class diagram with all details and dependencies would go beyond the scope of this paper and would not be useful for illustrating the process.

A typical first approach to modeling the class diagram is a mental decomposition of the system. The decomposition can refer to different properties, for example geometrical, mechanical, functional or discipline-specific. In this example, we started with a decomposition based on the mechanical components. The classes in the third line of the class diagram, e.g., Frame, Base_Plate and Stand are examples of such component-oriented classes. In addition to the mechanical functionality of the modules, there are still further dependencies that must be taken into account in the modeling. The dimensions and spatial positioning, materials and simulation fragments can be mentioned here.

Class diagrams can be nested, that means that not all information and dependencies have to be included into a single class diagram. An import mechanism allows classes from other projects to be accessed. This enables a sensible encapsulation of design knowledge. A common approach here is to first model independent class diagrams for the domains involved and then map the dependencies of these classes in a separate integration class diagram. In the example class diagram above, the different coloring of the classes Material, Color, Position, Dimension and Simulation at the very bottom indicates that these classes were imported from other class diagrams.

Since the modeling of the individual modules of the example PS is very similar from an abstract point of view, only the Handling module is described in more detail in the following. In design languages, there is a rule of thumb that the nouns used in a domain are the candidates for the classes. With this in mind, the Handling module is shown again in detail in Figure 9, where the relevant components are named. These names are the basis for the transfer to the class diagram. Figure 10 shows the relevant section of the overall class diagram (see Figure 8) in an enlarged view.

The entire module is represented by the Pneumatic_Swivel_Unit class, which in turn inherits from the more abstract class Module (cf. Figure 8). This class has dependencies (in the terminology of the UML so called associations, read: has-a) to its associated classes. These are for example the classes Part_Pick_Up, Rotary_Plate, Vacuum_Gripper, Swivel_Arm and Part_Deposit, where the representation being apparent from their names. The dependencies beyond the system boundaries can also be identified. All mentioned classes have an associated Simulation, Dimension and Position class. Furthermore, the classes Rotary_Plate and Swivel_Arm have a sensor-association. This association is provided with a multiplicity ([1..${}^{★}$]), which means that there can potentially be several sensors for one component. There are also associations that point to classes in this section view, e.g., the vacuum_Hose-Association. This association represents vacuum lines that connect the components of the module.

4.2. Modeling of the Activity Diagram and the Rules

There is next the need to instantiate concrete objects and links from the abstractly formulated classes and associations. This action requires the definition of rules and activities. Just like class diagrams, activities can be nested and imported. Figure 11 shows the overall activity diagram. The subprograms separate, assemble, treat and handle can be recognized, as well as the two graphical rules AddPLC and ConnectPLC.

At this point again we want to concentrate the description of the activities and rules on the Handling module in order to avoid repetitions. The modeled activity diagram of the Handling module consists of 12 graphical rules and is shown in Figure 12.

In the activity diagram the order in which the compiler should translate the rules is defined. In above case, the handling module and the associated station are first created in rule “AddStationHandle”. Then, in rule “AddSwivelUnit”, the Pneumatic_Swivel_Unit is instantiated and linked to the module. Next, the Rotary_Plate, the Swivel_Arm, the Vacuum_Gripper as well as the Part_Pick_Up and the Part_Storage objects are created and linked in the corresponding rules. After that the Pneumatics_Valve_Block, the Valves and the Pressure and Vaccuum-Line Links are instantiated. Finally, the Sensors and the Simulation instances are added to the data model (Design Graph).

Graphical rules all have the same structure. There is a Left- (LHS) and a Right-Hand Side (RHS). The graph pattern defined on the LHS is searched for on the Design Graph created so far. If it is found, the action described on the RHS is executed. Figure 13 shows the in-depth structure of the graphical rule “AddVacuumGripper”.

In this rule it is defined that if there is a Module named “M0009683” linked to a Pneumatic_Swivel_Unit in the Design Graph (see LHS of Figure 13), then a Vacuum_Gripper with a specified Dimension and Position is created and linked accordingly linked accordingly with the other objects. That way, the overall data model is further enriched.

4.3. The Design Graph

Once all the rules and activities are formulated, the Design Compiler can translate the instructions dynamically into the data model—called the Design Graph. Figure 14 shows the overall design graph for the entire IMS, after one iteration cycle (Note: If you are reading this article on screen, you will be able to zoom into the figure as it is a vector graphic file).

The Design Graph consists of nodes and edges, that represent an individual instantiation of the classes and associations formulated in the class diagrams and instantiated in the rules. Four larger clusters can be seen in the graph, connected by the central element of the controller (PLC, in turquoise). These are the four modules described above.

Figure 15 shows the part of the Design Graph belonging to the Handling module. The image is a section (enlargement) of Figure 14, recognizable by the turquoise arrow pointing to the first green node (Contact_Terminal_Block).

In the figure, for all nodes that have a geometric representation (shape), the abstract circles of the default graph view have been replaced with images of the represented component.

4.4. Generation of the Simulation Models

Apart from the concept given in Section 3 for the derivation of simulation models—which would require the formulation of numerous rules that would go beyond the scope of this educational example—a simplified way to couple a simulation library with the GBDL data model was chosen here: For a straight forward way of generating simulation models the graph from the last section, see Figure 14, is extended by a placeholder object Simulation. Each module is linked with its own simulation placeholder, that represents an object from the simulation library. In this case the composition of the simulation model will be derived from elements contained in a library. A generator (model-to-text) will then be able to transform the composition into the executable simulation model. The elements in the library are predefined solutions in a specific simulation tool and can be parameterized and connected together. For the application example the granularity ends at the module level which corresponds to the Cells level in the EIPPM. This leaves the observer of the class diagram with a black box representation of the simulation model, equivalent to the representation in the simulation tool, see Figure 16. The simulation model is only shown for the Handling module. For the other modules, however, the procedure is completely analogous.

Part of the inner structure of the black box model is shown in Figure 17. The screenshot has been labeled with the functionality behind the structure, rotary plate movement. Note, some of the green input and blue output ports can also be seen in Figure 16. The input pressure_hose_to_rotary_plate connected to the entire pneumatic swivel unit (Figure 16) delivers the medium (or signal) to the substructure (Figure 17) to rotate the plate by 90°. This will result in the same movement by the linked swivel arm. Feedback towards other simulation structures comes from the output ports (rotary_plate_0_degrees, rotation, rotary_ plate_90_degrees). As shown in the substructure the rotation is realized with an integrator behavior allowing for a smooth movement.

The purpose behind the detailed description of the simulation substructure is to show that all the instances, connections, constraints and parameters within the simulation model must be modeled in the EIPPM. Later, the simulation will be derived from the Design Graph and translated into an arbitrary simulation tool. This is the focus of the future work by the authors.

5. Discussion

In this section, the results, as well as the advantages and disadvantages of the EIPPM will be discussed in more detail. Since the presented approach partly emerged from a deficit analysis of the status quo in PS design (see Section 2.3), these deficits were deliberately addressed in the EIPPM. In addition, the embedding of a GBDL in the EIPPM and the intelligent linking with SBE is a key aspect of the presented approach.

A major advantage over other approaches is that a simulation model can be derived i.e., generated automatically from the EIPPM and executed at any time. This enables early and iterative use of simulations at different levels of detail (MiL, SiL or HiL) for validation of the current model stage. At the same time, validation by simulation can provide feedback that can lead directly to a modification of the boundary conditions and thus initiate a new design cycle with adjusted boundary conditions.

Another advantage of the EIPPM is that the data of the complete product-PS design is united in a central and interlinked data model, the design graph. In consequence, all disciplinary models are always consistent with each other, due to the automated generation from a common source. Domain-specific models (e.g., simulation models) can be generated in the appropriate format via interfaces from the design graph, see Figure 2.

Third, since the product is also modeled in the EIPPM, the dependencies between product and PS can be mapped directly. Changes to the product will therefore be taken into account immediately in the PS design. Within the EIPPM there are static components that do not change at runtime. These include the class diagram(s), the activity diagram(s), the individual rules and the interfaces. However, the activity diagram can contain elements that branch the flow depending on the precondition and the rules can also be formulated in such a way that different constraints lead to a different result. So overall, the design graph—i.e., the actual representation of a design cycle—is individually generated during execution. The design graph can then be translated at any time via interfaces into the target language of the desired domain.

The executability of the EIPPM, which it owes to its implementation as a GBDL makes a design of experiment possible that can be performed by changing the boundary conditions of the product and/or the production. This can not only lead to an optimization of the interaction between product and production, but also unconventional solutions may be considered that would otherwise never have been accounted for in the rigid models of the current status quo. As to the nature of this variant creation, there are two possible cases. In the first and simpler case of the two, they are merely parametric variants. These are characterized by the fact that the structure of the design graph remains constant and only the values of the attributes change. An example for such a parametric variant would be a change of the dimensions (e.g., additional 10 cm in length) of a component that remains constant in its shape (e.g., cubic). The second kind are topological variants, which are well supported by the re-executable sequence of design rules which directly manipulate the design graph as the abstract data model of the topology of the product and the production means.

As for the scalability of the approach, it should be noted that the Design Cockpit 43^® can cope with very large models. Graphs with several hundred thousand nodes can be processed on a standard computer without any problems. The approach can also handle nested models. This plays a role especially for more complex products, which may consist of partial assemblies with their own PS. Here, the ability of GBDLs to modularize comes into play, allowing different projects to be combined into one. A recent publication on the topic of system of systems in GBDLs using the example of a production line and the associated building can be found in [84].

A disadvantage of the methodology is the increased modeling effort—creation of the class diagrams, rules, activities and interfaces—an activity which must be undertaken before the first designs can be generated. However, all the subsequently necessary models can then be generated automatically. In this creation process, the generalization effects (i.e., the existence of parametric and topological variants) must be taken into account. For the creation of a single product-production model, this effort exceeds that of modeling with the tools and procedures of the status quo. In [85], this trade off between modeling effort and benefit from automation in knowledge-based engineering is discussed. The authors conclude that knowledge-based approaches—as the EIPPM also represents one—are, however, superior to manual ones in the long run. This finding at least gives hope that the EIPPM can ultimately reduce time-to-market. In principle, this would require a comparison of classical modeling with the EIPPM approach. However, this would go well beyond the scope of this paper, which is concerned with presenting the systematics. This issue will have to be addressed in future studies.

6. Summary and Conclusions

In this work, a new approach for the engineering of PSs was presented. The motivation for a new way of designing PS, also taking product requirements into consideration, stems from multiple shortcomings in current PS engineering. The authors name the exclusion of solution variants and discipline-specific decision making, as the two most disadvantageous actions. These disadvantages come from the predominant engineering process model that is mostly sequential and without feedback loops. These identified problems are not new to the research community and the most prominent way to address the shortcomings is seen in MBSE approaches (see Section 2.1 and Section 2.3).

The authors introduced the fundamentals of VCOM and GBDL, as these topics are the base for the new engineering approach. With that knowledge and the given disadvantages, specific requirements were derived to conduct a literature review. From the literature review, the authors concluded that (a) none of the methods in the reviewed papers met all four requirements defined as indispensable for future automation in the context of this work, (b) the state of the art showed that model-based description of either products or PSs had been extensively researched, (c) the state of the art focused on facilitating the manual creation and handling of a central data model representing the PS or product.

The new approach, called Executable Integrative Product-Production Model (EIPPM), uses a central data model but fundamentally changes the creation and update mechanisms of the model through automation. The automated creation and update, as well as transformation to discipline-specific models and views, is enabled through a formal description of vocabulary and rules. Vocabulary and rules are executable with a translation step of a compiler. Combined with a generation of simulation models for verification and validation tasks engineers are enabled to view and interact with the current state of the solution at any time. The feedback from engineering experts is taken back into vocabulary or rules to update the system design model. Requirements, from customer and the product to be produced on the PS are all modeled and thus taken into account.

To demonstrate the current state of the work progress an example PS from a laboratory course is used to show how the methodology can be applied in practice.

In the eyes of the authors, the presented work brings us a decisive step closer to the ultimate goal a of fully automated design of PSs. Nevertheless, there is still a long way to go. The implementation of the automatic generation of virtual validation setups, based on a meta-simulation model is the consequent next step that has to be done. Also, the EIPPM will have to be extended to map further applications. Finally, the procedure behind EIPPM will have to be described in the form of a manual to be widely used.