AutomationML is an emerging IEC standard for storing and exchanging engineering data among the heterogeneous software tools involved in the engineering of production systems. One important subset of such engineering data is the plant behavior. To make this data exchangeable, AutomationML uses the existing industry data format PLCopen XML. However, at the development stages of production systems, the plant behavior is usually defined using other representation means, such as Gantt charts, impulse diagrams, and sequential function charts. To make such plant behavior models exchangeable, AutomationML introduces the so-called Intermediate Modeling Layer (IML) with corresponding transformation rules to decouple the employed modeling languages from the target format PLCopen XML. However, IML itself as well as the transformations from and to IML are only semi-formally described. This not only hinders the adoption of IML as a common language for representing plant behavior, but also renders impossible the composition of heterogeneous plant behavior models for carrying out integrated analyses of the global plant behavior. In this work, we aim at clarifying syntactical and semantical aspects of IML by proposing a metamodel and operational semantics for IML. This constitutes the first step towards formalizing and validating transformations between behavioral modeling languages currently employed in the production domain (e.g., Gantt charts), IML, and PLCopen XML. Having this foundation, we aim at utilizing IML as the semantic domain for the composition of heterogeneous plant behavior models.
tems engineering [
In this paper we focus on PLCopen XML, which is utilized by AutomationML as an
exchange format for plant behavior models [
However, IML itself as well as the mappings between IML and the various behavioral modeling languages supported by AutomationML, and between IML and PLCopen XML are only semi-formally described. As a consequence, the mappings from and to IML are largely unvalidated. In particular, it is unclear whether the mappings preserve the semantics of plant behavior models. This hinders the adoption of IML as a common language for representing plant behavior and impedes the composition of heterogeneous plant behavior models as needed for analyzing the global plant behavior.
In this paper, we aim at clarifying syntactical and semantical aspects of IML by proposing a metamodel and operational semantics for IML. This constitutes the first step towards formalizing and validating transformations from and to IML. Furthermore, … Tool A Tool B Tool C
Gantt Chart PERT Chart Impulse Diagram …
Proprietary data formats
IML
Model
Execution
Intermediate PLCOpen XML
Modeling Layer (IML) (IEC 61131-3) we advocate the utilization of IML as a semantic integration layer for plant behavior models as depicted at the top of Fig. 1. In particular, we propose to use IML as the semantic domain for the plant behavior modeling languages supported by AutomationML. In a first step, this enables the execution of plant behavior models and the performance of dynamic validation and verification (V&V) activities for such models, such as model simulations and animation, trace analyses, etc. Going one step further, utilizing IML as the semantic domain for plant behavior models enables the composition of heterogeneous plant behavior models in IML and, consequently, the performance of analyses of the global plant behavior defined in the composed models. Such analyses comprise, for instance, the integrated simulation and animation of plant behavior models, the analyses of consistency among a set of plant behavior models, and the validation of refinement relationships between plant behavior models.
The remainder of this paper is structured as follows: In Section 2, we discuss stateof-the-art approaches in production systems engineering. Thereafter, in Section 3, we detail the contribution of this work, namely a formalization of IML. Finally, Section 4 concludes the paper with an outlook on future work. 2
Modeling languages are essential in planning, designing, realizing, and maintaining
production systems especially in the light of Industrie 4.0 [
The System Modeling Language (SysML) [
Concerning the exchange and integration of continuous behavior models, the
Functional Mockup Interface (FMI) [
For modeling and exchanging discrete-event systems and sequential control
processes in the context of industrial automation, GRAFCET [
As described above, IML is defined by AutomationML as an intermediate
representation format for plant behavior [
In this section, we describe our formalization of IML comprising a metamodel defining IML’s abstract syntax and an operational semantics defining IML’s execution semantics. Thereafter, we discuss an exemplary transformation towards IML. 3.1 IML Metamodel nnectionPoint, State.init and State.terminal, OCL contraints have to be introduced. , Jumps, Activity.initial, Activity.terminal, Time.start, Time.end have been left out.
Header inherit from IdentifyableElement (would mean that a Header can contain another Header). ements are State, StateTransition, Activity and Variable. The class State is used to represent the states of a system characterized by, for instance, running operations and values of process variables. Every IML model has to have exactly one initial state and may have a terminal state, which are indicated by the boolean flags init and terminal, respectively.
A state may comprise a set of operations represented by the class Activity, which are executed by the system within the state. Thereby, an activity may define its earliest and latest start and end time, time delay, and duration represented by the class Time. Transitions between states are represented by the class StateTransition. They may define variables represented by the class Variable as guards. IML also allows the definition of alternative and parallel state transitions. In particular, the classes SelectionDivergence and SelectionConvergence can be used to represent alternative and exclusive disjoint state transitions, while the classes SimultaneousDivergence and SimultaneousConvergence can be used to represent simultaneous state transitions.
Example. Figure 3 shows an exemplary IML model defining the behavior of a gripping robot. After the initial state InitialStep, the robot transitions through the state transition ST1 and the simultaneous divergence SD into the simultaneous states S_InitialiseRobot1 and S_LiftSkid. These states comprise two activities each, namely the activity DA_InitialiseRobot1 with a start time of 0, the activity TA_InitialiseRobot1 with a duration of 6, the activity DA_LiftSkid with a start time of 7, and the activity TA_LiftSkid with a duration of 9. Through the state transitions ST2 and ST3 the robot reaches the synchronization states Sys_ExecuteManufacturingRobot1_1 and Sys_ExecuteManufacS_InitialiseRobot1
ST2 Sys_ExecuteManufacturing
Robot1_1 Figure 4 gives an overview of the operational semantics that we defined for IML. To capture the execution state of an IML model, we introduced the properties current and value into the classes State and Variable, respectively. The property current indicates the current state(s) of an IML model, while the property value captures the current value of a variable. The steps of computation involved in the execution of IML models are defined by means of an endogenous in-place transformation. In Fig. 4, the rules of this transformation are depicted as operations contained by those classes that are matched by the rules. The rule execute of the class Header is the entry point of the transformation and defines the main control loop for executing an IML model. In particular, as shown in Algorithm 1, it first activates the initial state of the IML model by calling the rule activate on the initial state. Thereafter, enabled successor elements of the previously set current state (e.g., a state transition) are fired by calling the rule fire of the class ConnectionPoint. The rule fire of the class StateTransition is shown in Algorithm 2. It first deactivates the current state by calling the rule deactivate. In case the target element is a state, this state is activated. Otherwise, the successor element (e.g., a simultaneous convergence) is fired if it is enabled. The rule activate of the class State (not shown) first sets the state as being the current state and then executes the activities of this state by calling the rule executeActivities. The main control loop of the rule execute continues to fire enabled elements as long as the terminal state is reached.
Example. Figure 5 shows an excerpt of the execution of the example IML model shown in Fig. 3. For starting the execution, the rule execute is called for the single Header element. This rule first activates the initial state InitialStep. Then, it fires the state transition
Header execute()
ConnectionPoint isEnabled() : boolean fire()
State /currentStates current : boolean * activate() deactivate() executeActivities()
Variable value : String
Activity execute() Header::execFuigt. 4e:(O)ver{view of IML operational semantics.
initial {m Є members | m.isTypeOf(State) and m.init} Algoirinthimti1a:lex.eacuctte(iHveaadteer)() 1 begfinoreach s Є currentStates do 2 initiaflorfema2chmemcbeЄrs j{mc:isTЄypemOefm(Sbtaeter)s^m|:inictg.isTypeOf(Connection) and m.source = s} 3 initial:aictfivate()
cfa.lstearget.isEnabled() then 4 terminate 5 while :termcin.afteidroe() 6 } foreach s 2 currentStates do 7 foreach c 2 fm 2 members j m:isTypeOf(Connection)^m:source = sg do
if c:taanrgseti:itsEinoanbl:ed:(f)tihrene() { 89 StateTcr:target:fire()
if source.isTypeOf(State do 10 if tts a2rfcgse2tc.urdreenatSctattiesvjacst:teer(m)inalg then 11 terminate true if target.isTypeOf(State) do
target.activate() Algoerilthsme 2i:ffiret(SatartgeTertan.siitsioEn)nabled() then 1 begin target.fire() 2 } if source:isTypeOf(State)^source:current then 3 source:deactivate() 4 Stifattarege:t.:isaTycpteOifv(Satattee)(th)en{ 5 ctuarrgerte:ancttivat=e()true 6 else if target:isEnabled() then 7 target:fire() ST1, which in turn fires the simultaneous divergence SD. This results in the deactivation of the initial state InitialStep, and the activation of the states S_InitialiseRobot1 and S_LiftSkid, which execute their contained activities by calling the rule executeActivities.
H : Header
InitialStep :
State
ST1 : StateTransition
S_LiftSkid :
State
SD : Simultaneous
Divergence
Implementation. We have implemented the operational semantics for IML using the language and modeling workbench GEMOC studio4. The complete implementation may be found in our project repository5. The presented formalization enables the execution of plant behavior models defined with IML, as well as the performance of dynamic V&V activities for such models.
GEMOC studio provides, for instance, model debugging, model animation, and trace exploration tools that can be utilized for IML models directly based on the defined operational semantics. However, to utilize IML as a semantic domain for other commonly used plant behavior modeling languages, also the transformations from and to IML have to be formalized. We are currently in the process of developing such formalizations. In the following, we discuss as an example the transformation of Gantt charts.
Gantt charts are commonly used in the early phases of plant engineering processes to represent timing aspects of manufacturing processes. They offer two main types of modeling concepts: activities represented as bars, and predecessor-successor relationships between activities represented as connections between bars. For activities, a start time, end time, and duration relative to a global clock may be defined in addition.
Figure 6 shows the Gantt chart corresponding to the IML model depicted in Fig. 3.
For each of the bars defined in a Gantt chart, one state is created in the IML model 4 http://gemoc.org/studio 5 https://github.com/moliz/moliz.gemoc (1) Head.execute() effect: InitialStep.current = true (2) ST1.fire() (3) SD.fire() effect: S_InitialiseRobot1.current = true, S_LiftS (4) ST2.fire() effect: S_InitialiseRobot1.current = true, S_LiftS TerminalStep
ST5
Lift Skid
Initialise Robot 1 Execute Manufacturing Robot 1 0 (S_InitialiseRobot1, S_LiftSkid, S_ExecuteManufacturingRobot1). Two activities are added to each created state: The first activity represents the start time of the bar (e.g., DA_InitialiseRobot1) and the second activity represents the duration of the bar ensuring the correct deactivation of the state (e.g., TA_InitialiseRobot1). The start time and duration of bars have to be converted from a global clock used in Gantt charts to a local clock used in IML. If a Gantt bar has multiple successors, a simultaneous divergence is created in the IML model (SD). Similarly, a simultaneous convergence (SC) is created for bars that have multiple predecessors. In addition to the simultaneous convergence, synchronization states are created for each predecessor state (Sys_ExecuteManufacturingRobot1_1 and Sys_ExecuteManufacturingRobot1_2). Furthermore, one initial state InitialStep and one terminal state TerminalStep are created. The created elements are connected with state transitions (ST1-ST5). 4
In this paper, we have introduced a formalization of the Intermediate Modeling Layer (IML) of AutomationML comprising a metamodel and an operational semantics. Furthermore, we have proposed the utilization of IML as a semantic domain for heterogeneous plant behavior models.
Currently, we are working on the refinement of the operational semantics of IML,
such as the introduction of timing aspects. Furthermore, we are in the process of
formalizing and validating transformations between IML and the various plant behavior
modeling languages supported by AutomationML based on the semi-formal
descriptions given in [
This work has been supported by the Christian Doppler Forschungsgesellschaft, the BMWFW (Austria) and the COST Action MPM4CPS (IC1404).