Part 4 Description State: May 2010 - Automationml.org · 1.3 Interlocking Description in Automation...
Transcript of Part 4 Description State: May 2010 - Automationml.org · 1.3 Interlocking Description in Automation...
Whitepaper AutomationML
Part 4 – AutomationML Logic Description
State: May 2010
Part 4 - AutomationML Logic Description
2
© 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
Part 4 - AutomationML Logic Description
3
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
Part 4 - AutomationML Logic Description
4
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
Part 4 - AutomationML Logic Description
5
5.4.1 Overview ................................................................................................................... 97
5.5 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
Part 4 - AutomationML Logic Description
6
7.4 Complex Logic as Interlocking Condition ............................................................................. 140
7.5 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
Part 4 - AutomationML Logic Description
7
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
Part 4 - AutomationML Logic Description
8
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
Part 4 - AutomationML Logic Description
9
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
Part 4 - AutomationML Logic Description
10
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
Part 4 - AutomationML Logic Description
11
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
Part 4 - AutomationML Logic Description
12
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.
Part 4 - AutomationML Logic Description
13
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.
Intermediate
Modeling LayerPLCopen XML
XML Set of model
elementsSpecific models and charts
(Propriety data format)
Mapping rules for
transformation of
IML elements to
XML structures
Mapping Rules based
on transformation of
Model elements
Gantt chart
Impulse diagram
PERT chart
...
Part 4 - AutomationML Logic Description
14
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].
Part 4 - AutomationML Logic Description
15
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.
Figure 2: Types of logic descriptions in AutomationML
AutomationML Objects with Logic Description
Project
Device
sequencing
behavior
sequencing/behavior
Mechatronical Units with:
Reference
Robot
Gripper
Station
Behavior
Sequencing
Sequencing
Behavior
Part 4 - AutomationML Logic Description
16
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.
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
Id Name
1 Handover to HTR002 0 4 4
2 Move to Lift Position 1 4 3 7
3 Lift skid 2 7 2 9
4 Lower skid 7 23 4 27
5 Move to end of 110HTR002 4 27 7 34
6 Initialise Robot 1 0 6 6
7 Execute Manufacturing Robot 1 3, 6 9 9 18
8 Postprocess Robot 1 7 18 4 22
9 Initialise Robot 2 6 6 4 10
10 Execute Manufacturing Robot 2 7, 9 18 5 23
11 Postprocess Robot 2 10 23 3 26
Sequence 2
Prede-
cessor
Start
time
End
time
Dura-
tion0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85
Part 4 - AutomationML Logic Description
17
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.
Figure 4: Example of a PERT chart
4 4
1 1 5
0
Handover to HTR002
3 7
5 1 9
4
Move to Lift Position
2 9
9 1 12
7
Lift Skid
4 26
31 1 36
23
Lower skid
7 34
36 2 45
27
Move to end of 110HTR002
6 6
4 2 12
0
Initialse Robot 1
9 18
12 3 24
9
Execute Manufacturing
Robot 1
4 22
24 2 30
18
Postprocess Robot 1
4 10
18 2 24
6
Initialse Robot 2
5 23
24 2 31
18
Execute Manufacturing
Robot 2
3 26
31 1 35
23
Postprocess Robot 2
Part 4 - AutomationML Logic Description
18
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).
Figure 5: Example of an Impulse diagram with naming conventions
Figure 6: Signals in Impulse diagrams
Device 2
Pos1
Low
High
Pos3
Pos2
0 5 10
Resource State Flow Resource
Timeline
Signal
Resource
State
Resource
State Change
StateResource
Device 1
Pos1
Pos3
Pos2
0
Resource 1
Resource 2
Resource 3
Resource 4
Resource 5
A A
BC
D
B
E
E
5 10 15
Pos1
Pos2
Pos1
Pos2
Pos1
Pos2
Pos1
Pos2
StateResource
&
F
Part 4 - AutomationML Logic Description
19
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)”
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:
o Remaining within a resource state,
o Resource state changes.
2.5 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.
Pos2
Device 1
Pos1t
std
td1 tdntd3td2
StateResource
Part 4 - AutomationML Logic Description
20
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
o as long until it is directly switched of
o for a certain amount of time
o after a certain amount of time
An example of an SFC is depicted in Figure 8.
Part 4 - AutomationML Logic Description
21
Figure 8: Example of a SFC in IEC 61131-3
2.6 State Charts
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.
S1
T1
N A1
S2
T2
D 20
A3
D 17
A2
S3 S4 L 25
A4
SD 0
A5
T7
S1
T3 T4
S7
S5
T5
L 10
A6 S6
T6
L 15
A7
SD 5
LatestStart._A5
SL 10
EarliestEnd._A5
SL 15
LatestEnd._A5
N A8
D 5
Delay._A7
S1
T017
Simultaneous Divergence
Selection Convergence
Selection Divergence
Simultaneous Convergence
Step
Activity
Transition
Part 4 - AutomationML Logic Description
22
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.
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.
State 1
State 1.1
Event 1 / [Guard 1]
State 1.2
Event 2State 1.3
Event 3 / [Guard 3]
State 1.3
Event 2
State 2
State 3
Entrance Activity 2
Activity 3
Exit Activity 4
Event 4 / [Guard 5]
Guard 2 / Activity 1
HEvent 4 / [Guard 4]
Event 5
Event 6
[Guard 6]
C
[Guard 6.1]
[Guard 6.2]
Part 4 - AutomationML Logic Description
23
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.
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.
StateTransition st
st.ID
st.Name
st.Guard
Activity a
a.ID
a.Name
a.Init
a.Current
a.Terminal
a.Time
a.Formula
SelectionDivergence selDiv
simDiv.ID
Event ev
ev.Name
SimultaneousConvergence simCon
simCon.ID
Variable var
var.ID
var.Name
var.Type
Var.Content
var.SIUnit
var.InitialValue
var.Address
Comment com
com.Content
j.State
st.Pre
All entities
s.Pre
s.Pre
st.Pre
s.Pre
State s
s.ID
s.Name
s.Init
s.Current
s.Terminal
st.Guard.
ConsumedEvents
st.Guard.Boolean
st.Pre
a.Pre
a.FiredEvents
j.Pre
j.Pre
j.Pre
selDiv.Pre
simDiv.Pre
simCon.Pre
simCon.Pre
com.Pre
Header h
h.ID
h.Name
h.Members
addData ad
ad.ID
ad.Type
ad.Name
ad.Pre
Jump j
j.ID
SelectionConvergence selCon
selCon.ID
SimultaneousDivergence simDiv
simDiv.ID
Part 4 - AutomationML Logic Description
24
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.
Intermediate StateID= ISID_20090303_003,
Init=FALSE, Current=TRUE,
Terminal =FALSE
Terminal StateID= ISID_20090303_005, Init=
FALSE, Current=FALSE,
Terminal = TRUE
Action 1ID= ISID_20090303_008, Init=FALSE,
Current=TRUE, Terminal =FALSE,
Formula=[a=TRUE], FiredEvent={e},
Time.Duration=12, Time.Delay=6,
Initial StateInitial StateID= ISID_20090303_001,
Init=TRUE, Current=FALSE,
Terminal =FALSE
Initial StateInitial StateID= ISID_20090303_001,
Init=TRUE, Current=FALSE,
Terminal =FALSE
Transition 1ID= ISID_20090303_002,
Guard.Var=a,[2;17],
Transition 2ID= ISID_20090303_004,
Guard.Boolean=b,
ConsumedEvents={e}
JumpInitialStateID= ISID_20090303_007,
State=InitialState
Transition 3ID=
ISID_20090303_006,
Guard.Boolean=c,
ConsumedEvents={e}
SelectionDivergenceID= ISID_20090303_009
Event ID=ISID_20090303_013
Name=e
Variable ID= ISID_20090303_010,
Name=a, Type=Int,
InitialValue=9
Variable ID= ISID_20090303_011,
Name=b, Type=Boolean,
InitialValue=FALSE
Variable ID= ISID_20090303_012,
Name=c, Type=Boolean,
InitialValue=TRUE
Part 4 - AutomationML Logic Description
25
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. h.Members represents the set of member elements of the IML system.
3.3.2 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.
Part 4 - AutomationML Logic Description
26
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.
Part 4 - AutomationML Logic Description
27
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.
Part 4 - AutomationML Logic Description
28
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.
Part 4 - AutomationML Logic Description
29
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 Additional Data
4.2.1 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.
Part 4 - AutomationML Logic Description
30
Element AutomationML
diagram
properties content complex
children 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
Part 4 - AutomationML Logic Description
31
Element AutomationML/Time
diagram
type aml:TimeInfoType
properties isRef 0
minOcc 0
maxOcc 1
content complex
children aml:Duration aml:EarliestStart aml:LatestStart aml:EarliestEnd aml:LatestEnd aml:Delay
Table 2: <Time> element
Element AutomationML/Time/Duration
diagram
type xs:decimal
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 3: <Duration> element
Element AutomationML/Time/EarliestStart
diagram
type xs:decimal
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 4: <EarliestStart> element
Part 4 - AutomationML Logic Description
32
Element AutomationML/Time/LatestStart
diagram
type xs:decimal
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 5: <LatestStart> element
Element AutomationML/Time/EarliestEnd
diagram
type xs:decimal
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 6: <EarliestEnd> element
Element AutomationML/Time/LatestEnd
diagram
type xs:decimal
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 7: <Latest> element
Element AutomationML/Time/Delay
diagram
type xs:decimal
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 8: <Delay> element
Part 4 - AutomationML Logic Description
33
Element AutomationML/ChartType
diagram
type restriction of xs:string
properties isRef 0
minOcc 0
maxOcc 1
content simple
facets enumeration stateChart
enumeration impulseDiagram
enumeration ganttChart
enumeration pertChart
enumeration sequentialFunctionChart
Table 9: <ChartType> element
Element AutomationML/ResourceStateChangeDefinition
diagram
properties isRef 0
minOcc 0
maxOcc unbounded
content complex
children aml:DefinitionName aml:Duration
Table 10: <ResourceStateChangeDefinition> element
Element AutomationML/ResourceStateChangeDefinition/DefinitionName
diagram
type xs:string
properties isRef 0
content simple
Table 11: <DefinitionName> element
Element AutomationML/ResourceStateChangeDefinition/Duration
diagram
type xs:decimal
properties isRef 0
content simple
Table 12: <Durationn> element
Part 4 - AutomationML Logic Description
34
Element AutomationML/InterruptableAction
diagram
type xs:boolean
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 13: <InteruptableAction> element
Element AutomationML/StateChartSubCharts
diagram
properties isRef 0
minOcc 0
maxOcc 1
content complex
children aml:POURef
Table 14: <StateChartSubCharts> element
Element AutomationML/StateChartSubCharts/POURef
diagram
properties isRef 0
minOcc 1
maxOcc unbounded
Table 15: <POURef> element
Part 4 - AutomationML Logic Description
35
Element AutomationML/StateChartStateType
diagram
type restriction of xs:string
properties isRef 0
minOcc 0
maxOcc 1
content simple
facets enumeration higherLevelState
enumeration historyConnector
enumeration conditionConnector
enumeration stateForActivity
Table 16: <StateChartStateType> Element
Element AutomationML/StateChartActionType
diagram
type restriction of xs:string
properties isRef 0
minOcc 0
maxOcc 1
content simple
facets enumeration entryAction
enumeration doAction
enumeration extitAction
Table 17: <StateChartActionType> Element
Element AutomationML/ImpluseDiagramResorceGroup
diagram
type xs:string
properties isRef 0
minOcc 0
maxOcc 1
content simple
Table 18: <ImpulseChartResourceGroup> element
Part 4 - AutomationML Logic Description
36
Element AutomationML/ImpulseDiagramPLCVariable
diagram
properties isRef 0
minOcc 0
maxOcc 1
content complex
children aml:Name aml:DataType aml:Address
Table 19: <ImpulseDiagramPLCVariable> element
Element AutomationML/ImpulseDiagramPLCVariable/Name
diagram
properties isRef 0
Table 20: <Name> element
Element AutomationML/ImpulseDiagramPLCVariable/DataType
diagram
properties isRef 0
minOcc 0
maxOcc 1
Table 21: <Datatype> element
Element AutomationML/ImpulseDiagramPLCVariable/Address
diagram
properties isRef 0
minOcc 0
maxOcc 1
Table 22: <Address> element
Part 4 - AutomationML Logic Description
37
Element AutomationML/StateStatus
diagram
type restriction of xs:string
properties isRef 0
minOcc 0
maxOcc 2
content simple
facets enumeration initial
enumeration current
enumeration terminal
Table 23: <StateStatus> element
Element AutomationML/ActionStatus
diagram
type restriction of xs:string
properties isRef 0
minOcc 0
maxOcc 2
content simple
facets 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.
Part 4 - AutomationML Logic Description
38
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 Mapping of IML to PLCopen XML
4.3.1 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.
Part 4 - AutomationML Logic Description
39
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.
Part 4 - AutomationML Logic Description
40
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
h <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.
interface part of an POU
transition part of an POU
action part of an POU
SFC part of an POU
Part 4 - AutomationML Logic Description
41
IML Example Resulting PLCopen XML h
<pou pouType="program" globalID="ISID_20090303_000" name="ExampleIML"> … </pou>
h.ID= ISID_20090303_000
h.Name= ExampleIML
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
Representation in PLCopen XML
s <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”>
s.Current
If the value of s.Current is true, the mapping shall be done as
follows
<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.
s.Terminal
If the value of s.Terminal is true then the mapping shall be done
as follows
<step> <addData> <data name=”http://www.automationML.org/AML_addData.xsd”> <AutomationML> <StateStatus> terminal </StateStatus> </AutomationML> </data> </addData> </step>
If the value of s.Terminal is false, no mapping shall be done.
Part 4 - AutomationML Logic Description
42
Recommendation: Multiple vendor specific information can merged into one addData element.
s.Pre
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>
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 Resulting PLCopen XML s <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" /> </connectionPointIn> </step>
s.ID = ISID_20090303_003
s.Name =
IntermediateState
s.Init = false
s.Current = true
s.Terminal = false
s.Pre =
{ISID_20090303_002}
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
o the globalId parameter of <transition> within the <SFC> element of the <pou>
element
o and globalId parameter of <transition> element within the <transitions>
element of the <pou> element.
st.Name is mapped to
o the name attribute of the <reference> element within the conditions part of
<transition> of the <SFC> part of the <pou> element.
o 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.
Part 4 - AutomationML Logic Description
43
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 element’s 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
Representation in PLCopen XML
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>
st.Guard
IF the Guard element contains st.Guard.Boolean and
st.Guard.ConsumedEvent is the set {e1, …, en} then
<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 />
Part 4 - AutomationML Logic Description
44
ELSE st.Name:=FALSE;
<br /> END_IF; <br /> </div> </html> </ST> </body> </transition>
If the Guard element contains st.Guard.Value and
st.Guard.ConsumedEvent is the set {e1, …, en} then
<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.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 /> ELSE st.Name:=FALSE;
<br /> END_IF; <br /> </div> </html> </ST> </body> </transition>
If the Guard element contains st.Guard.Formula and
st.Guard.ConsumedEvent is the set {e1, …, en} then
<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.Formula AND e1 AND … en)
<br />
THEN st.Name:=TRUE;
<br /> e1:=False; <br /> …
Part 4 - AutomationML Logic Description
45
<br /> en:=False; <br />
ELSE st.Name:=FALSE;
<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.
st.Pre
For each element el with local ID el.x of st.Pre one
connectionPointIn element will be created as follows:
<sfc> <transition> <connectionPointIn>
<connection refLocalId=" el.x " />
</connectionPointIn> </transition > </sfc>
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 Resulting PLCopen XML st <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
st.ID =
ISID_20090303_006
st.Name = Transition3
st.Guard.Boolean = “c”
st.Guard.ConsumedEvents
= “e”
st.Pre =
{ISID_20090303_009}
Part 4 - AutomationML Logic Description
46
<br /> </div> </html> </ST> </body> </transition> </transitions> <body> <SFC> <transition localId="6" globalId="ISID_20090303_006"> <condition> <reference name="Transition3" /> </condition> <connectionPointIn> <connection refLocalId="9" /> </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.
Part 4 - AutomationML Logic Description
47
IML element, property, and relation
Representation in PLCopen XML
a
<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>
a.Init
If the value of a.Init is true then the mapping is done as follows
<SFC> <actionBlock> <action> <addData> <data name=”http://www.automationML.org/AML_addData.xsd”> <AutomationML> <ActionStatus> init </ActionStatus> </AutomationML> </data> </addData> <action> </actionBlock> </SFC>
If the value of a.Init is false, no mapping shall be done.
Recommendation: Multiple vendor specific information can merged into one addData element.
Part 4 - AutomationML Logic Description
48
a.Current
If the value of a.Current is true then the mapping is done as
follows
<SFC> <actionBlock> <action> <addData> <data name=”http://www.automationML.org/AML_addData.xsd”> <AutomationML> <ActionStatus> current </ActionStatus> </AutomationML> </data> </addData> <action> </actionBlock> </SFC>
If the value of a.Current is false then no mapping is done
Recommendation: Multiple vendor specific information can merged into one addData element.
a.Terminal
If the value of a.Terminal is true then the mapping is done as
follows
<SFC> <actionBlock> <action> <addData> <data name=”http://www.automationML.org/AML_addData.xsd”> <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.
Recommendation: Multiple vendor specific information can merged into one addData element.
Part 4 - AutomationML Logic Description
49
a.Formula
If the a.formula element is empty and the a.firedEvents element
is empty then the mapping is made as follows
<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:
<actions> <action name="a.Name"> <body> <ST> <html xmlns="http://www.w3.org/1999/xhtml"> <div xmlns="http://www.w3.org/1999/xhtml" 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.
a.FiredEvent
a.Time
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> <data name=”http://www.automationML.org/AML_addData.xsd”> <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>
Part 4 - AutomationML Logic Description
50
<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> <data name=”http://www.automationML.org/AML_addData.xsd”> <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.
Recommendation: Multiple vendor specific information can merged into one addData element.
a.Pre
For each element el with local ID el.x of a.Pre one
connectionPointIn element will be created as follows:
<SFC> <actionBlock> <connectionPointIn>
<connection refLocalId="el.x" />
</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
Part 4 - AutomationML Logic Description
51
An example of the translation is given in Table 32.
IML Example Resulting PLCopen XML a <actions>
<action globalId="ISID_20090303_008" name="Action1"> <body> <ST> <html xmlns="http://www.w3.org/1999/xhtml"> <div xmlns="http://www.w3.org/1999/xhtml" xml:space="preserve" WsName="Action1"> (*FiredEvent*) <br /> e:=true; <br /> (*ChangedVariables*) <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> <data name="http://www.automationML.org/AML_addData.xsd"> <AutomationML> <ActionStatus> current </ActionStatus> <Time> <delay> 6 </delay> </Time> </AutomationML> </data> </addData> <connectionPointIn> <connection refLocalId="3" /> </connectionPointIn> </action> </actionBlock> </SFC> <body>
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
}
Table 32: Example transformation IML activity to PLCopen XML
Part 4 - AutomationML Logic Description
52
4.3.6 Mapping of Jumps and their Relations
An IML jump j with its relations shall be mapped to a PLCopen <jumpStep>.
The mapping is formally described in Table 33.
IML element, property and relation
Representation in PLCopen XML
j <jumpStep>
j.ID <jumpStep localId= ”someIDValue” globalId=”j.ID” >
Where someIDValue is a valid value for a local ID.
j.State <jumpStep targetName=j.State>
j.Pre
For each element el with local ID el.x of j.Pre one
connectionPointIn element will be created as follows:
<SFC> <jumpStep> <connectionPointIn>
<connection refLocalId="el.x " />
</connectionPointIn> </jumpStep > </SFC>
Note: For each element of j.Pre one connectionPointIn element
will be created.
Table 33: Mapping of IML jump to PLCopen XML
An example of the translation is given in Table 33.
IML Example Resulting PLCopen XML j <jumpStep localId="7" globalId="ISID_20090303_007"
targetName="InitialState"> <connectionPointIn> <connection refLocalId="6" /> </connectionPointIn> </jumpStep >
j.ID = ISID_20090303_007
j.State = “InitialState”
j.Pre =
{ISID_20090303_006}
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.
The selDiv.Pre relation is mapped to <connectionPointIn> sub objects of
<selectionDivergence>.
The element IDs in selDiv.Pre are stored within the localRefID parameter of connection objects.
The mapping is formally described in Table 35.
Part 4 - AutomationML Logic Description
53
IML element, property, and relation
Representation in PLCopen XML
selDiv <selectionDivergence>
selDiv.ID
<selectionDivergence localId= ”someIDValue”
globalId=”selDiv.ID”>
Where someIDValue is a valid value for a local ID.
selDiv.Pre
For each element el with local ID el.x of selDiv.Pre one
connectionPointIn element will be created as follows:
<SFC> <selectionDivergence> <connectionPointIn> <connection refLocalId="el.x" />
</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 Resulting PLCopen XML selDiv
<selectionDivergence localId="9 " globalId="ISID_20090303_009"> <connectionPointIn> <connection refLocalId="3" /> </connectionPointIn> </selectionDivergence>
selDiv.ID =
ISID_20090303_009
selDiv.Pre =
{ISID_20090303_003}
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.
The simDiv.Pre relation is mapped to <connectionPointIn> sub objects of
<simultaneousDivergence>.
The element IDs in simDiv.Pre are stored within the localRefID parameter of connection objects.
The mapping is formally described in Table 37.
Part 4 - AutomationML Logic Description
54
IML element, property, and relation
Representation in PLCopen XML
simDiv <simultaneousDivergence>
simDiv.ID <simultaneous localId= ”someIDValue” globalId=”simDiv.ID”>
Where someIDValue is a valid value for a local ID.
simDiv.Pre
For each element el with local ID el.x of simDiv.Pre one
connectionPointIn element will be created as follows:
<SFC> <simultaneousDivergence> <connectionPointIn>
<connection refLocalId="el.x " />
</connectionPointIn> </simultaneousDivergence> </SFC>
Note: For each element of simDiv.Pre one connectionPointIn
element will be created.
Table 37: Mapping of IML simultaneous divergencies to PLCopen XML
An example of the translation is given in Table 38.
IML Example Resulting PLCopen XML
simDiv <simultaneousDivergence localId="19 " globalId="ISID_20090303_019"> <connectionPointIn> <connection refLocalId="39" /> </connectionPointIn> </simultaneousDivergence>
simDiv.ID =
ISID_20090303_019
simDiv.Pre =
{ISID_20090303018}
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.
The selCon.Pre relation is mapped to <connectionPointIn> sub objects of
<selectionConvergence>.
The element IDs in selCon.Pre are stored within the localRefID parameter of connection objects.
The mapping is formally described in Table 39.
Part 4 - AutomationML Logic Description
55
IML element, property, and relation
Representation in PLCopen XML
selCon <selectionConvergence>
selCon.ID
<selectionConvergence localId= ”someIDValue”
globalId=”selCon.ID”>
Where someIDValue is a valid value for a local ID.
selCon.Pre
For each element el with local ID el.x of selCon.Pre one
connectionPointIn element will be created as follows:
<SFC> <selectionConvergence> <connectionPointIn> <connection refLocalId="el.x " />
</connectionPointIn> </selectionConvergence> </SFC>
Note: For each element of selCon.Pre one connectionPointIn element will be created.
Table 39: Mapping of IML selection convergence to PLCopen XML
An example of the translation is given in Table 40.
IML Example Resulting PLCopen XML selCon
<selectionConvergence localId="20 " globalId="ISID_20090303_020"> <connectionPointIn> <connection refLocalId="57" /> </connectionPointIn> <connectionPointIn> <connection refLocalId="84" /> </connectionPointIn> </selectionConvergence>
selCon.ID =
ISID_20090303_20
selCon.Pre =
{ISID_200903030_57;
ISID_200903030_84}
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.
The simCon.Pre relation is mapped to <connectionPointIn> sub objects of
<simultaneousConvergence>.
The element IDs in simCon.Pre are stored within the localRefID parameter of connection objects.
The mapping is formally described in Table 41.
Part 4 - AutomationML Logic Description
56
IML element, property, and relation
Representation in PLCopen XML
simCon <simultaneousConvergence>
simCon.ID <simultaneous localId= ”someIDValue” globalId=”simCon.ID”>
Where someIDValue is a valid value for a local ID.
simCon.Pre
For each element el with local ID el.x of simCon.Pre one
connectionPointIn element will be created as follows:
<SFC> <simultaneousConvergence> <connectionPointIn>
<connection refLocalId="el.x " />
</connectionPointIn> </simultaneousConvergence> </SFC>
Note: For each element of simCon.Pre one connectionPointIn
element will be created.
Table 41: Mapping of IML simultaneous divergences to PLCopen XML
An example of the translation is given in Table 42.
IML Example Resulting PLCopen XML
simCon <simultaneousConvergence localId="21 " globalId="ISID_20090303_021"> <connectionPointIn> <connection refLocalId="29" /> </connectionPointIn> <connectionPointIn> <connection refLocalId="41" /> </connectionPointIn> </simultaneousConvergence>
simCon.ID
=ISID_20090303_021
simCon.Pre =
{ISID_20090303_029;
ISID_20090303_041}
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>.
The mapping is formally described in Table 43.
IML element, property, and relation
Representation in PLCopen XML
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
Part 4 - AutomationML Logic Description
57
An example of the translation is given in Table 44.
IML Example Resulting PLCopen XML ev <interface>
<localVars> <variable globalId="ISID_20090303_013" name="e"> <type> <derivied name="event"/> </type> </variable> </localVars> </interface>
ev.ID =
ISID_20090303_013
ev.Name = “e”
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.
The mapping is formally described in Table 45.
IML element, property, and relation
Representation in PLCopen XML
var <variable/>
var.ID <variable globalId=”var.ID”>
var.Name <variable name="var.Name" />
var.Type
<variable> <type> var.Type
</type> </variable>
var.initialValue
<variable > <initialValue>
<simpleValue value="var.InitialValue" />
</initialValue> </variable>
var.Address <variable address="var.Address"/>
Part 4 - AutomationML Logic Description
58
var.Content
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>
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
Part 4 - AutomationML Logic Description
59
An example of the translation is given in Table 46.
IML Example Resulting PLCopen XML var <interface>
<localVars> <variable globalId="ISID_20090303_010" name="a"> <type> <INT/> </type> <initialValue> <simpleValue value="9" /> </initialValue> </variable> </localVars> </interface>
var.ID =
ISID_20090303_010
var.Name = “a”
var.Type = INT
var.initialValue = 9
var.Address = empty
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.
The mapping is formally described in Table 47.
IML element, property, and relation
Representation in PLCopen XML
com <documentation>
com.Content
<documentation> <html xmlns="http://www.w3.org/1999/xhtml"> <p xmlns="http://www.w3.org/1999/ xhtml" xml:space="preserve"> com.Content <br/> </p> </html> </documentation>
com.Pre
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:
<SFC> <el globalId=”ID”> <documentation> … </documentation> </el> </SFC>
Table 47: Mapping of IML comment to PLCopen XML
Part 4 - AutomationML Logic Description
60
An example of the translation is given in Table 48.
IML Example Resulting PLCopen XML com <step globalId="ISID_20090303_001">
<documentation> <html xmlns="http://www.w3.org/1999/xhtml"> <div xmlns="http://www.w3.org/1999/xhtml" xml:space="preserve" wsName="Comment"> This is a test IML system. </div> </html> </documentation> <step/>
com.Content = “This is a
test IML system.”
com.Pre ={
ISID_20090303_001}
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.
The mapping is formally described in Table 49.
IML element, property, and relation
Representation in PLCopen XML
add <addData> add.ID For further use add.Type <addData>
<data name=”http://www.automationML.org/AML_addData.xsd”> <AutomationML> <add.Type> add.Value </add.Type> </AutomationML> </data> </addData>
Recommendation: Multiple vendor specific information can merged into one addData element.
add.Value
add.Pre
For each element el with global ID of add.Pre the mapping shall
be done as follows:
<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
Part 4 - AutomationML Logic Description
61
An example of the translation is given in Table 50.
IML Example Resulting PLCopen XML add <action globalId=”ISID_20090303_008”>
<addData> <data name="http://www.automationML.org/AML_addData.xsd"> <AutomationML> <ActionStatus> current </ActionStatus> </AutomationML> </data> </addData>
add.ID = n.a.
add.Type =
“ActionStatus”
add.Value = “current”
add.Pre=
{ISID_20090303_008}
Table 50: Example transformation IML addData to PLCopen XML
Part 4 - AutomationML Logic Description
62
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.
Figure 15: Actions of IML for Gantt- bar representation
Bar 1
t0 t1 t2
S_Bar 1
TA_Bar
DA_Bar 1
Condition for transition true:
step is deactivated
Part 4 - AutomationML Logic Description
63
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.
Figure 16: Example of the transformation of a Gantt diagram in SFC (IML)
0 4 6 7 9 10 18 22 23 26 27 34
Handover to HTR002
Move to Lift Position
Lift skid
Lower skid
Move to end of 110HTR002
Initialise Robot 1
Execute Manufacturing Robot 1
Postprocess Robot 1
Initialise Robot 2
Execute Manufacturing Robot 2
Postprocess Robot 2
Part 4 - AutomationML Logic Description
64
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.
S_Handover to HTR002
InitialStep_Gantt
D 0
SD 4
TRUE
DA_Handover to HTR002
TA_Handover to HTR002
TA_Handover to HTR002
S_Move to Lift PositionD 0
SD 3
DA_Move to Lift Position
TA_Move to Lift Position
TA_Move to Lift Position
S_Lift skid
D 0
SD 2
DA_Lift skid
TA_Lift skid
TA_Lift skid
S_InitialiseRobot1
D 0
SD 6
DA_InitialiseRobot1
TA_InitialiseRobot1
TA_InitialiseRobot1
S_InitialiseRobot2
D 0
SD 4
DA_InitialiseRobot2
TA_InitialiseRobot2
TA_InitialiseRobot2
S_ExecuteManufacturing
Robot1
D 0
SD 9
DA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturingRobot1
True
SyS_ExecuteManufacturing
Robot1_2
SyS_ExecuteManufacturing
Robot1_1
S_ExecuteManufacturing
Robot2
D 0
SD 5
DA_ExecuteManufacturing
Robot2
TA_ExecuteManufacturing
Robot2
TA_ExecuteManufacturingRobot2
True
SyS_ExecuteManufacturing
Robot2_2
SyS_ExecuteManufacturing
Robot2_1S_PostProcessRobot1
D 0
SD 4
DA_PostProcessRobot1
TA_PostProcessRobot1
TA_PostProcessRobot1
S_LowerSkid
D 0
SD 4
DA_LowerSkid
TA_LowerSkid
TA_LowerSkid
S_Move to end of 110HTR002
D 0
SD 7
DA_Move to end of
110HTR002
TA_Move to end of
110HTR002
TA_Move to end of
110HTR002
S_PostprocessRobot2
D 0
SD 3
DA_PostprocessRobot2
TA_PostprocessRobot2
TA_PostprocessRobot2
SyS_Terminal_1
SyS_Terminal_2
SyS_Terminal_3
TerminalStep
True
Part 4 - AutomationML Logic Description
65
5.1.2 Start of a Gantt Chart
Start of a Gantt Chart
IML Element Graphical IML representation as SFC
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
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
Table 51: Transformation of the start of a Gantt chart to IML elements
5.1.3 Bar
Bar
IML Element Graphical IML representation as SFC
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 state transition st with 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
Initial
Step
true
Initial
Step
true
Initial
Step
true
Initial
Step
true
Part 4 - AutomationML Logic Description
66
5.1.4 Bar Startpoint
Bar Startpoint
IML Element Graphical IML representation as SFC
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
Table 53: Transformation of Gantt chart bar start point to IML elements
5.1.5 Bar Endpoint
Bar Endpoint
IML Element Graphical IML representation as SFC
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
Table 54: Transformation of Gantt chart bar endpoint to IML elements
5.1.6 Successor Bar
Successor Bar
IML Element Graphical IML representation as SFC
Case A: (no or only one successor bar) Do nothing
Case A:
S_ “bar
name“
D t 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
S_ “bar
name“
D tx DA_“bar name“
SD t TA_“bar 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
S_ “bar
name“
D tx DA_“bar name“
SD ty TA_“bar name“
TA_“bar name“= 1
Part 4 - AutomationML Logic Description
67
Case B: (more than one successor bars) simultaneous divergence simDiv with simDiv.ID = <some ID> simDiv.Pre = st1.ID
Case B:
Table 55: Transformation of Gantt chart bar successor activities to IML
5.1.7 Predecessor Bar
Predecessor Bar
IML Element Graphical IML representation as SFC
Case A: (the only bar in diagram with no predecessorBars)
state s with: s.Pre = st.ID of the initial state transition
Case A:
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 the initial simultaneous divergence
Case B:
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:
S_ “bar
name“
D tx DA_“bar name“
SD ty TA_“bar name“
TA_“bar name“= 1
Initial
Step
true
D t1 DA_“bar name“
SD t2 TA_“bar name“
TA_“bar name“ = 1
S_ “bar
name“
Initial
Step
true
TA_“bar name“ = 1
D t1 DA_“bar name“
SD t2 TA_“bar name“
S_ “bar
name“
TA_“bar name“ = 1
D tx DA_xx
SD ty TA_xx
TA_xx = 1
D t1 DA_“bar name“
SD t2 TA_“bar name“
S_ “bar
name“
S_xx
Part 4 - AutomationML Logic Description
68
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:
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 s.Pre = st.ID of the predecessor state transition generated for the predecessor bar Note: For each predecessor step (if there is more than one) one synchronisation step is created. They shall be numbered to ensure unique naming. simultaneous convergence simCon with simCon.ID = <some ID> simCon.Pre = s.ID state transition st with st.ID = <some ID> st.Name = “SyT_” + bar name st.Guard.Boolean = TRUE st.Pre = simCon.ID
s.Pre = st.ID
Case E:
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 s.Pre = simDiv.ID of the predecessor simultaneous divergence generated for the predecessor bar Note: For each predecessor state (if there is more than one) one synchronization state is created. They shall be numbered to ensure unique naming. simultaneous convergence simCon with simCon.ID = <some ID> simCon.Pre = s2.ID
Case F:
TA_“bar name“ = 1
S_xxD tx DA_xx
SD ty TA_xx
TA_xx = 1
D t1 DA_“bar name“
SD t2 TA_“bar name“
S_ “bar
name“
S_xxD tx DA_xx
SD ty TA_xx
TA_xx = 1
SyS_
„bar
name“_i
TRUE
D t1 DA_“bar name“
SD t2 TA_“bar name“
S_ “bar
name“
S_xx
TA_“bar name“ = 1
D tx DA_xx
SD ty TA_xx
TA_xx = 1
SyS_
„bar
name“_i
TRUE
D t1 DA_“bar name“
SD t2 TA_“bar name“
S_ “bar
name“
Part 4 - AutomationML Logic Description
69
state transition st with st.ID = <some ID> st.Name = “SyT_” + bar name st.Guard.Boolean = TRUE 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 Graphical IML representation as SFC
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” st.Guard.Boolean = TRUE s.Pre = st.ID One simultaneous convergence for all synchronisation states: simultaneous convergence simCon with simCon.ID = <some ID> st.Pre = simCon.ID step s with s.ID = <some ID> s.Init = false s.Name = “SyS_Terminal”+”_” + i s.Pre = st.ID of the predecessor state transition generated for the predecessor bar simCon.Pre = {…, s.ID }
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
S_xx
Terminal
Step
D tx DA_xx
SD ty TA_xx
TA_xx = 1
SyS_
Terminal
_i
TRUE
Part 4 - AutomationML Logic Description
70
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.
Figure 18: Gantt translation example - activities without predecessor and successor relations
0 4 6 7 9
Handover to HTR002
Move to Lift Position
Lift skid
S_Handover to HTR002
InitialStep_Gantt
D 0
SD 4
TRUE
DA_Handover to HTR002
TA_Handover to HTR002
TA_Handover to HTR002
D 4
SD 7
DA_Move to Lift Position
TA_Move to Lift Position
TA_Move to Lift Position
S_Lift skidD 7
SD 9
DA_Lift skid
TA_Lift skid
TA_Lift skid
S_Move to Lift Position
SyS_Terminal_1SyS_Terminal_2 SyS_Terminal_3
TerminalStep
True
Part 4 - AutomationML Logic Description
71
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.
Figure 19: Gantt translation example – activity sequence
InitialStep_Gantt
D 0
SD 4
TRUE
DA_Handover to HTR002
TA_Handover to HTR002
TA_Handover to HTR002
S_Lift skid
D 7
SD 9
DA_Lift skid
TA_Lift skid
TA_Lift skid
TerminalStep
D 4
SD 7
DA_Move to Lift Position
TA_Move to Lift Position
TA_Move to Lift Position
S_Move to Lift Position
S_Handover to HTR002
0 4 6 7 9
Handover to HTR002
Move to Lift Position
Lift skid
Part 4 - AutomationML Logic Description
72
Example transformation of activity sequence with divergences
In this example a simultaneous divergence is introduced to describe multiple successors of one bar in IML.
Figure 20: Gantt translation example – activity sequence divagation
0 6 9 10 18
Initialise Robot 1
Execute Manufacturing Robot 1
Initialise Robot 2
InitialStep_Gantt
TRUE
S_InitialiseRobot1D 0
SD 6
DA_InitialiseRobot1
TA_InitialiseRobot1
TA_InitialiseRobot1
S_InitialiseRobot2
D 0
SD 4
DA_InitialiseRobot2
TA_InitialiseRobot2
TA_InitialiseRobot2
D 3
SD 12
DA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturingRobot1
SyS_Terminal_1
TerminalStep
True
S_ExecuteManufacturing
Robot1
SyS_Terminal_2
Part 4 - AutomationML Logic Description
73
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.
Figure 21: Gantt translation example – activity sequence convergence
InitialStep_Gantt
TRUE
S_InitialiseRobot1
D 0
SD 6
DA_InitialiseRobot1
TA_InitialiseRobot1
TA_InitialiseRobot1
D 0
SD 9
DA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturingRobot1
SyS_ExecuteManufacturing
Robot1_1
TerminalStep
S_ExecuteManufacturing
Robot1
TRUE
S_Lift skidD 7
SD 9
DA_Lift skid
TA_Lift skid
TA_Lift skid
SyS_ExecuteManufacturing
Robot1_1
0 6 7 9 10 18
Lift skid
Initialise Robot 1
Execute Manufacturing Robot 1
Part 4 - AutomationML Logic Description
74
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.
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.
DurationEarliest
end
Latest
startBuffer
Latest
end
Earliest
start
Node name
DurationEarliest
end
Latest
startBuffer
Latest
end
Earliest
start
Node name
Part 4 - AutomationML Logic Description
75
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.
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.
t0 t1 t1+t2
S_Note 1
TA_Note 1
DA_Note 1
Condition for transition true:
step is deactivated
t2 t3
t4 t5 t6
t1
Node 1
Part 4 - AutomationML Logic Description
76
5.2.2 Start of a PERT Chart
Start of a PERT chart
IML Element Graphical IML representation as SFC
step 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 = “Pert”
ad.Pre = s.ID
If more than one node with no predecessor nodes in the diagram additionally: simultaneous divergence simDiv with simDiv.ID = <some ID> simDiv.Pre = s.ID
Table 58: Transformation of a PERT node to IML elements
5.2.3 Node
Node
IML element Graphical IML representation as SFC
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 state transition st with st.ID = <some ID> st.Name = “T_” + node name st.Guard.Formular = “a2.name” st.Pre = s1.ID
Table 59: Transformation of PERT chart nodes to IML elements
Initial
Step
true
Initial
Step
true
Initial
Step
true
Initial
Step
true
S_ “node
name“
DA_“node name“
TA_“node name“
T_“node name“
Part 4 - AutomationML Logic Description
77
5.2.4 Node Earliest Startpoint
Node Earliest Startpoint
IML element Graphical IML representation as SFC
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
Table 60: Transformation of PERT chart node earliest startpoint to IML elements
5.2.5 Node Duration
Node Duration
IML Element SFC Representation
a.Time.Duration = Node.duration
Table 61: Transformation of PERT chart node duration to IML elements
5.2.6 Further Node Times
Further Node Times
IML element Graphical IML representation as SFC
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
Table 62: Transformation of PERT chart node duration to IML elements
S_
“node
name“
D t 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
S_
“node
name“
D tx DA_“node name“
SD t TA_“node name“
TA_“node name“= 1
t= Node.endpoint
S_
“node
name“
D t DA_“node name“
TA_“node name“
TA_“node name“= 1
Part 4 - AutomationML Logic Description
78
5.2.7 Successor Nodes
Successor Node
IML element Graphical IML representation as SFC
Case A: (no or only one successor node) Do nothing
Case A:
Case B: (more than one successor node) simultaneous divergence simDiv with simDiv.ID = <some ID> simDiv.Pre = st1.ID
Case B:
Table 63: Transformation of PERT diagram activity successor activity to IML
5.2.8 Predecessor Nodes
Predecessor Node
IML Element Graphical IML representation as SFC
Case A: (the only node in diagram with no predecessor node) s.Pre = st.ID of the initial state transition
Case A:
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:
S_
“node
name“
D tx DA_“node name“
SD ty TA_“node name“
TA_“node name“= 1
S_
“node
name“
D tx DA_“node name“
SD ty TA_“node name“
TA_“node name“= 1
Initial
Step
true
D t1 DA_“node name“
SD t2 TA_“node name“
TA_“node name“ = 1
S_
“node
name“
Initial
Step
true
D t1 DA_“node name“
SD t2 TA_“node name“
TA_“node name“ = 1
S_
“node
name“
Part 4 - AutomationML Logic Description
79
Case C: (only one predecessor node and no other activity with the same predecessor node) s.Pre = st.ID of the predecessor state transition generated for the predecessor node
Case C:
Case D: (only one predecessorNode and this predecessorNode has more than one successorNodes) s.Pre = simDiv.ID of the predecessor simultaneous divergence generated for the predecessor node
Case D:
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 s.Pre = st.ID of the predecessor state transition generated for the predecessor mode Note: If there are more than one predecessor states for each one synchronization state is created. They shall be numbered to ensure unique naming. simultaneous convergence simCon with simCon.ID = <some ID> simCon.Pre = s.ID state transition st with st.ID = <some ID> st.Name = “SyT_” + Nodename st.Guard.Boolean = TRUE st.Pre = simCon.ID s.Pre = st.ID
Case E:
S_xxD tx DA_xx
SD ty TA_xx
TA_xx = 1
D t1 DA_“node name“
SD t2 TA_“node name“
TA_“node name“ = 1
S_
“node
name“
S_xxD tx DA_xx
SD ty TA_xx
TA_xx = 1
D t1 DA_“node name“
SD t2 TA_“node name“
TA_“node name“ = 1
S_
“node
name“
S_xxD tx DA_xx
SD ty TA_xx
TA_xx = 1
SyS_
„node
name“_i
TRUE
D t1 DA_“node name“
SD t2 TA_“node name“
TA_“node name“ = 1
S_
“node
name“
Part 4 - AutomationML Logic Description
80
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 s.Pre = simDiv.ID of the predecessor simultaneous divergence generated for the predecessor node Note: If there are more than one predecessor states, for each of them one synchronization state is created. They shall be numbered to ensure unique naming. simultaneous convergence simCon with simCon.ID = <some ID> simCon.Pre = s2.ID state transition st with st.ID = <some ID> st.Name = “SyT_” + Nodename st.Guard.Boolean = TRUE st.Pre = simCon.ID s.Pre = st.ID
Case F:
Table 64: Transformation of a PERT diagram predecessor activity to IML elements
S_xxD tx DA_xx
SD ty TA_xx
TA_xx = 1
SyS_
„node
name“_i
TRUE
D t1 DA_“node name“
SD t2 TA_“node name“
TA_“node name“ = 1
S_
“node
name“
Part 4 - AutomationML Logic Description
81
5.2.9 End of a PERT Chart
End of a PERT Chart
IML Element Graphical IML representation as SFC
Terminal state states s with s.ID = <some ID> s.Init = false s.Name = “TerminalStep”
One predecessor state transition for the terminal state state transition st with st.ID = <some ID> st.Name = “TerminalTransition” st.Guard.Boolean = TRUE s.Pre = st.ID
One simultaneous convergence for all synchronisation states: simultaneous convergence simCon with simCon.ID = <some ID> st.Pre = simCon.ID states s with s.ID = <some ID> s.Init = false s.Name = “SyS_Terminal” + i s.Pre = st.ID of the predecessor state transition generated for the predecessorNode simCon.Pre = {…, s.ID }
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
S_xx
Terminal
Step
D tx DA_xx
SD ty TA_xx
TA_xx = 1
SyS_
Terminal
_i
TRUE
Part 4 - AutomationML Logic Description
82
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.
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.
4 4
1 1 5
0
Handover to HTR002
3 7
5 1 9
4
Move to Lift Position
2 9
9 1 12
7
Lift Skid
4 26
31 1 36
23
Lower skid
7 34
36 2 45
27
Move to end of 110HTR002
6 6
4 2 12
0
Initialse Robot 1
9 18
12 3 24
9
Execute Manufacturing
Robot 1
4 22
24 2 30
18
Postprocess Robot 1
4 10
18 2 24
6
Initialse Robot 2
5 23
24 2 31
18
Execute Manufacturing
Robot 2
3 26
31 1 35
23
Postprocess Robot 2
Part 4 - AutomationML Logic Description
83
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.
S_Handover to HTR002
InitialStep
D 0
SD 4
TRUE
DA_Handover to HTR002
TA_Handover to HTR002
TA_Handover to HTR002
S_Move to Lift PositionD 0
SD 3
DA_Move to Lift Position
TA_Move to Lift Position
TA_Move to Lift Position
S_Lift skid
D 0
SD 2
DA_Lift skid
TA_Lift skid
TA_Lift skid
S_InitialiseRobot1
D 0
SD 6
DA_InitialiseRobot1
TA_InitialiseRobot1
TA_InitialiseRobot1
S_InitialiseRobot2
D 0
SD 4
DA_InitialiseRobot2
TA_InitialiseRobot2
TA_InitialiseRobot2
S_ExecuteManufacturing
Robot1
D 0
SD 9
DA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturing
Robot1
TA_ExecuteManufacturingRobot1
True
SyS_ExecuteManufacturing
Robot1_2
SyS_ExecuteManufacturing
Robot1_1
S_ExecuteManufacturing
Robot2
D 0
SD 5
DA_ExecuteManufacturing
Robot2
TA_ExecuteManufacturing
Robot2
TA_ExecuteManufacturingRobot2
True
SyS_ExecuteManufacturing
Robot2_2
SyS_ExecuteManufacturing
Robot2_1S_PostProcessRobot1
D 0
SD 4
DA_PostProcessRobot1
TA_PostProcessRobot1
TA_PostProcessRobot1
S_LowerSkid
D 0
SD 4
DA_LowerSkid
TA_LowerSkid
TA_LowerSkid
S_Move to end of 110HTR002
D 0
SD 7
DA_Move to end of
110HTR002
TA_Move to end of
110HTR002
TA_Move to end of
110HTR002
S_PostprocessRobot2
D 0
SD 3
DA_PostprocessRobot2
TA_PostprocessRobot2
TA_PostprocessRobot2
SyS_Terminal_1
SyS_Terminal_2
SyS_Terminal_3
TerminalStep
True
Part 4 - AutomationML Logic Description
84
5.3 Impulse Diagrams
5.3.1 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.
Figure 26: Impulse diagram example of transformation
Pos1
PosB
PosA
Pos3
Pos2
Signal_Time _0
Signal_
Device1_2
Signal_
Device1_1
Signal_
Device2_1
0 5 10
Signal_Time _1
Device1
Device2
StateResource
Uses Signal_Device1_1
Uses Signal_Device1_3
Uses Signal_Device1_4
Uses Signal_Device2_1
Part 4 - AutomationML Logic Description
85
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.
Int
Device1_1
Time_Step_0SD0 Signal_Time_0
D0 Device1_Pos2Device1_0
SD1 Signal_Device1_1
D0 Device1_Pos2_to_Pos1
Device2_0D0 Device2_PosA
SD2 Signal_Device2_1
D0 Device2_PosA_to_PosB
Terminal
Step
[Signal_Time_0 = TRUE]
Time_Step_1SD8 Signal_Time_1
[Signal_Time_1 = TRUE]
Device1_2D0 Device1_Pos1
Device1_3SD1 Signal_Device1_2
D0 Device1_Pos1_to_Pos2
Device1_4SD2 Signal_Device1_3
D0 Device1_Pos2_to_Pos3
Device1_5D0 Device1_Pos3
Device1_6SD1 Signal_Device1_4
D0 Device1_Pos3_to_Pos2
Device1_7D0 Device1_Pos2
[Signal_Time_0 = TRUE]
[Signal_Device1_1 = TRUE] [Signal_Device1_1 = TRUE]
Device2_1
[Signal_Device2_1 = TRUE]
Device2_2D0 Device2_PosB
[Signal_Device2_1 = TRUE]
[Signal_Device1_2 = TRUE]
[Signal_Device1_3 = TRUE]
[Signal_Time_1 = TRUE]
Time_Step_
END
[Signal_Device1_4 = TRUE]
[TRUE]
[Signal_Time_END = TRUE]
SD2 Signal_Time_END
Part 4 - AutomationML Logic Description
86
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.
Part 4 - AutomationML Logic Description
87
5.3.2 Start of an Impulse Diagram
Start of an Impulse Diagram
IML Element Graphical IML representation as SFC
state s with s.ID = <some ID> s.Name = “INIT” s.Init = true state transition st with st.ID = <some ID> st.Name = “InitialTransition” st.Guard.Formular = True st.Pre = 1 addData ad with ad.ID = <some ID> ad.Type = ChartType ad.Value = “ImpulseDiagram” ad.Pre = s.ID simultaneous divergence simDiv with simDiv.ID = <some ID> simDiv.Pre = st.ID
Start for the SFC representation of an Impulse Diagram
Table 66: Transformation of the start of Impulse Diagrams to IML elements
5.3.3 Timeline
Timeline
IML element Graphical IML representation as SFC
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 state transition st with st.ID = <some ID> st.Name = “T_” + a1.Name st.Guard.Boolean = a1.Name st.Pre = s1.ID 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
Structural representation of the timeline
INIT
TRUE
Time_Step_0
D0 Signal_Time_0
[ Signal_Time_0 = TRUE]
INIT
TRUE
„Time_Step_“ +
SN
D td „Signal_Time_“+ SN
[ „Signal_Time_“ + SN = TRUE]
Part 4 - AutomationML Logic Description
88
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 Graphical IML representation as SFC
For each resource one parallel branch is created in the SFC. This branch contains: 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 Note: The sequence of values for the resource is represented by the resource state flow.
Structural representation of an resource
Table 68: Transformation of resources to IML elements
5.3.5 Resource State
Resource State
IML element Graphical IML representation as SFC
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 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.
Structural representation of a resource state
Table 69: Transformation of resource states to IML elements
Resource
Name + “_0“
D0 Resource Name + “_“ + Inital Resource State Name
INIT
TRUE
Resource Name
+ „_“ +SN
SD td „Signal_“ + Resource Name + „_“ + SN
D 0 Resource Name + „_“ + Resource State Name
Part 4 - AutomationML Logic Description
89
5.3.6 Resource State Change
Resource State Change
IML element Graphical IML representation as SFC
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 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
Structural representation of a resource state change
Table 70: Transformation of resource state changes to IML elements
5.3.7 Resource State Flow
Resource State Flow
IML element Graphical IML representation as SFC
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 s.Pre = st.ID of the predecessor state transition within the resource state flow 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.
Structural representation of an resource state flow
Resource Name
+ „_“ +SN
SD td „Signal_“ + Resource Name + „_“ + SN
D 0 Resource Name+ „_“ + Origin Resource State Name + „_“ + Traget Resource State Name
D 0 Resource Name + „_“ + Resource State Name
[ „Signal_“ + Resource Name + „_“ + SN = TRUE]
SD td „Signal_“ + Resource Name + „_“ + SN
Resource Name + „_“
+SN
Part 4 - AutomationML Logic Description
90
Resource State Change
Each resource state change leads to: one state s with s.ID = <some ID> s.Name = RN + “_” + SN s.Init = false s.Pre = st.ID of the predecessor state transition within the resource state flow 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 Graphical IML representation as SFC
Time Signals activity a with a.ID = <some ID> a.Name = ”Signal_Time” + SN a.Time.Duration = std a.Pre = actual state within the Timeline Note: Activity a belongs to a state in the timeline. state transition st1 with st1.ID = <some ID> st1.Name = “T_Signal_Time” + SN st1.Guard.Boolean = a.name st1.Pre = state associates to a state transition st2 with st2.ID = <some ID> st2.Name = “T_Signal_Time” + SN st2.Guard.Boolean = a.name st2.Pre = s.ID of active state within the resource state flow where a change is triggered by the signal
Structural representation of time signals
D 0 Resource Name+ „_“ + Origin Resource State Name
+ „_“ + Traget Resource State Name
[ „Signal_“ + Resource Name + „_“ + SN = TRUE]
SD td „Signal_“ + Resource Name + „_“ + SN
Resource
Name + „_“
+SN
„Time_Step
_“ + SN
SD std „Signal_Time_“ +SN
[ „Signal_Time_“ + SN = TRUE]
.. ….
Resource
Name + “_“+ SN
[ „Signal _Time_“ + SN = TRUE]
D 0 Resource Name + „_“ + Resource State Name
Part 4 - AutomationML Logic Description
91
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 state transition st1 with st1.ID = <some ID> st1.Name = “T_”+ Resource Name + “_” + SN st1.Guard.Boolean = a.name st1.Pre = state associates to a.ID state transition st2 with st2.ID = <some ID> st2.Name = “T_”+ Resource Name + “_” + SN st2.Guard.Boolean = a.name 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
Structural representation of Signal between two Resource State Flows
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 state transition st with st.ID = <some ID> st.Name = “T_Signal_”+ Resource Name + “_” + SN st.Guard.Boolean = a.name st.Pre = state associated to a.ID
Structural representation of signals within a Resource State Flows
Table 72: Transformation of signals to IML elements
.. ….
Resource
Name m +
“_“
+ SN
.. …. D0 Ressource Name + „_“ + Ressource State Name
SD td „Signal_“+ Ressource Name n “_“ + SN
Resource
Name n + “_ “
+ SN
[ „Signal_“+ Ressource Name n “_“ + SN = TRUE]
[ „Signal_“+ Ressource Name n “_“ + SN = TRUE]
.. ….
[„Signal_“+ Ressource Name n “_“ + SN = TRUE]
Resource Name n + “_“
+ SN
.. …. Resource
Name n + “_“+ SN SD td „Signal_“+ Ressource Name n “_“ + SN
D0 Ressource Name + „_“ + Ressource State Name
Part 4 - AutomationML Logic Description
92
5.3.9 End of Impulse Diagram and Terminal Step
End of Impulse Diagram and Terminal Step
IML element Graphical IML representation as SFC
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 activity a with a.ID = <some ID> a.Name =”Signal_Time_END” a.Time.Duration = std a.Pre = s1.ID simultaneous convergence simCon with: simCon.ID = <some ID> simCon.Pre = [a.ID; ID of the last states in each resource state flow]
state transition st with st.ID = <some ID> st.Name = “TerminalTransition” 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
Structural representation of the end of an impulse diagram
Table 73: Transformation of Impulse Diagram end to IML elements
Time_Step
_n
SD .. ...
SD std Signal_Time_END ...
[...]
Time_Step_
END
[Signal_Time_END = TRUE]
Terminal
Step
Part 4 - AutomationML Logic Description
93
5.3.10 Impulse Diagram Details
IML element Graphical IML representation as SFC
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.ID = <some ID> addData.type = ResourceStateChangeDefinition.DefinionName addData.value = Name of the resource change addData.Pre = ID of associated activity
Durations of resource states and resource state changes Additional Data addData with: addData.ID = <some ID> 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 Additional Data addData with: addData.ID = <some ID> addData.type = ImpulseDiagramPLCVariable.Name addData.value = name of the Variable associated to the input addData.Pre = ID of associated activity
Names of actuator outputs associated to resource states Additional Data addData with: addData.ID = <some ID> addData.type = ImpulseDiagramPLCVariable.Name addData.value = name of the Variable associated to the output addData.Pre = ID of associated activity
Table 74: Transformation of Impulse Diagram details to IML elements
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.ID = <some ID>
addData.Type = ResourceStateChangeDefinition.DefinionName
addData.Value = some name
addData.Pre = ID of associated action
Duration = some duration
addData.ID = <some ID>
addData.Type = ResourceStateChangeDefinition.Duration
addData.Value = some duration
addData.Pre = ID of associated action
PLCopenVariable = Variablename
addData.ID = <some ID>
addData.Type = ImpulseDiagramPLCVariable.Name
addData.Value = Variablename
addData.Pre = ID of associated action
PLCopenVariable = Variablename
addData.ID = <some ID>
addData.Type = ImpulseDiagramPLCVariable.Name
addData.Value = Variablename
addData.Pre = ID of associated action
Part 4 - AutomationML Logic Description
94
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.
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.
[Signal_Motor1_1 = TRUE]
Motor1_
1
Fast_run
Slow_run
Signal_Motor1_1
1 2
D0 Motor1_Slow_run_to_Fast_run
Motor1
SD1 Signal_Motor1_1
D0 Motor1_Fast_run
StateResource
Motor1_
2
Init
Time_Step_1SD1 Signal_Time_1
Time_Step_0SD 0 Signal_Time_0
[Signal_Time_0 = TRUE]
D0 Motor1_Slow_run
[Signal_Time_1= TRUE]
Motor1_0
Init
Uses
Time_Signal_1
Motor1_1
Motor1_0
Motor1_2
Part 4 - AutomationML Logic Description
95
Example External Signals
The next example handles two external signals, which are fired with delay of three seconds.
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.
Init
0
TimeStep_1SD3 Signal_Time_1
Motor1
1
Signal_Time_1Signal_Time_0
Time_Step_0SD 0 Signal_Time_0
[Signal_Time_0 = TRUE]
[Signal_Time_1 = TRUE]
32StateResource
Fast_run
Slow_run
D0 Motor1_Slow_run
SD1 Signal_Motor1_1
[Signal_Time_0= TRUE]
D0 Motor1_Fast_run_to_Slow_run
Motor1_0
Init
Motor1_0 Motor1_3Motor1_2Motor1_1
Uses Signal_Motor1_1
[Signal_Motor1_1 = TRUE]
D0 Motor1_Fast_run
.. ….
[Signal_Time_1= TRUE]
Motor1_3D0 Motor1_Fast_run_to_Slow_run
Motor1_2
Motor1_1
Part 4 - AutomationML Logic Description
96
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.
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.
.. ….
[Signal_Motor1_1 = TRUE]
D0 Mortor1_Slow_run_to_Fast_run D0 Gripper1_Open_to_Close
SD1 Signal_Motor1_2
Motor1_
1
[Signal_Motor1_1 = TRUE]
D0 Mortor1_Slow_runMotor1_
0
[Signal_Time_0 = TRUE]
D0 Mortor1_Fast_runMotor1_
2
[...]
Gripper1
_0
D0 Gripper1_OpenSD0 Signal_Time_0
[Signal_Motor1_0 = TRUE]
Gripper1
_1
Init
Time_Step
_0
Motor1
Close
OpenGripper1
Signal_Motor1_1
0 1 2 ...StateResource
Fast_run
Slow_run
Gripper1_0
Gripper1_1
Motor1_2Motor1_1
Motor1_0
Part 4 - AutomationML Logic Description
97
5.4 State Charts
5.4.1 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.
Figure 31: State chart example
State 1
State 1.1
Event 1 / [Guard 1]
State 1.2
Event 2State 1.3
Event 3 / [Guard 3]
State 1.4
Event 2
State 2
State 3
Entrance Activity 2
Activity 3
Exit Activity 4
Event 4 / [Guard 5]
Guard 2 / Activity 1
HEvent 4 / [Guard 4]
Event 5
Event 6
[Guard 6]
C
[Guard 6.1]
[Guard 6.2]
Part 4 - AutomationML Logic Description
98
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.
Main Chart
Chart State 1 Region 1 Chart State 1 Region 2
InitialStep_StateChart
TRUE
State 1
State 2
State 3Event 5
Event 6
Guard 2 Guard 6
TransitionActivity1
N Activity 1
End of Activity 1Event 4 Guard 4 Event 4
Guard 5
InitialStep_State1_Region1
TRUE
State 1.1
Connector1
Guard 6.1 Guard 6.2
Guard 6
State 3
Event 1 Guard 1
State 1.2
Event 2
InitialStep_State1_Region2
TRUE
State 1.3
History1
Event 4
Guard 4
State 2
Event 3 Guard 3
State 1.4
Event 2 Event 5
Part 4 - AutomationML Logic Description
99
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 s’is 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 Flat State Charts
5.5.1 Headers
This clause defines the IML representation of a flat State chart.
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).
State Chart IML System
State 1
State 2
[Event 1][Event 2]
InitialStep_noName
State_State_2
State_State1
[TRUE]
[Event 1]
[Event 2]
Part 4 - AutomationML Logic Description
100
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
s.Init True if the state is a start state
False if the state is not a start state
s.Terminal True if the state is an end state
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.
Figure 35: Transformation of predecessor states to IML elements
State_1
State_3
State_nState_2
[Event 1]
[Event 3]
[Event n]
State Chart IML System
State_State_nState_State_1
[Event n][Event 2]
State_State_2
[Event 1]
... ...
State_State_3
Part 4 - AutomationML Logic Description
101
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.
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.
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).
State 1
[Event 1] [Event n]
State Chart IML System
[Event 2]
State_State_1
[Event n][Event 2][Event 1]
State_1 State_nState_2 ... State_State_nState_State_1 State_State_2 ...
entry/action1
do/action2
exit/action3
State_1
State_State_1 Action_action2_ofState_State_1N
Action_action1_ofState_State_1N
Action_action3_ofState_State_1N
Part 4 - AutomationML Logic Description
102
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.
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 set of events fired by a
a.Pre s.ID for the state s the do action belongs to
ad.ID <some ID>
ad.Type StateChartActionType
ad.Value doAction
ad.Pre s.ID
Table 80: Attribute values for a do action representation in IML
entry/action1
do/action2
exit/action3
State_1
State_State_1
Action_action1_ofState_State_1N
Action_action3_ofState_State_1N
Action_action2_ofState_State_1N
Part 4 - AutomationML Logic Description
103
Note: If a do action contains events, this shall be expressed in the FiredEvents and the Formula relations of the resulting action.
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.
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 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 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 relations of the resulting action.
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.
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).
entry/action1
do/action2
exit/action3
State_1
State_State_1 Action_action2_ofState_State_1N
Action_action1_ofState_State_1N
Action_action3_ofState_State_1N
entry/action1
do/action2
exit/action3
Event/action_ev
State_1
Variable with:Name = Action_action_ev
Type= derived
IML Event with:Name = Event_action_ev
Part 4 - AutomationML Logic Description
104
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.
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.
Figure 42: Transformation a states transition to an IML transition
State 1
State 3
Event [Condition]/signal1
Variable with:Name = Signal_signal1
Type= Boolean
State 1
State 3
Event [Condition]/signal1
State_State_1
Condition
State_State_3
Part 4 - AutomationML Logic Description
105
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 of Successors
Number of Predecessors
Action during Execution
Hierarchy Level
A 1 1 No 1
B 1 1 Yes 1
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 1
State 3
[Guard]
State_State_1
[Guard]
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 s2
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
Part 4 - AutomationML Logic Description
106
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.
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 Content of the state transition guard
st1.Pre
s1.ID if st1 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)
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
State_1
State_2
[Guard]/action1
State_State_1
[Guard]
[TRUE]
State_State_2
StateForActivity_
action1Action_action1_ofStateTransitionN
Part 4 - AutomationML Logic Description
107
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 set of events fired by a
a.Pre s.ID
Successor relations for the state transition with one predecessor: If st2 is the only predecessor state transition of the destination state s2
s2.Pre st2.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 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.
Part 4 - AutomationML Logic Description
108
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.
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.
State_2
State_2-1 State_2-2
SFC State_2
State_1InitialStep_noName
State_State_2-1
State_State_2-2
[True]
SFC State_Main
InitialStep_noName
State_State_1
State_State_2
[True]
Contains AddData
element with
refrence to SFC
State_2
Part 4 - AutomationML Logic Description
109
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.
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.
State_1
HHistory_State1
State_2 State_3
State_State_2
State_State_3
SFC State_1
Part 4 - AutomationML Logic Description
110
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
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 90: 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. 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.
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).
SFC State_1State_1
cState_4
State_3
State_2
State_State_4
State_State_3State_State_2
Condition_ID_
State_1
Part 4 - AutomationML Logic Description
111
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
Note: Regarding its successor and predecessor relations the history connector shall be treated like a 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.
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
A 1 1 Higher Level No 1
B 1 1 Higher Level Yes 1
C 1 1 Lower Level No 1
D 1 1 Lower Level Yes 1
Table 92: Distinction of cases for the mapping of state transitions in hierarchical State charts
SFC State_2
Proxy_State_1
State_State_2-1
State_State_2-2
SFC State_Main
InitialStep_noName
State_State_1
State_State_2
[True]
State_2
State_2-2 State_2-1
State_1
[Guard]
[Guard]
[Guard]
Contains AddData
element with
refrence to SFC
State_2
Part 4 - AutomationML Logic Description
112
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_2
Proxy_State_1
State_State_2-1
State_State_2-2
SFC State_Main
InitialStep_noName
State_State_1
State_State_2
[True]
State_2
State_2-2 State_2-1
State_1
[Guard]
[Guard]
[Guard]
Contains AddData
element with
refrence to SFC2
Figure 49: Transformation of a state transition from a higher state 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 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 “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 successor 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 s2
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)
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).
Part 4 - AutomationML Logic Description
113
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 “StateTransition_” + State Transition Name
st.Guard.Formular Content of the state transition guard
st.Pre
s2.ID if st is the only successor state transition of the state s2
selDiv.ID if the state s2 has more than one successor r 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 s3 of the state transition
s3.Pre st.ID
Successor relations for the state transition with more than one predecessor: 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.
Part 4 - AutomationML Logic Description
114
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.
Figure 50: Transformation of a state transition from a higher state with 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 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 “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 successor 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 s2
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 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,
SFC State_2
Proxy_State_1
State_State_2-1
State_State_2-2
SFC State_Main
InitialStep_noName
State_State_1
State_State_2
[True]
State_2
State_2-2 State_2-1
State_1
[Guard]/action1[Guard]
[Guard]
Proxy_State_1
[True]
StateForActivity_
action1 Action_action1_ofStateTransitionN
Contains AddData
element with
refrence to SFC
State_2
Part 4 - AutomationML Logic Description
115
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
“Proxy_” state name of the originator of the state 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 “StateTransition_” + state transition name
st1.Guard.Formular Content of the state transition guard
st1.Pre
s1.ID if st1 is the only successor state transition of the source state s1
selDiv.ID if the source state s1 has more than one successor state transition (see section 5.5.3)
s2.ID <some ID>
s2.Name StateForActivity_” + activity 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 “StateTransitionForActivity_” + activity name
st2.Guard.Formual TRUE
st2.Pre s2.ID
Part 4 - AutomationML Logic Description
116
a.ID <some ID>
a.Name “Action_” + action name + “_ofStateTransition”
a.Formula Content of action a
a.FiredEvents set of events fired by a
a.Pre s2.ID
Successor relations for the state transition with one predecessor: If st2 is the only predecessor state transition of the destination state s3
s3.Pre st2.ID
Successor relations for the state transition with more than one predecessor: If the destination state s3 has more than one predecessor state transition (see section 5.5.3)
selCon.Pre st2.ID
Table 96: Attribute values for state transition representation in IML within the sub State charts
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.
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.
Figure 51: Transformation of a state transition from a lower level state 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 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).
SFC State_1
InitialStep_noName
State_State_2-1
SFC State_Main
InitialStep_noName
State_State_1
State_State_2
[True]
State_1
State_1-1 State_1-2
State_2
[Guard]
[Guard]
[Guard]
State_State_2-2
Proxy_State_State_1Contains AddData
element with
refrence to SFC
State_1
Part 4 - AutomationML Logic Description
117
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 successor 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 s2
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 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.
Part 4 - AutomationML Logic Description
118
IML element Attribute value
s3.ID <some ID>
s3.Name
“Proxy_” state name of the originator of the state 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 “StateTransition_” + state transition name
st.Guard.Formular Content of the state transition guard
st.Pre
s.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 successor state transition (see section 5.5.3)
Successor relations for the state transition with one predecessor: If st is the only predecessor state transition in the sub State chart of the state s3
s.Pre st.ID
Successor relations for the state transition with more than one predecessor: 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
Part 4 - AutomationML Logic Description
119
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.
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 attached additional data element ad,
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 “StateTransition_” + state transition name
st1.Guard.Formular Content of the state transition guard
st1.Pre
s1.ID if st1 is the only successor state transition of the 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 StateForActivity_” + activity name
s1.Init False
s1.Terminal False
s1.Pre st1.ID
ad.ID <some ID>
ad.Type StateChartStateType
SFC State_1SFC State_Main
State_1
State_1-1 State_1-2
State_2
[Guard]/action1
InitialStep_noName
State_State_1-1
[Guard]
State_State_1-2
Proxy_State_State_2
Action_action1_ofStateTransitionN
InitialStep_noName
State_State_1
State_State_2
[True]
[Guard]
[True]
StateForActivity_
action1
Contains AddData
element with
refrence to SFC
State_1
Part 4 - AutomationML Logic Description
120
ad.Value stateForActivity
ad.Pre s1.ID
st2.ID <some ID>
st2.Name “StateTransitionForActivity_” + activity name
st2.Guard.Formual TRUE
st2.Pre s1.ID
a.ID <some ID>
a.Name “Action_” + action name + “_ofStateTransition”
a.Formula Content of action a
a.FiredEvents set of events fired by a
a.Pre s1.ID
Successor relations for the state transition with one predecessor: If st2 is the only predecessor state transition of the destination state s3
s3.Pre st2.ID
Successor relations for the state transition with more than one predecessor: If the destination state s3 has more than one predecessor state transition (see section 5.5.3)
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
an attached additional data element ad,
and their corresponding IML attributes and their successor and predecessor relations to the source states of the transition (see Table 100).
Part 4 - AutomationML Logic Description
121
IML element Attribute value
s4.ID <some ID>
s4.Name
“Proxy_” state name of the originator of the state 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 “StateTransition_” + state transition name
st.Guard.Formular Content of the state transition guard
st.Pre
s4.ID if st is the only successor state transition of the source state s4
selDiv.ID if the source state s4 has more than one successor 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 state s4
s4.Pre st.ID
Successor relations for the state transition with more than one predecessor: If the destination state s4 has more than one predecessor state transition (see section 5.5.3)
selCon.Pre st.ID
Table 100: Attribute values for state transition representation in IML within the sub State charts
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.
Part 4 - AutomationML Logic Description
122
5.7 Example Transformation for State Charts to AutomationML Logic Representation
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, line-by-line execution of code, and PLC programming.
Figure 53: Example: transformation of a simple cyclic State chart
Figure 54: Example: transformation of a State chart with states with different predecessors and successors
ReadInput
[Inputs read]
ExecutePr
ogram
[Program executed]
SetOutputs
[Outputs set]
InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
ReadInput
[Inputs read]
ExecutePr
ogram
[Program executed]
SetOutputs
[Outputs set]
InterruptHa
ndling
[Interrupt][Interrupt handled]
InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
[Interrupt]
State_InterruptHandling
[Interrupt handled]
Part 4 - AutomationML Logic Description
123
Figure 55: Example: transformation of a State chart with actions
Figure 56: Example: transformation of a State charts with a condition connector
ReadInput
[Inputs read] Action SetLineCountzero
ExecuteProgram
DoAction IncrementLineCount
[Program executed]
SetOutputs
[Outputs set]
InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
N Action_IncrementLineCount_ofState_ExecuteProgram
StateForActivity_SetLineCountzero
[TRUE]
N Action_SetLineCountzero_ofStateTransition
ReadInput
[Inputs read]
ExecutePr
ogram
[Program executed]
SetOutputs
[Outputs set]
InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
C
InterruptHa
ndling
[NoInterrupt]
[Interrupt] [Interrupt handled]
Condition_C
[NoInterrupt] [Interrupt]
State_InterruptHandling
[InterruptHandled]
Part 4 - AutomationML Logic Description
124
Figure 57: Example: transformation of a State chart with simple hierarchy
Figure 58: Example: transformation of a State chart with complex hierarchy and connectors
SFC1 - Main SFC2 – Cyclic Behaviour
CyclicBehaviour
ReadInput
[Inputs read]
ExecutePr
ogram
[Program executed]
SetOutputs
[Outputs set]
InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
Programming
[Start][Stop]
InitialStep_noName
[TRUE]
State_Programming
[Start]
State_CyclicBehaviour
[Stop]
Contains
AddData element
with refrence to
SFC2
SFC1 - Main SFC2 – Cyclic Behaviour
CyclicBehaviour
ReadInput
[Inputs read]
ExecutePr
ogram
[Program executed]
SetOutputs
[Outputs set]
InitialStep_noName
[TRUE]
State_ReadInput
[Input read]
State_ExecuteProgram
[Program
executed]
State_SetOutputs
[Outputs set]
InitialStep_noName
[TRUE]
State_Programming
[Start]
State_CyclicBehaviour
[Stop]
Programming
EditProgram
[Editing finished]
CompileProgram
[Program correct]
UploadPro
gram
[Program change necessary]
C
[Program incorrect]
[Program compiled]H
[Start][Stop]
SFC3 – Programming
History_Programming
State_UploadProgram
[Program incorrect]
Condition_32_Programming
[Program correct]
InitialStep_noName
[TRUE]
State_EditProgram
[Editing finished]
State_CompileProgram
[Program
compiled]
[Program change
necessary]
Proxy_State_CyclicBehaviour
[Stop]
Contains
AddData element
with refrence to
SFC3
Contains
AddData element
with refrence to
SFC2
[Start]
Part 4 - AutomationML Logic Description
125
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].
Part 4 - AutomationML Logic Description
126
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 document’s 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.
Part 4 - AutomationML Logic Description
127
Examples
refURI = “file:///C:/Temp/PLCopenXML1.xml#POU1_globalId”
Reference to a POU within PLCopen XML document “PLCopenXML1.xml”
refURI = “file:///C:/Temp/ PLCopenXML1.xml #variable_globalID”
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
Part 4 - AutomationML Logic Description
128
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 AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ 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.
Figure 60: Storage of logics information with AutomationML
CAEX File PLCopen XML File
Station
Sequ1 (PLCopenXMLInterface/LogicInterface)
refURI = „file:///c:test.xml#POU_1“
Var1 (PLCopenXMLInterface/ VariableInterface)
refURI = „file:///c:test.xml#b“
ab
Init
End
Step 1
Part 4 - AutomationML Logic Description
129
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.
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.
Figure 62: Publishing PLCopen variables
CAEX File PLCopen XML File
Station
Sequ1 (PLCopenXMLInterface/LogicInterface)
refURI = „file:///c:test.xml#POU_1“
Init
End
Step 1
Published
LogicInterface
RefrencedPOU
CAEX File PLCopen XML File
Station
Sequ1 (PLCopenXMLInterface/LogicInterface)
Var1 (PLCopenXMLInterface/ VariableInterface)
refURI = „file:///c:test.xml#b“
ab
Init
End
Step 1
Published
VariableInterface
PLCopenvariable
Part 4 - AutomationML Logic Description
130
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.
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-92ea-c737e92ed093 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.
Sequencing
Behavior
Piece
Cylinder 1
Cylinder 2
+
Drill
C1R P
C1U
C1L
Piece
Transport
Unit 1
Transport Unit 2
Part 4 - AutomationML Logic Description
131
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
Drill_Station_Sequencing.xml
Drill_Station.aml<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>
AutomationML
PLCopen XML
Part 4 - AutomationML Logic Description
132
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.
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.
Drill_Station_Sequencing.xml
Drill_Station.aml<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" />
<Attribute Name="refURI" AttributeDataType="xs:anyURI">
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing.xml#
F_32b5a027-69d7-171b-9ea6-73c7f92aa093
</Value>
</Attribute>
</ExternalInterface>
<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>
AutomationML
PLCopen XML
Part 4 - AutomationML Logic Description
133
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.
Figure 66: Reference to multiple logic information
Drill_Station.aml
<InternalElement Name="Drill_Station">
<ExternalInterface Name="Drill_Station_Sequencing">
<Attribute Name="refURI" AttributeDataType="xs:anyURI">
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&Behaviou
r.xml# H_36b9a027-96cd-47db-92ea-c737e92ed093</Value>
</Attribute>
</ExternalInterface>
<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>
<ExternalInterface Name="Extract_Cylinder1">
<Attribute Name="refURI" AttributeDataType="xs:anyURI">
<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&B
ehaviour.xml# F_32b5a027-69d7-171b-9ea6-73c7f92aa093</Value>
</Attribute>
</ExternalInterface>
</InternalElement>
<InternalElement Name="Cylinder2"/>
<InternalElement Name="TransportUnit1"/>
<InternalElement Name="TransportUnit2"/>
</InternalElement>
Drill_Station_Sequencing&Behaviour.xml
AutomationML
PLCopen XML
Part 4 - AutomationML Logic Description
134
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.
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.
Emergencystop 1
Emergencystop 3
Light guard 2
Emergencystop 2Light guard 1
Welding tool 2
Gate 1 Gate 2
Press 1
Robot 1
Robot 2
Robot 3
Press 2
Robot 4
Conveyer 1
Safety shut-off mat 1
Safety shut-off mat 1
Gate 3
Part 4 - AutomationML Logic Description
135
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.
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“.
Signal Group Component Group
Emergencystop 1
Emergencystop 2
Light guard 1
Robot 1
Welding tool 2
Gate1
Robot 2
Signal Group A Component Group A
Emergencystop 1
Emergencystop 2
Light guard 1
Robot 1
Welding tool 2Gate 1
Robot 2
Signal Group B
Component Group B
Safety shut-off mat 1
Light guard 2
Robot 3
Gate 2
Press 1
Signal Group C Component Group C
Emergencystop 3
Robot 4
Conveyer 3
Press 2
Safety shut-off mat 2
Part 4 - AutomationML Logic Description
136
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.
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
SignalGroups with Mirror Objects
ComponentGroupswith Mirror Objects
InternalLink
AutomationML Object structure
InterlockingConnectorSignalGroup
InterlockingConnectorComponentGroup
Part 4 - AutomationML Logic Description
137
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;
InterlockingConnector shall be used only within elements of type “SignalGroup” or “ComponentGroup”.
InterlockingConnector interface shall be connected via InternalLinks to interfaces of the same type only.
Table 109 specifies the InterfaceClass “InterlockingConnector”.
Class name InterlockingConnector
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 Boolean Logic as Interlocking Condition
7.3.1 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.
Part 4 - AutomationML Logic Description
138
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 InterlockingVariableInterface
Description The InterfaceClass “InterlockingVariableInterface” shall be used in order to reference PLCopen XML documents
Parent Class AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ ExternalDataConnector/PLCopenXMLInterface/VariableInterface
Attributes SafeConditionEquals (type=”xs:Boolean”)
The attribute “SafeConditionEquals” allows to indicate which value of the reference variable indicates a save state.
Values:
“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
SignalGroup A
ComponentGroup A
Device 2
Device 1
Device 3
Device 4
Interlocking Connector
InterlockingVariableInterface
PLCopenXML
Document
Reference to a PLCopenXML variable as
interlocking condition
Link between a SignalGroup and a ComponentGroup
Part 4 - AutomationML Logic Description
139
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].
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
POU1
AND
OUT_SignalGroup_AEmergencyStop1
EmergencyStp2
LightGuard1
Part 4 - AutomationML Logic Description
140
the ComponentGroup shall be realized via an internal link.
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.
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.
SignalGroup A
ComponentGroup A
Device 1
Device 2
Device 3
Device 4
PLCopenXML
Document
Direct links between ComponentGroups and PLCopen variables are
permitted.
ComponentGroup A
SignalGroup A
Device 1
Device 2
Device 1
Device 4
Plant
…
Direct links between devices within plant
topology description and a ComponentGroup are
permitted.
Part 4 - AutomationML Logic Description
141
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.
Figure 74: Complex FBD networks for interlocking descriptions
7.5 Extended Use of Interlocking Description within AutomationML
7.5.1 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.
POU1
TAN LREAL_TO_BOOL
OUT_POU_1
POU3
AND
OUT_POU_3OUT_POU_1
OUT_POU_2
EmergencyStop3
POU2
INT_TO_BOOLLIMIT_INT
OUT_POU_2Min
Temp
Max
MN
IN
MX
Part 4 - AutomationML Logic Description
142
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 top-level 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.
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.
Device 1
Behaviour Device 1
&A
BC
A B C
ADD Var1 Var2
ADD NOT
OR
Var3 Var4
Interlocking_Var
Fast
Slow
1 2
Motor 1
State 3 4
Part 4 - AutomationML Logic Description
143
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.
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.
Emergencystop 1
Emergencystop 3
Light guard 2
Emergencystop 2Light guard 1
Welding Tool 2
Gate 1 Gate 2
Press 1
Robot 1
Robot 2
Robot 3
Press 2
Robot 4
Conveyer 1
Safety shut-off mat 1
Safety shut-off mat 1
Gate 3
Part 4 - AutomationML Logic Description
144
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
Part 4 - AutomationML Logic Description
145
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.
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 InterlockingVariableInterface 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.
InternalLink
Part 4 - AutomationML Logic Description
146
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.
SignalGroup_A_InterlockingDescription.xml
…<POU name=„SignalGroup_A“>…
<localVars><variable name=„OUT_SignalGroup_A“/>…
</localVars><body>
<FBD>…</FBD>
</body></POU>
Reference
InternalLink
Part 4 - AutomationML Logic Description
147
Figure 81: Interlocking example with references to PLCopen XML variables
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
OUT_SignalGroup_AEmergencyStop1
EmergencyStp2
LightGuard1
Reference
InternalLink
Part 4 - AutomationML Logic Description
148
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 Release 1.4.1, http://www.khronos.org/files/collada_spec_1_5.pdf, last accessed May 2010.
[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] Harel, D.: On Visual Formalisms; Communications of the ACM, Jg. 31, H. 5, S. 514–529.
Part 4 - AutomationML Logic Description
149
Annex A: Example for Mapping IML to PLCopen XML
Within Figure 82 example of an IML System is depicted.
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>
Intermediate StateID= ISID_20090303_003,
Init=FALSE, Current=TRUE,
Terminal =FALSE
Terminal StateID= ISID_20090303_005, Init=
FALSE, Current=FALSE,
Terminal = TRUE
Action 1ID= ISID_20090303_008, Init=FALSE,
Current=TRUE, Terminal =FALSE,
Formula=[a=TRUE], FiredEvent={e},
Time.Duration=12, Time.Delay=6,
Initial StateInitial StateID= ISID_20090303_001,
Init=TRUE, Current=FALSE,
Terminal =FALSE
Initial StateInitial StateID= ISID_20090303_001,
Init=TRUE, Current=FALSE,
Terminal =FALSE
Transition 1ID= ISID_20090303_002,
Guard.Var=a,[2;17],
Transition 2ID= ISID_20090303_004,
Guard.Boolean=b,
ConsumedEvents={e}
JumpInitialStateID= ISID_20090303_007,
State=InitialState
Transition 3ID=
ISID_20090303_006,
Guard.Boolean=c,
ConsumedEvents={e}
SelectionDivergenceID= ISID_20090303_009
Event ID=ISID_20090303_013
Name=e
Variable ID= ISID_20090303_010,
Name=a, Type=Int,
InitialValue=9
Variable ID= ISID_20090303_011,
Name=b, Type=Boolean,
InitialValue=FALSE
Variable ID= ISID_20090303_012,
Name=c, Type=Boolean,
InitialValue=TRUE
Part 4 - AutomationML Logic Description
150
<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> <html xmlns="http://www.w3.org/1999/xhtml"> <div xmlns="http://www.w3.org/1999/xhtml" xml:space="preserve" wsName="Action1"> (*FiredEvents*) <br /> e:=True; <br /> (*ChangedVariables*) <br /> a=True; <br /> </div> </html> </ST> </body> </action> </actions> <transitions> <transition globalId="ISID_20090303_002" name="Transition1"> <body> <ST> <html xmlns="http://www.w3.org/1999/xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"
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> <transition globalId="ISID_20090303_004" name="Transition2"> <body>
<ST> <html xmlns="http://www.w3.org/1999/xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"
xml:space="preserve" id="MWTDESCRIPTION" wsName=" ISID_20090303_004"> IF (b AND e) <br /> THEN Transition2:=True; <br /> e=False; <br /> ELSE Transition2:=False;
Part 4 - AutomationML Logic Description
151
<br /> END_IF </div> </html> </ST> </body> </transition> <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" id="MWTDESCRIPTION" wsName=" ISID_20090303_003">
IF (c AND e) <br /> THEN Transition3:=True; <br /> e=False; <br /> ELSE Transition3:=False; <br /> END_IF </div> </html> </ST> </body> </transition> </transitions> <body> <SFC> <actionBlock> <connectionPointIn> <connection refLocalId="3"/> </connectionPointIn> <action localId="8" globalId="ISID_20090303_008" qualifier="SD" duration="12"> <reference name="Action1" /> <addData> <data name="http://www.automationML.org/AML_addData.xsd"> <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> <connection refLocalId="1" /> </connectionPointIn> <condition>
<reference name="Transition1" /> </condition> </transition> <step initialStep="false" localId="3" globalId="ISID_20090303_003" name="Intermediate State"> <addData> <data name="http://www.automationML.org/AML_addData.xsd"> <AutomationML> <StateStatus> current </StateStatus> </AutomationML>
Part 4 - AutomationML Logic Description
152
</data> </addData> <connectionPointIn> <connection refLocalId="2" /> </connectionPointIn> </step>
<selectionDivergence localId="9" globalId="ISID_20090303_009"> <connectionPointIn> <connection refLocalId="3"/> </connectionPointIn> </selectionDivergence> <transition localId="4" globalId="ISID_20090303_004" > <connectionPointIn>
<connection refLocalId="9" /> </connectionPointIn> <condition> <reference name="Transition2" /> </condition> </transition> <transition localId="6" globalId="ISID_20090303_006" > <connectionPointIn> <connection refLocalId="9" /> </connectionPointIn> <condition> <reference name="Transition3" /> </condition> </transition> <step initialStep="false" localId="5" globalId="ISID_20090303_005" name="Terminal State"> <addData> <data name="http://www.automationML.org/AML_addData.xsd"> <AutomationML> <StateStatus> terminal </StateStatus> </AutomationML> </data> </addData> <connectionPointIn> <connection refLocalId="4" /> </connectionPointIn> </step> <jumpStep localId="7" globalId="ISID_20090303_007" targetName="Initial State"> <connectionPointIn> <connection refLocalId="6" /> </connectionPointIn> </jumpStep > </SFC> </body> </pou> </pous> </types> <instances/> </project>