1417686916-AutomationML Whitepaper Part 4 - AutomationML Logic Description v2 - Aug2013

Whitepaper AutomationML
Part 4 AutomationML Logic

Description
State: May 2010
Part 4 - AutomationML Logic Description

AutomationML consortium
Version 2.0, Mai 2010
Contact: www.automationml.org
Related documents
[1]
Whitepaper AutomationML Part 1 AutomationML Architecture, May 2010.
[2]
Whitepaper AutomationML Part 2 AutomationML Libraries, May 2010
[3]
Pirsch, M.: AutomationML Editor User Guideline, May 2010
[4]
Pirsch, M.: AutomationML Engine User Guideline, May 2010

Table of content
Table of content ...................................................................................................................................... 3
List of figures .......................................................................................................................................... 7
List of tables ........................................................................................................................................... 9
1
Introduction................................................................................................................................. 12
1.1 Logic Descriptions in Automation Engineering ...................................................................... 12
1.2 Storing Logic Descriptions within AutomationML .................................................................. 12
1.3 Interlocking Description in Automation Engineering .............................................................. 13
1.4 Structure of this Document .................................................................................................... 14
1.5 References to other Documents ............................................................................................ 14
2
Sequencing and Behaviour Models in AutomationML ............................................................... 15
2.1 Overview ................................................................................................................................ 15
2.2 Gantt Charts ........................................................................................................................... 16
2.3 PERT Charts .......................................................................................................................... 16
2.4 Impulse Diagrams .................................................................................................................. 18
2.5 Sequential Function Charts.................................................................................................... 19
2.6 State Charts ........................................................................................................................... 21
3
The Intermediate Modeling Layer .............................................................................................. 23
3.1 Overview ................................................................................................................................ 23
3.2 IML Systems Element Overview ............................................................................................ 24
3.3 Element Properties and Relations ......................................................................................... 25
3.3.1 Header Properties and Relations .............................................................................. 25
3.3.2 State Properties and Relations ................................................................................. 25
3.3.3 State Transition Properties and Relations ................................................................ 26
3.3.4 Activity Properties and Relations .............................................................................. 26
3.3.5 Jump Properties and Relations ................................................................................. 27
3.3.6 Selection Divergence Properties and Relations ........................................................ 27
3.3.7 Simultaneous Divergence Properties and Relations................................................. 27
3.3.8 Selection Convergence Properties and Relations .................................................... 27
3.3.9 Simultaneous Convergence Properties and Relations ............................................. 27
3.3.10 Event Properties ........................................................................................................ 27
3.3.11 Variable Properties and Relations ............................................................................. 28
3.3.12 Comment Properties and Relations .......................................................................... 28
3.3.13 Aditional Data properties and relation ....................................................................... 28
4
Mapping of IML to PLCopen XML SFC ...................................................................................... 29
4.1.1 Overview ................................................................................................................... 29
4.2 Additional Data ....................................................................................................................... 29
4.2.1 PLCopen XML addData ............................................................................................ 29
4.2.2 AutomationML Schema for Additional Data within the Logic Description ................. 29
4.2.3 Declaration and Usage of AutomationML Additional Data Schema in PLCopen
XML ........................................................................................................................... 37
4.3 Mapping of IML to PLCopen XML .......................................................................................... 38
4.3.1 Common Rules.......................................................................................................... 38
4.3.2 Mapping of Headers and their Relations ................................................................... 40
4.3.3 Mapping of States and their Relations ...................................................................... 41
3

4.3.4 Mapping of State Transitions and their Relations ..................................................... 42
4.3.5 Mapping of Activities and their Relations .................................................................. 46
4.3.6 Mapping of Jumps and their Relations ...................................................................... 52
4.3.7 Mapping of Selection Divergence and their Relations .............................................. 52
4.3.8 Mapping of Simultaneous Divergences and their Relations ..................................... 53
4.3.9 Mapping of Selection Convergence and their Relations ........................................... 54
4.3.10 Mapping of Simultaneous Convergences and their Relations .................................. 55
4.3.11 Mapping of Events and their Relations ..................................................................... 56
4.3.12 Mapping of Variables and their Relations ................................................................. 57
4.3.13 Mapping of Comment Properties and their Relations ............................................... 59
4.3.14 Mapping of Additional Data Properties and their Relations ...................................... 60
5
Representation of Logic Models in AutomationML .................................................................... 62
5.1 Gantt Charts ........................................................................................................................... 62
5.1.1 Overview ................................................................................................................... 62
5.1.2 Start of a Gantt Chart ................................................................................................ 65
5.1.3 Bar ............................................................................................................................. 65
5.1.4 Bar Startpoint ............................................................................................................ 66
5.1.5 Bar Endpoint.............................................................................................................. 66
5.1.6 Successor Bar ........................................................................................................... 66
5.1.7 Predecessor Bar........................................................................................................ 67
5.1.8 End of a Gantt Chart ................................................................................................. 69
5.1.9 Transformation Examples for Gantt Charts .............................................................. 70
5.2 PERT Charts .......................................................................................................................... 74
5.2.1 Overview ................................................................................................................... 74
5.2.2 Start of a PERT Chart ............................................................................................... 76
5.2.3 Node .......................................................................................................................... 76
5.2.4 Node Earliest Startpoint ............................................................................................ 77
5.2.5 Node Duration ........................................................................................................... 77
5.2.6 Further Node Times .................................................................................................. 77
5.2.7 Successor Nodes ...................................................................................................... 78
5.2.8 Predecessor Nodes ................................................................................................... 78
5.2.9 End of a PERT Chart ................................................................................................ 81
5.2.10 Transformation Example of PERT Charts ................................................................. 82
5.3 Impulse Diagrams .................................................................................................................. 84
5.3.1 Overview ................................................................................................................... 84
5.3.2 Start of an Impulse Diagram ..................................................................................... 87
5.3.3 Timeline ..................................................................................................................... 87
5.3.4 Resource ................................................................................................................... 88
5.3.5 Resource State .......................................................................................................... 88
5.3.6 Resource State Change ............................................................................................ 89
5.3.7 Resource State Flow ................................................................................................. 89
5.3.8 Signals ....................................................................................................................... 90
5.3.9 End of Impulse Diagram and Terminal Step ............................................................. 92
5.3.10 Impulse Diagram Details ........................................................................................... 93
5.3.11 Transformation Examples for Impulse Diagrams ...................................................... 94
5.4 State Charts ........................................................................................................................... 97
4

5.4.1 Overview ................................................................................................................... 97
Flat State Charts .................................................................................................................... 99
5.5.1 Headers ..................................................................................................................... 99
5.5.2 States ...................................................................................................................... 100
5.5.3 Number and Structure of Predecessor States ........................................................ 100
5.5.4 Number and Structure of Successors of States ...................................................... 101
5.5.5 Entry Action ............................................................................................................. 101
5.5.6 Action within a State; Do Action .............................................................................. 102
5.5.7 Exit Action ............................................................................................................... 103
5.5.8 Events ..................................................................................................................... 103
5.5.9 Signals ..................................................................................................................... 104
5.5.10 State Transitions ..................................................................................................... 104
5.6 State Charts with Hierarchies .............................................................................................. 108
5.6.1 Hierarchy Levels...................................................................................................... 108
5.6.2 History Connector.................................................................................................... 109
5.6.3 Condition Connector ............................................................................................... 110
5.6.4 State Transition among Hierarchies ........................................................................ 111
5.7 Example Transformation for State Charts to AutomationML Logic Representation ............ 122
6
Linking AutomationML Objects with Logic Information ............................................................ 125
6.1 Overview AutomationML Top Level Architecture ................................................................ 125
6.2 Reference Mechanisms between CAEX and PLCopen XML .............................................. 125
6.2.1 Overview ................................................................................................................. 125
6.2.2 Referencing PLCopen XML documents .................................................................. 126
6.2.3 InterfaceClass ExternalDataConnector ................................................................... 127
6.2.4 InterfaceClass PLCopenXMLInterface .................................................................... 127
6.2.5 InterfaceClass LogicInterface .................................................................................. 128
6.2.6 InterfaceClass VariableInterface ............................................................................. 128
6.3 Referencing Logic Information ............................................................................................. 128
6.3.1 Conceptual Overview .............................................................................................. 128
6.3.2 Referencing PLCopen XML Logic Information ........................................................ 129
6.3.3 Referencing PLCopen XML Variables .................................................................... 129
6.4 Examples ............................................................................................................................. 130
6.4.1 Referencing a PLCopen XML Document ................................................................ 130
6.4.2 Referencing and Connecting a PLCopen XML Variable ......................................... 131
6.4.3 Referencing and Connecting Behaviour and Sequence Information ...................... 132
7
Mapping Interlocking Information to AutomationML ................................................................ 134
7.1 Overview .............................................................................................................................. 134
7.2 Component Groups and Signal Groups ............................................................................... 134
7.2.1 Concept Description ................................................................................................ 134
7.2.2 RoleClass ComponentGroup .................................................................................. 136
7.2.3 RoleClass SignalGroup ........................................................................................... 137
7.2.4 InterfaceClass InterlockingConnector ..................................................................... 137
7.3 Boolean Logic as Interlocking Condition .............................................................................. 137
7.3.1 Concept Description ................................................................................................ 137
7.3.2 InterfaceClass InterlockingVariableInterface .......................................................... 138
7.3.3 Restricted Linking Mechanism ................................................................................ 139
5.5

7.4
7.5
Complex Logic as Interlocking Condition ............................................................................. 140

Extended Use of Interlocking Description within AutomationML ......................................... 141
7.5.1 Interlocking as Transition Condition in Sequence Descriptions .............................. 141
7.5.2 Interlocking Networks as Behaviour Description ..................................................... 142
7.6 Example for the Usage of Interlocking Descriptions within AutomationML ......................... 143
References ......................................................................................................................................... 148
Annex A: Example for Mapping IML to PLCopen XML ...................................................................... 149

List of figures
Figure 1: Transformation to PLCopen XML ......................................................................................... 13
Figure 2: Types of logic descriptions in AutomationML ....................................................................... 15
Figure 3: Example of a Gantt chart ...................................................................................................... 16
Figure 4: Example of a PERT chart ..................................................................................................... 17
Figure 5: Example of an Impulse diagram with naming conventions ................................................... 18
Figure 6: Signals in Impulse diagrams ................................................................................................. 18
Figure 7: Timing information within Impulse diagrams ......................................................................... 19
Figure 8: Example of a SFC in IEC 61131-3 ........................................................................................ 21
Figure 9: Example simple State chart .................................................................................................. 22
Figure 10: IML system entities and its relations ................................................................................... 23
Figure 11: Example of an SFC in IML .................................................................................................. 24
Figure 12: Declaration of the AutomationML additional data schema within PLCopen XML............... 38
Figure 13: Example of additional information in AutomationML ........................................................... 38
Figure 14 Used part of the PLCopen XML schema: ............................................................................ 40
Figure 15: Actions of IML for Gantt- bar representation ....................................................................... 62
Figure 16: Example of the transformation of a Gantt diagram in SFC (IML) ....................................... 63
Figure 17: SFC representation of the Gantt chart in Figure 16 ............................................................ 64
Figure 18: Gantt translation example - activities without predecessor and successor relations ......... 70
Figure 19: Gantt translation example activity sequence ................................................................... 71
Figure 20: Gantt translation example activity sequence divagation .................................................. 72
Figure 21: Gantt translation example activity sequence convergence.............................................. 73
Figure 22: Elements of a PERT chart .................................................................................................. 74
Figure 23: Boolean actions of SFC for PERT activity representation .................................................. 75
Figure 24: Example for the mapping of a PERT chart to a SFC .......................................................... 82
Figure 25: Timing behaviour of the SFC derived from a PERT chart node ......................................... 83
Figure 26: Impulse diagram example of transformation ....................................................................... 84
Figure 27: Resulting SFC for Impulse diagram example of Figure 26 ................................................. 85
Figure 28: Example transformation internal signal ............................................................................... 94
Figure 29: Example external signal ...................................................................................................... 95
Figure 30: Impulse diagram example of transformation ....................................................................... 96
Figure 31: State chart example ............................................................................................................ 97
Figure 32: IML representation of State chart example from Figure 31 ................................................ 98
Figure 33: Transformation of State chart to an IML system ................................................................. 99
Figure 34: Transformation states to IML states .................................................................................. 100
Figure 35: Transformation of predecessor states to IML elements .................................................... 100
Figure 36: Transformation of states to IML states .............................................................................. 101
Figure 37: Transformation of an entry action of states to an IML activity .......................................... 101
Figure 38: Transformation of a do action to an IML activity ............................................................... 102
Figure 39: Transformation of an exit action to an IML activity ........................................................... 103
Figure 40: Transformation of events to an IML event and PLCopen variable ................................... 103
Figure 41: Transformation of a signal to an IML variable ................................................................... 104
Figure 42: Transformation a states transition to an IML transition ..................................................... 104
Figure 43: Transformation of a state transition without an action to IML elements ........................... 105
Figure 44: Transformation of a state transition with an action to IML elements ................................ 106
7

Figure 45: Transformation of a hierarchical State chart to an IML System ........................................ 108
Figure 46: Transformation of a history connector to IML elements .................................................... 109
Figure 47: Transformation of a condition connector to IML elements ................................................ 110
Figure 48: Transformation of a state transition over different hierarchy level to IML element ........... 111
Figure 49: Transformation of a state transition from a higher state without an action to IML
elements............................................................................................................................... 112
Figure 50: Transformation of a state transition from a higher state with an action to IML
elements............................................................................................................................... 114
Figure 51: Transformation of a state transition from a lower level state without an action to IML
elements............................................................................................................................... 116
Figure 52: Transformation of a state transition from a lower level state with an action to IML
elements............................................................................................................................... 119
Figure 53: Example: transformation of a simple cyclic State chart .................................................... 122
Figure 54: Example: transformation of a State chart with states with different predecessors and
successors ........................................................................................................................... 122
Figure 55: Example: transformation of a State chart with actions ...................................................... 123
Figure 56: Example: transformation of a State charts with a condition connector ............................. 123
Figure 57: Example: transformation of a State chart with simple hierarchy ....................................... 124
Figure 58: Example: transformation of a State chart with complex hierarchy and connectors .......... 124
Figure 59: AutomationML top level architecture ................................................................................. 125
Figure 60: Storage of logics information with AutomationML ............................................................. 128
Figure 61: Referencing logic information ........................................................................................... 129
Figure 62: Publishing PLCopen variables .......................................................................................... 129
Figure 63: Example drilling system .................................................................................................... 130
Figure 64: Reference to logic description ........................................................................................... 131
Figure 65: Reference to variable within logic description ................................................................... 132
Figure 66: Reference to multiple logic information ............................................................................. 133
Figure 67: Example production system .............................................................................................. 134
Figure 68: Principle usage of signal and component groups ............................................................. 135
Figure 69: Linking of signal and component groups .......................................................................... 135
Figure 70 Example of creating signal and component groups ........................................................... 136
Figure 71: General reference mechanism for interlocking condition .................................................. 138
Figure 72: Example of use of InterfaceClass InterlockingVariableInterface ...................................... 139
Figure 73: Example FBD for second level of interlocking description ................................................ 139
Figure 74: Complex FBD networks for interlocking descriptions ....................................................... 141
Figure 75: Interlocking condition as additional transition condition within a network ......................... 142
Figure 76: Example of an interlocking network as behaviour description .......................................... 142
Figure 77: Interlocking example cell structure .................................................................................... 143
Figure 78: Interlocking example with modeled signal and component groups .................................. 144
Figure 79: Interlocking example with linked signal and component groups ....................................... 145
Figure 80: Interlocking example with references PLCopen XML document ...................................... 146
Figure 81: Interlocking example with references to PLCopen XML variables ................................... 147
Figure 82: Example IML system ......................................................................................................... 149

List of tables
Table 1: AutomationML element .......................................................................................................... 30
Table 2: <Time> element ..................................................................................................................... 31
Table 3: <Duration> element ............................................................................................................ 31
Table 4: <EarliestStart> element ................................................................................................. 31
Table 5: <LatestStart> element ..................................................................................................... 32
Table 6: <EarliestEnd> element ..................................................................................................... 32
Table 7: <Latest> element ................................................................................................................ 32
Table 8: <Delay> element .................................................................................................................. 32
Table 9: <ChartType> element .......................................................................................................... 33
Table 10: <ResourceStateChangeDefinition> element ............................................................ 33
Table 11: <DefinitionName> element ............................................................................................. 33
Table 12: <Durationn> element ........................................................................................................ 33
Table 13: <InteruptableAction> element .................................................................................... 34
Table 14: <StateChartSubCharts> element .................................................................................. 34
Table 15: <POURef> element .............................................................................................................. 34
Table 16: <StateChartStateType> Element.................................................................................. 35
Table 17: <StateChartActionType> Element ............................................................................... 35
Table 18: <ImpulseChartResourceGroup> element ..................................................................... 35
Table 19: <ImpulseDiagramPLCVariable> element ..................................................................... 36
Table 20: <Name> element ................................................................................................................... 36
Table 21: <Datatype> element .......................................................................................................... 36
Table 22: <Address> element ............................................................................................................ 36
Table 23: <StateStatus> element ................................................................................................... 37
Table 24: <ActionStatus> element ................................................................................................. 37
Table 25: Mapping of IML header to PLCopen XML ............................................................................ 40
Table 26: Example transformation IML header to PLCopen XML ....................................................... 41
Table 27: Mapping of IML state to PLCopen XML ............................................................................... 42
Table 28: Example transformation IML state to PLCopen XML ........................................................... 42
Table 29: Mapping of IML state transition to PLCopen XML ............................................................... 45
Table 30: Example transformation IML state transition to PLCopen XML ........................................... 46
Table 31: Mapping of IML activity to PLCopen XML ............................................................................ 50
Table 32: Example transformation IML activity to PLCopen XML ........................................................ 51
Table 33: Mapping of IML jump to PLCopen XML ............................................................................... 52
Table 34: Example transformation IML jump to PLCopen XML ........................................................... 52
Table 35: Mapping of IML selection divergence to PLCopen XML ...................................................... 53
Table 36: Example transformation IML selection divergence to PLCopen XML .................................. 53
Table 37: Mapping of IML simultaneous divergencies to PLCopen XML ............................................ 54
Table 38: Example transformation IML simultaneous divergencies to PLCopen XML ........................ 54
Table 39: Mapping of IML selection convergence to PLCopen XML ................................................... 55
Table 40: Example transformation IML selection convergence to PLCopen XML ............................... 55
Table 41: Mapping of IML simultaneous divergences to PLCopen XML ............................................. 56
Table 42: Example transformation IML simultaneous divergences to PLCopen XML ......................... 56

Table 43: Mapping of IML event to PLCopen XML .............................................................................. 56
Table 44: Example transformation IML event to PLCopen XML .......................................................... 57
Table 45: Mapping of IML variable to PLCopen XML .......................................................................... 58
Table 46: Example transformation IML variable to PLCopen XML ...................................................... 59
Table 47: Mapping of IML comment to PLCopen XML ........................................................................ 59
Table 48: Example transformation IML comment to PLCopen XML .................................................... 60
Table 49: Mapping of IML addData to PLCopen XML ......................................................................... 60
Table 50: Example transformation IML addData to PLCopen XML ..................................................... 61
Table 51: Transformation of the start of a Gantt chart to IML elements .............................................. 65
Table 52: Transformation of Gantt chart bars to IML elements ........................................................... 65
Table 53: Transformation of Gantt chart bar start point to IML elements ............................................ 66
Table 54: Transformation of Gantt chart bar endpoint to IML elements .............................................. 66
Table 55: Transformation of Gantt chart bar successor activities to IML ............................................. 67
Table 56: Transformation of Gantt chart predecessor bar to IML elements ........................................ 69
Table 57: Transformation of the end of a Gantt chart to IML elements ............................................... 69
Table 58: Transformation of a PERT node to IML elements ................................................................ 76
Table 59: Transformation of PERT chart nodes to IML elements ........................................................ 76
Table 60: Transformation of PERT chart node earliest startpoint to IML elements ............................. 77
Table 61: Transformation of PERT chart node duration to IML elements ........................................... 77
Table 62: Transformation of PERT chart node duration to IML elements ........................................... 77
Table 63: Transformation of PERT diagram activity successor activity to IML .................................... 78
Table 64: Transformation of a PERT diagram predecessor activity to IML elements.......................... 80
Table 65: Transformation of PERT diagram Terminal Step to IML elements ...................................... 81
Table 66: Transformation of the start of Impulse Diagrams to IML elements ...................................... 87
Table 67: Transformation of a timeline to IML elements ...................................................................... 88
Table 68: Transformation of resources to IML elements ..................................................................... 88
Table 69: Transformation of resource states to IML elements............................................................. 88
Table 70: Transformation of resource state changes to IML elements ................................................ 89
Table 71: Transformation of the resource state flows to IML elements ............................................... 90
Table 72: Transformation of signals to IML elements .......................................................................... 91
Table 73: Transformation of Impulse Diagram end to IML elements ................................................... 92
Table 74: Transformation of Impulse Diagram details to IML elements .............................................. 93
Table 75: Attribute values for flat State chart representation as IML system .................................... 100
Table 76: Attribute values for state representation in IML ................................................................. 100
Table 77: Attribute values for representation of multiple predecessors in IML .................................. 101
Table 78: Attribute values for the representation of multiple successors of a state in IML ................ 101
Table 79: Attribute values for an entry action representation in IML .................................................. 102
Table 80: Attribute values for a do action representation in IML ........................................................ 102
Table 81: Attribute values for an exit action representation in IML .................................................... 103
Table 82: Attribute values for an exit action representation in IML .................................................... 104
Table 83: Attribute values for signal representations in IML .............................................................. 104
Table 84: Distinction of cases for the mapping of state transitions in flat State charts ...................... 105
Table 85: Attribute values for signal representation in IML ................................................................ 105
Table 86: Attribute values for a state transition with an action in IML ................................................ 107
Table 87: Attribute values for hierarchical State chart representation as IML systems ..................... 108
Table 88: Attribute values for flat State chart representation as IML systems ................................... 108
10

Table 89: Attribute values for transformation of a history connector in IML ....................................... 109
Table 90: Attribute values for transformation of a history connector in IML ....................................... 110
Table 91: Attribute values for the condition connector representation in IML .................................... 111
Table 92: Distinction of cases for the mapping of state transitions in hierarchical State charts ........ 111
Table 93: Attribute values for state transition representation in IML within hierarchical State
charts ................................................................................................................................... 112
Table 94: Attribute values for state transition representation in IML within the sub State charts ...... 113
Table 95: Attribute values for state transition representation in IML within hierarchical State
charts ................................................................................................................................... 114
Table 96: Attribute values for state transition representation in IML within the sub State charts ...... 116
Table 97: Attribute values the representation of state transition among hierarchies in IML at the
higher level ........................................................................................................................... 117
Table 98: Attribute values for the state transition representation in IML within the sub State
charts ................................................................................................................................... 118
Table 99: Attribute values the representation of state transition among hierarchies in IML .............. 120
Table 100: Attribute values for state transition representation in IML within the sub State charts .... 121
Table 101: InterfaceClasses of the AutomationMLInterfaceClassLib ................................................ 126
Table 102: Examples for the attribute refURI .................................................................................. 127
Table 103: InterfaceClass ExternalDataConnector ............................................................................ 127
Table 104: InterfaceClass PLCopenXMLInterface ............................................................................. 127
Table 105: InterfaceClass LogicInterface ........................................................................................... 128
Table 106: InterfaceClass VariableInterface ...................................................................................... 128
Table 107: RoleClass ComponentGroup ........................................................................................... 136
Table 108: RoleClass SignalGroup .................................................................................................... 137
Table 109: InterfaceClass InterlockingConnector .............................................................................. 137
Table 110: InterfaceClass InterlockingVariableInterface ................................................................... 138
Table 111: Restrictions for the linking of signal and component groups............................................ 140
11

1
Introduction
1.1
Logic Descriptions in Automation Engineering
AutomationML (Automation Markup Language) is a neutral and XML-schema-based data format

designed for the vendor-independent storage of plant engineering information. The goal of
AutomationML is to interconnect the heterogeneous tool landscape of engineering tools in their
different disciplines, e.g. mechanical plant engineering, electrical design, HMI development, PLC, and
robot control programming.
Whereas [1] gives a top-level architecture overview of AutomationML, this document focuses on the
storage of logic information - an important aspect for electrical design, HMI development, PLC and
robot control programming.
AutomationML must be able to cover logic data from different tools and disciplines, and supports
different phases in the iterative plant engineering workflow covering different levels of detail.
AutomationML simplifies the engineering of production systems from the first engineering steps such
as plant design to the final commissioning of complete systems. Thus, different types of logic
information belonging to an industrial plant or to single components have to be stored.
This variety of information can be differentiated into two main concepts: sequencing and behaviour
which serve different purposes, but which can overlap depending on the point of view and utilization of
elements in AutomationML:
Description of behaviour of AutomationML objects as a given (uncontrolled) model of reaction of a

part on external inputs, e.g. behaviour of a gripper or valve.
Description of sequencing as required controlled behaviour of a system or part, which often

represents a program executed in one or more controllers, e.g. robot controller, PLC.
Intelligent devices with both behaviour and sequencing, e.g. robots or conveyors.
AutomationML provides a rich selection of typical logic description models for important phases of the
engineering process and data. These models are:
Gantt charts typically used during the first planning phases
PERT charts used in a similar way with complex timing conditions
Impulse diagrams to describe sequences in detail and to introduce real signals
State charts to describe internal behaviour in detail
Sequence Funktion Charts (SFCs) for executable PLC programs including a mapping to real
control hardware
1.2
Storing Logic Descriptions within AutomationML
AutomationML uses one common data model to describe both types of logic information, namely
Sequential Function Charts (SFC) as one of the PLC programming languages defined in IEC 61131-3
[IEC61131-3]. Thus, transformation rules to and from SFCs out of various input formats are essential
parts of the AutomationML logic concept.
Complete logic representations are stored in external documents, while the top-level format contains
selected published information only. Target data format for logic information is PLCopen XML.
To store a given logic description in AutomationML it has to be translated to SFCs described by a
PLCopen XML representation strictly following the rules defined in this document.
12

