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


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


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


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


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


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


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


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


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


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


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.


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

...


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].


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


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


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


Robot 2

3 26

31 1 35

23

Postprocess Robot 2


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


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


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.


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


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]


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


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



Terminal =FALSE

Transition 1ID= ISID_20090303_002,

Guard.Var=a,[2;17],


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


Name=b, Type=Boolean,

InitialValue=FALSE


Name=c, Type=Boolean,

InitialValue=TRUE


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.


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.


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.


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.


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.


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


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


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


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


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


35

Element AutomationML/StateChartStateType

diagram


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


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


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


37

Element AutomationML/StateStatus

diagram


properties isRef 0

minOcc 0

maxOcc 2

content simple

facets enumeration initial

enumeration current

enumeration terminal

Table 23: <StateStatus> element

Element AutomationML/ActionStatus

diagram


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.


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.


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.


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


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.


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.


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


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 />


44

ELSE st.Name:=FALSE;

<br /> END_IF; <br /> </div> </html> </ST> </body> </transition>

If the Guard element contains st.Guard.Value and


<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;


If the Guard element contains st.Guard.Formula and


<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 /> …


45

<br /> en:=False; <br />

ELSE st.Name:=FALSE;


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


<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}


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.


47



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.



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


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.



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>


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.


a.Pre

For each element el with local ID el.x of a.Pre one


<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


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


52

4.3.6 Mapping of Jumps and their Relations

An IML jump j with its relations shall be mapped to a PLCopen <jumpStep>.


IML element, property and relation


j <jumpStep>

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


j.State <jumpStep targetName=j.State>

j.Pre

For each element el with local ID el.x of j.Pre one


<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


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.



53



selDiv <selectionDivergence>

selDiv.ID

<selectionDivergence localId= ”someIDValue”

globalId=”selDiv.ID”>


selDiv.Pre

For each element el with local ID el.x of selDiv.Pre one


<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.



54



simDiv <simultaneousDivergence>

simDiv.ID <simultaneous localId= ”someIDValue” globalId=”simDiv.ID”>


simDiv.Pre

For each element el with local ID el.x of simDiv.Pre one


<SFC> <simultaneousDivergence> <connectionPointIn>


</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


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.



55



selCon <selectionConvergence>

selCon.ID

<selectionConvergence localId= ”someIDValue”

globalId=”selCon.ID”>


selCon.Pre

For each element el with local ID el.x of selCon.Pre one


<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


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.



56



simCon <simultaneousConvergence>

simCon.ID <simultaneous localId= ”someIDValue” globalId=”simCon.ID”>


simCon.Pre

For each element el with local ID el.x of simCon.Pre one


<SFC> <simultaneousConvergence> <connectionPointIn>


</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


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>.




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


57


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.




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"/>


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


59


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.




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


60


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.




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>


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


61


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


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


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


Lift skid

Lower skid


Initialise Robot 1

Execute Manufacturing Robot 1

Postprocess Robot 1

Initialise Robot 2


Postprocess Robot 2


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


S_Move to Lift PositionD 0

SD 3

DA_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


Robot1_1


Robot2

D 0

SD 5


Robot2


Robot2


True


Robot2_2


Robot2_1S_PostProcessRobot1

D 0

SD 4

DA_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


SyS_Terminal_1

SyS_Terminal_2

SyS_Terminal_3

TerminalStep

True


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


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


66

5.1.4 Bar Startpoint

Bar Startpoint


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


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


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“


Case A: t= Bar.endpoint

Case B: t= Bar.endpoint - predecessorBar.endpoint

Case C: t= Bar.endpoint – maxpredecessorBar predecessorBar.endpoint

S_ “bar

name“


SD ty TA_“bar name“



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


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“


SD ty TA_“bar name“


Initial

Step

true

D t1 DA_“bar name“

SD t2 TA_“bar name“

TA_“bar name“ = 1

S_ “bar

name“

Initial

Step

true




S_ “bar

name“


D tx DA_xx

SD ty TA_xx

TA_xx = 1



S_ “bar

name“

S_xx


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:


S_xxD tx DA_xx

SD ty TA_xx

TA_xx = 1



