AutomationML: From Data Exchange to System

AutomationML: From Data Exchange to System Planning and Simulation Sebastian Faltinski1 , Oliver Niggemann2

Natalia Moriz3 , Andr´e Mankowski4

Fraunhofer IOSB-INA Competence Center Industrial Automation Langenbruch 6, 32657 Lemgo, Germany Email: 1 [email protected], 2 [email protected]

inIT-Institut Industrial IT University of Ostwestfalen-Lippe Liebigstr. 87, 32657 Lemgo, Germany Email: 3 [email protected], 4 [email protected]

Abstract—The planning, testing and integration of modern automation systems is becoming more and more a bottleneck in the construction of new production facilities. This is due to the facts that plants grow in complexity and that modern automation systems are highly distributed and comprise complex components. To cope with these challenges and to guarantee short implementation times and a small number of errors for the automation systems, modern development processes are needed. Such modern processes can be reduced to four main aspects: (i) A seamless process with corresponding seamless tools, (ii) a high level of model reuse and adaptability, (iii) executable models and early tests, and (iv) a system-wide planing process of the distributed system. Therefore, the established tools landscape which its specialized tools for each discipline of engineering has difficulties to keep up with these trends. The approach presented in this paper implements a development process including the aspects (i) - (iv) using the new data exchange format AutomationML. AutomationML serves as an enabling technology and has the potential to change future development processes and may trigger the development of new, better integrated tools.

I. I NTRODUCTION The creation of a seamless engineering tool chain for the design and maintenance of complex automation systems remains a so-far unsolved problem; instead of a seamless tool chain isolated tool islands can be encountered: E.g. CAD tools do not communicate with electrical planing tools, control engineering tools remain separated from plant simulation tools. The result are inconsistencies and data redundancies, which lead to prolonged plant construction times. The new, XML-based, file format AutomationML is currently the only solution approach [1]: AutomationML is a vendor-independent data exchange format. While AutomationML is still being developed and currently falls short of solving all data exchange problems, it seems to be for two main reasons automation’s best bet for a future seamless engineering tool chain: (i) It is a standard supported by some of the biggest players in the field of automation and (ii) it is based on the flexible CAEX standard which follows modern modeling concepts such as an explicit meta model representation [1].

AutomationML refrains, from defining a specific development process: Tools and file formats should follow a companies development process and not vice versa. But reality often behaves differently: New tools and new technologies are often enablers, or catalysts, for process improvements. So, this paper describes a development process and a prototypical tool chain based on AutomationML which incorporates modern development paradigms such as: 1) A seamless modeling approach which is based on a common data basis (i.e. AutomationML) for all involved engineering tools 2) A model reuse-oriented modeling approach that supports the dynamic reconfiguration of the automation system 3) An executable modeling approach which supports both the early offline simulation and the hardware-in-the-loop (HIL) simulation of the automation system 4) A system-wide modeling approach that focuses on the modeling and integration of a distributed automation system instead of focusing on single control units The paper will show that AutomationML is especially suited for a modern development process as depicted in figure 1. This paper is organized as follows: Section III outlines in a general way why AutomationML is especially suited for tool integration and therefore for a seamless development process. Next, section IV will apply the Model-Driven Architecture approach of the Open Meta Group (OMG) to the modeling of automation systems with AutomationML. Section V will outline how AutomationML can be used as a basis for simulation. Finally, in section VI AutomationML is used as a basis for a system wide automation model. II. S TATE OF THE A RT IN AUTOMATION -S YSTEM D EVELOPMENT Like outlined in figure 1, the process of production system development in this work is based on modeling. Using a model-driven development process have been used in [2] or in [3] where in the last paper the concept has been applied to the field of industrial automation. A model-based plant engineering especially with the objective to an initial planning process, startup and redesign of production facilities has been investigated in the MODALE project [?]. In this field, the

Paradigm 1: Seamless development process

Simulation

Modeling Platformindependent Model (PIM)

Platformspecific Model (PSM)

Paradigm 2: Model reuse and support for reconfiguration

Fig. 1.

Integration Hardware-in-the Loop Simulation (HIL-Test)

OfflineSimulation

Paradigm 3: Executable models