Mapping Rules based
on transformation of
Model elements
Mapping rules for

transformation of
IML elements to
XML structures
Gantt chart
PERT chart
Impulse diagram
Intermediate
Modeling Layer
PLCopen XML
...
Specific models and charts
(Propriety data format)
Set of model
elements
XML
Figure 1: Transformation to PLCopen XML

To decouple the target format PLCopen XML from various input and output data formats,
AutomationML defines an Intermediate Modeling Layer (IML) as depicted in Figure 1. In this way the
complex transformation rules from and to PLCopen XML specifics need to be defined only once, for
each specific input format only transformation rules to the simpler intermediate layer need to be
defined, improving the extensibility of AutomationML for new input formats.
To summarize the main categories and to give them a formal background the Intermediate Modeling
Layer (IML) is defined for clarification and simplification of the mapping process of different model
types to AutomationML. Nevertheless, it does not constitute a new modeling language.
For the import of a logic description out of SFCs, a tool has to interpret them in an appropriate way to
restore the original format or create another representation of the information. Thus, tools can also use
AutomationML to transfer logic formats. In this case the user must be aware of possible information
loss, since AutomationML cannot compensate different modeling power of formats, e.g. a PERT chart
can be interpreted as Gantt chart but some PERT specific timing information will be lost.
1.3
Interlocking Description in Automation Engineering
The second part of logic information covered by AutomationML is the interlocking description in
different level of detail belonging to an industrial plant or to single components.
AutomationML distinguishes between two different types of interlocking information. It reflects the two
main concepts:
the causes of an interlocking condition and
the resulting effects of an interlocking condition.
Hereby, the cause represents the situation resulting in the need to interlock something. This case is
covered by the definition and description of signal groups. The effect to other groups of objects is
expressed by the definition, description, and association of component groups.
These relations between signal group and component group will express the relation between cause
and effect within an interlocking. In AutomationML different levels of detail are used to exchange these
logical interlocking conditions. Therefore, AutomationML provides common rules and mechanisms to
store different interlocking models for important phases of the engineering process.
AutomationML uses two concepts to store interlocking description. To describe signal group and
component group the basic AutomationML group concept is used. This concept exploits fundamental
CAEX capabilities and enables an integration of the necessary information within the AutomationML
top level documents. To express the relation between both types of groups and to express the internal
logical relation within the groups Function Block Diagrams (FBD) of the IEC 61131-3 are used. They
are stored in PLCopen XML documents similar to behaviour descriptions.
For the import of an interlocking description, a tool has to interpret according to its use case the signal
and component groups within the top level description or the FBD description within the refrenced
PLCopen XML documents. Of course it is possible to use both concepts in combination.
13

1.4
Structure of this Document
This document gives an introduction to the handling of logic information in AutomationML and
describes basic concepts and application rules for storing and reading different kinds of logic
information using AutomationML.
After a brief introduction chapter one presents the problem of storing logic information out of different
input models and charts within one common AutomationML logic description.
Chapter 2 describes the logic concepts with the corresponding logic models and charts considered in
AutomationML.
The Intermediate Modelling Layer (IML) as basement for a transparent mapping of logic models to the
target logic data format - PLCopen XML- is introduced in chapter 3.
In the following chapter 4 the detailed transformation rules necessary to transform IML described logic
models to the target format PLCopen XML are specified.
The complex transformation rules for the logic input formats Gantt chart, PERT chart, Impulse
diagrams and State charts to IML are defined in chapter 5.
Chapter 6 starts with a short overview about the AutomationML Top Level Architecture. This is used
for as basis for the detailed description of the mechanisms to link AutomationML logic description into
the top level format.
Finally the document closes with the AutomationML specification of the AutomationML interlocking
description in chapter 7.
1.5
References to other Documents
The AutomationML top-level architecture provides the ability to store all the different facets of the plant
engineering information including plant topology, geometry, kinematics, behaviour, references and
relations [1].
The international standard CAEX (Computer Aided Engineering Exchange) according to IEC 62424 is
a neutral data exchange format for storing hierarchical object information and properties [IEC62424].
PLCopen XML is a vendor-neutral data exchange format for the storage of PLC program information
according to IEC 61131-3 [PLCopen2010].
The international standard IEC 61131-3 specifies five programming languages for the implementation
of programs for programmable logic controllers (PLC) [IEC61131].
The COLLADA standard has been developed for the vendor-neutral data exchange for 3D graphical
assets [Collada2010].
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of
software engineering. It is created by, the Object Management Group [UML2010].
14

2
Sequencing and Behaviour Models in AutomationML
2.1
Overview
For logic descriptions, AutomationML covers data of different tools and disciplines, and supports
different phases in engineering with different levels of detail. AutomationML simplifies the engineering
of production systems from the first engineering steps such as plant design to final commissioning of
complete systems. Thus, different types of logic information belonging to a production system or to
single parts have to be stored. This variety of information can be differentiated into two main concepts,
namely sequencing and behaviour, but may overlap depending on the point of view and utilization of
elements in AutomationML:
Description of behaviour of AutomationML objects as a given uncontrolled model of reaction of a

part on external inputs, typically used in a white-box manner,
Description of sequencing as required controlled behaviour of a system or part, which often

represents a program executed in one or more controllers, e.g. robot controller, PLC etc..
The two concepts are typically used within AutomationML in the following contexts:
1. Uncontrolled behaviour of a single mechatronical unit:
An example of this type is the behaviour of a gripper. The interfaces of this element are
required for triggering the behaviour or signaling its states. In most cases, they represent the
same signals as the ones of the real physical element.
2. Sequences of cells or plants:
Sequences of cells or plants typically are descriptions of subsequent actions as high-level
input for PLC programming, e.g. in form of Gantt charts. They are normally bound to
compound elements such as a cell or controller. Interfaces are required for interaction with
other elements of the logic description, and consist of real signals or simplifications of these
signals. The evolution of sequences starts with a high level of abstract description of required
operations of a larger scale unit (cell, line, plant etc.), and ends with executable programs,
typically with several refinements in between.
3. Behaviour and sequencing of intelligent devices:
Intelligent devices can have both behaviour and sequencing. From an external view device
programs can be controlled by means of behaviour. From an internal view single programs
could be described as sequences. An example of this combined type is the behaviour of a
robot realized by programs interacting with a PLC as overall cell controller. It is important to
note that this example can be interpreted as both behaviour or sequencing, depending on the
point of view.
Mechatronical Units with:
Project
sequencing
AutomationML Objects with Logic Description
Station
Reference
behavior
Sequencing
sequencing/behavior
Sequencing
Robot
Behavior
Gripper
Behavior
Device
Figure 2: Types of logic descriptions in AutomationML
15

AutomationML provides a rich selection of typical models for important phases of the engineering
process and data:
Gantt charts are typically used to define sequences of operations during the first planning phases.
PERT charts are used in a similar way, but can additionally express complex timing conditions of
processes.
Impulse diagrams allow to describe sequences in detail and to introduce real signals and additional
conditions.
State charts are used to describe behaviour of mechatronical units.
SFCs can be used to describe complex sequences with loops and conditional execution; in later
engineering phases SFCs can describe executable PLC programs including mapping to real
control hardware.
The logic description within AutomationML is designed to be extensible for further models.
2.2
Gantt Charts
Gantt charts are a graphical representation of discrete event models typically used to describe the
order and execution time of activities, which are represented as bars, on a high level of abstraction.
They are used within early plant engineering phases to represent the timing of manufacturing
processes.
The main information stored within Gantt charts are start and end times of bars and
predecessor/successor relations among bars. Hence, the main modeling means of Gantt charts are:
bars with start and end point of time as well as duration,
ordering relations representing a predecessor-successor-relation between bars.
Usually Gantt charts enable the modeling of half ordered sets of sequential and concurrent running
activities. Thereby, Gantt charts enable the modeling of an AND divergence and convergence of
control flows. They do not provide modeling means for the modeling of alternatives or cycles.
Gantt charts have no fixed time scale, i.e. it is possible to represent the start and end points of bars
with respect to a global clock but also with respect to several local clocks started by end dates of bars.
Nevertheless, the most used version is the global clock which is also supported by AutomationML.
An example of a Gantt chart is given in Figure 3. It describes the processes of transport of a work
piece and its machining by a robot within a cell.
Sequence 2
Id
Name Prede- Start Dura- End

cessor time tion time
1
Handover to HTR002
2
Move to Lift Position
3
Lift skid
4
Lower skid
5
Move to end of 110HTR002
6
Initialise Robot 1
7 Execute Manufacturing Robot 1
8
Postprocess Robot 1
9
Initialise Robot 2
10 Execute Manufacturing Robot 2
11
Postprocess Robot 2
1
2
7
4
3, 6
7
6
7, 9
10
0
4
7
23
27
0
9
18
6
18
23
4
3
2
4
7
6
9
4
4
5
3
10
15
20
25
30
35
40
4
7
9
27
34
6
18
22
10
23
26
Figure 3: Example of a Gantt chart
2.3
PERT Charts
PERT charts belong to the group of network plans. They are used to describe and analyze temporal
relations of the execution of a set of interdependent nodes. Network plans are applied within early
16
45
50

stages of the engineering process to represent the timing and interdependence of manufacturing
processes with an enriched capability for timing description compared to Gantt charts.
The main information stored within PERT charts is:
Nodes with earliest and latest start time point, earliest and latest end time point, duration, as well
as delay
Ordering relations representing a predecessor-successor-relation between nodes
Generally, the ordering relations of network plans permit the following rules for two nodes to be
defined:
1. End-start relation: Node 2 starts after the end of node 1.
2. Start-start relation: Node 2 starts after the start of node 1.
3. Start-end relation: Node 2 ends after the start of node 1.
4. End-end relation: Node 2 ends after the end of node 1.
Since only end-start relations are commonly used in PERT charts, AutomationML supports only this
type of ordering relation.
Usually, PERT charts enable the modeling of concurrent nodes, i.e. the modeling of an AND
divergence and convergence of control flows. As Gantt charts, they do not provide means for the
modeling of alternatives or cycles.
The following figure shows an example of a PERT chart.
0
Handover to HTR002
1
23
12
18
31
18
24
24
30
10
18
23
23
26
Execute Manufacturing
Robot 2
24
31
27
36
36
Postprocess Robot 2
31
34
22
12
24
26
Postprocess Robot 1
12
4
Lower skid
Initialse Robot 2
18
2
Lift Skid
Robot 1
Initialse Robot 1
4
35
Figure 4: Example of a PERT chart
17
45

2.4
Impulse Diagrams
Impulse diagrams are used to describe the temporal course of states of system components together
with signals among them to activate state changes. To describe the value sequences and relations of
signals over time, a global timescale or internal clocks of the components can be used.
Some conventions are made for the naming of modeling elements of Impulse diagrams as illustrated
in Figure 5:
An object within the diagram representing a signal or state of an mechatronical unit with different
possible values will be named a resource. In the Impulse diagram each resource will be
represented by a set of rows indicating possible states of the resource.
Resources can be organized within groups representing hierarchies of mechatronical unit.
A resource can attain resource states, e.g. indicating different discrete values of an associated real
I/O signal or variable. Changes of the state of resource are named resource state changes.
A sequence of resource states and resource state changes in the diagram is named a resource
state flow. Remaining in a resource state is indicated by horizontal line; resource state changes are
visualized by lines connecting the predecessing and successing resource state.
Signals in the Impulse diagram are links between resource state flows representing
dependencies. When entering a new resource state, signals can trigger state changes of another
resource (internal signal). Resources can also fire internal signals when leaving states after a given
duration.
The timeline within an Impulse diagram represents a time scale with discrete points in time that is
used globally within the system. At any point in time, signals can be fired from the timeline (external
signal).
Timeline
State
Resource
Resource
Pos1
Device 1
10
Resource State Flow

Resource
State
Pos2
Pos3
High
Device 2
Signal
Low
Resource
State Change
Figure 5: Example of an Impulse diagram with naming conventions

Resource
State
Pos1
Resource 1
A
B
10
15
E
E
Pos2
B
Pos3
Pos1
Resource 2
Pos2
Pos1
Resource 3
Pos2
Pos1
Resource 4
&
Pos2
Pos1
Resource 5
Pos2
Figure 6: Signals in Impulse diagrams

18

Signals have the following properties and types:
External signals have an origin outside of resource state flows in the diagram; thus, they are not
bound to resource state changes, but may occur at any point in time. They are fired by the timeline.
A special case is a start signal occurring at time point zero (A in Figure 6).
Internal signals result from the end of a resource state change or from leaving a resource state
after a pre-defined duration and may trigger other resource state changes (B in Figure 6).
One signal can trigger several resource state changes of different resources (C in Figure 6).
Resource state changes can depend on more than one signal. These signals are in a logical
relation, but need not occur at the same point in time (D in Figure 6).
Signals resulting of the end of a resource state change can be consumed by the corresponding
resource internally, e.g. to trigger a subsequent resource state change (E in Figure 6).
Resource state changes can also be triggered by the resource internally without signals, e.g. by an
internal clock (F in Figure 6).
Two types of timing information have to be considered and illustrated in Figure 7:
The delay between two subsequent external signals is defined as signal time delay (std)
The duration of a resource state change or a predefined duration within a resource state is defined
as time delay (td)
std
Resource
State
t
Pos1
Device 1
Pos2
td1
td2
td3
tdn
Figure 7: Timing information within Impulse diagrams

Impulse diagrams may contain additional information, which is not considered here:
Names of groups (in a hierarchy),
Names of resource state changes,
Names of signal inputs associated to resource states,
Names of actuator outputs associated to resource states,
Pre-defined durations with respect to the global clock for:
2.5
Remaining within a resource state,
Resource state changes.
Sequential Function Charts
Sequential Function Charts (SFC) are one of the programming languages of IEC 61131-3. They have
been developed to provide means for easy implementation of sequences of operations within a
controlled system.
Therefore, SFCs serve for the representation of state based operation sequences with a variety of
temporal conditions to control the operation execution timing and provide basic rules for the
development of control programs.
The main but not exhaustive modeling means of SFCs are:
Steps represent stable situations within the system enabling the execution of operations.
Transitions represent the condition-based change between steps.
19
Actions represent the execution of operations. They can be associated to one or more than one
step grouped within action blocks. Actions may have timing conditions controlling the time point
and duration of execution of the covered operations.
Convergences and divergences represent the selective or parallel threading of the control flow
within a SFC.
Jump steps represent timeless hops to defined steps.
Timing conditions represent temporal conditions of actions related to the activity of steps. Thereby
it is possible to execute an activity:
o
as long as the step it belongs to is active
as long until it is directly switched of
for a certain amount of time
after a certain amount of time
An example of an SFC is depicted in Figure 8.
20

S1
A1
T1
S2
Step
D
17
D
20
A2
A3
Activity
T2
Simultaneous Divergence
S3
L
25
A4
S4
SL
15
SL
10
SD
5
SD
0
LatestEnd._A5
EarliestEnd._A5
LatestStart._A5
A5
Selection Divergence
T3
S5
T4
L
10
A6
S6
T5
T6
D
5
L
15
Delay._A7
A7
Selection Convergence
S7
A8
Simultaneous Convergence
T7
S1
Transition
Figure 8: Example of a SFC inT017

IEC 61131-3
2.6
State Charts
S1
A State chart is a discrete event model based on the work of Harel [Harel1988]. They are widely
known as part of the Unified Modeling Language (UML). Usually they are used to describe the
behaviour of a system in terms of its reachable state space. Hence, within the engineering chain of
manufacturing systems they are mostly applied during the design of system components to represent
their uncontrolled behaviour. Within the simulation and verification of controlled systems they typically
serve as counterpart of the controller to close the control loop.
The main modeling elements of State charts are states, transitions, activities, guards and events as
trigger conditions. In addition State charts enable the design of hierarchical and concurrent acting
systems by providing means for the modeling of concurrent sub-states.
21

Within AutomationML the following modeling elements and concepts are used:
States representing stable situations within the system enabling or requiring the execution of
operations. Initial state and terminal state are special states.
Actions associated to states representing operations which are executed at the moment of the
state entry, during the duration of the state, or at the moment of state exit.
State transitions representing the control flow over states. Associated guards and events are used
as trigger conditions.
Actions associated to state transitions representing operations made during the state transition.
Note: The AutomationML concept for logic description implements a mechanism for the modelling
of run to completion. This allows to store State charts into the target format PLCopen XML.
Events representing external signals and driving the control flow within the modeled system.
States may contain sub states; these are organized in one or more concurrent State charts. Thus,
State charts can have a state hierarchy.
State transitions may connect states of different levels of the state hierarchy.
History connectors represent the last recent state valid within a State chart. They replace all states
of a State chart region and can be the end point of a state transition but not its beginning.
Condition connectors represent a state transition split expressing a decision between two or more
states depending on its attached events and guards.
An example of a State chart as considered within AutomationML is given in Figure 9.
State 1
Event 4 / [Guard 5]
H
Event 4 / [Guard 4]
State 2
State 1.1
State 1.3
Event 2
[Guard 6.1]
Event 2
Event 1 / [Guard 1]
State 1.2
C
Event 5
Event 3 / [Guard 3]
Guard 2 / Activity 1
State 1.3
[Guard 6.2]
Event 6
[Guard 6]
State 3
Entrance Activity 2
Activity 3
Exit Activity 4
Figure 9: Example simple State chart

AutomationML does not provide mechanisms to evaluate State charts but only a data exchange
format for logic data expressed by State charts. Nevertheless, AutomationML will enable the mapping
of behaviour relevant information which is not coded within the structure of State charts.
AutomationML will consider therefore the following information:
State internal charts can be distinguished with respect to its level of execution completeness at the
moment of chart drop out. It is possible to define that a chart can be left only if its execution has
reached a terminal state.
22

3
The Intermediate Modeling Layer
3.1
Overview
The purpose of the Intermediate Modeling Layer (IML) is to decouple the target format PLCopen XML
from various input and output data formats. It is quite comparable to SFCs of the IEC 61131-3, but
extended to support further models and diagrams. The IML shall be used for the description of
sequencing and behaviour of different elements and not for further information like interlocking
information.
An IML system consists of elements with their properties and relations, and rules for the definition of
valid IML models as depicted in Figure 10.
Jump j
j.Pre
j.ID
j.Pre
j.State
SimultaneousDivergence simDiv
j.Pre
simDiv.ID
State s
Activity a
a.ID
a.Name
a.Init
a.Current
a.Terminal
a.Time
a.Formula
a.Pre
s.Pre
s.ID
s.Name
s.Init
s.Current
s.Terminal
simDiv.Pre
SelectionConvergence selCon
s.Pre
selCon.ID
simCon.Pre
selDiv.Pre
SelectionDivergence selDiv
s.Pre
a.FiredEvents
st.Pre
st.Guard. StateTransition st
ConsumedEvents
st.ID
st.Name
st.Guard
st.Pre
st.Pre
simCon.Pre
simDiv.ID
SimultaneousConvergence simCon
simCon.ID
st.Guard.Boolean
Variable var
Event ev
ev.Name
var.ID
var.Name
var.Type
Var.Content
var.SIUnit
var.InitialValue
var.Address
Comment com
com.Content
All entities
com.Pre
h.Members
Header h
h.ID
h.Name
ad.Pre
addData ad
ad.ID
ad.Type
ad.Name
Figure 10: IML system entities and its relations

An example of an IML system with all IML elements is depicted in Figure 11; its mapping to PLCopen
XML is described in Annex A in detail.
23
InitialInitial
StateState
ID= ISID_20090303_001,
Init=TRUE, Current=FALSE,
Terminal =FALSE
Transition 1
ID= ISID_20090303_002,
Guard.Var=a,[2;17],
Event
Variable
ID=ISID_20090303_013
Name=e
ID= ISID_20090303_011,
Name=b, Type=Boolean,
InitialValue=FALSE
Variable
Variable
ID= ISID_20090303_010,
Name=a, Type=Int,
InitialValue=9
ID= ISID_20090303_012,
Name=c, Type=Boolean,
InitialValue=TRUE
Intermediate State
Action 1
ID= ISID_20090303_003,
Init=FALSE, Current=TRUE,
Terminal =FALSE
ID= ISID_20090303_008, Init=FALSE,

Current=TRUE, Terminal =FALSE,
Formula=[a=TRUE], FiredEvent={e},
Time.Duration=12, Time.Delay=6,
SelectionDivergence
Transition 2
ID= ISID_20090303_004,
Guard.Boolean=b,
ConsumedEvents={e}
ID= ISID_20090303_009
Transition 3
ID=
ISID_20090303_006,
Guard.Boolean=c,
ConsumedEvents={e}
Terminal State
JumpInitialState
ID= ISID_20090303_005, Init=

FALSE, Current=FALSE,
Terminal = TRUE
ID= ISID_20090303_007,
State=InitialState
Figure 11: Example of an SFC in IML

The following sections cover the description of abstract IML elements. These elements represent the
main categories usually exploited within logic models.
These IML elements and their meaning in AutomationML are defined in the second section of this
chapter. Within the third part of this chapter the properties of each IML element and the relations
between IML elements are defined.
3.2
IML Systems Element Overview
Each IML system consists of sets of the following model elements.

1. Header h
The header h consists of an identifier, a name and a set of all IML elements belonging to the
ILM system. Attributes of the element header are described in chapter 3.3.1.
2. State
A state describes a stable situation within a system where a dedicated set of properties is
valid. These properties can be given by running actions, events, and values of process
variables. States are reached and left via state transitions. Special states are initial, current,
and terminal states. Attributes of the element state are described in chapter 3.3.2.
3. State transition
A state transition is a change from one state to one or several next states by interpreting state
transition conditions. Attributes of the element state transition are described in chapter 3.3.3.
4. Activity
An activity describes one or more operations related to certain states. It is characterized by
required and changed variables, local time properties and by possible events fired after its
execution. Special activities are initial, current, and terminal activities. Attributes of the element
activity are described in chapter 3.3.4.
Note: Activities can not be attached to transitions in IML.
5. Jump
A jump is an additional representation of a state. Its activation leads to entering the associated
target state. Attributes of the element jump are described in chapter 3.3.5.
24

6. Selection divergence
A selection divergence is a logical association between one predecessor state and two or
more successor state transitions. The successor state transitions can be regarded as having
an XOR relation. Attributes of the element selection divergence are described in chapter 3.3.6.
7. Simultaneous divergence
A simultaneous divergence is a logical association between one predecessor state transition
and two or more successor states. The successor state can be regarded as having an AND
relation. Attributes of the lement simultaneous divergence are described in chapter 3.3.7.
8. Selection convergence
A selection convergence is a logical association between two or more predecessor state
transitions and one successor state. The predecessor state transitions can be regarded as
having an XOR relation. Attributes of the element selection convergenceare described in
chapter 3.3.8.
9. Simultaneous convergence
A simultaneous convergence is a logical association between two or more predecessor states
and one successor state transition. The predecessor states can be regarded as having an
AND relation. Attributes of the element simultaneous convergence are described in chapter
3.3.9.
10. Event
An event is fired by an activity to which it is associated. Events are mainly used as triggers for
state transitions. Attributes of the element event are described in chapter 3.3.10.
11. Variable
A variable is a modeling entitie that characterize states and activities.It value can be changed
by activities; it can be used as trigger conditions for state transitions or as system input and
output. Attributes of the element variable are described in chapter 3.3.11.
12. Comment
Comment is used for descriptive information. Attributes of the element comment are described
in chapter 3.3.12.
13. Additional data
Additional data allow storing information beyond the definitions of SFC in both IML and IEC
61131-3. Examples complex timing information, runtime information and descriptive data.
Attributes of the element additional data are described in chapter 3.3.13.
Note: The syntax of additional data is specified in a separate XML schema in chapter 4.2.2.
3.3
Element Properties and Relations
The IML elements own properties and relations to other elements which are described in this chapter.
3.3.1
Header Properties and Relations
A header h is characterized by the following properties:

1. h.ID represents the unique identification of the IML system.
2. h.Name represents the unique name of the IML system.
An header h has the following relations:
3.
3.3.2
h.Members represents the set of member elements of the IML system.
State Properties and Relations
A state s is characterized by the following properties:

1. s.ID represents the unique identification of s within an IML system.
2. s.Name is the unique name of s within an IML system.
3. s.Init is a Boolean value indicating that s is an initial state.
25

4. s.Current is a Boolean value indicating that s is a current activated state.
5. s.Terminal is a Boolean value indicating that s is a terminal state.
Each state s can have the following relations:
6. s.Pre is the set of predecessors of s covering the references to selection convergences,
simultaneous divergences and state transitions.
3.3.3
State Transition Properties and Relations
A state transition st is characterized by the following properties:

1. st.ID represents the unique identification of st within an IML system.
2. st.Name represents the unique name of st within an IML system.
3. st.Guard represents one or more of the following execution conditions of the state transition:
a. Empty guard.
b. One of the following:
i. st.Guard.Boolean names the unique Boolean variable giving the firing
condition.
ii. st.Guard.Value names a unique variable and a closed interval of valid
values
for
the
variable
as
necessary
firing
condition.
Note: The condition is true only if the value of the variable is within or on the
borders of the interval.
iii. st.Guard.Formula names a Structured Text following IEC 61131-3 formula
providing a Boolean value to encode the necessary firing condition.
iv. Combination of ii and iii.
c.
st.Guard.ConsumedEvent names all events that together are necessary firing
conditions.
Each state transition can have the following relations:
4. st.Pre is the set of predecessors of st covering the references to predecessor states,
simultaneous convergences and selection divergences.
3.3.4
Activity Properties and Relations
An activity a is characterized by the following properties:

1. a.ID represents the unique identification of a within an IML system.
2. a.Name represents the unique name of a within an IML system.
3. a.Init is a Boolean value indicating that a is an initial activity.
4. a.Current is a Boolean value indicating that a is a currently running activity.
5. a.Terminal is a Boolean value indicating that a is a terminal activity.
6. a.Formula names a Structured Text formula.
7. a.Time represents the time condition of a, all using seconds (s) (see section 3.4.4):
a. a.Time.Duration is a non-negative real value representing the duration of a.
b. a.Time.Start is a range [Earliest,Latest] with non-negative real values as boundaries
for the start point of a.
c.
a.Time.End is a range [Earliest,Latest] with non-negative real values as boundaries