S_ “bar

name“

S_xxD tx DA_xx

SD ty TA_xx

TA_xx = 1

SyS_

„bar

name“_i

TRUE



S_ “bar

name“

S_xx


D tx DA_xx

SD ty TA_xx

TA_xx = 1

SyS_

„bar

name“_i

TRUE



S_ “bar

name“


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


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


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


Lift skid


InitialStep_Gantt

D 0

SD 4

TRUE




D 4

SD 7




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


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




S_Lift skid

D 7

SD 9

DA_Lift skid

TA_Lift skid

TA_Lift skid

TerminalStep

D 4

SD 7




S_Move to Lift Position


0 4 6 7 9

Handover to HTR002


Lift skid


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


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


Robot1


Robot1


SyS_Terminal_1

TerminalStep

True


Robot1

SyS_Terminal_2


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


Robot1


Robot1



Robot1_1

TerminalStep


Robot1

TRUE

S_Lift skidD 7

SD 9

DA_Lift skid

TA_Lift skid

TA_Lift skid


Robot1_1

0 6 7 9 10 18

Lift skid

Initialise Robot 1



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


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


76

5.2.2 Start of a PERT Chart

Start of a PERT chart


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“


77

5.2.4 Node Earliest Startpoint

Node Earliest Startpoint


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


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“


t= Node.endpoint

S_

“node

name“

D t DA_“node name“

TA_“node name“



78

5.2.7 Successor Nodes

Successor Node


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


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“


SD ty TA_“node name“


S_

“node

name“


SD ty TA_“node name“


Initial

Step

true

D t1 DA_“node name“

SD t2 TA_“node name“

TA_“node name“ = 1

S_

“node

name“

Initial

Step

true




S_

“node

name“


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




S_

“node

name“

S_xxD tx DA_xx

SD ty TA_xx

TA_xx = 1




S_

“node

name“

S_xxD tx DA_xx

SD ty TA_xx

TA_xx = 1

SyS_

„node

name“_i

TRUE




S_

“node

name“


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




S_

“node

name“


81

5.2.9 End of a PERT Chart

End of a PERT Chart


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


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


2 9

9 1 12

7

Lift Skid

4 26

31 1 36

23

Lower skid

7 34

36 2 45

27


6 6

4 2 12

0

Initialse Robot 1

9 18

12 3 24

9


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


Robot 2

3 26

31 1 35

23

Postprocess Robot 2


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.


InitialStep

D 0

SD 4

TRUE




S_Move to Lift PositionD 0

SD 3




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


Robot1

D 0

SD 9


Robot1


Robot1


True


Robot1_2


Robot1_1


Robot2

D 0

SD 5


Robot2


Robot2


True


Robot2_2


Robot2_1S_PostProcessRobot1

D 0

SD 4

DA_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



SyS_Terminal_1

SyS_Terminal_2

SyS_Terminal_3

TerminalStep

True


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





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]



Device1_2D0 Device1_Pos1

Device1_3SD1 Signal_Device1_2









[Signal_Device1_1 = TRUE] [Signal_Device1_1 = TRUE]

Device2_1

[Signal_Device2_1 = TRUE]

Device2_2D0 Device2_PosB





Time_Step_

END


[TRUE]

[Signal_Time_END = TRUE]

SD2 Signal_Time_END


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.


87

5.3.2 Start of an Impulse Diagram

Start of an Impulse Diagram


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


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]


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


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


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


89

5.3.6 Resource State Change

Resource State Change


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


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


D 0 Resource Name+ „_“ + Origin Resource State Name + „_“ + Traget Resource State Name


[ „Signal_“ + Resource Name + „_“ + SN = TRUE]


Resource Name + „_“

+SN


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


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]


Resource

Name + „_“

+SN

„Time_Step

_“ + SN

SD std „Signal_Time_“ +SN

[ „Signal_Time_“ + SN = TRUE]

.. ….

Resource

Name + “_“+ SN

[ „Signal _Time_“ + SN = TRUE]



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


92

5.3.9 End of Impulse Diagram and Terminal Step

End of Impulse Diagram and Terminal Step


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


93

5.3.10 Impulse Diagram Details


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.Type = ResourceStateChangeDefinition.Duration