Integration of the Automation System

Paradigm 4: System wide models and support for integration

Development process and corresponding development paradigms.

MEDEIA project is especially focused on the improvement of productivity for the development of embedded control systems [?]. Unlike the field of modeling, the field of simulation is supported by different commercial tools like WinMod [?], SIMIT [?] or DELMIA[?]. Those tools are widely used but focus on different, highly specialized aspects like simulation of visualization of automation systems. Beside the field of industrial engineering, tools ans languages like Matlab/Simulink, Modelica or SysML are used to model different aspects of a system. The third group of tools involved in the process of automation systems engineering are the tools used for integration. Those are PLC programming tools, following the IEC 61131 standard. Examples from different vendors are CoDeSys, Step7 or PCWORX. Beside PLC programming, many other tools for specialized purposes like HMI design or robot programming exist. These examples show that very specialized tools are widely used, but a seamless engineering process is still missing. This makes the engineering process often complex and error-prone. However, AutomationML [1], [4], [5] seems to be promising for a seamless engineering data exchange. III. PARADIGM 1: AUTOMATION ML FOR A S EAMLESS P ROCESS The new data-format AutomationML tries to fill the gap between different engineering tools and disciplines [1]. It provides a file format which is capable of including several types of planing and engineering data of a production facility. AutomationML is based on XML and makes use of well established, open and free standards of the involved engineering disciplines. For example, the structure and hierarchy of a plant is given by CAEX [6], geometries and kinematics are described by COLLADA [7] and the control application of the plant is described with PLCopen XML [8]. Using these standards ensures a slim specification of AutomationML [1]. AutomationML is based on CAEX, which stores the system topology and acts as base for the integration of other fileformats. Within the CAEX structure, objects are organized in a hierarchical structure. Those objects might be a sensor but also a complete production module. Each object comprises a set of properties describing the object, and can be interconnected with another object via interfaces. To provide a machine readable and extendable description of all objects, AutomationML includes the RoleClassLib and

the SystemUnitClassLib, where objects are derived from. The RoleClassLib provides a library of abstract types of plant components (e.g. conveyor, sensor, motor), that can be used to give a certain meaning to objects in the hierarchical CAEX structure. The second level of description is provided by the SystemUnitClassLib. It provides a library of specific products (e.g. Siemens S7-300) that can be assigned to an object in the CAEX structure [5]. This structure allows for seamless data exchange between CAD tools (e.g. Catia, Pro/Engineer) used in the early state of system engineering. Later, tools for logical engineering like Step7, RSLogix, WinCC or RobotStudio are used and AutomationML might also be used in this phase. IV. PARADIGM 2: AUTOMATION ML FOR M ODEL R EUSE A. Concepts of Modeling The proposed modeling approach in this paper is inspired by Object Management Group’s (OMG’s) Model-Driven Architecture (MDA) paradigm (see [9] for details): In a first step, a logical architecture comprising only software modules and plant models is created—MDA’s Platform Independent Model (PIM). In a second step, this logical architecture is mapped onto a specific hardware topology, creating the system architecture—MDA’s Platform Specific Model (PSM). Software components are control algorithms, diagnosis software algorithms or monitoring software modules, used in the automation domain. The main advantage of using the MDA approach in the automation domain is driven by the demand for reusability of planning data. This is due to the fact that components of production systems are typically reused for several automation projects. Especially AutomationML supports the integration of models for different domains while providing a separation and therefore a reuse of these models. Beside the description of the plant itself, each model also includes an explicit meta-description as a library of components that can be used on instance level. This explicit meta-description is the main advantage compared to other modeling languages. Such explicit meta-models included in the AutomationML file can be extended by the user and can be interpreted by tools. B. Platform Independent Model As outlined in figure 1, the platform independent model (PIM) is the initial step in the planning phase of an automation