for the end point of a.
26

d. a.Time.Delay is a non-negative real value representing the delay of starting a.
An activity a can have the following relations:
8. a.FiredEvent names all events fired at the end of a.
9. a.Pre represents the set of predecessors of a covering the relationship to predecessor states.
3.3.5
Jump Properties and Relations
A jump j is characterized by the following property:

1. j.ID is the unique identification of j within an IML system.
Each jump can have the following relations:
2. j.Pre is the set of predecessors of j referencing predecessor selection convergences,
simultaneous divergences, and state transitions.
3. j.State is the unique name defining the state to which j belongs to.
3.3.6
Selection Divergence Properties and Relations
A selection divergence selDiv is characterized by the following property:

1. selDiv.ID is the unique identifier of selDiv within an IML system.
A selection divergence selDiv has the following relation:
2. selDiv.Pre is the unique predecessor state of selDiv.
3.3.7
Simultaneous Divergence Properties and Relations
A simultaneous divergence simDiv is characterized by the following property:

1. simDiv.ID is the unique identifier of simDiv within an IML system.
A simultaneous divergence simDiv can have the following relation:
2. simDiv.Pre is the unique predecessor state transition of simDiv.
3.3.8
Selection Convergence Properties and Relations
A selection convergence selCon is characterized by the following property:

1. selCon.ID is the unique identification of selCon within an IML system.
A selection convergence selCon can have the following relation:
2. selCon.Pre is the set of predecessors of selCon referencing predecessor state transitions.
3.3.9
Simultaneous Convergence Properties and Relations
A simultaneous convergence simCon is characterized by the following property:

1. simCon.ID is the unique identification of simCon within an IML system.
A simultaneous convergence simCon can have the following relation:
2. simCon.Pre is the set of predecessors of simCon referencing predecessor states.
3.3.10 Event Properties
An event ev is characterized by the following property:
1. ev.ID is the unique identification of ev within an IML system
2. ev.Name is the unique name of ev within an IML system.
27

3.3.11 Variable Properties and Relations
A variable var is characterized by the following properties:
1. var.ID is the unique identifier of var within an IML system.
2. var.Name is the unique name of var within an IML system.
3. var.Type is the data type of var following the data types defined by IEC 61131-3.
4. var.SIUnit is the measurement type of var following the SI system of measuring units.
5. var.InitialValue is the initial value of var.
6. var.Address is the physical address of var as defined by IEC 61131-3.
7. var.Content describes the use of var as local, input, output or inout variable. Default value
is local.
3.3.12 Comment Properties and Relations
A comment com is characterized by the following property:
1. com.Content is the content string of com.
A comment com has the following relation:
2. com.Pre references the unique IML element to which com is associated.
3.3.13 Aditional Data properties and relation
An addData element ad is characterized by the following properties:
1. ad.ID represents the unique identification of ad within an IML system.
2. ad.Type contains one value of the list of types for additional data as described in section 4.2
3. ad.Value is a string representing the XML content of the addData element.
An addData element ad has the following relation:
4.
ad.Pre represents the unique predecessor of ad of any type of element of an IML system.
28

4
Mapping of IML to PLCopen XML SFC
4.1.1
Overview
The XML data format PLCopen XML [PLCopen2010] specified by the PLCopen association has the
purpose to store and exchange all relevant programming information for IEC 61131-3 PLC
programming projects. Thereby, it covers the exchange of the five IEC 61131-3 programming
languages, graphical information for the graphic based programming languages and the structure of
programming projects as well as supplier specific information. These information can be integrated
into PLCopen XML documents via an own XML schema for the definition of the additional data.
AutomationML uses the programming language Sequence Function Charts (SFC) and its
representation in PLCopen XML to store all relevant logic information. Therefore, the following
sections provide the specification of the AutomationML additional data schema and mapping rules for
the IML systems to PLCopen XML documents.
4.2
4.2.1
Additional Data
PLCopen XML addData
One principal of the integration of logic data into AutomationML with PLCopen XML is the definition of
AutomationML specific information and its integration in the data format.
PLCopen XML implements such a mechanism to integrate vendor specific data by introducing new
schema elements addData and addDataInfo.
The element addDataInfo is used to specify the vendor specific data with a name and an URI (uniform
resource identifier) for the corresponding addData schema in a unique way to identify the additional
data element content. It enables tools to interpret and process the vendor specific data. From version
2.0, PLCopen XML allows to integrate multiple vendor specific schemas. For each schema one
instance of addDataInfo is used within the <contentHeader> element to specify this necessary
information globally for the PLCopen XML document.
Then vendor specific information can be stored in <addData> elements at any place in the document,
following the schema as determined in the <addDataInfo> element.
4.2.2
AutomationML Schema for Additional Data within the Logic Description
As indicated AutomationML exploits the additional data mechanisms of PLCopen XML to integrate
vendor specific data for storing information required by AutomationML but not covered by the
PLCopen XML specification. Within IML systems these information are expressed by single properties
of different IML elements and the addData element. Hence, AutomationML specifies a schema
covering the structure to store the content of these IML addData elements. Within the following section
this schema is defined.
29

Element AutomationML
diagram
properties
children
content
complex
aml:Time aml:ChartType aml:ResourceStateChangeDefinition aml:InterruptableAction

aml:StateChartSubCharts
aml:StateChartStateType
aml:StateChartActionType
aml:ImpluseChartResorceGroup aml:ImpulseDiagramPLCVariable aml:StateStatus
aml:ActionStatus
Table 1: AutomationML element
30

Element AutomationML/Time
diagram
type
properties
children
aml:TimeInfoType
isRef
minOcc
maxOcc
content
complex
aml:Duration
aml:Delay
aml:EarliestStart
aml:LatestStart
aml:EarliestEnd
aml:LatestEnd
Table 2: <Time> element

Element AutomationML/Time/Duration
diagram
type
properties
xs:decimal
isRef
minOcc
maxOcc
content
simple
Table 3: <Duration> element

Element AutomationML/Time/EarliestStart
diagram
type
properties
xs:decimal
isRef
minOcc
maxOcc
content
simple
Table 4: <EarliestStart> element
31

Element AutomationML/Time/LatestStart
diagram
type
properties
xs:decimal
isRef
minOcc
maxOcc
content
simple
Table 5: <LatestStart> element

Element AutomationML/Time/EarliestEnd
diagram
type
properties
xs:decimal
isRef
minOcc
maxOcc
content
simple
Table 6: <EarliestEnd> element

Element AutomationML/Time/LatestEnd
diagram
type
properties
xs:decimal
isRef
minOcc
maxOcc
content
simple
Table 7: <Latest> element

Element AutomationML/Time/Delay
diagram
type
properties
xs:decimal
isRef
minOcc
maxOcc
content
simple
Table 8: <Delay> element
32

Element AutomationML/ChartType
diagram
type
properties
facets
restriction of xs:string
isRef
minOcc
maxOcc
content
simple
enumeration
stateChart
enumeration
impulseDiagram
enumeration
ganttChart
enumeration
pertChart
enumeration
sequentialFunctionChart
Table 9: <ChartType> element

Element AutomationML/ResourceStateChangeDefinition
diagram
properties
children
isRef
minOcc
maxOcc
unbounded
content
complex
aml:DefinitionName aml:Duration
Table 10: <ResourceStateChangeDefinition> element

Element AutomationML/ResourceStateChangeDefinition/DefinitionName
diagram
type
properties
xs:string
isRef
content
simple
Table 11: <DefinitionName> element

Element AutomationML/ResourceStateChangeDefinition/Duration
diagram
type
properties
xs:decimal
isRef
content
simple
Table 12: <Durationn> element

33

Element AutomationML/InterruptableAction
diagram
type
properties
xs:boolean
isRef
minOcc
maxOcc
content
simple
Table 13: <InteruptableAction> element

Element AutomationML/StateChartSubCharts
diagram
properties
children
isRef
minOcc
maxOcc
content
complex
aml:POURef
Table 14: <StateChartSubCharts> element

Element AutomationML/StateChartSubCharts/POURef
diagram
properties
isRef
minOcc
maxOcc
unbounded
Table 15: <POURef> element
34

Element AutomationML/StateChartStateType
diagram
type
properties
facets
isRef
minOcc
maxOcc
content
simple
enumeration
higherLevelState
enumeration
historyConnector
enumeration
conditionConnector
enumeration
stateForActivity
Table 16: <StateChartStateType> Element

Element AutomationML/StateChartActionType
diagram
type
properties
facets
isRef
minOcc
maxOcc
content
simple
enumeration
entryAction
enumeration
doAction
enumeration
extitAction
Table 17: <StateChartActionType> Element

Element AutomationML/ImpluseDiagramResorceGroup
diagram
type
properties
xs:string
isRef
minOcc
maxOcc
content
simple
Table 18: <ImpulseChartResourceGroup> element
35

Element AutomationML/ImpulseDiagramPLCVariable
diagram
properties
children
isRef
minOcc
maxOcc
content
complex
aml:Name aml:DataType aml:Address
Table 19: <ImpulseDiagramPLCVariable> element

Element AutomationML/ImpulseDiagramPLCVariable/Name
diagram
properties
isRef
Table 20: <Name> element

Element AutomationML/ImpulseDiagramPLCVariable/DataType
diagram
properties
isRef
minOcc
maxOcc
Table 21: <Datatype> element

Element AutomationML/ImpulseDiagramPLCVariable/Address
diagram
properties
isRef
minOcc
maxOcc
Table 22: <Address> element
36

Element AutomationML/StateStatus
diagram
type
properties
facets
isRef
minOcc
maxOcc
content
simple
enumeration
initial
enumeration
current
enumeration
terminal
Table 23: <StateStatus> element

Element AutomationML/ActionStatus
diagram
type
properties
facets
isRef
minOcc
maxOcc
content
simple
enumeration
initial
enumeration
current
enumeration
terminal
Table 24: <ActionStatus> element

4.2.3
Declaration and Usage of AutomationML Additional Data Schema in PLCopen XML
To make use of the AutomationML additional data schema, it has to be declared within the PLCopen
XML document according to the definition of PLCopen XML 2.0. This declaration is depicted in Figure
12.
37
Figure 12: Declaration of the AutomationML additional data schema within PLCopen XML
The following example depicts the usage of additional data within a PLCopen XML document. The
additional information is attached to an action, whether this action is interruptible.
Figure 13 shows how this additional information is attached to the action element.
Figure 13: Example of additional information in AutomationML
4.3
4.3.1
Mapping of IML to PLCopen XML

Common Rules
The translation of IML to PLCopen XML is based on the similarity of IML and SFC following the IEC
61131-3 and the capability of PLCopen XML to store SFCs. Within this translation process the
different IML elements and their parameters and relations are, if possible, translated one by one to
SFC elements and stored as such with PLCopen XML. Information required by PLCopen XML but not
given in IML is generated in a unique way. Information given in IML but not directly expressible by
PLCopen XML is mapped to additional data as given in section 4.2.
38

The general mapping is based on the following principles:
Each IML system, i.e. its header and its elements, is mapped to one POU and corresponding sub
elements.
Each state element of IML is mapped to one step element.
Each state transition element of IML is mapped to one transition element.
Each activity element of IML is mapped to one action element within an action block element.
Each jump element of IML is mapped to one jump step element.
Each selection divergence element of IML is mapped to one selection divergence element.
Each selection convergence element of IML is mapped to one selection convergence element.
Each simultaneous divergence element of IML is mapped to one simultaneous divergence element.
Each simultaneous convergence element of IML is mapped to one simultaneous convergence

element.
Each event element of IML is mapped to one variable element.
Each variable element of IML is mapped to one variable element.
Each comment element of IML is mapped to one documentation element.
Each addData element of IML is mapped to one element of the AutomationML addData schema
according to the PLCopen XML 2.0 specification. However, this is an extension to IEC 61131-3
SFCs.
The detailed mapping rules are described in the following subsections.

The different properties and relations of the IML elements are mapped to attributes or to sub elements
of the corresponding PLCopen XML element. Examples are the mapping of the IML element property
id to the PLCopen XML element attribute globalID respectively the mapping of the IML element
relation Pre to the PLCopen XML element attribute localId together with its application within PLCopen
sub-elements connection as refLocalId. Another example is the mapping of the IML st.Guard to the
sub-element body of the PLCopen XML transition element.
To ensure an efficient data storage, only one addData element shall be used within one PLCopen
XML element. Several IML addData elements shall be combined to only one PLCopen XML addData
element.
According to the structure of the PLCopen XML schema all information are stored weather in the
interface, action, transition or SFC parts of one POU within on PLCopen document, see Figure 14.
39

interface part of an POU
action part of an POU
transition part of an POU
SFC part of an POU
Figure 14 Used part of the PLCopen XML schema:

4.3.2
Mapping of Headers and their Relations
An IML header h with its relations shall be mapped to PLCopen XML <pou> element.
The mapping of properties is straightforward and formally described in Table 26.
IML element, property
Representation in PLCopen XML
<pou pouType=program>
h.ID
<pou globalID=h.ID>
h.Name
<pou name=h.Name>
Table 25: Mapping of IML header to PLCopen XML

All listed elements of h.Members shall be mapped into sub elements of the same PLCopen XML pou
element.
An example of this translation is given in Table 27.
40

IML Example
h
h.ID= ISID_20090303_000
h.Name= ExampleIML
Resulting PLCopen XML

<pou pouType="program" globalID="ISID_20090303_000"
name="ExampleIML">
</pou>
Table 26: Example transformation IML header to PLCopen XML

4.3.3
Mapping of States and their Relations
An IML state s with its relations shall be mapped to PLCopen <step> element.
The mapping of properties is straightforward and formally described in Table 27.
The s.Pre relation is mapped to <connectionPointIn> sub objects of <step>.
IML element, property and

relation
<step>
s.ID
<step localId= someIDValue globalId=s.ID>

where someIDValue is a valid value for a local ID.
s.Name
<step name= s.Name>
s.Init
<step InitialStep=s.Init>
If the value of s.Current is true, the mapping shall be done as
follows
s.Current
<step>
<addData>
<data name=http://www.automationML.org/AML_addData.xsd>
<AutomationML>
<StateStatus>
current
</StateStatus>
</AutomationML>
</data>
</addData>
</step>
If the value of s.Current is false, no mapping shall be done.
If the value of s.Terminal is true then the mapping shall be done
as follows
s.Terminal
<step>
<addData>
<AutomationML>
<StateStatus>
terminal
</StateStatus>
</AutomationML>
</data>
</addData>
</step>
If the value of s.Terminal is false, no mapping shall be done.
41

Recommendation: Multiple vendor specific information can merged
into one addData element.
For each element el with local ID el.x of s.Pre one
connectionPointIn element will be created as follows:
<step>
<connectionPointIn>
<connection refLocalId="el.x" />
</connectionPointIn>
</step>
s.Pre
Note: s.Pre contains the global IDs of s.

Table 27: Mapping of IML state to PLCopen XML
An example of the mapping of an IML state s is given in Table 28.
IML Example
s
s.ID = ISID_20090303_003
s.Name =
IntermediateState
s.Init = false
s.Current = true
s.Terminal = false
s.Pre =
{ISID_20090303_002}

<step localId="3" globalId="ISID_20090303_003"
name="IntermediateState" InitialStep="FALSE">
<addData>
<data name="http://www.automationML.org/AML_addData.xsd">
<AutomationML>
<StateStatus>
current
</StateStatus>
</AutomationML>
</data>
</addData>
<connectionPointIn>
<connection refLocalId="2" />
</step>
Table 28: Example transformation IML state to PLCopen XML

4.3.4
Mapping of State Transitions and their Relations
An IML state transition st is mapped to PLCopen XML <transition> element in the corresponding
SFC.
If st.Guard is not empty, st is addtionally mapped to a <transition> within the transitions part of the
same <pou>.
The properties and relations are mapped as follows:
st.ID is mapped to
the globalId parameter of <transition> within the <SFC> element of the <pou>
element
and globalId parameter of <transition> element within the <transitions>

element of the <pou> element.
st.Name is mapped to
the name attribute of the <reference> element within the conditions part of
<transition> of the <SFC> part of the <pou> element.
If st.Guard is not empty, st.Name is also mapped to the name parameter of

<transition> element within the <transitions> element of the <pou> element.
42
st.Guard is mapped to a <body> element with its specific structure within the <transition>
element in the <transitions> element of the <pou> element.
The st.Pre relation is mapped to one <connectionPointIn> sub element of <transition>

element of the <SFC> element. The elements ID is stored within the localRefID parameter of the
corresponding connection object.
The mapping is formally described in Table 29.
IML element, property, and

relation
st
<transitions>
<transition>
</transitions>
<SFC>
<transition>
<SFC>
st.ID
<transitions>
<transition globalId=st.ID>
</transitions>
<SFC>
<transition localId= someIDValue globalId=st.ID>
<SFC>
where someIDValue is a valid value for a local ID.
st.Name
<transitions>
<transition name=st.Name>
</transitions>
<SFC>
<condition>
<reference name="st.Name" />
</condition>
<SFC>
the Guard element contains st.Guard.Boolean
st.Guard.ConsumedEvent is the set {e1, , en} then
IF
st.Guard
<transitions>
<transition>
<body>
<ST>
<html xmlns="http:// www.w3.org/1999/xhtml">
<div xmlns="http:// www.w3.org/1999/xhtml"
xml:space="preserve" wsName="st.ID ">
IF (st.Guard.Boolean AND e1 AND en)
<br />
THEN st.Name:=TRUE;
<br />
e1:=False;
<br />
<br />
en:=False;
<br />
43
and

ELSE st.Name:=FALSE;
<br />
END_IF;
<br />
</div>
</html>
</ST>
</body>
</transition>
the Guard element contains st.Guard.Value
If
and
<transitions>
<transition>
<body>
<ST>
IF (st.Guard.Value.low <= st.Guard.Value.var AND
st.Guard.Value.var<= st.Guard.Value.high AND e1 AND
en)
<br />
THEN st.Name:=TRUE;
<br />
e1:=False;
<br />
<br />
en:=False;
<br />
<br />
END_IF;
<br />
</div>
</html>
</ST>
</body>
</transition>
the Guard element contains st.Guard.Formula
If
<transitions>
<transition>
<body>
<ST>
IF (st.Guard.Formula AND e1 AND en)
<br />
THEN st.Name:=TRUE;
<br />
e1:=False;
<br />
44
and

<br />
en:=False;
<br />
<br />
END_IF;
<br />
</div>
</html>
</ST>
</body>
</transition>
Note: st.Guard.Formula shall be defined as a string following the
syntax of structured text of IEC 61131-3; providing a Boolean value
as evaluation result.
Note: Only one entity out of st.Guard.Boolean, st.Guard.Value,
st.Guard.Formula can be not empty.
Note: For each element of st.Consumed.Events, the name of the
PLCopen XML element variable representing it is integrated in the
structured text body by (a) integrating its logical value in the
transition firing condition and (b) afterwards set to False.
For each element el with local ID el.x of st.Pre one
<sfc>
<transition>
<connectionPointIn>
<connection refLocalId=" el.x " />
</transition >
</sfc>
st.Pre
Note: For each element of st.Pre one connectionPointIn element

will be created.
Table 29: Mapping of IML state transition to PLCopen XML
An example of the mapping of an IML state transition st is given in Table 30.
IML Example
st
st.ID =
ISID_20090303_006
st.Name = Transition3
st.Guard.Boolean = c
st.Guard.ConsumedEvents
= e
st.Pre
{ISID_20090303_009}

<transitions>
<transition globalId="ISID_20090303_006" name="Transition3">
<body>
<ST>
<html xmlns="http://www.w3.org/1999/xhtml">
<div xmlns="http://www.w3.org/1999/xhtml"
xml:space="preserve" wsName="ISID_20090303_006">
IF (c AND e)
<br />
THEN Transition3:=TRUE;
<br />
e:=False;
<br />
ELSE Transition3:=FALSE;
<br />
END_IF
45

<br />
</div>
</html>
</ST>
</body>
</transition>
</transitions>
<body>
<SFC>
<transition localId="6" globalId="ISID_20090303_006">
<condition>
<reference name="Transition3" />
</condition>
<connectionPointIn>
</transition>
</SFC>
</body>
Table 30: Example transformation IML state transition to PLCopen XML
4.3.5
Mapping of Activities and their Relations
An IML activity a is mapped to two PLCopen XML elements,
first an <action> element within the <SFC> part and
second an <action> element within the <actions> part of the <pou> element resulting from the
IML system where a is a member.
Its properties and relations are mapped as follows:
a.ID is mapped to the globalId parameter of <action> within the <actions> part of the POU,
and the globalId parameter an <action> within the action block of the <SFC> part.
a.Name is mapped to the name parameter of <action> within the <actions> part of the POU, and
to a reference name of an <action> within the action block of the <SFC> part.
a.Init, a.Current, and a.Terminal are mapped to addData elements.
a.Formula and a.FiredEvents are mapped either to a body with a specific structure of an
<action> object within the <actions> part or to a Boolean variable depending on the existence of
content within both elements.
a.Duration is mapped to an action duration with the qualifier SD.
a.Delay is mapped to an action duration with the qualifier D.
All other timing information is directly mapped to corresponding timings of action elements. As
PLCopen SFC actions only have one qualifier that can be used for timing information, addData
information are necessary to support more complex timing information and used to express these.
Zero time values shall not be integrated in the PLCopen XML representation.
The a.Pre relation is mapped to <connectionPointIn> sub objects of <actionBlock> with the
element IDs given in a.Pre within the localRefID parameter of connection objects.
The formal description of the mapping is given in Table 31.
46

relation
<actions>
<action>
</actions>
<SFC>
<actionBlock>
<action>
</actionblock>
</SFC>
a.ID
<actions>
<action globalId=a.ID>
</actions>
<SFC>
<actionBlock>
<action localId= someIDValue globalId=a.ID/>
</actionBlock>
<SFC>
Where someIDValue is a valid value for a local ID.
a.name
<actions>
<action name="a.Name">
</actions>
<SFC>
<actionBlock>
<action>
<reference name="a.Name"/>
</action >
</actionBlock>
<SFC>
If the value of a.Init is true then the mapping is done as follows
a.Init
<SFC>
<actionBlock>
<action>
<addData>
<AutomationML>
<ActionStatus>
init
</ActionStatus>
</AutomationML>
</data>
</addData>
<action>
</actionBlock>
</SFC>
If the value of a.Init is false, no mapping shall be done.
47

If the value of a.Current is true then the mapping is done as
follows
a.Current
<SFC>
<actionBlock>
<action>
<addData>
<AutomationML>
<ActionStatus>
current
</ActionStatus>
</AutomationML>
</data>
</addData>
<action>
</actionBlock>
</SFC>
If the value of a.Current is false then no mapping is done
If the value of a.Terminal is true then the mapping is done as
follows
a.Terminal
<SFC>
<actionBlock>
<action>
<addData>
<AutomationML>
<ActionStatus>
terminal
</ActionStatus>
</AutomationML>
</data>
</addData>
<action>
</actionBlock>
</SFC>
If the value of a.Terminal is false, no mapping shall be done.
Note: If there is more than one reason to integrate an addData
element the information mapped to it is integrated in one addData
element following the AutomationML addData schema.
48

If the a.formula element is empty and the a.firedEvents element
is empty then the mapping is made as follows
a.Formula
<variable name="a.Name">
<type>
<Bool/>
</type>
</variable>
If a.formula or the set {e1,en} of a.firedEvents are NOT empty
the mapping is done as follows:
a.FiredEvent
<actions>
<action name="a.Name">
<body>
<ST>
xml:space="preserve" WsName=" a.Name ">
(*FiredEvent*)
<br />
e1:=true;
<br />
<br />
en:=true;
<br />
(*ChangedVariables*)
<br />
a.Formula
</div>
</html>
</ST>
</body>
</action>
</actions>
Note: Within action body the representing variable of a.FiredEvents
has to be set to True.
If the a.Time.Duration element is NOT empty then the mapping is
made as follows
<actionBlock>
<action qualifier="SD" duration=a.Time.Duration>
<addData>
<AutomationML>
<Time>
<earliestStart>
a.Time
a.Time.Start.earliestStart
</earliestStart>
<latestStart>
a.Time.Start.latestStart
</latestStart>
<earliestEnd>
a.Time.End.earliestEnd
</earliestEnd>
<latestEnd>
a.Time.End.latestEnd
</latestEnd>
49

<delay>
a.Time.Delay
</delay>
</Time>
</AutomationML>
</data>
</addData>
</action>
</actionBlock>
If the a.Time.Duration element is empty then the mapping is
made as follows
<actionBlock>
<action qualifier="D" duration=a.Time.Delay>
<addData>
<AutomationML>
<Time>
<earliestStart>
a.Time.Start.earliestStart
</earliestStart>
<latestStart>
a.Time.Start.latestStart
</latestStart>
<earliestEnd>
a.Time.End.earliestEnd
</earliestEnd>
<latestEnd>
a.Time.End.latestEnd
</latestEnd>
</Time>
</AutomationML>
</data>
</addData>
</action>
</actionBlock>
Note:
If
one
of
the
elements
a.Time.EarliestStart,
a.Time.EarliestEnd, and a.Time.Delay is empty, the corresponding
parts of the addData element will NOT be used.
For each element el with local ID el.x of a.Pre one
a.Pre
<SFC>
<actionBlock>
<connectionPointIn>
</actionBlock>
</SFC>
Note: For each element of a.Pre one connectionPointIn element
will be created.
Table 31: Mapping of IML activity to PLCopen XML
50

An example of the translation is given in Table 32.
IML Example
a
a.ID = ISID_20090303_008
a.name = Action1
a.Init = false
a.Current = true
a.Terminal = false
a.Formula = a:=true
a.FiredEvent = {e}
a.Time.Delay = 6
a.Pre={ISID_20090303_003
}