addData.Value = some duration


PLCopenVariable = Variablename


addData.Type = ImpulseDiagramPLCVariable.Name

addData.Value = Variablename


PLCopenVariable = Variablename


addData.Type = ImpulseDiagramPLCVariable.Name

addData.Value = Variablename



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_0SD 0 Signal_Time_0


D0 Motor1_Slow_run

[Signal_Time_1= TRUE]

Motor1_0

Init

Uses

Time_Signal_1

Motor1_1

Motor1_0

Motor1_2


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



32StateResource

Fast_run

Slow_run

D0 Motor1_Slow_run

SD1 Signal_Motor1_1


D0 Motor1_Fast_run_to_Slow_run

Motor1_0

Init

Motor1_0 Motor1_3Motor1_2Motor1_1

Uses Signal_Motor1_1


D0 Motor1_Fast_run

.. ….


Motor1_3D0 Motor1_Fast_run_to_Slow_run

Motor1_2

Motor1_1


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.

.. ….


D0 Mortor1_Slow_run_to_Fast_run D0 Gripper1_Open_to_Close

SD1 Signal_Motor1_2

Motor1_

1


D0 Mortor1_Slow_runMotor1_

0


D0 Mortor1_Fast_runMotor1_

2

[...]

Gripper1

_0

D0 Gripper1_OpenSD0 Signal_Time_0


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


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]


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


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]


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).


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_State_nState_State_1

[Event n][Event 2]

State_State_2

[Event 1]

... ...

State_State_3


101

Multiple predecessors results in an IML selection convergence selCon and additional IML attribute

values of the successor state s (see Table 77).


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).


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]


[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



102


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).


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.Pre s.ID for the state s the do action belongs to

ad.ID <some ID>


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





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).


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.Pre s.ID for the state the entry action belongs to

ad.ID <some ID>


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



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


104


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).


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


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).


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


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).


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


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.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


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.


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).


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.


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


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).


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.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


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.


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.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


111


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.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


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


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).


st.ID <some ID>



st.Pre


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


s2.Pre st.ID


sel.Div st.ID

Table 93: Attribute values for state transition representation in IML within hierarchical State charts

Additionally the state transition is mapped to the following elements within the IML system representing the sub State chart of the super state:

an IML state transition st,

an IML state s2,

their attribute values and their successor and predecessor relations to the state s1 and the destination

state s3 of the transition (see Table 94).


113


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.Value higherLevelState

ad.Pre s2.ID



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.


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


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).


st.ID <some ID>



st.Pre




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


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).


s1.ID <some ID>

s1.Name


s1.Init False

s1.Terminal False

ad.ID <some ID>



ad.Pre s1.ID

st1.ID <some ID>



st1.Pre

s1.ID if st1 is the only successor state transition of the source state s1


s2.ID <some ID>

s2.Name StateForActivity_” + activity name

s2.Init False

s2.Terminal False

s2.Pre st1.ID

ad.ID <some ID>



ad.Pre s2.ID

st2.ID <some ID>



st2.Pre s2.ID


116

a.ID <some ID>




a.Pre s2.ID


s3.Pre st2.ID


selCon.Pre st2.ID




Case C

In this case the state transition connects states or connectors within the different hierarchy levels whereas the originator of the state transition belongs to the lower hierarchy level. Furthermore no action is executed during the transition.

Figure 51: Transformation of a state transition from a lower level state without an action to IML elements


predecessor relations of the super state s1 of the source state and the destination state s2 of the

transition, within the IML system representing the higher level (see Table 97).

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


117


st.ID <some ID>



st.Pre




s2.Pre st.ID


selCon.Pre st.ID

Table 97: Attribute values the representation of state transition among hierarchies in IML at the higher level

Additionally the state transition is mapped to the following elements within the IML system representing the sub State chart of the super state:

an IML state transition st,

an additional data element ad,

an IML state s3

and their attribute values see Table 98.


118


s3.ID <some ID>

s3.Name


s3.Init False

s3.Terminal False

ad.ID <some ID>



ad.Pre s3.ID

st.ID <some ID>

st.Name “StateTransition_” + state transition name