system. This chapter describes the two main parts of such a platform independent model: structural models and behavioral models. 1) Platform Independent Structure Models: At the beginning of the plant design process, the structure and the components of a plant are sketched in a very abstract way. These first ideas are depicted using a structural model, comprising alignment of plant modules in a first place and might be extended by adding components like sensors, actors or other components in detailed levels of the model. To describe the functionality of elements in this hierarchical model, AutomationML provides the RoleClassLib. In terms of the MDA approach, components modeled as instances of this library end up in a PIM. For each component in the structural model, an additional component might be added to the model which describes the behavior of this component. This additional model is described using either PLCopenXML or a Functional Mock-up Unit (FMU). This concept is described in the following section. 2) Platform Independent Behavior Models: To provide the ability to test the behavior of a plant model, two types of executable models can be added to the structural models. Each behavioral model describes the behavior of a well defined component. Therefore, those individual models can be reused or instantiated several times in the same model. AutomationML describes two different types of models, which are: • Sequencing: Describes the behavior of components, due to some control algorithms applied • Behavior: Describes the behavior of the components due to its physics Due to the AutomationML standard, PLCopenXML is used to describe sequencing which is implemented as control software algorithms and are applied in the PLC. The use of PLCopenXML provides the ability to integrate control software components from the model into PLCs in a later integration process. Beside PLCs, the description of physical components in the plant are necessary to provide a complete system model. The physical behavior of such components can be modeled using mathematical expressions. Those are implemented using tools and languages like Matlab/Simulink, Modelica or MathML. The approach of using MathML for behavior description especially in this context has been described in [10]. MathML is a XML based language to describe mathematical expressions. However such expressions are sufficient to describe the behavior of different components, the creation of such models will become very complex and error-prone. This is due to the fact that MathML does not provide any library to model components behavior. We try to overcome the complex modeling approach in MathML by supporting the component-based modeling approach described above: A structure model defines the system as a set of connected components where each component’s behavior is defined by either a PLCopenXML model or a FMU component. FMU components can be generated from a large set of modeling tools, e.g. Simulink, SimulationX, AMESim,

or Dymola. In this paper we mainly use Dymola models: these models are defined using the well-known Modelica standard [11]. Modelica is an object-oriented and standardized language to model complex physical systems, where standard libraries for different domains (e.g. mechanics, electronics) can be used to describe a system. Furthermore, different Modelica tools like such mentioned above provide an Function Mock-up Interface (FMI). Using this interface, models can be exported as knowhow protected and runable simulation components represented by a FMU. 3) Integration of Behavioral Models into AutomationML: Since the description of physical behavior (using FMU’s) is not part of AutomationML itself, a behavioral model created by external tools and exported as FMU has to be integrated into the structural model. The upcoming AutomationML file format provides a wide range of interfaces for external files, organized in the InterfaceClassLib. Those are used for the integration of PLCopenXML or COLLADA files which are not integrated into a certain AML file by copying its content but by providing a reference to the external file. Based on this association, signals from a real automation system (e.g. a PLC) can be mapped to a simulated component. This modular Modeling

Simulation

AutomationML Library Phoenix RFC 470, Siemens S7-200, ... ...

Functional Mockup Unit (FMU) Specification

AutomationMLBaseRoleClassLib

Meta Level Instance Level

PLC, Sensor, Port, ... ...

AutomationML System Description

Behaviour Model Module 1

Factory Plant Module 1

Behaviour Model Module 2

Interface Plant Module 2 Interface ...

isTypeOf

Reference

Fig. 2. Structure of an AML based System Model including references to Behavioral Models

structure is outlined in figure 2. The AutomationML model acts as basic system description on instance level. Behavior models are attached to components on different levels in the system model (e.g. production cells, robots, or sensor and actor level). This modular approach supports the reusability of each component (e.g. behavior models) used in an overall system model. C. Exemplary Tool Chain 1) Creating Structural Models: To provide tools necessary to create a structural model for this modular development process, we have developed a graphical editor on a prototypical basis which is shown in figure 3. The editor is based on the Visual Studio 2010 Visualization and Modeling SDK [12]. It provides the ability to model the plant structure in an easy way: in a first step the model is abstracted from the hardware used in the plant (PIM). As library of components, the Editor

Plant Model

Module2

Module1 SW component1

Max1

Min1

Conveyer Belt1

Fig. 3.

SW component2

Aspirator1

Funnel Blocked1

Max2

Min2

Muscle Trigger

Aspirator2 Funnel Blocked2