<actions>
<action globalId="ISID_20090303_008" name="Action1">
<body>
<ST>
xml:space="preserve" WsName="Action1">
(*FiredEvent*)
<br />
e:=true;
<br />
<br />
a:=True
</div>
</html>
</ST>
</body>
</action>
</actions>
<body>
<SFC>
<actionBlock localId="14">
<action localId="6" globalId="ISID_20090303_008"
qualifier="D" duration="6">
<reference name="Action1"/>
<addData>
<AutomationML>
<ActionStatus>
current
</ActionStatus>
<Time>
<delay>
6
</delay>
</Time>
</AutomationML>
</data>
</addData>
<connectionPointIn>
</action>
</actionBlock>
</SFC>
<body>
Table 32: Example transformation IML activity to PLCopen XML
51

4.3.6
Mapping of Jumps and their Relations
An IML jump j with its relations shall be mapped to a PLCopen <jumpStep>.

IML element, property and

relation
<jumpStep>
<jumpStep localId= someIDValue globalId=j.ID >
j.ID

j.State
<jumpStep targetName=j.State>
For each element el with local ID el.x of j.Pre one
<SFC>
<jumpStep>
<connectionPointIn>
<connection refLocalId="el.x " />
</jumpStep >
</SFC>
j.Pre
Note: For each element of j.Pre one connectionPointIn element

will be created.
Table 33: Mapping of IML jump to PLCopen XML
IML Example
j
j.ID = ISID_20090303_007
j.State = InitialState
j.Pre =
{ISID_20090303_006}

<jumpStep localId="7" globalId="ISID_20090303_007"
targetName="InitialState">
<connectionPointIn>
</jumpStep >
Table 34: Example transformation IML jump to PLCopen XML

4.3.7
Mapping of Selection Divergence and their Relations
An IML selection divergence selDiv shall be mapped to PLCopen <selectionDivergence> element.

selDiv.Pre
relation
<selectionDivergence>.
The
is
mapped
to
<connectionPointIn>
sub
objects
The element IDs in selDiv.Pre are stored within the localRefID parameter of connection objects.
52
of

relation
selDiv
<selectionDivergence>
selDiv.ID
<selectionDivergence
globalId=selDiv.ID>
someIDValue
localId=

For each element el with local ID el.x of selDiv.Pre one
selDiv.Pre
<SFC>
<selectionDivergence>
<connectionPointIn>
</selectionDivergence>
</SFC>
Note: For each element of selDiv.Pre one connectionPointIn
element will be created.
Table 35: Mapping of IML selection divergence to PLCopen XML

An example of this translation is given in Table 36.
IML Example
selDiv
selDiv.ID =
ISID_20090303_009
selDiv.Pre =
{ISID_20090303_003}

<selectionDivergence localId="9 " globalId="ISID_20090303_009">
<connectionPointIn>
Table 36: Example transformation IML selection divergence to PLCopen XML

4.3.8
Mapping of Simultaneous Divergences and their Relations
An IML simultaneous divergence simDiv shall be mapped to PLCopen <simultaneousDivergence>

element.
simDiv.Pre
relation
<simultaneousDivergence>.
The
is
mapped
to
<connectionPointIn>
sub
objects
The element IDs in simDiv.Pre are stored within the localRefID parameter of connection objects.
53
of

relation
simDiv
<simultaneousDivergence>
simDiv.ID
<simultaneous localId= someIDValue globalId=simDiv.ID>

For each element el with local ID el.x of simDiv.Pre one
simDiv.Pre
<SFC>
<simultaneousDivergence>
<connectionPointIn>
</simultaneousDivergence>
</SFC>
Note: For each element of simDiv.Pre one connectionPointIn
Table 37: Mapping of IML simultaneous divergencies to PLCopen XML

IML Example
simDiv
simDiv.ID =
ISID_20090303_019
simDiv.Pre =
{ISID_20090303018}

<simultaneousDivergence localId="19 "
globalId="ISID_20090303_019">
<connectionPointIn>
</simultaneousDivergence>
Table 38: Example transformation IML simultaneous divergencies to PLCopen XML

4.3.9
Mapping of Selection Convergence and their Relations
IML selection convergences selCon shall be mapped to PLCopen <selectionConvergence>

elements.
selCon.Pre
relation
<selectionConvergence>.
The
is
mapped
to
<connectionPointIn>
sub
objects
The element IDs in selCon.Pre are stored within the localRefID parameter of connection objects.
54
of

relation
selCon
<selectionConvergence>
selCon.ID
<selectionConvergence
globalId=selCon.ID>
someIDValue
localId=

For each element el with local ID el.x of selCon.Pre one
selCon.Pre
<SFC>
<selectionConvergence>
<connectionPointIn>
</selectionConvergence>
</SFC>
Note: For each element of selCon.Pre one connectionPointIn
Table 39: Mapping of IML selection convergence to PLCopen XML

IML Example
selCon
selCon.ID =
ISID_20090303_20
selCon.Pre =
{ISID_200903030_57;
ISID_200903030_84}

<selectionConvergence localId="20 "
<connectionPointIn>
<connectionPointIn>
</selectionConvergence>
Table 40: Example transformation IML selection convergence to PLCopen XML

4.3.10 Mapping of Simultaneous Convergences and their Relations
IML simultaneous convergences simCon shall be mapped to PLCopen <simultaneousConvergence>
elements.
simCon.Pre
relation
<simultaneousConvergence>.
The
is
mapped
to
<connectionPointIn>
sub
objects
The element IDs in simCon.Pre are stored within the localRefID parameter of connection objects.
55
of

relation
simCon
<simultaneousConvergence>
simCon.ID
<simultaneous localId= someIDValue globalId=simCon.ID>

For each element el with local ID el.x of simCon.Pre one
simCon.Pre
<SFC>
<simultaneousConvergence>
<connectionPointIn>
</simultaneousConvergence>
</SFC>
Note: For each element of simCon.Pre one connectionPointIn
Table 41: Mapping of IML simultaneous divergences to PLCopen XML

IML Example
simCon
simCon.ID
=ISID_20090303_021
simCon.Pre =
{ISID_20090303_029;
ISID_20090303_041}

<simultaneousConvergence localId="21 "
<connectionPointIn>
<connectionPointIn>
</simultaneousConvergence>
Table 42: Example transformation IML simultaneous divergences to PLCopen XML

4.3.11 Mapping of Events and their Relations
Each IML event ev shall be mapped to a PLCopen <variable> element within the interface of the
PLCopen <pou>.
relation
ev
<variable>
<type>
<derivied name=event/>
</type>
</variable>
ev.ID
<variable globalId="ev.ID">
ev.Name
<variable name="ev.Name"/>
Table 43: Mapping of IML event to PLCopen XML
56

IML Example
ev
ev.ID =
ISID_20090303_013
ev.Name = e

<interface>
<localVars>
<variable globalId="ISID_20090303_013" name="e">
<type>
<derivied name="event"/>
</type>
</variable>
</localVars>
</interface>
Table 44: Example transformation IML event to PLCopen XML

4.3.12 Mapping of Variables and their Relations
An IML variable var shall be mapped to a PLCopen <variable> element within the interface of the
PLCopen <pou> element.
relation
var
<variable/>
var.ID
<variable globalId=var.ID>
var.Name
<variable name="var.Name" />

<variable>
<type>
var.Type
var.Type
</type>
</variable>
var.initialValue
<variable >
<initialValue>
<simpleValue value="var.InitialValue" />
</initialValue>
</variable>
var.Address
<variable address="var.Address"/>
57

If the var.Content element has the value local the mapping is
made as follows:
<interface>
<localVars>
<variable>
</variable>
</localVars>
</interface>
If the var.Content element has the value input the mapping is
made as follows:
<interface>
<inputVars>
<variable>
</variable>
</inputVars>
</interface>
var.Content
If the var.Content element has the value output the mapping is

made as follows:
<interface>
<outputVars>
<variable>
</variable>
</outputVars>
</interface>
If the var.Content element has the value inout the mapping is
made as follows:
<interface>
<inOutVars>
<variable>
</variable>
</inOutVars>
</interface>
Note: The default value for of var.Content is local. If the no value
is specified the mapping for the default value shall be done.
Table 45: Mapping of IML variable to PLCopen XML
58

IML Example
var
var.ID =
ISID_20090303_010
var.Name = a
var.Type = INT
var.initialValue = 9
var.Address = empty

<interface>
<localVars>
<variable globalId="ISID_20090303_010" name="a">
<type>
<INT/>
</type>
<initialValue>
<simpleValue value="9" />
</initialValue>
</variable>
</localVars>
</interface>
Table 46: Example transformation IML variable to PLCopen XML

4.3.13 Mapping of Comment Properties and their Relations
An IML comment com shall be mapped to a <documentation> element within the corresponding
modeling element.

relation
com
<documentation>
com.Content
<documentation>
<p xmlns="http://www.w3.org/1999/
xhtml" xml:space="preserve">
com.Content
<br/>
</p>
</html>
</documentation>
Within each element el with local ID el.x of com.Pre one
<documentation> element will be created within the PLCopen XML
representation of el ows:
com.Pre
<SFC>
<el globalId=ID>
<documentation>
</documentation>
</el>
</SFC>
Table 47: Mapping of IML comment to PLCopen XML
59

IML Example
com
com.Content = This is a
test IML system.
com.Pre ={
ISID_20090303_001}

<step globalId="ISID_20090303_001">
<documentation>
xml:space="preserve"
wsName="Comment">
This is a test IML system.
</div>
</html>
</documentation>
<step/>
Table 48: Example transformation IML comment to PLCopen XML

4.3.14 Mapping of Additional Data Properties and their Relations
An IML additional data element add shall be mapped to a PLCopen <addData> element within the
corresponding modeling element.

relation
add
add.ID
add.Type
add.Value

<addData>
For further use
<addData>
<AutomationML>
<add.Type>
add.Value
</add.Type>
</AutomationML>
</data>
</addData>
For each element el with global ID of add.Pre the mapping shall
be done as follows:
add.Pre
<SFC>
<el>
<addData>
</addData>
</el>
</SFC>
Note: For each element of add.Pre one <addData> element will be
created within the relevant elements represented by ID within
add.Pre.
Table 49: Mapping of IML addData to PLCopen XML
60

IML Example
add
add.ID = n.a.
add.Type =
ActionStatus
add.Value = current
add.Pre=
{ISID_20090303_008}

<action globalId=ISID_20090303_008>
<addData>
<data
name="http://www.automationML.org/AML_addData.xsd">
<AutomationML>
<ActionStatus>
current
</ActionStatus>
</AutomationML>
</data>
</addData>
Table 50: Example transformation IML addData to PLCopen XML
61

5
Representation of Logic Models in AutomationML
5.1
Gantt Charts
5.1.1
Overview
Gantt charts are typically used to describe the order, i.e. sequence and concurrency, and execution
time of activities, which are named as bars in the following, on a high level of abstraction in early plant
engineering stages. The main stored information is: start time, end time, and duration of bars as well
as predecessor and successor relations between bars.
This section describes the basic concepts for representation of Gantt charts with IML elements. The
structure of the resulting IML model is derived from the Gantt chart according to the following
principles:
1. Gantt charts are mapped to IML Systems to support parallel bars, see chapter Start of a Gantt
Chart5.1.2..
2. Bars in Gantt diagrams shall be mapped to activities see chapter Start of a Gantt Chart5.1.3.
3. These activities shall be associated to states see chapter 5.1.3.
4. If there are no explicit relations between Gantt bars defined, i.e. they are concurrent, the order
of associated IML states is parallel, i.e. they have no ordering relation based on state-state
transition sequences see chapters 5.1.6 and 5.1.7.
5. If predecessor/successor relations between Gantt bars are described the resulting structure is
a sequence of IML states and state transitions see chapter 5.1.6 and 5.1.7.
6. For each SFC representing a Gantt chart, an initial state shall be created, followed by a state
transition with condition true as link to all further elements see chapter 5.1.2.
7. Each Gantt bar is represented by a state with two associated activities and a successor state
transition see chapter 5.1.35.1.3.
a. The first activity directly represents the time behaviour of the related Gantt bar and
may be delayed in execution in order to start synchronously to the appropriate Gantt
bar (see red line in Figure 15). Hence the activity will have a definition for its earliest
startpoint. The naming convention for this action is: DA_ + name of the Gantt bar.
b. The second activity is responsible for enabling the transition to synchronously
deactivate the state according to the end of the Gantt bar. Hence the activity will
contain a definition for the duration in order to delay the start of the activity and to
store it for synchronization reasons. The naming convention for this activity is: TA_ +
name of the Gantt bar.
Bar 1
t0
t1
t2
S_Bar 1
DA_Bar 1
TA_Bar
Condition for transition true:

step is deactivated
Figure 15: Actions of IML for Gantt- bar representation
62

8. As Gantt charts typically have a global time, while IML activities use local time starting at
activation of the state, a conversion between the two time systems is needed. For bars with no
predecessors the reference time point is the start point of the Gantt diagram. For bars with
predecessors, the reference time point is the end of the latest predecessor bar see chapter
5.1.5.
9. If a Gantt bar has two or more successor bars, it is connected to them by a simultaneous
divergence see chapter 5.1.6.
10. If a Gantt bar has two or more predecessors, they are connected to them by an SFC
simultaneous convergence. Between this simultaneous convergence and the predecessor
states there are synchronization states with no activities and a successor transition with TRUE
condition see chapter 5.1.7.
11. Each Gantt chart has a unique start and a unique termination state see chapter 5.1.8.
Based on these general translation rules Figure 16 and Figure 17 give an example of the mapping
process of Gantt charts.
Handover to HTR002
Lift skid
Lower skid
Initialise Robot 1
Execute Manufacturing Robot 1
Postprocess Robot 1
Initialise Robot 2
Postprocess Robot 2
0
9 10
18
22 23
26 27
34
Figure 16: Example of the transformation of a Gantt diagram in SFC (IML)
63

InitialStep_Gantt
TRUE
D0
DA_Handover to HTR002
SD 4
TA_Handover to HTR002
S_Handover to HTR002
D0
DA_InitialiseRobot1
SD 6
TA_InitialiseRobot1
S_InitialiseRobot1
TA_InitialiseRobot1
D0
DA_Move to Lift Position
SD 3
TA_Move to Lift Position
S_Move to Lift Position
D0
DA_InitialiseRobot2
SD 4
TA_InitialiseRobot2
S_InitialiseRobot2
TA_InitialiseRobot2
D0
DA_Lift skid
SD 2
TA_Lift skid
S_Lift skid
TA_Lift skid
SyS_ExecuteManufacturing
Robot1_1
Robot1_2
True
S_ExecuteManufacturing
Robot1
D0
SD 9
DA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturingRobot1
D0
DA_PostProcessRobot1
SD 4
TA_PostProcessRobot1
S_PostProcessRobot1
Robot2_1
Robot2_2
SyS_Terminal_1
True
Robot2
D0
SD 5
Robot2
Robot2
TA_ExecuteManufacturingRobot 2
D0
DA_PostprocessRobot2
SD 3
TA_PostprocessRobot2
DA_LowerSkid
TA_LowerSkid
TA_LowerSkid
SyS_Terminal_2
D0
SD 4
S_LowerSkid
S_PostprocessRobot2
D0
S_Move to end of 110HTR002
SD 7
DA_Move to end of
110HTR002
TA_Move to end of
110HTR002
TA_Move to end of
110HTR002
SyS_Terminal_3
True
TerminalStep
Figure 17: SFC representation of the Gantt chart in Figure 16

The following subchapters show the transformation rules for Gantt Chart elements to IML and an SFC
representation in detail.
64

5.1.2
Start of a Gantt Chart
Start of a Gantt Chart

IML Element
state s with
s.ID = <some ID>
s.Name = InitialStep
s.Init = true
state transition st with
st.ID = <some ID>
st.Name = InitialTransition
st.Guard.Formular = True
st.Pre = s.ID
addData ad with
ad.ID = <some ID>
ad.Type = ChartType
ad.Value = Gantt
ad.Pre = s.ID
Graphical IML representation as SFC
Initial
Step
true
Initial
Step
true
If more than one bar with no predecessor

bar in the diagram additionally:
simultaneous divergence simDiv with
simDiv.ID = <some ID>
simDiv.Pre = st.ID
Initial
Step
true
Table 51: Transformation of the start of a Gantt chart to IML elements

5.1.3
Bar
Bar
IML Element
state s with
s.ID = <some ID>
s.Name = S_ + bar name
s.Init = false
activity a1 with
a1.ID = <some ID>
a1.Name = DA_ + bar name
a1.Pre = s.ID
activity a2 with
a2.ID = <some ID>
a2.Name = TA_ + bar name
a2.Pre = s.ID
st.ID = <some ID>
st.Name = T_ + bar name
st.Guard.Formular = a2.name
st.Pre = s.ID
S_ bar
name
DA_bar name
TA_bar name
T_bar name
Table 52: Transformation of Gantt chart bars to IML elements
65

5.1.4
Bar Startpoint
Bar Startpoint
IML Element
activity a with:
Case A:
(no predecessor bar)
a.Time.Start.Earliest = Bar.startpoint
Case B:
(one predecessor bar)
a.Time.Start.Earliest = Bar.startpoint predecessorBar.endpoint
Case C:
(more than one predecessor bar)
a.Time.Start.Earliest = Bar.startpoint maxpredecessorActivity
predecessorBar.endpoint
S_ bar
Dt
name
DA_bar name
TA_bar name
TA_bar name= 1
Case A: t=0
Case B: t= Bar.startpoint - predecessorBar.endpoint
Case C: t= Bar.startpoint maxpredecessorBar predecessorBar.endpoint
Table 53: Transformation of Gantt chart bar start point to IML elements
5.1.5
Bar Endpoint
Bar Endpoint
IML Element
activity a with:
Case A:
(no predecessor bar)
a.Time.Duration = Bar.endpoint
Case B:
(one predecessorBar)
a.Time.Duration = Bar.endpoint predecessorBar.endpoint
Case C:
(more than one predecessor bar)
a.Time.Duration = Bar.endpoint
maxpredecessorActivity
predecessorBar.endpoint
S_ bar
D tx
DA_bar name
SD t
TA_bar name
name
TA_bar name= 1
Case A: t= Bar.endpoint
Case B: t= Bar.endpoint - predecessorBar.endpoint
Case C: t= Bar.endpoint maxpredecessorBar predecessorBar.endpoint
Table 54: Transformation of Gantt chart bar endpoint to IML elements

5.1.6
Successor Bar
Successor Bar
IML Element
Case A:
(no or only one successor bar)
Do nothing

Case A:
S_ bar
D tx
DA_bar name
SD ty
TA_bar name
name
TA_bar name= 1
66

Case B:
(more than one successor bars)
simDiv.Pre = st1.ID
Case B:
S_ bar
D tx
DA_bar name
SD ty
TA_bar name
name
TA_bar name= 1
Table 55: Transformation of Gantt chart bar successor activities to IML

5.1.7
Predecessor Bar
Predecessor Bar
IML Element
Case A:
(the only bar in diagram with no
predecessorBars)

Case A:
Initial
Step
state s with:
s.Pre = st.ID of the initial state transition
true
S_ bar
D t1
DA_bar name
name
SD t2
TA_bar name
TA_bar name = 1
Case B:
Initial
Step
Case B:
(no predecessor bar and at least one
other bar in the Gantt diagram with no
predecessor)
state s with:
s.Pre = simDiv.ID of
simultaneous divergence
the
initial
true
S_ bar
D t1
DA_bar name
name
SD t2
TA_bar name
TA_bar name = 1
Case C:
(only one predecessor bar and no other
bar with the same predecessor bar)
s.Pre = st.ID of the predecessor state
transition generated for the predecessor
bar
Case C:
D tx
DA_xx
S_xx
SD ty
TA_xx
TA_xx = 1
S_ bar
name
D t1
SD t2
DA_bar name
TA_bar name
TA_bar name = 1
67

Case D:
(only one predecessor bar and this
predecessor bar has more than one
successor bar)
s.Pre = simDiv.ID of the predecessor
simultaneous divergence generated for
the predecessor bar
Case D:
D tx
S_xx
SD ty
DA_xx
TA_xx
TA_xx = 1
S_ bar
D t1
name
SD t2
DA_bar name
TA_bar name
TA_bar name = 1
Case E:
(more than one predecessor bar, the
predecessor bar has only one successor)
state s with
s.ID = <some ID>
s.Init = false
s.Name = SyS_ + bar name + _+ i
bar
Case E:
S_xx
D tx
DA_xx
SD ty
TA_xx
TA_xx = 1
Note: For each predecessor step (if there

is more than one) one synchronisation
step is created. They shall be numbered
to ensure unique naming.
SyS_
bar
name_i
TRUE
simultaneous convergence simCon with

simCon.ID = <some ID>
simCon.Pre = s.ID
S_ bar
D t1
DA_bar name
name
SD t2
TA_bar name

st.ID = <some ID>
st.Name = SyT_ + bar name
st.Guard.Boolean = TRUE
st.Pre = simCon.ID
s.Pre = st.ID
Case F:
(more than one predecessor bars, the
predecessor bar has more than one
successor bar)
state s with
s.ID = <some ID>
s.Init = false
s.Name = SyS_ + bar name + _+ i
the predecessor bar
Case F:
D tx
S_xx
SD ty
DA_xx
TA_xx
TA_xx = 1
SyS_
bar
name_i
TRUE
Note: For each predecessor state (if there

is more than one) one synchronization
state is created. They shall be numbered
to ensure unique naming.
S_ bar
D t1
DA_bar name
name
SD t2
TA_bar name
TA_bar name = 1

simCon.Pre = s2.ID
68

st.ID = <some ID>
st.Name = SyT_ + bar name
st.Pre = simCon.ID
s.Pre = st2.ID
Table 56: Transformation of Gantt chart predecessor bar to IML elements
5.1.8
End of a Gantt Chart
End of a Gantt Chart

IML Element
Terminal state
step s with
s.ID = <some ID>
s.Init = false
s.Name = TerminalStep
One predecessor state transition for the
terminal state
state transition st3 with
st.ID = <some ID>
st.Name = TerminalTransition
s.Pre = st.ID
One simultaneous convergence for all
synchronisation states:
st.Pre = simCon.ID
D tx
S_xx
SD ty
DA_xx
TA_xx
TA_xx = 1
SyS_
Terminal
_i
step s with
s.ID = <some ID>
s.Init = false
s.Name = SyS_Terminal+_ + i
bar
simCon.Pre = {, s.ID }
TRUE
Terminal
Step
Note: For each state with no successor

state (if there is more than one) one
synchronization state is created. They
shall be numbered to ensure unique
naming. All synchronization states are
predecessors of the final simultaneous
convergence.
Table 57: Transformation of the end of a Gantt chart to IML elements
69

5.1.9
Transformation Examples for Gantt Charts
The following examples show the usage of the mapping rules to transform Gantt diagrams and parts
of Gantt diagrams to SFC.
Example transformation of activities without predecessor and successor relation
The following Gantt chart example has no predecessor and successor relations among the bars. It will
be translated to a set of activities all being parallel within the resulting SFC. The temporal conditions
will represent its sequence based on global timing.
Handover to HTR002
Lift skid
InitialStep_Gantt
TRUE
D0
SD 4
SyS_Terminal_1
D4
SD 7
SyS_Terminal_2
D7
DA_Lift skid
SD 9
TA_Lift skid
S_Lift skid
TA_Lift skid
SyS_Terminal_3
True
TerminalStep
Figure 18: Gantt translation example - activities without predecessor and successor relations
70

Example transformation of activity sequence
The following example depicts a Gantt chart with a predecessor/successor sequence among the bars.
It will be translated to a sequence of states and activities within the resulting IML system. The
temporal conditions represent its sequence based on local timing.
Handover to HTR002
Lift skid
0
InitialStep_Gantt
TRUE
D0
SD 4
D4
SD 7

D7
DA_Lift skid
SD 9
TA_Lift skid
S_Lift skid
TA_Lift skid
TerminalStep
Figure 19: Gantt translation example activity sequence
71

Example transformation of activity sequence with divergences
In this example a simultaneous divergence is introduced to describe multiple successors of one bar in
IML.
Initialise Robot 1
Initialise Robot 2
0
9 10
18
InitialStep_Gantt
TRUE
D0
DA_InitialiseRobot1
SD 6
TA_InitialiseRobot1
S_InitialiseRobot1
TA_InitialiseRobot1
Robot1
D3
SD 12
Robot1
Robot1
D0
DA_InitialiseRobot2
SD 4
TA_InitialiseRobot2
S_InitialiseRobot2
TA_InitialiseRobot2
SyS_Terminal_2
SyS_Terminal_1
True
TerminalStep
Figure 20: Gantt translation example activity sequence divagation
72

Example transformation of activity sequence with convergences
The Gantt chart example includes a convergence with the predecessor successor sequence among
the bars of the Gantt chart. This results in a simultaneous convergence in the SFC.
Lift skid
Initialise Robot 1
0
6 7
9 10
18
InitialStep_Gantt
TRUE
D0
DA_InitialiseRobot1
D7
DA_Lift skid
SD 9
TA_Lift skid
S_Lift skid
S_InitialiseRobot1
SD 6
TA_InitialiseRobot1
TA_Lift skid
TA_InitialiseRobot1
Robot1_1
Robot1_1
TRUE
Robot1
D0
SD 9
Robot1
Robot1
TerminalStep
Figure 21: Gantt translation example activity sequence convergence
73

5.2
PERT Charts
5.2.1
Overview
Net plan techniques enable the description and analysis of time behaviour of activities and tasks
based on graph theory. Out of the various net plans, AutomationML uses only PERT charts, because
they are widely used and can describe a set of different time relations between nodes. Following the
usual application of PERT charts, only end-start-relations between nodes are used, i.e.
predecessor/successor relations.
Nodes in PERT charts can have the following time information:
duration
earliest start
latest start
earliest end
latest end
buffer times
For PERT charts, different buffer types are defined. Overall and free buffers are the ones mostly used.
In the following, only one buffer time is considered in a generic way; if needed additional buffer times
can be handled in the same way. In addition, AutomationML assumes a reasonable application of the
timing information duration, earliest start, and earliest end.
Earliest
start
Duration
Earliest
end
Earliest
start
Node name
Latest
start
Buffer
Duration
Earliest
end
Node name
Latest
end
Latest
start
Buffer
Latest
end
Figure 22: Elements of a PERT chart