st.Pre

s.ID if st is the only successor state transition of the source state s1


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


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 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).


st1.ID <some ID>



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>


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


120


ad.Pre s1.ID

st2.ID <some ID>



st2.Pre s1.ID

a.ID <some ID>




a.Pre s1.ID


s3.Pre st2.ID


selCon.Pre st2.ID

Table 99: Attribute values the representation of state transition among hierarchies in IML

Additional the state transition results in the following elements within the IML representations of the sub State chart:

one IML state transition st,

one IML state s4


and their corresponding IML attributes and their successor and predecessor relations to the source states of the transition (see Table 100).


121


s4.ID <some ID>

s4.Name


s4.Init False

s4.Terminal False

ad.ID <some ID>



ad.Pre s4.ID

st.ID <some ID>

st.Name “StateTransition_” + state transition name


st.Pre



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


selCon.Pre st.ID





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]


[Program

executed]

State_SetOutputs

[Outputs set]

[Interrupt]

State_InterruptHandling

[Interrupt handled]


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]


[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]


[Program

executed]

State_SetOutputs

[Outputs set]

C

InterruptHa

ndling

[NoInterrupt]

[Interrupt] [Interrupt handled]

Condition_C

[NoInterrupt] [Interrupt]

State_InterruptHandling

[InterruptHandled]


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]


[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]


[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]


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].


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.


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


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


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


Station


refURI = „file:///c:test.xml#POU_1“

Init

End

Step 1

Published

LogicInterface

RefrencedPOU


Station


Var1 (PLCopenXMLInterface/ VariableInterface)

refURI = „file:///c:test.xml#b“

ab

Init

End

Step 1

Published

VariableInterface

PLCopenvariable


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


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


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" />


<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing.xml#

F_32b5a027-69d7-171b-9ea6-73c7f92aa093

</Value>

</Attribute>


<ExternalInterface Name="Extract_Cylinder1"

RefBaseClassPath="AutomationMLInterfaceClassLib/AutomationMLBaseInterface/

Communication/SignalInterface"

ID="{dd563b37-f9ea-44b0-866f-a672fa00727c}"/>

<InternalLink Name=" Extract_Cylinder1"

RefPartnerSideA="{46ba65e0-5f6d-48ff-9b70-a0030d9dc7b5}:Extract_Cylinder1"

RefPartnerSideB="{46ba65e0-5f6d-48ff-9b70-a0030d9dc7b5}:Extract_Cylinder1"/>

</InternalElement>

AutomationML

PLCopen XML


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">


<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&Behaviou

r.xml# H_36b9a027-96cd-47db-92ea-c737e92ed093</Value>

</Attribute>


<InternalElement Name="Drill"/>

<InternalElement Name="Cylinder1"/>

<ExternalInterface Name="Cylinder1_Behaviour">

<Attribute Name="refURI" AttributeDataType="xs:anyURI"/>

<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&B

ehaviour.xml# G_36b9abd6-96cd-47db-92ea-c737e92ed088</Value>

</Attribute>


<ExternalInterface Name="Extract_Cylinder1">


<Value>file:///c:/Projects/Drill_Project/Drill_Station_Sequencing&B

ehaviour.xml# F_32b5a027-69d7-171b-9ea6-73c7f92aa093</Value>

</Attribute>


</InternalElement>

<InternalElement Name="Cylinder2"/>

<InternalElement Name="TransportUnit1"/>

<InternalElement Name="TransportUnit2"/>

</InternalElement>

Drill_Station_Sequencing&Behaviour.xml

AutomationML

PLCopen XML


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


Gate 3


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


Light guard 2

Robot 3

Gate 2

Press 1

Signal Group C Component Group C

Emergencystop 3

Robot 4

Conveyer 3

Press 2



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


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.


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


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


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.


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


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


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



Gate 3


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


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


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


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


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.


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,



Terminal =FALSE



Terminal =FALSE


Guard.Var=a,[2;17],


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


Name=a, Type=Int,

InitialValue=9


Name=b, Type=Boolean,

InitialValue=FALSE


Name=c, Type=Boolean,

InitialValue=TRUE


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;


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>


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>