Graphical AutomationML Editor for structural models

uses the RoleClassLib, of AutomationML: each graphical component in the editor is mapped to an element of this library. The editor offers a graphical representation for each of the RoleClassLib components. Examples of these components are robots, silos, belt conveyors, software-modules and signals. In figure 3 we modeled two production modules of our model factory. This factory in small scale transports bulk material from a storage container using a conveyor belt to a funnel where the material is transported to the following production module. Each module used for this example comprises a storage container, a conveyor and other transport components. Signals of physical components (e.g. sensors and actors) are mapped to a software component which represents the PLC software used to control a certain module. On top of these components, the simulation-model is located which references an FMU component that describes the behavior of all physical components below. The relation between a certain FMU and a physical component is outlined by a dotted arrow. 2) Creating Behavioral Models: As outlined in section IV-B2, we are able to integrate models created by different tools as long the model can be exported as an FMU component. In our example we use Dymola as Modelica based tool to describe the behavior of plant components. As can be seen in figure 3 we provide models for complete production modules. However, it would also be possible to provide individual models for each component like conveyors or sensors. This modular concept is also supported by the interface concept of AutomationML: interfaces which reference to FMU components can be added to each component in the InstanceHierarchy of AutomationML. Furthermore, this provides the ability to include behavioral models only for those components where these models are needed, e.g. for a HIL test. D. Platform Specific Models for Automation Systems After the basic structure of an automation system has been described, the planning will become more detailed by adding a mapping to a certain hardware. The PIM describes the structure and the functionality of certain components of the

system. However, based on this PIM, no automation system can be build. This is due to missing information regarding which parts shall be used to fulfill a certain functionality. Therefore, this information has to be added to the PIM, leading to a platform specific model (PSM). The concept to transform the PIM into a PSM is supported by AutomationML, using the SystemUnitClassLib. This library contains certain components which are deliverable by some supplier. However, to use such library, suppliers have to provide a description of each component to their customers. To add components from the SystemUnitClassLib to the model, elements in the model are linked to components in the library. V. PARADIGM 3: AUTOMATION ML FOR S IMULATION Only models with an executable semantics allow for a simulation and can therefore be used to test the system under development—modeling without simulation hardly justifies the modeling efforts. How can a executable semantics be defined? For this, two approaches exist: First of all, an overall executable meta-model can be defined; this approach is used by modeling languages such as SDL, Modelica, Simulink, or PSpice. Here, a second approach is used: As described in section IV, the overall system’s behavior is defined by the aggregation of component behaviors where a component’s behavior is defined by means of a PLCopenXML model or by a FMU—e.g. as exported by tools such as Dymola, Simulink, AMESim, or SimulationX. As a file format, AutomationML is used to define this overall model. The main idea is depicted in figure 4: The componentoriented modeling approach described in section IV is complemented with a component-oriented simulation framework. The synergy between AutomationML’s support for components (for the modeling step) and the FMU components defined by the Modelisar project (for the simulation step) create an executable AutomationML model and allow therefore for an early test of control algorithms and PLC programs. Examples are given in sections V-A and V-B. The simulation framework

Component-oriented Modeling Component-oriented Simulation

AutomationML Modeling Component

Modeling Component References

Soft-PLC Simulation based on PLCOpenXML

Functional Mockup Unit (FMU)

Modeling Component References Functional Mockup Unit (FMU)

ODE Interface: x'(t) = f(x,t,u) Numerical Integration Simulation Framework

Numerical Integration

Test Cases .... ............ ................ .... .... .... ....

Fig. 4. The correspondence between the component-oriented modeling approach and the component-oriented simulation approach.