In general, the mapping of predecessor relations and parallel execution of nodes shall be done in the
same way as for Gantt charts (see section 4.1) resulting in a similar structure of the IML System. For
the expression of timing information, specific additional data related to activities according to the
additional data structure defined by PLCopen XML 2.0 are used. They have to be created according to
the following rules:
1. PERT charts are mapped to IML Systems to support parallel nodes.
2. Nodes in PERT chart shall be mapped to activities.
3. These activities shall be associated to states according to IML syntax.
4. If no explicit relations between PERT nodes are defined, i.e. they are concurrent, the order of
associated IML states is parallel, i.e. they have no ordering relation based on state transition
sequences.
5. Predecessor/successor relations between PERT nodes are mapped to a sequence of IML
states and state transitions.
6. For each IML System representing a PERT chart, an initial state shall be created, followed by
a state transition with condition true as link to all further elements.
7. Each node of the PERT chart is represented by a state with two associated activities and one
successor state transition.
a. The first activity directly represents the timing behaviour of the related PERT node
and may be delayed in execution in order to start synchronously to the appropriate
PERT node. Hence the activity will have a definition for its earliest start point. The
naming convention for this activity is: DA_ + name of the PERT node.
74

b. The second activity is responsible for enabling the state transition to synchronously
deactivate the state according to the end of the PERT node. Hence the activity will
contain a definition for the duration in order to delay the start of the activity and to
store it for synchronization reasons. The naming convention for this activity is: TA_ +
name of the PERT node.
c.
The subsequent state transition shall have the condition: name of this activity + =
TRUE
8. PERT charts use global time values. Hence, for timing values of IML activities these timing
values have to be converted to local relative time related to the activation time of the current
state.
9. Within PERT charts, various timing conditions are used. They can be stored in AutomationML
specific additional data related to the first activity (DA_ + name of the PERT node) according
to the additional data structure defined by PLCopen XML 2.0.
10. If a PERT node has two or more successor nodes, it is connected to them by a simultaneous
divergence.
11. If a PERT node has two or more predecessor nodes, it is connected to them by a
simultaneous convergence. Between this simultaneous convergence and the predecessor
states, synchronization states with no activities and successor state transitions with TRUE
condition are used.
12. Each PERT chart will have a unique start and a unique termination state.
t1
t2
t3
Node 1
t4
t5
t6
S_Note 1
DA_Note 1
TA_Note 1
t0
t1
t1+t2
Condition for transition true:
step is deactivated
Figure 23: Boolean actions of SFC for PERT activity representation

The following tables define the rules for transformation of PERT charts to IML Systems. The basic
rules defining the structure of the IML System are the same as given for Gantt charts in section 4.1 but
extended with respect to the additional timing conditions.
75

5.2.2
Start of a PERT Chart
Start of a PERT chart

IML Element
step s with
s.ID = <some ID>
s.Name = InitialStep
s.Init = true
st.ID = <some ID>
st.Pre = s.ID
addData ad with
ad.ID = <some ID>
ad.Type = ChartType
ad.Value = Pert
Initial
Step
true
Initial
Step
Initialtrue
Step
ad.Pre = s.ID
true
If more than one node with no

predecessor nodes in the diagram
additionally:
simDiv.Pre = s.ID
Initial
Step
true
Table 58: Transformation of a PERT node to IML elements

5.2.3
Node
Node
IML element
state s with
s.ID = <some ID>
s.Name = S_ + node name
s.Init = false
activity a with
a1.ID = <some ID>
a1.Name = DA_ + node name
a1.Pre = s1.ID
activity a with
a2.ID = <some ID>
a2.Name = TA_ + node name
a2.Pre = s1.ID
st.ID = <some ID>
st.Name = T_ + node name
st.Guard.Formular = a2.name
st.Pre = s1.ID
S_ node
name
DA_node name
TA_node name
T_node name
Table 59: Transformation of PERT chart nodes to IML elements
76

5.2.4
Node Earliest Startpoint
Node Earliest Startpoint

IML element
Case A:
(no predecessor node)
a1.Time.Start.Earliest = Node.startpoint
Case B:
(one predecessor node)
a1.Time.Start.Earliest = Node.earlieststart
- predecessorNode.earliestend
Case C:
(more than one predecessor node)
a1.Time.Start.Earliest = Node.earlieststart
maxpredecessorNode
predecessorNode.earliestend
S_
node
name
Dt
DA_node name
TA_node name
TA_node name= 1
Case A: t=0
Case B: t= Node.earlieststart - predecessorNode.earliestend
Case C: t= Node.earlieststart maxpredecessorNode predecessorNode.earliestend
Table 60: Transformation of PERT chart node earliest startpoint to IML elements
5.2.5
Node Duration
Node Duration
IML Element
a.Time.Duration = Node.duration
SFC Representation
S_
node
name
D tx
DA_node name
SD t
TA_node name
TA_node name= 1
t= Node.endpoint
Table 61: Transformation of PERT chart node duration to IML elements
5.2.6
Further Node Times
Further Node Times

IML element
a.Time.duration = Node.duration
a.Time.start.latest = Node.lateststart
a.Time.end.earliest = Node.earliestend
a.Time.end.latest = Node.latestend
a.Time.delay = Node.delay

S_
node
name
Dt
DA_node name
TA_node name
TA_node name= 1
Table 62: Transformation of PERT chart node duration to IML elements
77

5.2.7
Successor Nodes
Successor Node
IML element
Case A:
(no or only one successor node)
Do nothing

Case A:
S_
node
name
D tx
DA_node name
SD ty
TA_node name
TA_node name= 1
Case B:
(more than one successor node)
simDiv.Pre = st1.ID
Case B:
S_
node
name
D tx
DA_node name
SD ty
TA_node name
TA_node name= 1
Table 63: Transformation of PERT diagram activity successor activity to IML

5.2.8
Predecessor Nodes
Predecessor Node
IML Element

Case A:
Initial
Step
Case A:
(the only node in diagram with no
predecessor node)
s.Pre = st.ID of the initial state transition
true
S_
node
name
D t1
DA_node name
SD t2
TA_node name
TA_node name = 1
Case B:
(no predecessor node and at least one
other node in the PERT diagram with no
predecessor)
s.Pre = simDiv.ID of the initial
simultaneous divergence
Case B:
Initial
Step
true
S_
node
name
D t1
SD t2
DA_node name
TA_node name
TA_node name = 1
78

Case C:
(only one predecessor node and no other
activity with the same predecessor node)
node
Case C:
D tx
S_xx
DA_xx
SD ty
TA_xx
TA_xx = 1
S_
node
name
DA_node name
D t1
TA_node name
SD t2
TA_node name = 1
Case D:
(only one predecessorNode and this
predecessorNode has more than one
successorNodes)
the predecessor node
Case D:
D tx
S_xx
SD ty
DA_xx
TA_xx
TA_xx = 1
S_
node
name
D t1
SD t2
DA_node name
TA_node name
TA_node name = 1
Case E:
(more than one predecessor node, the
predecessorNode
has
only
one
successorNode)
state s with
s.ID = <some ID>
s.Init = false
s.Name = SyS_ + node name +_+i
mode
Note: If there are more than one
predecessor states for each one
naming.
simCon.Pre = s.ID
Case E:
S_xx
D tx
DA_xx
SD ty
TA_xx
TA_xx = 1
SyS_
node
name_i
TRUE
S_
node
name
D t1
DA_node name
SD t2
TA_node name
TA_node name = 1

st.ID = <some ID>
st.Name = SyT_ + Nodename
st.Pre = simCon.ID
s.Pre = st.ID
79

Case F:
(more than one predecessor nodes, the
predecessor node has more than one
succeeding nodes)
state s with
s.ID = <some ID>
s.Init = false
s.Name = SyS_ + node name + _+
i
the predecessor node
Note: If there are more than one
predecessor states, for each of them one
naming.
Case F:
D tx
S_xx
TA_xx
TA_xx = 1
SyS_
node
name_i
TRUE
S_

simCon.Pre = s2.ID
DA_xx
SD ty
node
name
D t1
DA_node name
SD t2
TA_node name
TA_node name = 1

st.ID = <some ID>
st.Name = SyT_ + Nodename
st.Pre = simCon.ID
s.Pre = st.ID
Table 64: Transformation of a PERT diagram predecessor activity to IML elements
80

5.2.9
End of a PERT Chart
End of a PERT Chart

IML Element
Terminal state
states s with
s.ID = <some ID>
s.Init = false
s.Name = TerminalStep
One predecessor state transition for the

terminal state
st.ID = <some ID>
s.Pre = st.ID
One simultaneous convergence for all
synchronisation states:
st.Pre = simCon.ID
states s with
s.ID = <some ID>
s.Init = false
s.Name = SyS_Terminal + i
transition
generated
for
the
predecessorNode
simCon.Pre = {, s.ID }
S_xx
D tx
DA_xx
SD ty
TA_xx
TA_xx = 1
SyS_
Terminal
_i
TRUE
Terminal
Step
Note: If there are more than one state with

no succeeding state one synchronization
state is created for each. They shall be
numbered to ensure unique naming. All
synchronization states are predecessors
of the final simultaneous convergence.
Table 65: Transformation of PERT diagram Terminal Step to IML elements
81

5.2.10 Transformation Example of PERT Charts
Figure 24 shows an example of a PERT chart. The information expressed therein is equal to the
information of the Gantt chart in Figure 16.
It depicts that for example the activities Handover to HTR002 and Initialise Robot 1 have no explicit
predecessors, Execute Manufacturing Robot 1 is a successor activity of Lift skid and Initialise Robot 1,
Execute Manufacturing Robot 2 is a predecessor of the activities Postprocess Robot 2 and Lower
skid, and Postprocess Robot 1, Postprocess Robot 2, and Move to end of 110HTR002 are activities
with no successor activities.
Handover to HTR002
1
23
Lift Skid
9
12
18
31
18
24
24
30
10
18
23
23
26
Robot 2
24
31
27
34

36
36
45
22
12
24
26
Postprocess Robot 1
12
4
Lower skid
Initialse Robot 2
18
Robot 1
Initialse Robot 1
4
Postprocess Robot 2
31
35
Figure 24: Example for the mapping of a PERT chart to a SFC

The resulting IML System of the transformation is depicted Figure 25.
Please note that PERT activities with no explicit predecessor result in parallel steps with a time delay
derived from the start point of the diagram. The predecessor/successor relation between Execute
Manufacturing Robot 1 and Lift skid results in a predecessor/successor relation between
S_ExecuteManufacturingRobot1 and S_Lift Skid with an intermediate synchronization step to ensure
the synchronization with the other predecessor of Execute Manufacturing Robot 1. This additional step
has no effect on the timing behaviour of the IML, beside that of storing the successor information of
Execute Manufacturing Robot 1.
The additional added steps SyS_Terminal_1, SyS_Terminal_2, and SyS_Terminal_3 result from the
definition of the terminal step.
AddData elements are not displayed in Figure 25.
82

InitialStep
TRUE
D0
SD 4
D0
DA_InitialiseRobot1
SD 6
TA_InitialiseRobot1
S_InitialiseRobot1
TA_InitialiseRobot1
D0
SD 3
D0
DA_InitialiseRobot2
SD 4
TA_InitialiseRobot2
S_InitialiseRobot2
TA_InitialiseRobot2
D0
DA_Lift skid
SD 2
TA_Lift skid
S_Lift skid
TA_Lift skid
Robot1_1
Robot1_2
True
Robot1
D0
SD 9
Robot1
Robot1
D0
DA_PostProcessRobot1
SD 4
S_PostProcessRobot1
Robot2_1
Robot2_2
SyS_Terminal_1
True
Robot2
D0
SD 5
Robot2
Robot2
TA_ExecuteManufacturingRobot 2
D0
DA_PostprocessRobot2
SD 3
DA_LowerSkid
TA_LowerSkid
TA_LowerSkid
SyS_Terminal_2
D0
SD 4
S_LowerSkid
S_PostprocessRobot2
D0
S_Move to end of 110HTR002
SD 7
DA_Move to end of
110HTR002
TA_Move to end of
110HTR002
TA_Move to end of
110HTR002
SyS_Terminal_3
True
TerminalStep
Figure 25: Timing behaviour of the SFC derived from a PERT chart node
In addition the comparison of the Gantt example given in section 4.1 with the PERT example shown in
this figure depicts the equivalent of the transformation rules given above.
83

5.3
5.3.1
Impulse Diagrams
Overview
The mapping of Impulse Diagrams to IML elements follows similar rules as the mapping of Gantt and
PERT diagrams. In general the resource state and resource state changes are represented by
sequences of states with activities and transitions while they are interconnected by signals
representing activities.
As a frame each Impulse Diagram representation as SFC shall contain:
an initial state,
an initial state transition,
one initial simultaneous divergence,
one branch for representing the timeline,
one branch for each resource,
one terminal simultaneous convergence,
a terminal state transition,
a terminal state.
This frame is depicted as example in Figure 26 and Figure 27.
Resource
State
0
Signal_Time _0
10
Uses Signal_Device1_1
Signal_Time _1
Pos1
Device1
Signal_
Device1_2
Pos2
Pos3
Signal_
Device1_1
Device2
PosA
PosB
Signal_
Device2_1
Figure 26: Impulse diagram example of transformation
84

Int
Time_Step_0
Device1_0
D0
Device1_Pos2
D0
Device2_0
Device2_PosA
SD0 Signal_Time_0
[Signal_Time_0 = TRUE]
Device1_1
D0
Device1_Pos2_to_Pos1
SD1 Signal_Device1_1
[Signal_Device1_1 = TRUE]
Device1_2
D0
Device1_Pos1
Device1_3
D0
SD1
Signal_Device1_2
Device1_4
D0
D0
Device2_1
Device2_PosA_to_PosB
Device2_2
D0
Device2_PosB
[TRUE]
Time_Step_1
SD8 Signal_Time_1
Device1_5
D0
Device1_Pos3
Device1_6
D0
Time_Step_
END
Device1_7
D0
Device1_Pos2
SD2 Signal_Time_END
[Signal_Time_END = TRUE]
Terminal
Step
Figure 27: Resulting SFC for Impulse diagram example of Figure 26

Based on this general idea and the frame, the mapping exploits the following basic translation
procedure:
1. The representation of Impulse Diagrams as IML System leads to an initial state, a successor
initial state transition and an initial simultaneous divergence as a start. The condition of this
initial transition is always true.
2. The timeline and each resource within an Impulse diagram are represented by parallel
branches in the IML System, describing the corresponding resource state flows.
3. Each resource state flow is represented by a sequence of states and their state transitions in
the associated branch of the IML System.
4. Each resource state is represented by an activity and can be associated to a SFC state within
the corresponding branch.
85

5. Each resource state change is also represented by an activity, that can be associated to a
state within the corresponding branch.
6. The timeline is represented as sequence of states within the timeline branch of the IML
System.
7. Predecessor successor relations between resource states and resource state changes of
one resource are represented by sequences of states and state transitions.
8. The current resource state or resource state change is represented by one activity attached to
the active state in the corresponding IML System branch.
9. Each resource state change must be triggered by a signal. Signals shall be represented by the
integration of Boolean values within state transition guards.
10. Each resource state change shall have a duration which is defined in the corresponding
activity. The duration can be zero. The end of a resource state change leads to firing a signal
which shall be used as only condition to enter the subsequent resource state or resource state
change.
11. Signals can also be fired by the timeline at any time or by a resource after remaining within a
resource state with a predefined duration.
12. Firing of signals resulting from a resource state change is represented by an activity,
associated to the corresponding state.
13. Each firing of a signal from the timeline is described by a state and one attached activity.
14. Each representation of an Impulse Diagram shall contain a terminal simultaneous
convergence, a terminal state transition and a terminal step as end frame. The condition for
the terminal state transition is the firing of an external end signal.
The following subchapters define the rules for transformation of all Impulse Diagram elements to IML
and their representation as SFC. The basic rules defining the structure of the IML systems are the
same as given for Gantt charts in 5.1. Therefore only rules which are specific for Impulse Diagrams
are described in detail.
The acronyms RN, RS, RSN, and SN are used for resource name, resource state, resource state
name, respectively sequence number in the tables of the following subchapters. Timing information is
described with td for time delay respectively std for signal time delay, see chapter 5.3.8.
For the SFC representation the, the activity qualifiers D for delay and SD for store delay of the IEC
61131-3 are heavily used.
86

5.3.2
Start of an Impulse Diagram
Start of an Impulse Diagram

IML Element
state s with
s.ID = <some ID>
s.Name = INIT
s.Init = true

Start for the SFC representation of an Impulse
Diagram
INIT

st.ID = <some ID>
st.Pre = 1
TRUE
addData ad with
ad.ID = <some ID>
ad.Type = ChartType
ad.Value = ImpulseDiagram
ad.Pre = s.ID
simDiv.Pre = st.ID
Table 66: Transformation of the start of Impulse Diagrams to IML elements
5.3.3
Timeline
Timeline
IML element
state s with
s.ID = <some ID>
s.Name = Time_Step_0
s.Init = false
s.Pre = simDiv.ID of simultaneous
divergence resulting form the
start of Impulse Diagrams
activity a with
a.ID = <some ID>
a.Name = Signal_Time_0
a.Pre = s1.ID
a.Time.Delay = 0
st.ID = <some ID>
st.Name = T_ + a1.Name
st.Guard.Boolean = a1.Name
st.Pre = s1.ID

Structural representation of the timeline
INIT
TRUE
D0
Signal_Time_0
Time_Step_0
[ Signal_Time_0 = TRUE]
Time_Step_ +
SN
D td
Signal_Time_+ SN
[ Signal_Time_ + SN = TRUE]
For each additional fired external signal

state sx with:
s.ID = <some ID>
s.Name = Time_Step_ +SN
s.Init = false
s.Pre = Predecessor state transition
87

within Timeline
Note: The related activities for the
external signals are described in Table 1
Table 67: Transformation of a timeline to IML elements
5.3.4
Resource
Resource
IML element
For each resource one parallel branch is
created in the SFC. This branch contains:

Structural representation of an resource
a first state s with

s.ID = <some ID>
s.Name = RN + _0
s.Init = False
s.Pre = simDiv.ID
an activity a with
a.ID = <some ID>
a.Name = RN + _ Initial RSN of the
Resource
a.Pre = s.ID
a.Time.Delay = 0
INIT
TRUE
D0
Resource
Name + _0
Resource Name + _ + Inital Resource State Name
Note: The sequence of values for the

resource is represented by the resource
state flow.
Table 68: Transformation of resources to IML elements
5.3.5
Resource State
Resource State
IML element
activity a with
a.ID = <some ID>
a.Name = RN + _ + RSN
a.Time.Delay = 0
a.Pre = s.ID of associated state
within the resource state flow

Structural representation of a resource state
Resource Name
+ _ +SN
D0
SD td
Resource Name + _ + Resource State Name

Signal_ + Resource Name + _ + SN
Note: If the resource state is never

entered within the resource state flow, the
action is defined in the declarative part of
the PLCopen XML document only.
Table 69: Transformation of resource states to IML elements
88

5.3.6
Resource State Change

IML element
activity a with
a.ID = <some ID>
a.Name = RN +_ + Origin RSN +
_to_ + Target RSN
a.Time.Delay = 0
a.Pre = s.ID of associated state
within the resource state flow

Structural representation of a resource state change
D0
Resource Name
+ _ +SN
SD td
Resource Name+ _ + Origin Resource State Name

+ _ + Traget Resource State Name
Note: If a predefined resource state

change is never executed within the
resource state flow the action is defined in
the declarative part of the PLCopen XML
document only
Table 70: Transformation of resource state changes to IML elements
5.3.7
Resource State Flow
Resource State Flow

IML element
Remain within one Resource State (active
state)
Each active resource state leads to one
state s with:
s.ID = <some ID>
s.Name = RN + _ + SN
s.Init = false
transition within the resource state flow

Structural representation of an resource state flow
Resource
Name + _
+SN
D0
SD td

[ Signal_ + Resource Name + _ + SN = TRUE]
Note: Multiple activations of resource

states are possible and lead to a new
state each time.
Note: To each state at least one activity is
associated, setting the active resource
state. The following state transition waits
for a signal to trigger the succeeding
resource state change. (Remember the
active resource state will automatically be
set to false when leaving the step.) When
leaving the state after a predefined
duration, a second activity is needed.
89

Each resource state change leads to:
one state s with
s.ID = <some ID>
s.Name = RN + _ + SN
s.Init = false
transition within the resource state flow
D0
Resource
Name + _
+SN
SD td
Resource Name+ _ + Origin Resource State Name

+ _ + Traget Resource State Name
[ Signal_ + Resource Name + _ + SN = TRUE]
Note: Multiple activations, even with

different durations, are possible and lead
to a new state each time.
Note: To each state two activities are
associated: one activity to set the active
resource state change and one activity to
fire a signal at the end of the resource
state change. A state transition activates
the succeeding state. The condition for
this state transition shall only be the
Boolean signal of the resource state
change.
Table 71: Transformation of the resource state flows to IML elements
5.3.8
Signals
Signals
IML element
Time Signals
activity a with
a.ID = <some ID>
a.Name = Signal_Time + SN
a.Time.Duration = std
a.Pre = actual state within
Timeline

Structural representation of time signals
[ Signal _Time_ + SN = TRUE]

Time_Step
_ + SN
the
SD std
Signal_Time_ +SN
Resource
Name + _
+ SN
D0
..
[ Signal_Time_ + SN = TRUE]
Note: Activity a belongs to a state in the

timeline.
st1.ID = <some ID>
st1.Name = T_Signal_Time + SN
st1.Guard.Boolean = a.name
st1.Pre = state associates to a
st2.ID = <some ID>
st2.Name = T_Signal_Time + SN
st2.Pre = s.ID of active state within
the resource state flow where a change is
triggered by the signal
90

Signals between two Resource State
Flows
activity a with
a.ID = <some ID>
a.Name =Signal_+ Resource Name
+ _ + SN
a.Time.Duration = td
a.Pre = actual state within the
Resource State Flow
Structural representation of Signal between two

Resource State Flows
[ Signal_+ Ressource Name n _ + SN = TRUE]

Resource
Name n + _
+ SN
..
SD td Signal_+ Ressource Name n _ + SN
Resource
Name m +
_
+ SN
D0
..
Ressource Name + _ + Ressource State Name
[ Signal_+ Ressource Name n _ + SN = TRUE]

st1.ID = <some ID>
st1.Name = T_+ Resource Name +
_ + SN
st1.Pre = state associates to a.ID
st2.ID = <some ID>
st2.Name = T_+ Resource Name +
_ + SN
st2.Pre = s.ID of active state within
the Resource State Flow where a change
is triggered by the signal
Note: If a change within a resource state
flow depends on more than one signal,
these signals can be combined with a
Boolean expression, see chapter 7.5.1
Signal within one Resource State Flow
activity a with
a.ID =<some ID>
a.Name =Signal_+ Resource Name
+ _ +
SN
a.Time.Duration = td
a.Pre = actual state within the
Resource State Flow
Structural representation of signals within a Resource

State Flows
Resource
Name n + _
+ SN
..
SD td
.
Signal_+ Ressource Name n _ + SN
[Signal_+ Ressource Name n _ + SN = TRUE]

Resource
Name n + _
+ SN
D0
..
Ressource Name + _ + Ressource State Name

st.ID = <some ID>
st.Name = T_Signal_+ Resource
Name + _
+ SN
st.Guard.Boolean = a.name
st.Pre = state associated to a.ID
Table 72: Transformation of signals to IML elements
91

5.3.9
End of Impulse Diagram and Terminal Step
End of Impulse Diagram and Terminal Step

IML element
For termination of the complete Impulse
Diagram, all resource state flows and the
timeline are synchronized by an END time
signal and the following resulting
elements:
Timeline End state s1 with
s1.ID = <some ID>
s1.Init = false
s1.Name = Time_Step_END
s1.Pre = st.ID of last State Transition
within Timeline

Structural representation of the end of an impulse
diagram
Time_Step
SD ..
...
_n
[...]
Time_Step_
END
SD std
activity a with
a.ID = <some ID>
a.Name =Signal_Time_END
a.Time.Duration = std
a.Pre = s1.ID
Signal_Time_END
...
[Signal_Time_END = TRUE]
Terminal
Step
simultaneous convergence simCon with:

simCon.Pre = [a.ID; ID of the last
states in each resource state flow]
st.ID = <some ID>
st.Guard.Boolean=
[Signal_Time_END = True]
st.Pre = simCon.ID
Terminal state s2 with
s2.ID = <some ID>
s2.Init = false
s2.Terminal = true
s2.Name = TerminalStep
s2.Pre = st.ID
Table 73: Transformation of Impulse Diagram end to IML elements
92

5.3.10 Impulse Diagram Details
IML element
Name of groups
Additional Data addData with
addData.ID = <some ID>
addData.type =
ImpluseChartResorceGroup
addData.value = name of the Group
the Element belongs to
addData.Pre = ID of the first step within
the parallel branch belonging to the
resource
Names of resource state changes
Additional Data addData with:
addData.type =
ResourceStateChangeDefinition.Definion
Name
addData.value = Name of the
resource change
addData.Pre = ID of associated
activity
Durations of resource states and resource
state changes
addData.type =
ResourceStateChangeDefinition.Duration
addData.value = name of the group the
element belongs to
addData.Pre = t
Names of signal inputs associated to
resource states
addData.type =
ImpulseDiagramPLCVariable.Name
addData.value = name of the
Variable associated to the input
activity
Names of actuator outputs associated to
resource states
addData.type =
ImpulseDiagramPLCVariable.Name
addData.value = name of the
Variable
associated to the
output
activity
Group = some_group/some_subgroup
addData.id = <some ID>
addData.Type = ImpluseChartResorceGroup
addData.value = some_group/some_subgroup
addData.Pre = ID of the first step within the parallel branch
belonging to the resource
Name = some name

addData.Type = ResourceStateChangeDefinition.DefinionName
addData.Value = some name
addData.Pre = ID of associated action
Duration = some duration