works as follows: • Each component is defined by a set of input signals and output signals. Each signal is typed by atomic data types such as integer, real, string and boolean. • Each component tells the simulation framework when new output signals will be available. • When new output signals are available, the simulation framework triggers the corresponding components, reads these new output signals and transports these signals to those components which use the signals as input signals. Please note that these inter-component connections are defined in the AutomationML model. • The simulation framework always executes one test case. The test case defines (i) additional signals which are set at predefined points in time (i.e. test stimuli) and (ii) at some point in time a test verdict is returned (i.e. test successful or failed); the verdict is based on the current signal values. Details for the definition of test cases are given in section V-A. The simulation framework currently supports two simulatable component types: First of all, PLC programs defined in PLCopenXML can be simulated. PLCopenXML is already support by AutomationML and comes with an interface which allows for an integration in the simulation framework as described above. Second, FMUs can be simulated. For this, an integration of this standard into AutomationML was proposed in [13]. FMUs come with an interface that corresponds to ordinary differential equations (ODEs), i.e the interface defines the derivatives of the components’s state variables. So in order to support the simulation framework interface described above, a numerical integrator must derive new output signals by integrating over the changes of the state variables. In the following two use cases we use the overall model of the modules one and two shown in figure 3 and described in section IV-C1. In the offline simulation use case we explain a non faulty behavior of a control algorithm. The second use case we change the environment model to show a faulty behavior and test this model by using a real PLC in a HIL scenario. A. Offline Simulation In the following sections, the simulation framework is explained using an example: A hardware communication error

between PLC and IO devices is detected in a HIL test. A sequential execution of (i) an offline simulation, i.e. a simulation without real hardware, and (ii) a HIL test, i.e. a simulation including a real PLC, is often used to detect errors in the hardware setup. In our example here, the automation system from figure 3 is tested: The control algorithm (in “SW Component1” and “SW Component2”) is supposed to start the first conveyer belt. But if the first funnel is blocked, as detected by the sensor “Funnel Blocked 1”, the first conveyer belt is not started to avoid a spilling of the material. The corresponding offline simulation configuration is depicted in figure 5: Three components are simulated, component 1 comprises the control algorithm (defined as a PLCOpen model), component 2 and 3 model the plant modules from figure 3 and are defined as Modelica models. As explained before, such Modelica models are integrated into the simulation as FMUs. The simulation framework is then executed on a standard PC; the time basis of this simulation does not correspond to the real, environment time. The applied test Component 1 PLCopenXML

Component 2

Component 3

module1.mo

module2.mo

Init Step1 Code Generation

Code Generation

End

module1.fmu

module2.fmu

Numerical Integration

Numerical Integration

Code Generation

C#

Simulation Framework FunnelBlocked1

Aspirator1

ConveyerBelt1 time

Fig. 5.

Offline simulation scenario.

case works as follows: (i) start the plant, (ii) block the funnel and (iii) transport the material for one hundred seconds. The simulation results can be seen on the lower right side of figure 5: The control algorithm correctly refuses to start the conveyer belt since the funnel is blocked. B. Realtime Simulation As a next step in the development process, a HIL test is used to test the control algorithm on a real Hardware-PLC. Unlike the offline simulation described above, the new test setup from figure 6 is used: The control algorithms for the two plant modules are now running on the real PLC which is connected via a network interface (here: Profinet) to the simulation PC. On this simulation PC, the plant modules 1 and 2 are simulated. In this setup, questions such as a real-time enabled simulation and the simultaneous execution of several IO device communication stacks have been answered. Again, the same test case as for the offline simulation is executed. As can be seen on the lower right of figure 6, the

conveyor belt is not stopped when the funnel of the module 1 is blocked, i.e. an error has occurred. Now, since this error did Component 3

Component 2

Component 1

Hardware Attachment Point Simulation Framework

FunnelBlocked1

Aspirator1 ConveyerBelt1 time time

Fig. 6.

Hardware-in-the-loop test.

not occur in the offline simulation, the error cause must lie in the hardware implementation and not in the control algorithm itself, e.g. the network configuration could be incorrect. The reader may note that such a continuous verification of the system under development allows for a fast and early detection of implementation errors and avoids therefore difficult and time-consuming debugging efforts using the real plant. VI. PARADIGM 4: AUTOMATION ML FOR S YSTEM M ODELING AND I NTEGRATION The last step in our design process like outlined in 1 is described as integration. Today, the setup process of automation systems is done by different disciplines (e.g. PLC programming, mechanical and electrical engineering, HMI programmer) where each disciplines uses specific engineering tools. Each tool uses special formats and therefore, the automation system has to be designed from scratch, including only those information used in a certain discipline. Based on the system wide model of the distributed automation system, components of the automation system have been simulated and tested. Therefore, this model should be used as basis for system integration. Using available data from the tested model might reduce errors during and therefore reduce necessary time for system setup. As mentioned in section III AutomationML is able to include PLC programs or 3D visualization of parts of an automation system. To use such information from the system model, involved planning tools have to import AutomationML files and extract those information useful for a certain tool. Those informations might be variable names or types for PLC programming, topology of the fieldbus or visualization for the HMI interface. However, the system model does not necessarily include all information to setup a runnable system. In this case, the engineering tool might use a filter mechanism to derive necessary information based on available planning data provided by AutomationML. Extracting information to create a list of signals necessary for PLC programming might be an example. VII. C ONCLUSION This paper has presented a model based process of designing, testing and integrating of automation systems. The

planning process starts by describing its structure which is done using AutomationML. Components, based on the tool independent FMU standard are referenced from the AutomationML file to include executable models of physical automation components. Based on this platform independent model, a platform specific model can be created. This system model can be used to test the entire automation system including PLC programs in a virtual environment (HIL). Furthermore tested system models can be used to extract engineering informations used by several engineering domains in the phase of system integration. Compared to todays approach, this style of development helps to avoid tool islands (AutomationML) and supports the integration process by providing tested automation systems. Key tools of the development tool chain are outlined in this paper. However, further work will focus on detailed implementations such as the graphical AutomationML editor and especially its ability to create platform specific models. The performance of the simulation framework has to be evaluated for models with higher complexity with the aim to derive performance limitations especially for the HIL environment. R EFERENCES [1] R. Drath, D. Weidemann, S. Lips, L. Hundt, A. L¨uder, and M. Schleipen, Datenaustausch in der Anlagenplanung mit AutomationML, R. Drath, Ed. Springer, 2010. [2] S. Stein, S. Khne, J. Drawehn, S. Feja, and W. Rotzoll, “Evaluation of OrViA Framework for Model-Driven SOA Implementations: An Industrial Case Study,” in 6th International Conference on Business Process Management, Milan, Italy, 2008. [3] T. Strasser, C. Snder, and A. Valentini, “Model-driven embedded systems design environment for the industrial automation sector,” in Proceedings of the 6th IEEE International Conference on Industrial Informatics, Daejeon, South Korea, 2008. [4] J. Prinz, A. L¨uder, N. Suchold, and R. Drath, “Design and Engineering AutomationML,” in VDI Kongress AUTOMATION 2011. Baden Baden, Jun 2011. [5] R. Drath, A. L¨uder, J. Peschke, and L. Hundt, “AutomationML - the glue for seamless automation engineering,” in Emerging Technologies and Factory Automation, 2008. ETFA 2008. IEEE International Conference on, sept. 2008, pp. 616 –623. [6] IEC 62424, “Festlegung f¨ur die Darstellung von Aufgaben der Prozessleittechnik in Fliessbildern und f¨ur den Datenaustausch zwischen EDV-Werkzeugen zur Fliessbilderstellung und CAE-Systemen,” 2008. [7] Khronos Group, “COLLADA - 3D Asset Exchange Schema,” February 2011, http://www.khronos.org/collada/. [8] PLCopen, 2011, http://www.plcopen.org/. [9] S. Mellor, K. Scott, A. Uhl, and D. Weise, MDA Distilled: Principles of Model-Driven Architecture. Addison Wesley, 2004. [10] M. Bergert, S. H¨ome, and L. Hundt, “Verhaltensmodelierung f¨ur die Virtuelle Inbetriebnahme, Integration von hybriden State Charts in AutomationML mit MathML,” in VDI Kongress AUTOMATION 2010. [11] Modelica Association, www.modelica.org, 2011. [12] Microsoft, “Microsoft Visual Studio 2010 Visualization & Modeling SDK,” http://www.microsoft.com/download/en/details.aspx?id=23025. [13] N. Moriz, S. Faltinski, O. Graeser, O. Niggemann, M. Barth, and A. Fay, “Integration und Anwendung von objektorientierten Simulationsmodellen in AutomationML,” in VDI Kongress AUTOMATION 2011. Baden Baden, Jun 2011.