addData.Type = ResourceStateChangeDefinition.Duration
addData.Value = some duration
PLCopenVariable = Variablename
addData.Type = ImpulseDiagramPLCVariable.Name
addData.Value = Variablename
PLCopenVariable = Variablename
addData.Type = ImpulseDiagramPLCVariable.Name
addData.Value = Variablename
Table 74: Transformation of Impulse Diagram details to IML elements
93

5.3.11 Transformation Examples for Impulse Diagrams
The following examples show the use of the mapping rules to transform Impulse Diagrams and parts
of Impulse Diagrams to SFCs.
Example transformation internal signal
The first example handles the transition from a state change to the subsequent state. To accomplish
an executable SFC an additional signal has to be introduced which is normally not displayed in the
diagram, see Figure 28.
Resource
State
Uses
Time_Signal_1
Signal_Motor1_1
Fast_run
Motor1
Motor1_1
Slow_run
Motor1_2
Motor1_0
Init
Time_Step_0
SD 0
Signal_Time_0
Time_Step_1
SD1
Signal_Time_1
D0
Motor1_Slow_run
Motor1_0
[Signal_Time_1= TRUE]
Motor1_
1
D0
Motor1_Slow_run_to_Fast_run
SD1 Signal_Motor1_1
[Signal_Motor1_1 = TRUE]
Motor1_
2
D0
Motor1_Fast_run
Figure 28: Example transformation internal signal

To achieve the transformation, the following elements are needed and described in detail:
One activity representing the additional signal with the name Signal_Motor1_n. This action has got
a delay of 1 for the duration of the state change from Slow_run to Fast_run.
One transition that is activated by the signal as successor for the state representing the resource
state change from Slow_run to Fast_run, i.e. when Signal_Motor1_1 becomes TRUE.
One new SFC state with an associated action, indicating the new status of the resource. In this
case the resource has entered its resource state Fast_run.
94

Example External Signals
The next example handles two external signals, which are fired with delay of three seconds.
State
Resource
Fast_run
Uses Signal_Motor1_1
Signal_Time_0
Signal_Time_1
Motor1
Slow_run
Motor1_0
Motor1_1
Motor1_2
Motor1_3
Init
Time_Step_0
SD 0
Signal_Time_0
D0
TimeStep_1
SD3
Signal_Time_1
Motor1_Slow_run
Motor1_0
D0
Motor1_Fast_run_to_Slow_run
Motor1_1
SD1 Signal_Motor1_1
D0
Motor1_Fast_run
Motor1_2
D0
Motor1_3
..
Motor1_Fast_run_to_Slow_run
.
Figure 29: Example external signal

For this example the following SFC elements are needed:
One activity for each external signal within the timeline representing the signal with the names
Signal_Time_0 and Signal_Time_1. The first action has got a delay of 1 and the second of 3
representing the delay between both signals.
A transition after each of the two states associated to the signals within the timeline. These
transitions are activated by the corresponding time signal.
One transition as predecessor for each state representing the state change within a resource state
flow that is triggered by the time signals. These transitions are activated by the corresponding time
signal.
95
One new SFC state for each signal within the resource state flow with the names Motor1_2 and
Motor1_3.
The associated actions that represent the new status of the resource, in this example the state
change from Slow_run to Fast_run for the first signal and the state change form Fast_run to
Slow_run for the second signal with the names Motor1_Fast_run_to_Slow_run and
Motor1_Slow_run_to_Fast_run.
Example Signal Between two Resource States Flows

The last handles the transformation of a signal fired by one resource state and consumed by another.
Resource
State
...
Motor1_2
Motor1_1
Fast_run
Motor1
Motor1_0
Slow_run
Signal_Motor1_1
Gripper1_0
Gripper1
Open
Gripper1_1
Close
Init
Time_Step
_0
SD0
Signal_Time_0
Motor1_
0
D0
Mortor1_Slow_run
Motor1_
1
D0
Mortor1_Slow_run_to_Fast_run
SD1 Signal_Motor1_2
Gripper1
_0
D0
Gripper1_Open
Gripper1
_1
D0
..
Gripper1_Open_to_Close
.
Motor1_
2
D0
Mortor1_Fast_run
[...]
Figure 30: Impulse diagram example of transformation

For this example the following SFC elements are needed:
One activity for the signal within the firing resource state flow for Motor1 with the name
Signal_Motor_1.
A transition after the state associated to the signal within the resource state flow for Motor1. This
transitions activated by the signal Signal_Motor_1.
One transition as predecessor for the state representing the state change from Open to Close
within a resource state flow for Gripper1. The transition is activated by the signal Signal_Motor1_1.
One new SFC state within the resource state flow of Gripper1 with the name Gripper1_1.
The associated action that represent the new status of the resource, that represents the new status
of resource, in this example the state change from Open to Close with the name
Gripper1_Open_to_Close.
96

5.4
5.4.1
State Charts
Overview
In general, the mapping of State charts is done according to a simple principle: states are mapped to
IML states, transitions to IML transitions, and activities to IML activities.
In addition, hierarchies within State charts are expressed by sets of IML systems with cross
referencing. Within the translation to SFCs the different IML systems will result in different POUs of the
PLCopen XML structure.
Facing these basic decisions, the mapping of State charts to IML systems is made by the following
rules. These rules can be divided into those for flat State charts and State chart hierarchies.
The example depicted in Figure 31 and Figure 32 shall illustrate the basic transformation rules
explained below.
State 1
Event 4 / [Guard 5]
H
Event 4 / [Guard 4]
State 2
State 1.1
State 1.3
Event 2
[Guard 6.1]
Event 2
Event 1 / [Guard 1]
State 1.2
C
Event 5
Event 3 / [Guard 3]
Guard 2 / Activity 1
State 1.4
[Guard 6.2]
Event 6
[Guard 6]
State 3
Entrance Activity 2
Activity 3
Exit Activity 4
Figure 31: State chart example
97

Main Chart
InitialStep_StateChart
TRUE
State 1
Event 6
Event 5
State 3
Guard 2
Guard 6
State 2
TransitionActivity1
N
Event 4
Guard 5
Event 4
Guard 4
Activity 1
End of Activity 1
Chart State 1 Region 1
Chart State 1 Region 2

InitialStep_State1_Region2
State 3
TRUE
Guard 6
Connector1
State 1.3
InitialStep_State1_Region1
Event 3
Guard 3
TRUE
Guard 6.1
Guard 6.2
State 1.4
State 1.1
Event 2
Event 1
Guard 1
Event 5
State 2
Event 4
Guard 4
State 1.2
Event 2
History1
Figure 32: IML representation of State chart example from Figure 31
The mapping rules for flat State charts are:

1. A state s of a State chart is mapped to a state s of an IML system. If s is an initial state, the
s.INIT property shall be set to true. If s is an end state, the s.Terminal property shall be
set to true, see chapter 5.5.2.
2. An entry action a attached to a state s of a State chart is mapped to an activity a associated
to the state s of the IML system, where s is the mapping of s. An IML additional data
element attached to a indicates it as entry action, see chapter 5.5.5.
3. A do action a within a state s of a State chart is mapped to an activity a associated to the
state s of the IML system, where s is the mapping of s. An IML additional data element
attached to a indicates it as do action, see chapter 5.5.6.
98

4. An exit action a attached to a state s of a State chart is mapped to an activity a associated to
the state s of the IML system, where sis the mapping of s. An IML additional data element
attached to a indicates it as exit action, see chapter 5.5.7.
5. A state transition st of a State chart is mapped to a state transition st of the IML system.
Thereby, the guard of st will be mapped to the guard of st, see chapter 5.5.10 and 5.6.4.
6. An action a associated to a state transition st of a State chart is mapped to an additional
created state s, an additional state transition st, and an action a associated to it s, see
chapter 5.5.10 and 5.6.4.
7. An event ev of a State chart is mapped to an event ev of the IML system, see chapter 5.5.8.
8. Connectors of State charts (condition as well as history connectors) are mapped to IML
system states, see chapter 5.6.3 and 5.6.2.
State chart hierarchies are mapped to sets of IML systems i.e. each sub-state-chart results in a new
IML system. Hence, the mapping rules for hierarchies of State charts are (see chapter 0):
9. Each flat State chart will result in an IML system, i.e. connected state reduced by their sub
states.
Note: As a flat State chart those parts of State charts are considered having no state hierarchy
and are connected with respect to graph theoretical principles.
10. Concurrent sub-states of a state will result in different IML systems.
Note: The dependencies between states and their sub-states are expressed by IML additional
data elements attached to the affected IML states.
11. Inter level transitions of State charts are mapped to one state transition within each IML
systems representing the relevant state hierarchy levels. Additional one state shall be created
within in the IML system, representing internal State chart of the hierarchy, to represent the
external state.
Note: The relation of the state transitions in the different IML systems is indicated by an IML additional
data element.
5.5
5.5.1
Flat State Charts

Headers
This clause defines the IML representation of a flat State chart.
InitialStep_noName
[TRUE]
State 1
State_State1
[Event 2]
[Event 1]
[Event 1]
State 2
State_State_2
[Event 2]
State Chart
IML System
Figure 33: Transformation of State chart to an IML system

Each flat State chart shall be represented by one IML system with its IML header h. The
corresponding IML header has the following attributes (see Table 75).
99

IML element
Attribute value
h.ID
<some ID>
h.Name
Name of the State chart
h.Members
IDs of all entities that resulting from the transformation

of the State chart members.
Table 75: Attribute values for flat State chart representation as IML system
5.5.2
States
This clause defines the IML representation of a State chart state.
State
IML State
Figure 34: Transformation states to IML states

Each state of a State chart results in one IML state s. The corresponding IML state has the following
attributes (see Table 76).
IML element
Attribute value
s.ID
<some ID>
s.Name
State_ + state name

True if the state is a start state
s.Init
False if the state is not a start state

True if the state is an end state
s.Terminal
False if the state is not an end state
Table 76: Attribute values for state representation in IML

5.5.3
Number and Structure of Predecessor States
This clause defines the IML representation of the structure and number of predecessor states in flat
State charts in IML system elements.
State_1
...
State_2
State_n
State_State_1
[Event 1]
State_State_2
...
State_State_n
[Event 2]
[Event n]
[Event 3]
[Event 1]
[Event n]
State_State_3
State_3
State Chart
IML System
Figure 35: Transformation of predecessor states to IML elements
100

Multiple predecessors results in an IML selection convergence selCon and additional IML attribute
values of the successor state s (see Table 77).
IML element
Attribute value
selCon.ID
<some ID>
selCon.Pre
IDs of all predecessor state transitions
s.Pre
selCon.ID
Table 77: Attribute values for representation of multiple predecessors in IML

Note: If a state s has only one predecessor no additional selection convergence is needed.
5.5.4
Number and Structure of Successors of States
This clause defines the IML representation of multiple successors of a State chart state in flat State
charts. These successors can be states or connectors.
State_State_1
State 1
[Event n]
[Event 1]
[Event 2]
[Event 1]
State_1
State_2
...
State_n
State_State_1
[Event n]
[Event 2]
State_State_2
State Chart
...
State_State_n
IML System
Figure 36: Transformation of states to IML states

Multiple successors of a state result in an IML selection divergence selDiv as successor of state s
(see Table 78).
IML element
Attribute value
selDiv.ID
<some ID>
selDiv.Pre
s.ID for the considered state
Table 78: Attribute values for the representation of multiple successors of a state in IML
Note: If a state s has only one successor no additional selection divergence is needed.
Note: If the execution order for processing the successor relations is defined within the State chart
this shall be stored with the natural means within PLCopen XML.
5.5.5
Entry Action
This clause defines the IML representation of entry actions of a state.

State_1
entry/action1
do/action2
exit/action3
State_State_1
N
N
N
Action_action1_ofState_State_1
Figure 37: Transformation of an entry action of states to an IML activity

An entry action results in an IML activity a, an additional data element ad and the attribute
corresponding values of this activity (see Table 79).
101

IML element
Attribute value
a.ID
<some ID>
a.Name
Action_action name + _ofState_ + s.Name for the

state the entry action belongs to
a.Formula
content of action a
a.FiredEvents
set of events fired by a
a.Pre
s.ID for the state the entry action belongs to
ad.ID
<some ID>
ad.Type
StateChartActionType
ad.Value
entryAction
ad.Pre
s.ID
Table 79: Attribute values for an entry action representation in IML

Note: If an entry action contains events, this shall be expressed in the FiredEvents and the Formula
relations of the resulting action.
Note: If an entry action addresses signals, this shall be expressed in the Formula relations of the
action by using the relevant variables resulting from the signal.
5.5.6
Action within a State; Do Action
This clause defines the IML representation of actions within a state. These actions are called do
actions.
State_1
entry/action1
do/action2
exit/action3
State_State_1
N
N
N
Figure 38: Transformation of a do action to an IML activity

A do action results in an IML activity a and the attribute values of this activity (Table 80).
IML element
Attribute value
a.ID
<some ID>
a.Name
Action_ + action name + _ofState_ + s.Name for the

state s the do action belongs to
a.Formula
content of action a
a.FiredEvents
a.Pre
s.ID for the state s the do action belongs to
ad.ID
<some ID>
ad.Type
ad.Value
doAction
ad.Pre
s.ID
Table 80: Attribute values for a do action representation in IML

102

Note: If a do action contains events, this shall be expressed in the FiredEvents and the Formula
Note: If a do actions addresses signals, this shall be expressed in the Formula relations of the action
by using the relevant variables resulting from the signal.
5.5.7
Exit Action
This clause defines the IML representation of an exit action of a state.

State_1
entry/action1
do/action2
exit/action3
State_State_1
N
N
N
Figure 39: Transformation of an exit action to an IML activity

An exit action results in an IML activity a and the attribute values of this activity (see Table 81).
IML element
Attribute value
a.ID
<some ID>
a.Name
Action_ + action name + _ofState_ + s.Name for the

state the exit action belongs to
a.Formula
Content of action
a.FiredEvents
a.Pre
s.ID for the state the entry action belongs to
ad.ID
<some ID>
ad.Type
ad.Value
exitAction
ad.Pre
s.ID
Table 81: Attribute values for an exit action representation in IML

Note: If an exit action contains events, this shall be expressed in the FiredEvents and the Formula
Note: If an exit action addresses signals, this shall be expressed in the Formula relations of the action
by using the relevant variables resulting from the signal.
5.5.8
Events
This clause defines the IML representation of events.

State_1
entry/action1
do/action2
exit/action3
Event/action_ev
IML Event with:

Name = Event_action_ev
Variable with:
Name = Action_action_ev
Type= derived
Figure 40: Transformation of events to an IML event and PLCopen variable

An Event results in an IML event e and additional IML attribute values of this event (see Table 82).
103

IML element
Attribute value
ev.ID
<some ID>
ev.Name
Event_ + signal name
Table 82: Attribute values for an exit action representation in IML

Note: Events can be consumed within one or more IML systems.
5.5.9
Signals
This clause defines the IML representation of signals. Within the context of AutomationML signals are
the representation of external events.
State 1
Variable with:
Event [Condition]/signal1
Name = Signal_signal1
Type= Boolean
State 3
Figure 41: Transformation of a signal to an IML variable

The mapping of a signal results in an IML variable var and its IML attribute values (see Table 83).
IML element
Attribute value
var.ID
<some ID>
var.Name
Signal_ + signal name
var.Type
Boolean
var.SIUnit
empty
var.Initialvalue
empty
var.Address
empty
Table 83: Attribute values for signal representations in IML

Note: Signals can be consumed within one or more IML systems.
5.5.10 State Transitions
This clause defines the IML representation of state transitions; therefore different cases are
considered. Figure 42 depicts the general mapping of State chart state transitions.
State 1
Event [Condition]/signal1
State 3
State_State_1
Condition
State_State_3
Figure 42: Transformation a states transition to an IML transition

104

Table 84 gives an overview about the different cases that are considered for the mapping of state
transitions in flat State charts to IML elements.
Case
Number
Successors
of
Number
Predecessors
of
Action
Execution
during
Hierarchy Level
No
Yes
Table 84: Distinction of cases for the mapping of state transitions in flat State charts
Case A
The state transition connects states or connectors within the same super state in the same hierarchy
level and no action is executed during the transition.
State_State_1
State 1
[Guard]
[Guard]
State 3
State_State_3
Figure 43: Transformation of a state transition without an action to IML elements

The state transition results in an IML state transition st, its IML attribute values and its successor and
predecessor relations of the source state s1 and the destination state s2 of the state transition (see
Table 85).
IML element
Attribute value
st.ID
<some ID>
st.Name
StateTransition_ + State Transition Name
st.Guard.Formular
Content of the state transition guard
st.Pre
s1.ID if st is the only successor state transition of the

source state s1
selDiv.ID if the source state s1 has more than one
predecessor state transition (see section 5.5.3)
Successor relations for the state transition with one predecessor:

If st is the only predecessor state transition of the destination state s 2
s2.Pre
st.ID
Successor relations for the state transition with more than one predecessor:
If the destination state s2 has more than one predecessor state transition (see section 5.5.3)
selCon.Pre
st.ID
Table 85: Attribute values for signal representation in IML
105

Case B
In this case the state transition connects states or connectors within the same super state in the same
hierarchy level and at least one action is executed during the transition.
State_State_1
[Guard]
State_1
[Guard]/action1
StateForActivity_
action1
Action_action1_ofStateTransition
[TRUE]
State_2
State_State_2
Figure 44: Transformation of a state transition with an action to IML elements

The state transition results in two IML state transition st1 and st2, a newly created IML state s with
an attached additional data element ad, an IML activity a, their corresponding IML attributes and
their successor and predecessor relations to the source state s1 and the destination state s2 of the
transition (see Table 86).
IML element
Attribute value
st1.ID
<some ID>
st1.Name
StateTransition_ + state transition name
st1.Guard.Formular
st1.Pre
s1.ID if st1 is the only successor state transition of the

source state s1
predecessor state transition (see section 5.5.3)
s.ID
<some ID>
s.Name
StateForActivity_ + activity name
s.Init
False
s.Terminal
False
s.Pre
st1.ID
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
stateForActivity
ad.Pre
s.ID
106

st2.ID
<some ID>
st2.Name
StateTransitionForActivity_ + activity name
st2.Guard.Formual
TRUE
st2.Pre
s.ID
a.ID
<some ID>
a.Name
Action_ + action name + _ofStateTransition
a.Formula
Content of action a
a.FiredEvents
a.Pre
s.ID

If st2 is the only predecessor state transition of the destination state s 2
s2.Pre
st2.ID
selCon.Pre
st2.ID
Table 86: Attribute values for a state transition with an action in IML
Note: If a state transition action contains events, this shall be expressed in the FiredEvents and the
Formula relations of the resulting action.
Note: If a state transition action addresses signals, this shall be expressed in the Formula relations of
the action by using the relevant variables resulting from the signal.
107

5.6
State Charts with Hierarchies
This clause defines additional mapping rules for State charts with hierarchies into IML systems. All
definitions for flat State charts are valid for State charts with hierarchies as well.
5.6.1
Hierarchy Levels
This clause defines the IML representation of a State chart with more than one hierarchy level.
SFC State_Main
State_1
InitialStep_noName
SFC State_2
InitialStep_noName
[True]
[True]
State_2
State_2-1
State_State_2-1
State_State_1
State_2-2
State_State_2-2
State_State_2
Contains AddData
element with
refrence to SFC
State_2
Figure 45: Transformation of a hierarchical State chart to an IML System

A State chart with more than one hierarchy level shall result in one IML system with its IML header h
for each sub State chart. The corresponding IML header has the following attributes (see Table 87).
IML element
Attribute value
h.ID
<some ID>
h.Name
Name of the State chart
h.Members
IDs of all entities resulting of the transformation of the

State chart members of the corresponding sub State
chart.
Table 87: Attribute values for hierarchical State chart representation as IML systems
Note: If inter level transitions exist in the State charts, proxy states for the super state may be required
in the IML system representing states of the higher level State chart, see the following subsections.
The relation between a state s and its internal sub State charts is represented by an additional data
element attached to the state.
IML element
Attribute value
ad.ID
<some ID>
ad.Type
StateChartSubCharts/POURef
ad.Value
Refrence to the IML System representing the sub State

chart
Note: In PLCopen XML the URI of the POU
ad.Pre
s.ID
Table 88: Attribute values for flat State chart representation as IML systems
Note: If a state has more than one sub State charts this is expressed by multiple additional data
elements.
108

5.6.2
History Connector
This clause defines the IML representation of a history connector, as defined in the UML 2.0
specification [UML2010]; therefore two different cases have to be considered. Case A defines the
mapping of a shallow history connector and case B defines the mapping of a deep history connector.
SFC State_1
State_1
State_State_2
History_State1
State_2
State_3
State_State_3
Figure 46: Transformation of a history connector to IML elements

Case A
The mapping of a shallow history connector results in an IML state s, an IML additional data element
ad and its IML attribute values (see Table 89).
IML element
Attribute value
s.ID
<some ID>
s.Name
History_ + state name of the super state of the history

connector
s.Init
False
s.Terminal
False
s.Pre
selDiv.ID if the history connector has more than one

predecessor (see section 5.5.3)
st.ID of the predecessor state transition if the history
connector has one predecessor
<empty> if history connector has no predecessor
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
historyConnector
ad.Pre
s.ID
Table 89: Attribute values for transformation of a history connector in IML

Note: Regarding its successor and predecessor relations the history connector shall be treated like a
simple state, see 5.5.3 and 5.5.4.
109

Case B
The mapping of a deep history connector results in an IML state s, an IML additional data element ad
and its IML attribute values (see Table 90), in at least each IML system representing a sub State chart
of state the deep history connector belongs to.
IML element
Attribute value
s.ID
<some ID>
s.Name
History_ + state name of the super state of the history

connector
s.Init
False
s.Terminal
False
selDiv.ID if the history connector has more than one
predecessor (see section 5.5.3)
st.ID of the predecessor state transition if the history
connector has one predecessor
s.Pre
<empty> if history connector has no predecessor
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
historyConnector
ad.Pre
s.ID
Table 90: Attribute values for transformation of a history connector in IML

simple state, see 5.5.3 and 5.5.4.
Note: Predecessors and successors can be states and connectors on each hierarchy level.
5.6.3
Condition Connector
This clause defines the IML representation of a condition connector within IML.
SFC State_1
State_1
State_State_4
State_3
Condition_ID_
State_1
State_4
c
State_2
State_State_2
State_State_3
Figure 47: Transformation of a condition connector to IML elements

A condition connector results in an IML state s, an IML additional data element ad and its IML attribute
values (see Table 91).
110

IML element
Attribute value
s.ID
<some ID>
s.Name
Condition_ + s.ID + _+ state name of the state the

condition connector is directly integrated in
s.Init
False
s.Terminal
False
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
Condition Connector
ad.Pre
s.ID
Table 91: Attribute values for the condition connector representation in IML
simple state, see section 5.5.3 and 5.5.4.
Note: Predecessors and successors can be states and connectors on each hierarchy level.
5.6.4
State Transition among Hierarchies
This clause defines the IML representation of inter level state transitions; therefore different cases are
considered Figure 48 depicts the general mapping of State chart state transitions.
SFC State_Main
State_1
InitialStep_noName
SFC State_2
Proxy_State_1
[Guard]
[True]
[Guard]
State_2
State_State_2-1
State_State_1
[Guard]
State_2-2
State_2-1
State_State_2-2
State_State_2
Contains AddData
element with
refrence to SFC
State_2
Figure 48: Transformation of a state transition over different hierarchy level to IML element
Note: Within the following mapping rules predecessors and successors of the state transitions can be
states and connectors on each hierarchy level.
Table 92 gives an overview about the different cases that are considered for the mapping of state
transitions in hierarchical State charts between different levels to IML elements.
Case
Number
of
Successors
Number
of
Predecessors
Successor
State Level
Action during
Execution
Hierarchy
Level
Higher Level
No
Higher Level
Yes
Lower Level
No
Lower Level
Yes
Table 92: Distinction of cases for the mapping of state transitions in hierarchical State charts
111

Case A
The state transition connects states or connectors within the different hierarchy levels whereas the
originator of the state transition belongs to the higher hierarchy level. Furthermore no action is
executed during the transition.
SFC State_Main
State_1
SFC State_2
Proxy_State_1
InitialStep_noName
[Guard]
[True]
[Guard]
State_2
State_State_2-1
State_State_1
[Guard]
State_2-2
State_2-1
State_State_2-2
State_State_2
Contains AddData
element with
refrence to SFC2
Figure 49: Transformation of a state transition from a higher state without an action to IML elements
predecessor relations of the source state s1 and super state s2 of the destination state of the transition,
within the IML system representing the higher level (see Table 93).
IML element
Attribute value
st.ID
<some ID>
st.Name
st.Guard.Formular
st.Pre

source state s1
successor state transition (see section 5.5.3)

s2.Pre
st.ID
sel.Div
st.ID
Table 93: Attribute values for state transition representation in IML within hierarchical State charts
Additionally the state transition is mapped to the following elements within the IML system
representing the sub State chart of the super state:
an IML state transition st,
an IML state s2,
their attribute values and their successor and predecessor relations to the state s1 and the destination
state s3 of the transition (see Table 94).
112
IML element
Attribute value
s2.ID
<some ID>
s2.Name
Proxy_ state name of the originator of the state

transition
s2.Init
False
s2.Terminal
False
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
higherLevelState
ad.Pre
s2.ID
st.Name
st.Guard.Formular
st.Pre

state s2
selDiv.ID if the state s2 has more than one successor r
state transition (see section 5.5.3)

If st is the only predecessor state transition of the destination state s 3 of the state transition
s3.Pre
st.ID
If the destination state s3 of the state transition has more than one predecessor state transition (see
section 5.5.3)
selCon.Pre
st.ID
Table 94: Attribute values for state transition representation in IML within the sub State charts
Note: For the structure and the integration of the internal State charts all provisions of the previous
sections shall be exploited.
113

Case B
In this case the state transition connects states or connectors within the different hierarchy levels
whereas the originator of the state transition belongs to the higher hierarchy level. Furthermore at
least one action is executed during the transition.
SFC State_2
SFC State_Main
Proxy_State_1
InitialStep_noName
[Guard]
[True]
State_1
StateForActivity_
Proxy_State_1
action1
State_State_1
[True]
[Guard]/action1
State_2
[Guard]
State_State_2-1
State_State_2
State_2-2
State_2-1
Contains AddData
element with
refrence to SFC
State_2
State_State_2-2
Figure 50: Transformation of a state transition from a higher state with an action to IML elements
predecessor relations of the source state s1 and super state s2 of the destination state of the transition
within the IML system representing the higher level (see Table 95).
IML element
Attribute value
st.ID
<some ID>
st.Name
st.Guard.Formular
st.Pre

source state s1

s2.Pre
st.ID
If the destination state s2 has more than one predecessor state transitions (see section 5.5.3)
selCon.Pre
st.ID
Table 95: Attribute values for state transition representation in IML within hierarchical State charts
Additionally the state transition results in the following elements within the IML representation of the
sub State chart:
one IML state s1
two IML state transition st1 and st2,
a new created IML state s2,
an attached additional data element ad,
an IML activity a,
114

their corresponding IML attributes and their successor and predecessor relations to the state s1 and
the destination state s3 of the transition (see Table 96).
IML element
Attribute value
s1.ID
<some ID>
s1.Name

transition
s1.Init
False
s1.Terminal
False
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
higherLevelState
ad.Pre
s1.ID
st1.ID
<some ID>
st1.Name
st1.Guard.Formular
st1.Pre

source state s1
s2.ID
<some ID>
s2.Name
s2.Init
False
s2.Terminal
False
s2.Pre
st1.ID
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
stateForActivity
ad.Pre
s2.ID
st2.ID
<some ID>
st2.Name
st2.Guard.Formual
TRUE
st2.Pre
s2.ID
115

a.ID
<some ID>
a.Name
a.Formula
Content of action a
a.FiredEvents
a.Pre
s2.ID

s3.Pre
st2.ID
selCon.Pre
st2.ID
Case C
In this case the state transition connects states or connectors within the different hierarchy levels
whereas the originator of the state transition belongs to the lower hierarchy level. Furthermore no
action is executed during the transition.
SFC State_1
SFC State_Main
InitialStep_noName
InitialStep_noName
State_2
[True]
State_State_2-1
[Guard]
State_State_1
State_1
[Guard]
State_State_2-2
State_1-1
State_1-2
State_State_2
[Guard]
Contains AddData
element with
refrence to SFC
State_1
Proxy_State_State_1
Figure 51: Transformation of a state transition from a lower level state without an action to IML
elements
predecessor relations of the super state s1 of the source state and the destination state s2 of the
transition, within the IML system representing the higher level (see Table 97).
116

IML element
Attribute value
st.ID
<some ID>
st.Name
st.Guard.Formular
st.Pre

source state s1

s2.Pre
st.ID
selCon.Pre
st.ID
Table 97: Attribute values the representation of state transition among hierarchies in IML at the higher
level
Additionally the state transition is mapped to the following elements within the IML system
representing the sub State chart of the super state:
an IML state transition st,
an additional data element ad,
an IML state s3
and their attribute values see Table 98.
117

IML element
Attribute value
s3.ID
<some ID>
s3.Name

transition
s3.Init
False
s3.Terminal
False
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
higherLevelState
ad.Pre
s3.ID
st.ID
<some ID>
st.Name
st.Guard.Formular
st.Pre
s.ID if st is the only successor state transition of the

source state s1

If st is the only predecessor state transition in the sub State chart of the state s3
s.Pre
st.ID
If the state s3 has more than one predecessor state transition in the sub State chart (see section
5.5.3)
selCon.Pre
st.ID
Table 98: Attribute values for the state transition representation in IML within the sub State charts
118

Case D
In this case the state transition connects states or connectors within the different hierarchy levels while
originator of the state transition has the lower hierarchy level. Furthermore at least one action is
executed during the transition.
SFC State_Main
SFC State_1
InitialStep_noName
InitialStep_noName
[True]
State_2
State_State_1
[Guard]
[Guard]/action1
State_1
Contains AddData
element with
refrence to SFC
State_1
StateForActivity_
action1
State_State_1-1
State_State_1-2
[True]
State_1-1
[Guard]
State_1-2
State_State_2
Proxy_State_State_2
Figure 52: Transformation of a state transition from a lower level state with an action to IML elements
The state transition results in:
two IML state transitions st1 and st2,
a new created IML state s1,
an IML activity a,
their corresponding IML attributes and their successor and predecessor relations to attribute values
and its successor and predecessor relations of the super state s2 of the source state and the
destination state s3 of the transition (see Table 99).
IML element
Attribute value
st1.ID
<some ID>
st1.Name
st1.Guard.Formular
st1.Pre

state s1
selDiv.ID if the state s1 has more than one successor
state transition (see section 5.5.3)
s1.ID
<some ID>
s1.Name
s1.Init
False
s1.Terminal
False
s1.Pre
st1.ID
ad.ID
<some ID>
ad.Type
StateChartStateType
119

ad.Value
stateForActivity
ad.Pre
s1.ID
st2.ID
<some ID>
st2.Name
st2.Guard.Formual
TRUE
st2.Pre
s1.ID
a.ID
<some ID>
a.Name
a.Formula
Content of action a
a.FiredEvents
a.Pre
s1.ID

s3.Pre
st2.ID
selCon.Pre
st2.ID
Table 99: Attribute values the representation of state transition among hierarchies in IML
Additional the state transition results in the following elements within the IML representations of the
sub State chart:
one IML state transition st,
one IML state s4
and their corresponding IML attributes and their successor and predecessor relations to the source
states of the transition (see Table 100).
120

IML element
Attribute value
s4.ID
<some ID>
s4.Name

transition
s4.Init
False
s4.Terminal
False
ad.ID
<some ID>
ad.Type
StateChartStateType
ad.Value
higherLevelState
ad.Pre
s4.ID
st.ID
<some ID>
st.Name
st.Guard.Formular
st.Pre

source state s4

If st is the only predecessor state transition of the state s 4
s4.Pre
st.ID
selCon.Pre
st.ID
121

5.7
Example Transformation
Representation
for
State
Charts
to
AutomationML
Logic
Within the following examples the application of the transformation rules is depicted based on the
example of the behaviour of a PLC. The first example represents the cyclic execution of a PLC
program and all further examples are enriched by additional details including interrupt handling, lineby-line execution of code, and PLC programming.
InitialStep_noName
[TRUE]
[Outputs set]
ReadInput
State_ReadInput
SetOutputs
[Input read]
[Inputs read]
[Program executed]
ExecutePr
ogram
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
Figure 53: Example: transformation of a simple cyclic State chart

InitialStep_noName
[TRUE]
[Outputs set]
State_ReadInput
ReadInput
[Inputs read]
SetOutputs
[Program executed]
ExecutePr
ogram
[Interrupt handled]
[Input read]
[Program
executed]
[Interrupt]
InterruptHa
ndling
State_SetOutputs
[Interrupt]
State_InterruptHandling
[Outputs set]
[Interrupt handled]
Figure 54: Example: transformation of a State chart with states with different predecessors and
successors
122

InitialStep_noName
[TRUE]
State_ReadInput
[Outputs set]
ReadInput
[Input read]
SetOutputs
StateForActivity_SetLineCountzero
[Inputs read] Action SetLineCountzero
Action_SetLineCountzero_ofStateTransition
Action_IncrementLineCount_ofState_ExecuteProgram
[TRUE]
[Program executed]
ExecuteProgram
[Program
executed]
DoAction IncrementLineCount
State_SetOutputs
[Outputs set]
Figure 55: Example: transformation of a State chart with actions

InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
[Outputs set]
Condition_C
ReadInput
SetOutputs
[Program executed]
[NoInterrupt]
[Inputs read]
ExecutePr
ogram
C
[NoInterrupt]
[Interrupt]
State_InterruptHandling
[InterruptHandled]
[Interrupt]
[Interrupt handled]
InterruptHa
ndling
[Program
executed]
State_SetOutputs
[Outputs set]
Figure 56: Example: transformation of a State charts with a condition connector
123

SFC2 Cyclic Behaviour
SFC1 - Main
Programming
InitialStep_noName
InitialStep_noName
[TRUE]
[TRUE]
[Stop]
[Start]
State_ReadInput
State_Programming
CyclicBehaviour
[Outputs set]
[Input read]
[Start]
ReadInput
SetOutputs
State_CyclicBehaviour
[Program
executed]
[Stop]
[Inputs read]
[Program executed]
ExecutePr
ogram
Contains
AddData element
with refrence to
SFC2
State_SetOutputs
[Outputs set]
Figure 57: Example: transformation of a State chart with simple hierarchy

SFC2 Cyclic Behaviour
SFC1 - Main
InitialStep_noName
InitialStep_noName
[TRUE]
[TRUE]
State_ReadInput
State_Programming
Contains
AddData element
with refrence to
SFC3
[Start]
[Input read]
State_CyclicBehaviour
[Stop]
Contains
AddData element
with refrence to
SFC2
[Program
executed]
State_SetOutputs
[Outputs set]
SFC3 Programming
Programming
InitialStep_noName
Proxy_State_CyclicBehaviour
[Program change necessary]

[TRUE]
UploadPro
gram
EditProgram
[Stop]
History_Programming
[Editing finished][Program incorrect]

CompileProgram
H
State_EditProgram
[Program correct]
C
[Editing finished]
[Program compiled]
State_CompileProgram
[Stop]
[Start]
[Program
compiled]
CyclicBehaviour
Condition_32_Programming
[Outputs set]
[Program incorrect]
ReadInput
[Program correct]
SetOutputs
State_UploadProgram
[Inputs read]
[Program executed]
ExecutePr
ogram
[Program change
necessary]
[Start]
Figure 58: Example: transformation of a State chart with complex hierarchy and connectors
124

6
Linking AutomationML Objects with Logic Information
6.1
Overview AutomationML Top Level Architecture
As described within section 1.1 the main purpose of AutomationML is the exchange of engineering
information of manufacturing systems along the engineering chain. Therefore, the logic descriptions
covered by this document need to be combined with the information of the top-level architecture of
AutomationML [1] to enable a consistent association of logic information with system objects of
production systems or its components respectively.
Within this concept the top-level architecture of AutomationML covers the representation of
hierarchical structures of plant objects. These objects are used to store information to a certain level of
detail only. Additionally, aspects of these objects are stored in external documents which are
referenced by the corresponding AutomationML objects.
CAEX forms the basis data format for the exchange of plant topology information. Relevant for
association of logic aspect to AutomationML objects within the plant topology are the CAEX element
InternalElement and a specific AutomationML reference mechanism.
The InstanceHierarchy stores the plant structure as a hierarchy of object instances together with their
individual properties, interfaces, references, and relations among them. The internal elements
constitute these object instances representing individual units.
References describe associations from CAEX internal elements to information stored in external
documents e.g. COLLADA [Collada2010] or PLCopen XML.
An overview of this architecture is given in the Figure 59.
Figure 59: AutomationML top level architecture
6.2
Reference Mechanisms between CAEX and PLCopen XML
6.2.1
Overview
A document reference serves for the linking between one AutomationML object and one external
document which may contain e.g. sequence, behaviour, or interlocking information. The reference
mechanism bases on standard AutomationML interfaces see [1;2].
125

Thereby
the
PLCopenXMLInterface,
LogicInterface,
VariableInterface
and
InterlockingVariableInterface of the standard AutomationMLInterfaceClassLib according to Table 101
shall be used.
InterfaceClass library
InterfaceClass
Description
AutomationMLBaseInterface
Abstract interface type
ExternalDataConnector
Generic connector
interface to external data
PLCopenXMLInterface
Interface to a PLCopen
XML document
LogicInterface
Interface to a logic
description within a
PLCopen XML document
VariableInterface
Interface to a variable
definition within a PLCopen
XML document
InterlockingVariableInterface
Interface to an interlocking
description within a
PLCopen XML document
Table 101: InterfaceClasses of the AutomationMLInterfaceClassLib

6.2.2
Referencing PLCopen XML documents
Regarding referencing PLCopen XML documents, the following provisions apply:
A reference from an AutomationML object to an external PLCopen XML document shall be

modeled using one of the standard InterfaceClass PLCopenXMLInterface, LogicInterface,
VariableInterface, and InterlockingVariableInterface specified in clause 0, 0, 6.2.6, and 7.3.2.
If sequence or behaviour description or another logic description is referenced, the LogicInterface
shall be used, see 0.
If single variables within a PLCopen XML document are referenced, the VariableInterface shall be
used, see 6.2.6.
If interlocking descriptions are referenced, the InterlockingVariableInterface shall be used, see
7.3.2.
The location of the external document is stored within the standard attribute refURI of these
interfaces specified in clause 6.3.2.
Note: It is recommended to reference the corresponding POU instead of the document, as the
document may contain several POUs.
Referencing multiple PLCopen XML documents is allowed and shall be modeled by using multiple
interfaces of the type PLCopenXMLInterface, LogicInterface, VariableInterface, respectively
InterlockingVariableInterface.
Referencing data within a PLCopenXML document shall be modeled by adding the separating
character # to the documents location in the refURI attribute, followed by the globalId attribute
of the data.
If multiple documents are referenced depicting different versions, variants, or alternatives of the
same logic information, the CAEX header of the CAEX interfaces shall be used in order to
document its version.
126

Examples
refURI =
file:///C:/Temp/PLCopenXML1.xml#POU1_globalId
refURI =
file:///C:/Temp/ PLCopenXML1.xml #variable_globalID
Reference to a POU within PLCopen XML

document PLCopenXML1.xml
Reference to a variable within a PLCopen XML
document
Table 102: Examples for the attribute refURI

6.2.3
InterfaceClass ExternalDataConnector
Table 103 specifies the InterfaceClass ExternalDataConnector.
Class name
ExternalDataConnector
Description
The InterfaceClass ExternalDataConnector is a basic abstract interface type

and shall be used for the description of connector interfaces referencing external
documents. The classes COLLADAInterface and PLCopenXMLInterface are
derived from this class. All existing and future connector classes shall be derived
directly or indirectly from this class.
Parent Class
AutomationMLInterfaceClassLib/AutomationMLBaseInterface
Attribute
refURI
(type=xs:anyURI)
The attribute refURI shall be used in order to

store the path to the reference external
document.
Table 103: InterfaceClass ExternalDataConnector

Note: Derived interface classes inherit all attributes of their respective parent class.
6.2.4
InterfaceClass PLCopenXMLInterface
Table 104 specifies the InterfaceClass PLCopenXMLInterface.
Class name
PLCopenXMLInterface
Description
The InterfaceClass PLCopenXMLInterface shall be used in order to reference

external PLCopen XML documents or to publish signals or variables that are
defined inside of a PLCopen XML logic description. Details are described in 6.3
of this document.
Parent Class
AutomationMLBaseInterface/ExternalDataConnector
Table 104: InterfaceClass PLCopenXMLInterface
127

6.2.5
InterfaceClass LogicInterface
Table 105 specifies the InterfaceClass LogicInterface.
Class name
LogicInterface
Description
The InterfaceClass LogicInterface shall be used in order to reference a logic

description within an external PLCopen XML document. Details are described in
section 6.3 of this document.
Parent Class
AutomationMLInterfaceClassLib/AutomationMLBaseInterface/
ExternalDataConnector/PLCopenXMLInterface
Table 105: InterfaceClass LogicInterface

6.2.6
InterfaceClass VariableInterface
Table 106 specifies the InterfaceClass VariableInterface.
Class name
VariableInterface
Description
The InterfaceClass VariableInterface shall be used in order to reference

variables in external PLCopen XML documents. Details are described in section
6.3 of this document.
Parent Class
ExternalDataConnector/PLCopenXMLInterface
Table 106: InterfaceClass VariableInterface
6.3
Referencing Logic Information
6.3.1
Conceptual Overview
Logic information is stored in separate documents following the PLCopen XML data format.
Modeling logic information is, therefore, split into two parts. On the one hand, the corresponding object
is modeled within CAEX without any logic information. On the other hand, a PLCopen XML document
has to be provided containing the logic information. Finally, the CAEX object stores a reference to the
PLCopen XML document. Therefore, two different reference mechanisms are defined.
Figure 60 depicts the base concepts of referencing a PLCopen XML document out of CAEX. For this,
the standard AutomationML InterfaceClasses LogicInterface and VariableInterface are assigned to
the AutomationML object. Details regarding modeling logic information are specified in sections above.
CAEX File
Station
PLCopen XML File
Init
Sequ1 (PLCopenXMLInterface/LogicInterface)
refURI = file:///c:test.xml#POU_1
Step 1
a
b
Var1 (PLCopenXMLInterface/ VariableInterface)
End
refURI = file:///c:test.xml#b
Figure 60: Storage of logics information with AutomationML
128

6.3.2
Referencing PLCopen XML Logic Information
Logic information describing the sequencing or behaviour information of AutomationML objects is

stored in POUs of PLCopen XML documents. For referencing these information the LogicInterface,
defined in section 0, shall be used.
The LogicInterface shall be added to the object the logic information is assigned to.
Figure 61 depicts such a reference.
CAEX File
PLCopen XML File
Init
Station
Step 1
Refrenced
POU
refURI = file:///c:test.xml#POU_1
Published
End
LogicInterface
Figure 61: Referencing logic information

6.3.3
Referencing PLCopen XML Variables
Within logic information descriping the sequencing or behaviour information of AutomationML objects
variables are stored as part of PLCopen XML documents representing signal of controls. For
referencing these information the VariableInterface, defined in section 6.2.6 shall be used.
The VariableInterface shall be added to corresponding object the logic information is assignt to.
Figure 62 depicts such a reference.
CAEX File
Station
PLCopen XML File
Init
Step 1
a
b
PLCopen
variable
Var1 (PLCopenXMLInterface/ VariableInterface)
End
Published
refURI = file:///c:test.xml#b
VariableInterface
Figure 62: Publishing PLCopen variables
129

6.4
Examples
As an example for referencing logic descriptions a small drilling system is considered. It consists of
five components; two of them are cylinders. The overall system has a controller which has to be
programmed. Hence, for the complete drilling system sequencing information have to be stored. In
addition for purposes like virtual commissioning behaviour information can be assigned to each unit. In
our case the Cylinder 1 has additional behaviour information.
The complete system is depicted in Figure 63.
Sequencing
Cylinder 2
+
Drill
C1U
Behavior
Cylinder 1
C1L
Transport
Unit 1
Piece
Transport Unit 2
C1R
P
Piece
Figure 63: Example drilling system

6.4.1
Referencing a PLCopen XML Document
The sequencing information for the drill station is stored in the PLCopen XML document
Drill_Station_Sequencing.xml within the POU with the name 010BES_021 and the globalId
H_36b9a027-96cd-47db-92ea-c737e92ed093. This POU has to be referenced from the
InternalElement representing the complete drilling station.
To reference the sequencing information a LogicInterface object named Drill_Station_Sequencing is
placed within the InternalElement representing the complete drilling station. This LogicInterface object
has the attribute refURI. RefURI is used to refer to the POU named above.
Therefore, it has the value file:///c:/Drill_Station_Sequencing.xml#H_36b9a027-96cd-47db-92eac737e92ed093 were file:///c:/Drill_Station_Sequencing.xml gives the path to the PLCopen XML
document within the project documents and H_36b9a027-96cd-47db-92ea-c737e92ed093 defines the
unique identification of the POU that is referenced.
The resulting reference structure is depicted in Figure 64.
130
Drill_Station.aml
AutomationML
<InternalElement Name="Drill_Station"
RefBaseSystemUnitPath="Drill_Station_Lib/MechatronicUnit"
ID="{afda820d-7fb6-4304-9710-8c0987a0f56c}">
<ExternalInterface Name="Drill_Station_Sequencing"
RefBaseClassPath="AutomationMLInterfaceClassLib/AutomationMLBaseInterfa
ce/ExternalDataConnector/PLCopenXMLInterface/LogicInter
face"
ID="{d7fc3628-d056-4acd-818b-d6d033d6058b}">
<Attribute Name="SchemaVersion" AttributeDataType="xs:string">
<Value>2.0</Value>
</Attribute>
<Attribute Name="refURI" AttributeDataType="xs:anyURI">
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing.xml#
H_36b9a027-96cd-47db-92ea-c737e92ed093
</Value>
</Attribute>
</ExternalInterface>
</InternalElement>
Drill_Station_Sequencing.xml
PLCopen XML
Figure 64: Reference to logic description

6.4.2
Referencing and Connecting a PLCopen XML Variable
Within the logic information of the drilling station the different sensor and actuators can be addressed.
Thus, the individual sensors and actuators can be part of both the sequencing description within the
PLCopen XML as well as the top level architecture representation.
In the example, the actuator responsible to extract Cylinder 1 can be a valve. This valve is controlled
by the signal Extract_Cylinder1. This signal is integrated in the top level description by an interface
element of type SignalInterface.
To reference from the top level architecture representation of this actor to the PLCopen XML
representation of the signal the VariableInterface is used.
Within the InternalElement for Cylinder 1 a VariableInterface Extract_Cylinder1 is modeled which is
connected to the SignalInterface Extract_Cylinder1 by an internal link. This attribute refURI of the
VariableInterface object used to refer to the variable within the PLCopen XML. Therefore, it get the
131

value
file:///c:/Drill_Station_Sequencing.xml#F_32b5a027-69d7-171b-9ea6-73c7f92aa093
were
file:///c:/Drill_Station_Sequencing.xml gives the path to the PLCopen XML document within the
project documents and F_32b5a027-69d7-171b-9ea6-73c7f92aa093 defines the unique identification
of the variable that is referenced.
The resulting reference structure is depicted in Figure 65.
Drill_Station.aml
AutomationML
<InternalElement Name="Cylinder1"
RefBaseSystemUnitPath="Drill_Station_Lib/Cylinder"
ID="{46ba65e0-5f6d-48ff-9b70-a0030d9dc7b5}">
<ExternalInterface Name="Extract_Cylinder1"
RefBaseClassPath="AutomationMLInterfaceClassLib/AutomationMLBaseInterface/
ExternalDataConnector/PLCopenXMLInterface/VariableInterface"
ID="{3807ad7f-8875-42d4-b7e3-66fbefe46621}">
<Attribute Name="SchemaVersion" AttributeDataType="xs:string" />
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing.xml#
F_32b5a027-69d7-171b-9ea6-73c7f92aa093
</Value>
</Attribute>
<ExternalInterface Name="Extract_Cylinder1"
RefBaseClassPath="AutomationMLInterfaceClassLib/AutomationMLBaseInterface/
Communication/SignalInterface"
ID="{dd563b37-f9ea-44b0-866f-a672fa00727c}"/>
<InternalLink Name=" Extract_Cylinder1"
RefPartnerSideA="{46ba65e0-5f6d-48ff-9b70-a0030d9dc7b5}:Extract_Cylinder1"
RefPartnerSideB="{46ba65e0-5f6d-48ff-9b70-a0030d9dc7b5}:Extract_Cylinder1"/>
</InternalElement>
Drill_Station_Sequencing.xml
PLCopen XML
Figure 65: Reference to variable within logic description

6.4.3
Referencing and Connecting Behaviour and Sequence Information
Not only sequencing information can be stored within PLCopen XML documents but also behaviour
information. Both can be combined within one document or described in multiple documents. The
mapping of this information is similar to the examples given above.
132

Figure 66 depicts an example were the behaviour of Cylinder 1 and the sequencing of the drilling
station are integrated within one PLCopen XML document. Within the referencing they are
distinguished by the unique globalId of the POUs representing the different information.
In addition, the referencing to variables is integrated.
Drill_Station.aml
AutomationML
<InternalElement Name="Drill_Station">
<ExternalInterface Name="Drill_Station_Sequencing">
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&Behaviou
r.xml# H_36b9a027-96cd-47db-92ea-c737e92ed093</Value>
</Attribute>
<InternalElement Name="Drill"/>
<InternalElement Name="Cylinder1"/>
<ExternalInterface Name="Cylinder1_Behaviour">
<Attribute Name="refURI" AttributeDataType="xs:anyURI"/>
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&B
ehaviour.xml# G_36b9abd6-96cd-47db-92ea-c737e92ed088</Value>
</Attribute>
<ExternalInterface Name="Extract_Cylinder1">
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&B
ehaviour.xml# F_32b5a027-69d7-171b-9ea6-73c7f92aa093</Value>
</Attribute>
</InternalElement>
<InternalElement Name="Cylinder2"/>
<InternalElement Name="TransportUnit1"/>
<InternalElement Name="TransportUnit2"/>
</InternalElement>
Drill_Station_Sequencing&Behaviour.xml
PLCopen XML
Figure 66: Reference to multiple logic information

133

7
Mapping Interlocking Information to AutomationML
7.1
Overview
The description of interlocking conditions is an important part within the engineering of production
systems to ensure their safe behaviour. It affects not only the safe interaction with humans and
environment but also helps to avoid unstable situations of the systems possibly causing harmful
effects on humans and environment or damages on machines and products.
AutomationML provides three levels of detail to describe and store interlocking conditions. These
levels are based on each other and can be used within different engineering phases:
linking of different signal and component groups to describe functional dependencies among
objects in the first stages,
adding of Boolean logic stored as function block networks to describe basic interlocking conditions
within a second stage, and
extension of these function block networks to complex interlocking descriptions in a third stage.
7.2
Component Groups and Signal Groups
7.2.1
Concept Description
Within a first stage AutomationML sum up objects that belong to groups of objects that indicate unsafe
states within a production system, the signal groups, see Figure 68, or to groups of objects that are
influenced in their behaviour by signal groups, the so called component groups. To describe this
concept, the example production system in Figure 68 is used.
Safety shut-off mat 1
Emergencystop 1
Light guard 2
Robot 1
Gate 1
Robot 4
Robot 3
Gate 2
Welding
tool 2
Press 1
Emergencystop 3
Gate 3
Conveyer 1
Press 2
Robot 2
Emergencystop 2
Light guard 1
Figure 67: Example production system

A signal group is a set of system elements with the joint property, that a dedicated state of these
elements requires activities to ensure safe system behaviour. In Figure 67 the state of Emergencystop
1, Emergencystop 2, and Light guard 1 indicates the admissibility of operation within the first
manufacturing cell consisting of Gate 1, Welding tool 2, Robots 1 and Robot 2.
A component group, in contrast, is a set of system elements used to execute the required activities to
ensure safety. In this example, Gate 1, Welding tool 2, and Robots 1 and Robot 2 constitute such a
component group.
The assignment between a signal and a component group represents that the component group has
to execute the necessary activity called by the signal group. In the example, the activity connecting
this group to its signal group is the direct stop of any motion of the elements in the component group.
134
Signal Group
Component Group
Emergencystop 1
Robot 1
Emergencystop 2
Welding tool 2
Gate1
Light guard 1
Robot 2
Figure 68: Principle usage of signal and component groups

The assignment between these groups is not restricted to a 1:1 relation. Several signal groups can
exist, that are connected to one or more component groups. Figure 69 depicts the linking between
multiple groups. In the example, the Signal Group A affects the Component Group A and Component
Group B, in the case of an unsafe state, while the Signal Group B only has effects on Component
Group B. Finally the Signal Group C influences Component Group B and Component Group C.
Signal Group A
Emergency
stop 1
Emergency
stop 2
Component Group A
Robot 1
Welding tool 2
Gate 1
Light guard 1
Robot 2
Signal Group B
Component Group B
Safety shut-off
mat 1
Robot 3
Gate 2
Light guard 2
Press 1
Signal Group C
Safety shut-off
mat 2
Emergencystop 3
Component Group C
Robot 4
Conveyer 3
Press 2
Figure 69: Linking of signal and component groups

For modeling signal and component groups the AutomationML group concept is used. This allows
separating structure information from instance information. For this purpose the SignalGroup role
class and the ComponentGroup role class are defined, see chapter 7.2.2 and 7.2.3. Both classes are
derived from the AutomationML BaseRoleClass Group.
135

Each of the signal and component groups shall have an interface from the InterfaceClass type
InterlockingConnector, see chapter 7.2.4. These interfaces are used as terminal point for the
connection between signal and component groups. The links between these interfaces shall be
established with CAEX InternalLinks.
The example of signal and component group is modeled in Figure 70. It contains the SignalGroup_A
with mirror objects of the objects Emergencystop_1, Emergencystop_2, and Light_guard_1 being
elements of Cell_1 in the InstanceHierarchy. In addition, it contains a ComponentGroup_A with mirror
objects of Gate_1, Welding_tool_2, and Robot_1 and Robot_2.
AutomationML
Object structure
InterlockingConnector
SignalGroup
SignalGroups with
Mirror Objects
InternalLink
ComponentGroups
with Mirror Objects
ComponentGroup
Figure 70 Example of creating signal and component groups

7.2.2
RoleClass ComponentGroup
Table 107 specifies the RoleClass ComponentGroup.
Class name
ComponentGroup
Description
The RoleClass ComponentGroup is a role type for objects that group objects
belonging to one component group according to the interlocking definition of
AutomationML.
Parent Class
AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Group
Table 107: RoleClass ComponentGroup
136

7.2.3
RoleClass SignalGroup
Class name
SignalGroup
Description
The RoleClass SignalGroup is a role type for objects that group objects
belonging to one signal group according to the interlocking definition of
AutomationML.
Parent Class
AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Group
Table 108: RoleClass SignalGroup

7.2.4
InterfaceClass InterlockingConnector
The InterlockingConnector is a special connector class defined in the AutomationMLInterfaceClassLib.

It will be used to connect signal groups and components groups within the AutomationML interlocking
description only. Hence, the usage of the InterlockingConnector applies to the following provisions;
shall
be
used
only
within
elements
of
type
SignalGroup
ComponentGroup.
or
InterlockingConnector interface shall be connected via InternalLinks to interfaces of the same type
only.
Table 109 specifies the InterfaceClass InterlockingConnector.

Class name
Description
The InterfaceClass InterlockingConnector shall be used in order to model

relations between signal groups and component groups.
Parent Class
AutomationMLInterfaceClassLib/AutomationMLBaseInterface
Table 109: InterfaceClass InterlockingConnector
7.3
7.3.1
Boolean Logic as Interlocking Condition

Concept Description
The second level of interlocking description exceeds the simple grouping of devices to signal and
component groups by a Boolean function describing the interlocking conditions of the signal groups.
The usage of the Boolean function for describing interlocking conditions in this level applies the
following provision:
The Boolean function shall be expressed in Function Block Diagrams (FBD).
The Boolean function shall be stored in the corresponding PLCopen XML representation of FBD.
The Boolean function shall be represented by a single POU element within PLCopen XML.
The use of function blocks within FBD is restricted to the usage of AND, OR, TON, TOF and NOT
function blocks corresponding to IEC 61131-3.
The FBD shall have one dedicated variable as evaluation result of the FDB evaluation representing
the interlocking condition of a signal group.
The restriction of the applicable function block set within the second level of the interlocking conditions
on a minimal set of function blocks is made to ensure the exchange between different software tools
within the engineering process, while all necessary Boolean and temporal conditions can still be
expressed.
137

Reference to a PLCopen
XML variable as
interlocking condition
SignalGroup A
PLCopen
XML
Document
Device 2
Link between a
SignalGroup and a
ComponentGroup
Device 1
ComponentGroup A
Device 3
Interlocking Connector
Device 4
Figure 71: General reference mechanism for interlocking condition

The reference mechanism InterlockingVariableInterface shall be used to connect the PLCopen XML
document to the signal groups. For this use case the InterfaceClass InterlockingVariableInterface
extends the InterfaceClass VariableInterface with an additional attribute SafeConditionEquals. This
attribute indicates either TRUE or FALSE of the referenced variable representing the safe state of the
signal group. Additionally, the use of the interfaces is restricted to direct references to the PLCopen
XML variable representing the unique resulting variable of the FBD network evaluation representing
the interlocking condition and not only to reference documents.
Figure 71 depicts the general reference mechanism between signal groups and component groups as
well as between signal groups and PLCopen documents.
7.3.2
InterfaceClass InterlockingVariableInterface
Table 107 specifies the extension of InterfaceClass InterlockingVariableInterface.
Class name
Description
The InterfaceClass InterlockingVariableInterface shall be used in order to

reference PLCopen XML documents
Parent Class
ExternalDataConnector/PLCopenXMLInterface/VariableInterface
The attribute SafeConditionEquals allows to
indicate which value of the reference variable
indicates a save state.
Values:
Attributes
SafeConditionEquals
(type=xs:Boolean)
TRUE: indicates that the value TRUE of the

variable within the PLCopen XML description
represents the safe state of the signal group.
FALSE: indicates that the value FALSE of the
variable within the PLCopen XML description
represents the safe state of the signal group.
Note: Use of the attribute is optional, default
value is TRUE.
Table 110: InterfaceClass InterlockingVariableInterface

138

The application of the InterfaceClass InterlockingVariableInterface is based on its integration within a
signal group. The association of the PLCopen XML variable representing the unique resulting variable
of the FBD network representing the interlocking condition is done within the attribute refURI.
Additional the attribute SafeConditionEquals indicates the condition of the safe state of the signal
group. Possible values of the attribute are TRUE or FALSE. An example is depicted in Figure 72.
Figure 72: Example of use of InterfaceClass InterlockingVariableInterface

The interlocking condition for the example of SignalGroup_A consisting of Emergencystop_1,
Emergencystop_2, and Light_guard_1 is none of the elements should have the state TRUE for a safe
operation. The resulting network is given in Figure 73. It has one unique output variable indicating the
safe state. Within the mapping of the PLCopen XML document containing this network the attribute
SafeConditionEquals will have the value TRUE while the attribute refURI will end with
#[globalId of variable OUT_SignalGroup_A].
POU1
AND
EmergencyStop1
OUT_SignalGroup_A
EmergencyStp2
LightGuard1
Figure 73: Example FBD for second level of interlocking description

7.3.3
Restricted Linking Mechanism
The use of the linking mechanism based on the InterfaceClasses InterlockingConnector and
InterlockingVariableInterface in the application case interlocking description is restricted to guarantee
a uniform understanding of interlocking information.
The following mechanisms for interlinking interlocking information are permitted.
Restricted
Mechanism
Description
Direct
Linking
from PLCopen
variables
to
Component
Groups
The logic that describes the interlocking condition for a component group is
stored in a PLCopen document as FBD and the resulting variable is direct linked
via PLCopenXMLInterface to this group.
In this case the PLCopen XML variable shall be linked to a PLCopenXML
Interface that belongs to a SignalGroup. The relation between the variable and
139

the ComponentGroup shall be realized via an internal link.
SignalGroup A
Direct links between

ComponentGroups and
PLCopen variables are
permitted.
Device 1
Device 2
ComponentGroup A
PLCopen
XML
Document
Device 3
Device 4
Direct
Linking
from
Object
Interfaces
to
Component
Groups
The signal of one object describes the interlocking condition for one component
group,
In this case the Object shall be referenced in an own Signal Group and this
group shall be linked with the Component group.
Plant
Device 1
Direct links between

devices within plant
topology description and a
ComponentGroup are
permitted.
Device 4
SignalGroup A
Device 1
Device 2
ComponentGroup A
Table 111: Restrictions for the linking of signal and component groups
7.4
Complex Logic as Interlocking Condition
As extension to the description of interlocking conditions with Boolean logic, AutomationML provides a
third level for the interlocking description. Within this level an FBD network with one resulting Boolean
variable shall be used as interface between signal groups and the logic description.
In addition it is intended to store complex FBD networks with e.g. vendor specific function blocks. The
usage of the concept applies following provision:
The FBD for complex logic shall be stored in separate POUs of the PLCopen XML document.
140
Each of these FBD networks shall result in a unique Boolean variable describing the evaluation
result of the FBD network.
The resulting variable of the single networks shall be used as input variable for the FBD with the
Boolean interlocking description following level 2 interlocking description.
Figure 75 depicts the concept of using complex FBD networks to describe interlocking conditions.
Here the POU1 and POU2 describe the third level interlocking descriptions. Each of them has a
unique variable describing the evaluation result of the FBD network. In the case of POU2 this variable
is OUT_POU_2. POU3 gives the description for the interlocking condition following the second level.
Here the variables describing the evaluation result of the FBD network of the third level descriptions
(OUT_POU_1 and OUT_POU_2) are used as input signals in combination with other signals.
POU1
POU2
LIMIT_INT
Min
TAN
INT_TO_BOOL
MN
Temp
IN
Max
MX
LREAL_TO_BOOL
OUT_POU_2
OUT_POU_1
POU3
AND
OUT_POU_1
OUT_POU_3
OUT_POU_2
EmergencyStop3
Figure 74: Complex FBD networks for interlocking descriptions
7.5
7.5.1
Extended Use of Interlocking Description within AutomationML

Interlocking as Transition Condition in Sequence Descriptions
Beyond the description of interlocking, FBD networks can be used within the definition of sequences
as transition condition e.g. as step enabling condition in combination with signals as trigger for the
state transitions.
An example for this use case of interlocking is depicted in Figure 75. In this example the transition
from resource state Slow to the resource state change Slow_to_Fast depends on a signal and the
fulfillment of an interlocking condition described in an FBD.
141
State
Motor1
Fast
Slow
ADD
OR
Var1
Interlocking_Var
Var2
ADD
NOT
Var3
Var4
Figure 75: Interlocking condition as additional transition condition within a network

The combination of interlocking and sequence descriptions applies to the following provision:
An interlocking variable that is used within a sequence description shall be published within the toplevel format.
Within the PLCopen XML document for the sequence description a placeholder for this variable
shall be created and this shall be published within the top-level format.
The interlocking variable and the placeholder variable shall be linked with an Internal Link within
the top-level format.
7.5.2
Interlocking Networks as Behaviour Description
In addition it is possible to use FBDs with interlocking conditions to describe the behaviour of single
objects.
Figure 4 gives an example for this description.
Device 1
A
Behaviour Device 1
A
B
&
Figure 76: Example of an interlocking network as behaviour description

The behaviour description of objects with FBD networks applies to the following provisions:
The PLCopen XML document containing the FDB network shall be attached to the object with a
LogicInterface.
Only AND, OR, TON, TOF and NOT function blocks shall be used within the FDB network.
142

7.6
Example for the Usage of Interlocking Descriptions within AutomationML
As example for the usage of interlocking descriptions the example given initially in Figure 77 is used.
This example depicts a manufacturing system consisting of three cells containing different
manufacturing equipments and safety structures.
Emergencystop 1
Light guard 2
Robot 3
Robot 1
Gate 1
Robot 4
Gate 2
Welding
Tool 2
Press 1
Emergencystop 3
Gate 3
Conveyer 1
Press 2
Robot 2
Emergencystop 2
Light guard 1
Figure 77: Interlocking example cell structure

Cell 1 contains the manufacturiung resources Welding tool 2, Robot 1 and Robot 2. It also contains
the safety devices Light guard 1 and Emergencystop 1. Cell 2 consists of the resources Press 1 and
Robot 3 and the safety devices Light guard 2, Safety shut-off matl 1, and Emergencystop 1. Finally,
Cell 3 is composed by the resources Press 2 and Robot 4 and the safety devices Safety shut-off mat 2
and Emergencystop 3. In addition, the cells are connected by 3 gates and Conveyer 1 for
transportation issues.
For the modeling of the interlocking conditions at first the InstanceHierarchy of the resources,
transportation means, and safety devices is developed in the three cells. Based on them, the signal
and component groups are modeled. In our example each cell has one signal and one component
group. The component groups are established by the resources and transportation devices of the
cells. This results in the following component groups:
ComponentGroup_A: Welding tool 2, Robot 1, Robot 2, Gate 1, and Gate 2,

ComponentGroup_B: Gate 2, Press 1, Robot 3, Conveyer 1, and
ComponentGroup_C: Conveyer 1, Press 2, Robot 3, and Gate 3.
Then the signal groups are modeled possibly effecting the behaviour of the component groups. In our
example the signal groups are:
SignalGroup_A: Emergencystop 1, Emergencystop 2, and Light guard 1,

SignalGroup_B: Light guard 2 and shut-off mat 1, and
SignalGroup_C: Emergencystop 3, and shut-off mat 2.
The example depicts the possibility that elements of the InstanceHierarchy are used to implement as
mirror objects within more than one signal or component group.
The resulting structure of the AutomationML project including the described signal and component
groups is depicted in Figure 78.
143
Figure 78: Interlocking example with modeled signal and component groups
The next step of modeling interlocking description with AutomationML is the linking of the signal and
component groups. Therefore, the IntelickingConnector interface and InternalLinks are used. In the
example, SignalGroup_A is linked with ComponentGroup_A, SignalGroup_B is linked with
ComponentGroup_B and SignalGroup_C is linked with ComponentGroup_C. Therefore, each group
has a unique element of the class InterlockingConnector. In the example of the InterlockingConnector
144

of
SignalGroup_A
is
Connector_SignalGroup_A
and
of
ComponentGroup_A
Connector_ComponentGroup_A. Both connectors are set into a relation by using an InternalLink.
The resulting structure for the example is depicted in Figure 79.
InternalLink
Figure 79: Interlocking example with linked signal and component groups
The next step is the modeling of the interlocking condition on second and third level. Therefore, the
FBD networks are specified and attached to the InterlockingVariableInterface of the signal groups. In
the
case
of
SignalGroup_A
the
name
of
the
is
InterlockingVariableInterface_SignalGroup_A. It contains a reference to the variable of the FBD
network that represents the evaluation result of the network. This example is depicted in Figure 80.
145
SignalGroup_A_InterlockingDescription.xml
<POU name=SignalGroup_A>
<localVars>
<variable name=OUT_SignalGroup_A/>
</localVars>
<body>
<FBD>
</FBD>
</body>
</POU>
Reference
InternalLink
Figure 80: Interlocking example with references PLCopen XML document
The modeling of the interlocking description is complete with the linking the FBD network. But the
concepts of AutomationML logic description can be used the express further information.
Furthermore, the input variables of the FBD network can be linked to the relevant interfaces of
elements in the InstanceHierarchy. In the example, the Light guard 1, the Emergencystop 1, and the
Emergencystop 2 are composed in the SignalGroup A. All of them have a SignalInterface within the
InstanceHierarchy. These interfaces can be connected to the PLCopen XML representation of the
interlocking condition to express the dependency of the interlocking condition on them.
Therefore, each of the named devices has an additional interface object of InterfaceClass
VariableInterface. This is connected by an InternalLink to the SignalInterface. Within the
VariableInterface, the corresponding variable of the PLCopen XML representation of the interlocking
condition is references.
The structure of this example is depicted in Figure 81.
146

SignalGroup_A_InterlockingDescription.xml
<POU name=SignalGroup_A>
<localVars>
<variable name= LightGuard1 />
<variable name= EmergencyStop1 />
<variable name= EmergencyStop12/>
<variable name=OUT_SignalGroup_A/>
</localVars>
<body>
<FBD>
</FBD>
</body>
</POU>
SignalGroup_A
AND
EmergencyStop1
OUT_SignalGroup_A
EmergencyStp2
LightGuard1
Reference
InternalLink
Figure 81: Interlocking example with references to PLCopen XML variables
147

References
[IEC62424]
International Electrotechnical Commission: IEC PAS 62424 - Specification for
Representation of process control engineering requests in P&I Diagrams and for data exchange
between P&ID tools and PCE-CAE, www.iec.ch, last accessed Mayl 2010.
[PLCopen2010] PLCopen Technical Committee 6: XML Formats for IEC 61131-3 Version 2.01,
http://www.plcopen.org/pages/tc6_xml/index.htm, last accessed May 2010.
[Collada2010]
Khronos Group: COLLADA Digital Asset Schema
http://www.khronos.org/files/collada_spec_1_5.pdf, last accessed May 2010.
Release
1.4.1,
[IEC61131]
International Electrotechnical Commission: IEC 61131 -Programmable controllers Part 3: Programming languages, www.iec.ch, last accessed Mayl 2010.
[UML2010]
OMG Unified Modeling LanguageTM (OMG UML), Infrastructure, Version 2.2
http://www.omg.org/spec/UML/2.2/Infrastructure/PDF/, last accessed May 2010.
[Harel1988]
529.
Harel, D.: On Visual Formalisms; Communications of the ACM, Jg. 31, H. 5, S. 514
148

Annex A: Example for Mapping IML to PLCopen XML
Within Figure 82 example of an IML System is depicted.
InitialInitial
StateState
ID= ISID_20090303_001,
Init=TRUE, Current=FALSE,
Terminal =FALSE
Transition 1
ID= ISID_20090303_002,
Guard.Var=a,[2;17],
Event
Variable
ID=ISID_20090303_013
Name=e
ID= ISID_20090303_011,
Name=b, Type=Boolean,
InitialValue=FALSE
Variable
Variable
ID= ISID_20090303_010,
Name=a, Type=Int,
InitialValue=9
ID= ISID_20090303_012,
Name=c, Type=Boolean,
InitialValue=TRUE
Intermediate State
Action 1
ID= ISID_20090303_003,
Init=FALSE, Current=TRUE,
Terminal =FALSE
ID= ISID_20090303_008, Init=FALSE,

Current=TRUE, Terminal =FALSE,
Formula=[a=TRUE], FiredEvent={e},
Time.Duration=12, Time.Delay=6,
SelectionDivergence
Transition 2
ID= ISID_20090303_004,
Guard.Boolean=b,
ConsumedEvents={e}
ID= ISID_20090303_009
Transition 3
ID=
ISID_20090303_006,
Guard.Boolean=c,
ConsumedEvents={e}
Terminal State
JumpInitialState
ID= ISID_20090303_005, Init=

FALSE, Current=FALSE,
Terminal = TRUE
ID= ISID_20090303_007,
State=InitialState
Figure 82: Example IML system

The resulting PLCopen XML document is given below as XML content.
<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.plcopen.org/xml/tc6.xsd">
<fileHeader companyName="AutomationML"
companyURL="www.automationml.org" productName=""
productVersion="" productRelease=""
creationDateTime="2009-03-03T16:10:00" contentDescription="" />
<contentHeader name="IML_Beispiel" version="00001"
modificationDateTime="2010-04-30T09:00:00">
</contentHeader>
<types>
<dataTypes />
<pous>
<pou name="IML_Beispiel " globalID=" ISID_20090303_000" pouType="program">
<interface>
<localVars>
<variable globalID=" ISID_20090303_013" name="e">
<type>
<derived name=event/>
</type>
</variable>
<variable globalID=" ISID_20090303_010" name="a">
<type>
<INT/>
</type>
<initialValue>
<simpleValue value="9" />
</initialValue>
</variable>
<variable globalID=" ISID_20090303_011" name="b">
<type>
149

<BOOL/>
</type>
<initialValue>
<simpleValue value="False" />
</initialValue>
</variable>
<variable globalID=" ISID_20090303_012" name="c">
<type>
<BOOL/>
</type>
<initialValue>
<simpleValue value="True" />
</initialValue>
</variable>
<localVars>
<interface>
<actions>
<action globalId="ISID_20090303_008" name="Action1">
<body>
<ST>
xml:space="preserve" wsName="Action1">
(*FiredEvents*)
<br />
e:=True;
<br />
<br />
a=True;
<br />
</div>
</html>
</ST>
</body>
</action>
</actions>
<transitions>
<body>
<ST>
xml:space="preserve" id="MWTDESCRIPTION" wsName=" ISID_20090303_002">
IF (2 <= a AND a <= 17)
<br />
THEN Transition1:=True;
<br />
ELSE Transition1:=False;
<br />
END_IF
</div>
</html>
</ST>
</body>
</transition>
<body>
<ST>
IF (b AND e)
<br />
<br />
e=False;
<br />
150

<br />
END_IF
</div>
</html>
</ST>
</body>
</transition>
<body>
<ST>
IF (c AND e)
<br />
<br />
e=False;
<br />
<br />
END_IF
</div>
</html>
</ST>
</body>
</transition>
</transitions>
<body>
<SFC>
<actionBlock>
<connectionPointIn>
<connection refLocalId="3"/>
<action localId="8" globalId="ISID_20090303_008" qualifier="SD" duration="12">
<reference name="Action1" />
<addData>
<AutomationML>
<Time>
<Delay>
6
</Delay>
</Time>
<ActionStatus>
current
</ActionStatus>
</AutomationML>
</data>
</addData>
</action>
</actionBlock>
<step initialStep="true" localId="1" globalId="ISID_20090303_001" name="Initial State"/>
<transition localId="2" globalId="ISID_20090303_002" >
<connectionPointIn>
<condition>
</condition>
</transition>
<step initialStep="false" localId="3" globalId="ISID_20090303_003" name="Intermediate State">
<addData>
<AutomationML>
<StateStatus>
current
</StateStatus>
</AutomationML>
151

</data>
</addData>
<connectionPointIn>
</step>
<selectionDivergence localId="9" globalId="ISID_20090303_009">
<connectionPointIn>
<connection refLocalId="3"/>
<connectionPointIn>
<condition>
</condition>
</transition>
<connectionPointIn>
<condition>
</condition>
</transition>
<step initialStep="false" localId="5" globalId="ISID_20090303_005" name="Terminal State">
<addData>
<AutomationML>
<StateStatus>
terminal
</StateStatus>
</AutomationML>
</data>
</addData>
<connectionPointIn>
</step>
<jumpStep localId="7" globalId="ISID_20090303_007" targetName="Initial State">
<connectionPointIn>
</jumpStep >
</SFC>
</body>
</pou>
</pous>
</types>
<instances/>
</project>
152

1417686916-AutomationML Whitepaper Part 4 - AutomationML Logic Description v2 - Aug2013

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1417686916-AutomationML Whitepaper Part 4 - AutomationML Logic Description v2 - Aug2013

Uploaded by

Copyright:

Available Formats

Whitepaper AutomationML

Part 4 AutomationML Logic

Part 4 - AutomationML Logic Description

Whitepaper AutomationML Part 1 AutomationML Architecture, May 2010.

Whitepaper AutomationML Part 2 AutomationML Libraries, May 2010

Pirsch, M.: AutomationML Editor User Guideline, May 2010

Pirsch, M.: AutomationML Engine User Guideline, May 2010

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Complex Logic as Interlocking Condition ............................................................................. 140

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Part 4 - AutomationML Logic Description

Logic Descriptions in Automation Engineering

AutomationML (Automation Markup Language) is a neutral and XML-schema-based data format

Description of behaviour of AutomationML objects as a given (uncontrolled) model of reaction of a

Description of sequencing as required controlled behaviour of a system or part, which often

Gantt charts typically used during the first planning phases

PERT charts used in a similar way with complex timing conditions

Impulse diagrams to describe sequences in detail and to introduce real signals

State charts to describe internal behaviour in detail

Storing Logic Descriptions within AutomationML

Part 4 - AutomationML Logic Description

Mapping rules for

Figure 1: Transformation to PLCopen XML

Interlocking Description in Automation Engineering

the causes of an interlocking condition and

the resulting effects of an interlocking condition.

Part 4 - AutomationML Logic Description

Structure of this Document

References to other Documents

Part 4 - AutomationML Logic Description

Sequencing and Behaviour Models in AutomationML

Description of behaviour of AutomationML objects as a given uncontrolled model of reaction of a

Description of sequencing as required controlled behaviour of a system or part, which often

Figure 2: Types of logic descriptions in AutomationML

Part 4 - AutomationML Logic Description

State charts are used to describe behaviour of mechatronical units.

bars with start and end point of time as well as duration,

ordering relations representing a predecessor-successor-relation between bars.

Name Prede- Start Dura- End

Figure 3: Example of a Gantt chart

Part 4 - AutomationML Logic Description

Ordering relations representing a predecessor-successor-relation between nodes

Move to end of 110HTR002

Move to Lift Position

Figure 4: Example of a PERT chart

Part 4 - AutomationML Logic Description

Resources can be organized within groups representing hierarchies of mechatronical unit.

Resource State Flow

Figure 5: Example of an Impulse diagram with naming conventions

Figure 6: Signals in Impulse diagrams

Part 4 - AutomationML Logic Description

Two types of timing information have to be considered and illustrated in Figure 7:

Figure 7: Timing information within Impulse diagrams

Names of groups (in a hierarchy),

Names of resource state changes,

Names of signal inputs associated to resource states,