the mechatronicuml design method process and language … · the mechatronicuml design method –...

The MechatronicUML Design Method –Process and Language for

Platform-Independent Modeling

MECHATRONIC UML

Technical Reporttr-ri-14-337

Steffen Becker, Stefan Dziwok, Christopher GerkingChristian Heinzemann, Sebastian Thiele, Wilhelm Schäfer

Software Engineering Group, Heinz Nixdorf Institute, University of PaderbornZukunftsmeile 1, 33102 Paderborn, Germany

[stefan.dziwok|wilhelm]@upb.de

Matthias Meyer, Uwe Pohlmann, Claudia PriesterjahnFraunhofer IPT, Project Group Mechatronic Systems Design

Zukunftsmeile 1, 33102 Paderborn, Germany

Matthias TichySoftware Engineering Group

Chalmers Technical University and University of Gothenburg, Sweden

Version: 0.4Paderborn, March 7, 2014

HEINZ NIXDORF INSTITUTEUniversity of PaderbornSoftware Engineering

Contents

1. Introduction 11.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Benefits for the Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. MECHATRONICUML Overview 7

3. Modeling Language 113.1. Data Type Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Primitive Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2. Ranged Primitive Data Type . . . . . . . . . . . . . . . . . . . . . . 123.1.3. Array Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.4. Component Model Data Type . . . . . . . . . . . . . . . . . . . . . 12

3.2. Message Type Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1. Message Type Repository . . . . . . . . . . . . . . . . . . . . . . . 143.2.2. Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3. Real-Time Coordination Protocol . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1. Example of a Real-Time Coordination Protocol . . . . . . . . . . . . 173.3.2. Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.2.1. Coordination Direction of Roles . . . . . . . . . . . . . . 193.3.2.2. Cardinality of Roles . . . . . . . . . . . . . . . . . . . . . 193.3.2.3. Incoming Message Buffer . . . . . . . . . . . . . . . . . . 20

3.3.3. Role Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3.1. Steps of a Message Transmission . . . . . . . . . . . . . . 223.3.3.2. QoS Assumption of the Role Connector . . . . . . . . . . 22

3.3.4. Classification of Real-Time Coordination Protocols . . . . . . . . . . 233.3.4.1. Directions of Coordination . . . . . . . . . . . . . . . . . 243.3.4.2. Forms of Coordination . . . . . . . . . . . . . . . . . . . 24

3.3.5. Real-Time Coordination Protocol Instance . . . . . . . . . . . . . . . 253.3.6. Protocol Behavior Specification . . . . . . . . . . . . . . . . . . . . 273.3.7. Real-Time Model Checking of Protocol Properties . . . . . . . . . . 28

3.4. Real-Time Statechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.1. Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.1.1. Time Value . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.1.2. Clock Constraint . . . . . . . . . . . . . . . . . . . . . . . 32

III

IV CONTENTS

3.4.1.3. Clock Reset . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.2. State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4.2.1. Invariant . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.2.2. State Events . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.2.3. Initial State . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.2.4. Final State . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.2.5. Simple State . . . . . . . . . . . . . . . . . . . . . . . . . 373.4.2.6. Composite State . . . . . . . . . . . . . . . . . . . . . . . 38

3.4.3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.3.1. Types of Transitions . . . . . . . . . . . . . . . . . . . . . 413.4.3.2. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.3.3. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.3.4. Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.3.5. Deadlines . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4.4. State Connection Point . . . . . . . . . . . . . . . . . . . . . . . . . 483.4.4.1. Entry Point . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.4.2. Exit Point . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.5. Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.6. Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.7. Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.8. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4.9. Asynchronous Messages Exchange . . . . . . . . . . . . . . . . . . 52

3.4.9.1. Raise Message . . . . . . . . . . . . . . . . . . . . . . . . 533.4.9.2. Trigger Message . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.10. Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.10.1. Synchronization with Selector . . . . . . . . . . . . . . . . 543.4.10.2. Execution Semantics of Synchronizations . . . . . . . . . 55

3.4.11. Multi Role and Multi Port Real-Time Statechart . . . . . . . . . . . . 603.4.12. Execution Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.4.12.1. Enabling Transitions . . . . . . . . . . . . . . . . . . . . . 633.4.12.2. Selection Criteria for Firing Transitions . . . . . . . . . . . 643.4.12.3. Firing Transitions . . . . . . . . . . . . . . . . . . . . . . 65

3.5. Action Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.5.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.5.2. Local Variable Declaration and Initialization . . . . . . . . . . . . . 683.5.3. Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.5.3.1. Selector Expressions . . . . . . . . . . . . . . . . . . . . . 703.5.4. Operation Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.5.5. Operation Implementation . . . . . . . . . . . . . . . . . . . . . . . 703.5.6. Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.5.7. Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.5.8. If-Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

CONTENTS V

3.5.9. Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.5.10. Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.5.11. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.6. Component Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.6.1. Atomic Component Type . . . . . . . . . . . . . . . . . . . . . . . . 75

3.6.1.1. Atomic Component . . . . . . . . . . . . . . . . . . . . . 753.6.1.2. Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.6.1.3. Port Behavior Specification . . . . . . . . . . . . . . . . . 793.6.1.4. Discrete Component Behavior Specification . . . . . . . . 82

3.6.2. Structured Component Type . . . . . . . . . . . . . . . . . . . . . . 843.6.2.1. Structured Component . . . . . . . . . . . . . . . . . . . . 843.6.2.2. Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.6.2.3. Component Part . . . . . . . . . . . . . . . . . . . . . . . 853.6.2.4. Delegation Connector . . . . . . . . . . . . . . . . . . . . 873.6.2.5. Assembly Connector . . . . . . . . . . . . . . . . . . . . 89

3.7. Component Instance Configuration . . . . . . . . . . . . . . . . . . . . . . . 933.7.1. Component Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.7.1.1. Atomic Component Instance . . . . . . . . . . . . . . . . 933.7.1.2. Structured Component Instance . . . . . . . . . . . . . . . 94

3.7.2. Port Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943.7.2.1. Discrete Port Instance . . . . . . . . . . . . . . . . . . . . 953.7.2.2. Continuous And Hybrid Port Instance . . . . . . . . . . . 96

3.7.3. Connector Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . 973.7.3.1. Assembly Connector Instance . . . . . . . . . . . . . . . . 973.7.3.2. Delegation Connector Instance . . . . . . . . . . . . . . . 97

3.7.4. Component Instance Configuration . . . . . . . . . . . . . . . . . . 97

4. Modeling Extensions for Reconfigurable Systems 1014.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.2. Component Model Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.2.1. Reconfigurable Atomic Component . . . . . . . . . . . . . . . . . . 1044.2.1.1. Reconfiguration of Single Port Instances . . . . . . . . . . 1044.2.1.2. Reconfiguration of Multi Port Instances . . . . . . . . . . . 105

4.2.2. Reconfigurable Structured Component . . . . . . . . . . . . . . . . . 1064.3. Component Story Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.3.1. Component Story Pattern . . . . . . . . . . . . . . . . . . . . . . . . 1074.3.2. Specification of the Control Flow . . . . . . . . . . . . . . . . . . . 108

5. Development Process 1095.1. Process for Self-Optimizing Mechatronic Systems . . . . . . . . . . . . . . . 1095.2. The MECHATRONICUML Platform-Independent Modeling Process . . . . . 112

5.2.1. Determination of Coordination Protocols (Step 3) . . . . . . . . . . . 116

VI CONTENTS

5.2.2. Modeling of a Real-Time Coordination Protocol (Step 3.2) . . . . . . 1175.2.3. Determination of the Components’ Behavior (Step 4) . . . . . . . . . 1195.2.4. Modeling of the Components’ Behavior (Step 4.3) . . . . . . . . . . 121

6. Complete Example 1256.1. Real-Time Coordination Protocols and Message Interfaces . . . . . . . . . . 125

6.1.1. Navigation Protocol and Message Interface . . . . . . . . . . . . . . 1266.1.1.1. Role Navigator . . . . . . . . . . . . . . . . . . . . . . . . 1276.1.1.2. Role Provider . . . . . . . . . . . . . . . . . . . . . . . . 127

6.1.2. Delegation Protocol and Message Interface . . . . . . . . . . . . . . 1286.1.2.1. Role Master . . . . . . . . . . . . . . . . . . . . . . . . . 1286.1.2.2. Role Slave . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.1.3. Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.1.3.1. Role Distributor . . . . . . . . . . . . . . . . . . . . . . . 1306.1.3.2. Role Client . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.1.4. PositionTransmission Protocol and Message Interface . . . . . . . . 1326.1.4.1. Role Sender . . . . . . . . . . . . . . . . . . . . . . . . . 1326.1.4.2. Role Receiver . . . . . . . . . . . . . . . . . . . . . . . . 133

6.1.5. AllPositionsTransmission Protocol and Message Interface . . . . . . 1346.1.5.1. Role Sender . . . . . . . . . . . . . . . . . . . . . . . . . 1346.1.5.2. Role Receiver . . . . . . . . . . . . . . . . . . . . . . . . 134

6.2. System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356.2.1. Structured Components . . . . . . . . . . . . . . . . . . . . . . . . . 1356.2.2. Atomic Components . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.2.2.1. Exploration . . . . . . . . . . . . . . . . . . . . . . . . . 1386.2.2.2. Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.2.2.3. BeBot Observer . . . . . . . . . . . . . . . . . . . . . . . 1396.2.2.4. Collision Control . . . . . . . . . . . . . . . . . . . . . . 1396.2.2.5. PosData . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.2.2.6. MotionCtrl . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6.3. Real-Time Statechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.3.1. Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.3.2. Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.3.3. BeBot Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.3.4. Collision Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

6.4. Component Instance Configuration . . . . . . . . . . . . . . . . . . . . . . . 1496.4.1. Single BeBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506.4.2. Networks of BeBots . . . . . . . . . . . . . . . . . . . . . . . . . . 150

7. Related Work 1577.1. Contract-Based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

7.1.1. Contract Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

CONTENTS VII

7.1.2. Automata Models for Supporting the Contract Levels . . . . . . . . . 1587.1.2.1. Untimed Automata Models . . . . . . . . . . . . . . . . . 159

7.1.3. SPEEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.2. Behavioral Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

7.2.1. Higher-Order Architectural Connectors . . . . . . . . . . . . . . . . 1607.2.2. Reo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

7.3. Multi-Agent-Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.4. Specification Languages for Systems Engineering . . . . . . . . . . . . . . . 161

7.4.1. SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.4.2. MATLAB/Simulink Stateflow . . . . . . . . . . . . . . . . . . . . . 1627.4.3. Modelica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637.4.4. CHARON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647.4.5. Masaccio/Giotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

7.5. Process Models for Systems Engineering . . . . . . . . . . . . . . . . . . . . 1657.6. Software Component Models . . . . . . . . . . . . . . . . . . . . . . . . . . 165

7.6.1. Component Models for Business Information Systems SupportingRun-Time Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . 166

7.6.2. Component Models for Embedded and Real-Time Systems . . . . . . 1677.7. Specifications of Self-Adaptive Systems . . . . . . . . . . . . . . . . . . . . 172

7.7.1. Reference Architectures for Self-Adaptive Systems . . . . . . . . . . 1727.7.2. Modeling of Self-Adaptive Systems . . . . . . . . . . . . . . . . . . 174

7.7.2.1. Graph Transformation based Approaches . . . . . . . . . . 1747.7.2.2. Process Algebra based Approaches . . . . . . . . . . . . . 1777.7.2.3. Formal Logic based Approaches . . . . . . . . . . . . . . 1797.7.2.4. Approaches Defining an Own Semantics . . . . . . . . . . 179

7.7.3. Run-Time Frameworks for Self-Adaptation . . . . . . . . . . . . . . 1807.8. Formal Models for Modeling of Real-time Behavior . . . . . . . . . . . . . . 181

7.8.1. Discrete time models . . . . . . . . . . . . . . . . . . . . . . . . . . 1817.8.2. Dense time models . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

8. Conclusions and Future Work 183

9. Bibliography 1859.1. Own Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.2. Bachelor Theses, Master Theses and Ph.D. Theses . . . . . . . . . . . . . . . 1919.3. Foreign Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

A. Meta-model Documentation 211A.1. EPackage modelinstance . . . . . . . . . . . . . . . . . . . . . . . . . 211

A.1.1. EClass ModelElementCategory . . . . . . . . . . . . . . . . . 211A.1.2. EClass RootNode . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

VIII CONTENTS

A.2. EPackage muml::behavior . . . . . . . . . . . . . . . . . . . . . . . . . 214A.2.1. Abstract EClass Behavior . . . . . . . . . . . . . . . . . . . . . . 214A.2.2. Abstract EClass BehavioralElement . . . . . . . . . . . . . . . 215A.2.3. EClass Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 215A.2.4. EClass Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . 215A.2.5. EClass ParameterBinding . . . . . . . . . . . . . . . . . . . . 216A.2.6. Abstract EClass TypedNamedElement . . . . . . . . . . . . . . . 216A.2.7. EClass Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

A.3. EPackage muml::component . . . . . . . . . . . . . . . . . . . . . . . . 218A.3.1. EClass AssemblyConnector . . . . . . . . . . . . . . . . . . . . 218A.3.2. Abstract EClass AtomicComponent . . . . . . . . . . . . . . . . 221A.3.3. Abstract EClass Component . . . . . . . . . . . . . . . . . . . . . 222A.3.4. EEnumeration ComponentKind . . . . . . . . . . . . . . . . . . . 223A.3.5. EClass ComponentPart . . . . . . . . . . . . . . . . . . . . . . . 223A.3.6. EClass ContinuousPort . . . . . . . . . . . . . . . . . . . . . . 225A.3.7. EClass CoordinationProtocolPart . . . . . . . . . . . . . . 225A.3.8. EClass DelegationConnector . . . . . . . . . . . . . . . . . . 226A.3.9. Abstract EClass DirectedTypedPort . . . . . . . . . . . . . . . 228A.3.10. EClass DiscretePort . . . . . . . . . . . . . . . . . . . . . . . . 229A.3.11. EClass HybridPort . . . . . . . . . . . . . . . . . . . . . . . . . 231A.3.12. Abstract EClass Port . . . . . . . . . . . . . . . . . . . . . . . . . 232A.3.13. Abstract EClass PortConnector . . . . . . . . . . . . . . . . . . 232A.3.14. EEnumeration PortDirectionKind . . . . . . . . . . . . . . . . 233A.3.15. EClass PortPart . . . . . . . . . . . . . . . . . . . . . . . . . . . 233A.3.16. EClass StaticAtomicComponent . . . . . . . . . . . . . . . . 234A.3.17. Abstract EClass StaticComponent . . . . . . . . . . . . . . . . 234A.3.18. EClass StaticStructuredComponent . . . . . . . . . . . . . 235A.3.19. Abstract EClass StructuredComponent . . . . . . . . . . . . . 235

A.4. EPackage muml::connector . . . . . . . . . . . . . . . . . . . . . . . . 238A.4.1. Abstract EClass Connector . . . . . . . . . . . . . . . . . . . . . 238A.4.2. Abstract EClass ConnectorEndpoint . . . . . . . . . . . . . . . 239A.4.3. Abstract EClass ConnectorEndpointInstance . . . . . . . . 239A.4.4. Abstract EClass ConnectorInstance . . . . . . . . . . . . . . . 240A.4.5. Abstract EClass DiscreteInteractionEndpoint . . . . . . . 240A.4.6. Abstract EClass DiscreteInteractionEndpointInstance 242A.4.7. Abstract EClass

DiscreteMultiInteractionEndpointInstance . . . . . 242A.4.8. Abstract EClass

DiscreteSingleInteractionEndpointInstance . . . . 243A.4.9. EClass MessageBuffer . . . . . . . . . . . . . . . . . . . . . . . 243

A.5. EPackage muml::constraint . . . . . . . . . . . . . . . . . . . . . . . 245A.5.1. Abstract EClass ConstrainableElement . . . . . . . . . . . . 245

CONTENTS IX

A.5.2. Abstract EClass Constraint . . . . . . . . . . . . . . . . . . . . 245A.5.3. EEnumeration Correctness . . . . . . . . . . . . . . . . . . . . 246A.5.4. Abstract EClass ModelingConstraint . . . . . . . . . . . . . . 246A.5.5. EClass TextualConstraint . . . . . . . . . . . . . . . . . . . . 247A.5.6. Abstract EClass VerifiableConstraint . . . . . . . . . . . . 247

A.6. EPackage muml::instance . . . . . . . . . . . . . . . . . . . . . . . . . 248A.6.1. EClass AssemblyConnectorInstance . . . . . . . . . . . . . 248A.6.2. EClass AtomicComponentInstance . . . . . . . . . . . . . . . 248A.6.3. Abstract EClass ComponentInstance . . . . . . . . . . . . . . . 250A.6.4. EClass ComponentInstanceConfiguration . . . . . . . . . 250A.6.5. EClass ContinuousPortInstance . . . . . . . . . . . . . . . . 251A.6.6. EClass CoordinationProtocolInstance . . . . . . . . . . . 251A.6.7. EClass DelegationConnectorInstance . . . . . . . . . . . . 252A.6.8. EClass DiscreteMultiPortInstance . . . . . . . . . . . . . 252A.6.9. Abstract EClass DiscretePortInstance . . . . . . . . . . . . 253A.6.10. EClass DiscreteSinglePortInstance . . . . . . . . . . . . 254A.6.11. EClass HybridPortInstance . . . . . . . . . . . . . . . . . . . 256A.6.12. Abstract EClass PortConnectorInstance . . . . . . . . . . . 256A.6.13. Abstract EClass PortInstance . . . . . . . . . . . . . . . . . . . 257A.6.14. EClass StructuredComponentInstance . . . . . . . . . . . . 258

A.7. EPackage muml::msgtype . . . . . . . . . . . . . . . . . . . . . . . . . 259A.7.1. EClass MessageType . . . . . . . . . . . . . . . . . . . . . . . . 259A.7.2. EClass MessageTypeRepository . . . . . . . . . . . . . . . . 260

A.8. EPackage muml::protocol . . . . . . . . . . . . . . . . . . . . . . . . . 261A.8.1. Abstract EClass AbstractCoordinationSpecification . . 261A.8.2. EClass ConnectorQualityOfServiceAssumptions . . . . 263A.8.3. EClass CoordinationProtocol . . . . . . . . . . . . . . . . . 263A.8.4. EClass Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264A.8.5. EClass RoleConnector . . . . . . . . . . . . . . . . . . . . . . . 265

A.9. EPackage muml::realtimestatechart . . . . . . . . . . . . . . . . . 267A.9.1. EClass AbsoluteDeadline . . . . . . . . . . . . . . . . . . . . 267A.9.2. EClass Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267A.9.3. EClass AsynchronousMessageEvent . . . . . . . . . . . . . . 267A.9.4. EClass Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269A.9.5. EClass ClockConstraint . . . . . . . . . . . . . . . . . . . . . 269A.9.6. Abstract EClass Deadline . . . . . . . . . . . . . . . . . . . . . . 270A.9.7. EClass DoEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270A.9.8. EClass EntryEvent . . . . . . . . . . . . . . . . . . . . . . . . . 270A.9.9. Abstract EClass EntryOrExitEvent . . . . . . . . . . . . . . . 271A.9.10. EClass EntryPoint . . . . . . . . . . . . . . . . . . . . . . . . . 271A.9.11. Abstract EClass Event . . . . . . . . . . . . . . . . . . . . . . . . 272A.9.12. EEnumeration EventKind . . . . . . . . . . . . . . . . . . . . . . 272

X CONTENTS

A.9.13. EClass ExitEvent . . . . . . . . . . . . . . . . . . . . . . . . . . 272A.9.14. EClass ExitPoint . . . . . . . . . . . . . . . . . . . . . . . . . . 272A.9.15. EClass Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274A.9.16. Abstract EClass PrioritizedElement . . . . . . . . . . . . . . 274A.9.17. EClass RealtimeStatechart . . . . . . . . . . . . . . . . . . . 275A.9.18. EClass Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279A.9.19. EClass RelativeDeadline . . . . . . . . . . . . . . . . . . . . 279A.9.20. EClass State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280A.9.21. Abstract EClass StateConnectionPoint . . . . . . . . . . . . 283A.9.22. Abstract EClass StateEvent . . . . . . . . . . . . . . . . . . . . 283A.9.23. EClass Synchronization . . . . . . . . . . . . . . . . . . . . . 284A.9.24. EClass SynchronizationChannel . . . . . . . . . . . . . . . . 284A.9.25. EEnumeration SynchronizationKind . . . . . . . . . . . . . . 285A.9.26. EClass Transition . . . . . . . . . . . . . . . . . . . . . . . . . 285A.9.27. Abstract EClass TransitionEvent . . . . . . . . . . . . . . . . 292A.9.28. Abstract EClass Vertex . . . . . . . . . . . . . . . . . . . . . . . 292

A.10.EPackage muml::types . . . . . . . . . . . . . . . . . . . . . . . . . . . 294A.10.1. EClass ArrayDataType . . . . . . . . . . . . . . . . . . . . . . . 294A.10.2. Abstract EClass DataType . . . . . . . . . . . . . . . . . . . . . . 294A.10.3. EClass PrimitiveDataType . . . . . . . . . . . . . . . . . . . . 295A.10.4. EEnumeration PrimitiveTypes . . . . . . . . . . . . . . . . . . 295A.10.5. EClass RangedPrimitiveDataType . . . . . . . . . . . . . . . 295

A.11.EPackage muml::valuetype . . . . . . . . . . . . . . . . . . . . . . . . 296A.11.1. EClass Cardinality . . . . . . . . . . . . . . . . . . . . . . . . 296A.11.2. EClass NaturalNumber . . . . . . . . . . . . . . . . . . . . . . . 296A.11.3. EClass Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299A.11.4. EDataType TimeUnit . . . . . . . . . . . . . . . . . . . . . . . . 300A.11.5. EClass TimeValue . . . . . . . . . . . . . . . . . . . . . . . . . . 300

A.12.EPackage actionlanguage . . . . . . . . . . . . . . . . . . . . . . . . . 302A.12.1. EClass ArrayInitializeExpression . . . . . . . . . . . . . 302A.12.2. EEnumeration AssignOperator . . . . . . . . . . . . . . . . . . 302A.12.3. EClass Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 302A.12.4. EClass Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304A.12.5. EClass DiscreteInteractionEndpointReference . . . . 305A.12.6. EClass DoWhileLoop . . . . . . . . . . . . . . . . . . . . . . . . 305A.12.7. EClass ForLoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306A.12.8. EClass IfStatement . . . . . . . . . . . . . . . . . . . . . . . . 306A.12.9. EEnumeration IncrementDecrementOperator . . . . . . . . 307A.12.10.EClass LocalVariableDeclarationStatement . . . . . . . 307A.12.11.Abstract EClass Loop . . . . . . . . . . . . . . . . . . . . . . . . . 308A.12.12.EClass NondeterministicChoiceExpression . . . . . . . . 308A.12.13.EClass OperationCall . . . . . . . . . . . . . . . . . . . . . . . 309

CONTENTS XI

A.12.14.EClass PositionSelector . . . . . . . . . . . . . . . . . . . . 310A.12.15.EEnumeration PositionSelectorKind . . . . . . . . . . . . . 310A.12.16.EClass ReturnStatement . . . . . . . . . . . . . . . . . . . . . 311A.12.17.EClass TriggerMessageExpression . . . . . . . . . . . . . . 311A.12.18.EClass TypedNamedElementExpression . . . . . . . . . . . . 311A.12.19.EClass WhileLoop . . . . . . . . . . . . . . . . . . . . . . . . . . 312

A.13.EPackage core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313A.13.1. Abstract EClass CommentableElement . . . . . . . . . . . . . . 313A.13.2. Abstract EClass ExtendableElement . . . . . . . . . . . . . . . 313A.13.3. Abstract EClass Extension . . . . . . . . . . . . . . . . . . . . . 316A.13.4. Abstract EClass NamedElement . . . . . . . . . . . . . . . . . . . 316A.13.5. Abstract EClass TypedElement . . . . . . . . . . . . . . . . . . . 316

A.14.EPackage core::expressions . . . . . . . . . . . . . . . . . . . . . . 318A.14.1. Abstract EClass Expression . . . . . . . . . . . . . . . . . . . . 318A.14.2. EClass TextualExpression . . . . . . . . . . . . . . . . . . . . 318

A.15.EPackage core::expressions::common . . . . . . . . . . . . . . . . 320A.15.1. EClass ArithmeticExpression . . . . . . . . . . . . . . . . . 320A.15.2. EEnumeration ArithmeticOperator . . . . . . . . . . . . . . . 321A.15.3. Abstract EClass BinaryExpression . . . . . . . . . . . . . . . 321A.15.4. EEnumeration ComparingOperator . . . . . . . . . . . . . . . . 321A.15.5. EClass ComparisonExpression . . . . . . . . . . . . . . . . . 322A.15.6. EClass LiteralExpression . . . . . . . . . . . . . . . . . . . . 322A.15.7. EEnumeration LogicOperator . . . . . . . . . . . . . . . . . . . 322A.15.8. EClass LogicalExpression . . . . . . . . . . . . . . . . . . . . 323A.15.9. EClass UnaryExpression . . . . . . . . . . . . . . . . . . . . . 323A.15.10.EEnumeration UnaryOperator . . . . . . . . . . . . . . . . . . . 323

A.16.EPackage storydiagrams . . . . . . . . . . . . . . . . . . . . . . . . . 325A.16.1. Abstract EClass Variable . . . . . . . . . . . . . . . . . . . . . . 325

A.17.EPackage storydiagrams::activities . . . . . . . . . . . . . . . . 326A.17.1. EClass Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . 326A.17.2. EClass ActivityCallNode . . . . . . . . . . . . . . . . . . . . 326A.17.3. EClass ActivityEdge . . . . . . . . . . . . . . . . . . . . . . . . 328A.17.4. EClass ActivityFinalNode . . . . . . . . . . . . . . . . . . . . 329A.17.5. Abstract EClass ActivityNode . . . . . . . . . . . . . . . . . . . 329A.17.6. EEnumeration EdgeGuard . . . . . . . . . . . . . . . . . . . . . . 330A.17.7. EClass ExceptionVariable . . . . . . . . . . . . . . . . . . . . 331A.17.8. EClass FlowFinalNode . . . . . . . . . . . . . . . . . . . . . . . 331A.17.9. EClass InitialNode . . . . . . . . . . . . . . . . . . . . . . . . 332A.17.10.EClass JunctionNode . . . . . . . . . . . . . . . . . . . . . . . . 332A.17.11.EClass MatchingStoryNode . . . . . . . . . . . . . . . . . . . . 332A.17.12.EClass ModifyingStoryNode . . . . . . . . . . . . . . . . . . . 332A.17.13.EClass OperationExtension . . . . . . . . . . . . . . . . . . . 333

XII CONTENTS

A.17.14.EClass StatementNode . . . . . . . . . . . . . . . . . . . . . . . 333A.17.15.Abstract EClass StoryNode . . . . . . . . . . . . . . . . . . . . . 334A.17.16.EClass StructuredNode . . . . . . . . . . . . . . . . . . . . . . 334

A.18.EPackage storydiagrams::activities::expressions . . . . . 335A.18.1. EClass ExceptionVariableExpression . . . . . . . . . . . . 335

A.19.EPackage storydiagrams::calls . . . . . . . . . . . . . . . . . . . . 336A.19.1. Abstract EClass Callable . . . . . . . . . . . . . . . . . . . . . . 336A.19.2. Abstract EClass Invocation . . . . . . . . . . . . . . . . . . . . 336A.19.3. EClass OpaqueCallable . . . . . . . . . . . . . . . . . . . . . . 338A.19.4. EClass ParameterBinding . . . . . . . . . . . . . . . . . . . . 339A.19.5. EClass ParameterExtension . . . . . . . . . . . . . . . . . . . 339

A.20.EPackage storydiagrams::calls::expressions . . . . . . . . . 340A.20.1. EClass MethodCallExpression . . . . . . . . . . . . . . . . . 340A.20.2. EClass ParameterExpression . . . . . . . . . . . . . . . . . . 340

A.21.EPackage storydiagrams::patterns . . . . . . . . . . . . . . . . . 343A.21.1. Abstract EClass AbstractLinkVariable . . . . . . . . . . . . 343A.21.2. Abstract EClass AbstractVariable . . . . . . . . . . . . . . . 345A.21.3. EClass AttributeAssignment . . . . . . . . . . . . . . . . . . 345A.21.4. EEnumeration BindingOperator . . . . . . . . . . . . . . . . . 346A.21.5. EEnumeration BindingSemantics . . . . . . . . . . . . . . . . 346A.21.6. EEnumeration BindingState . . . . . . . . . . . . . . . . . . . . 347A.21.7. EClass CollectionVariable . . . . . . . . . . . . . . . . . . . 347A.21.8. EClass Constraint . . . . . . . . . . . . . . . . . . . . . . . . . 348A.21.9. EClass InclusionLink . . . . . . . . . . . . . . . . . . . . . . . 348A.21.10.EClass LinkConstraint . . . . . . . . . . . . . . . . . . . . . . 349A.21.11.EEnumeration LinkConstraintType . . . . . . . . . . . . . . . 349A.21.12.EClass LinkVariable . . . . . . . . . . . . . . . . . . . . . . . . 350A.21.13.EClass MatchingPattern . . . . . . . . . . . . . . . . . . . . . 351A.21.14.EClass MaybeLink . . . . . . . . . . . . . . . . . . . . . . . . . . 351A.21.15.EClass ObjectVariable . . . . . . . . . . . . . . . . . . . . . . 351A.21.16.EClass Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352A.21.17.EClass PrimitiveVariable . . . . . . . . . . . . . . . . . . . . 353A.21.18.EClass StoryPattern . . . . . . . . . . . . . . . . . . . . . . . . 353

A.22.EPackage storydiagrams::patterns::expressions . . . . . . . 355A.22.1. EClass AttributeValueExpression . . . . . . . . . . . . . . 355A.22.2. EClass CollectionSizeExpression . . . . . . . . . . . . . . 355A.22.3. EClass ObjectVariableExpression . . . . . . . . . . . . . . 357A.22.4. EClass PrimitiveVariableExpression . . . . . . . . . . . . 357

A.23.EPackage storydiagrams::templates . . . . . . . . . . . . . . . . . 358A.23.1. EClass PropertyBinding . . . . . . . . . . . . . . . . . . . . . 358A.23.2. EClass TemplateBinding . . . . . . . . . . . . . . . . . . . . . 359A.23.3. EClass TemplateSignature . . . . . . . . . . . . . . . . . . . . 359

CONTENTS XIII

B. Action Language XText Grammar 361

CONTENTS XV

Contributors and Acknowledgments

MECHATRONICUML is the result of many people’s work, which we are greatly indebted to.

Current Contributors

Today, Prof. Dr. Wilhelm Schäfer is the chair of MECHATRONICUML. It is jointly developedby the Software Engineering Group of the University of Paderborn, the Project GroupMechatronic Systems Design of Fraunhofer IPT, and the Software Engineering Group ofChalmers Technical University and University of Gothenburg. As a consequence, the authorsof this document are members of these three groups.

We thank the PhD students Anas Anis, Christian Brenner, Jens Frieben, David Schmelter,and Lars Stockmann for reviewing this document and for the helping in the marketing ofMECHATRONICUML (in aphabetical order).

Moreover, many students helped us to improve the document and to develop our modelingtool-suite for MECHATRONICUML, the Fujaba Real-Time Tool Suite. In particular, we thankin alphabetical order Ingo Budde, Andres Dann, Johannes Geismann, Marcus Huewe, JenniferKane, David Schubert, and Christian Stroh.

Former Contributors

Prof. Dr. Holger Giese, now Professor at the Hasso-Plattner-Institut at the University ofPotsdam, started MECHATRONICUML while he was with the Software Engineering Group atthe University of Paderborn. He designed the initial MECHATRONICUML approach (calledUML-RT) and developed the foundations. Thus, he greatly influenced the current state ofMECHATRONICUML.

Additional work has been done by the following doctoral students during their timeat the Software Engineering Group in Paderborn (in alphabetical order): Dr. SvenBurmester [Bur06], Tobias Eckardt, Dr. Stefan Henkler [Hen12], Prof. Dr. MartinHirsch [Hir08], Renate Löffer, Dr. Claudia Priesterjahn [Pri13], Julian Suck, Dr. FlorianStallmann [Sta08], Dr. Daniela Schilling [Sch06], and Prof. Dr. Matthias Tichy [Tic09].

We thank the following people who contributed as authors to earlier versions of thisdocument: Christian Brenner, Christopher Brink, Thomas Gewering, Julian Suck, and OliverSudmann.

Additionally, we thank all former students of the Software engineering Group of Paderbornwho helped us to improve previous versions of the document or who developed previousversion of the Fujaba Real-Time Tool Suite. In particular, we thank Jannis Drewello andBoris Wolf.

XVI CONTENTS

Involved ProjectsMECHATRONICUML is and was partially developed . . .

• . . . in the course of the Special Research Initiative 614 - Self-optimizing Concepts andStructures in Mechanical Engineering - University of Paderborn, and was published onits behalf and funded by the Deutsche Forschungsgemeinschaft.• . . . in the course of the Special Research Initiative 901 - On-The-Fly Computing -

University of Paderborn, and was published on its behalf and funded by the DeutscheForschungsgemeinschaft.• . . . in the project ENTIME: Entwurfstechnik Intelligente Mechatronik (Design Methods

for Intelligent Mechatronic Systems). The project ENTIME was funded by the stateof North Rhine-Westphalia (NRW), Germany and the EUROPEAN UNION, EuropeanRegional Development Fund, ‘Investing in your future’.• . . . in the Leading-Edge Cluster Intelligent Technical Systems OstWestfalenLippe (it’s

OWL). The Leading-Edge Cluster is funded by the German Federal Ministry ofEducation and Research (BMBF).• . . . by PhD students that were funded by the International Graduate School Dynamic

Intelligent Systems.

CONTENTS XVII

Document Changelog

Since this document is updated regularly, we list here the major changes compared to thepreceding versions.

Version 0.4

Version 0.4 includes the following major changes compared to the preceding version 0.3.

General

• Changed title from “The MechatronicUML Design Method – Process, Syntax andSemantics” to “The MechatronicUML Design Method – Process and Language forPlatform-Independent Modeling”.• The document now focuses on the platform-independent modeling. Requirements and

platform-specific modeling will be published in separate technical documents.• Revised Chapter “Introduction”• Revised Chapter “Overview”• Revised Chapter “Modeling Language”• Revised Chapter “Complete Example”• Revised Chapter “Conclusions and Future Work”•

Document Structure

• Reordered the Sections of Chapter “Modeling Language”• Added Section “Data Type Specification” in Chapter “Modeling Language”• Extracted Section “Action Language” from Section “Real-Time Statechart”• Added Chapter “Modeling Extensions for Reconfigurable Systems”

– Added Section “Requirements”– Added Section “Reconfiguration in Real-Time Coordination” Protocols– Added Section “Component Model Extensions”– Added Section “Component Story Diagrams”

• Extracted Section “Acknowledgements” from Section “Conclusions and Future Work”and moved it before the “Changelog”

Modeling Language

• Separated concrete syntax description from abstract syntax and semantics for eachmodeling element.• Defined the allowed data types of MECHATRONICUML.

XVIII CONTENTS

• Message interfaces have been removed from MECHATRONICUML. Instead, developerscan use message type repositories for grouping message types. Ports and Roles directlyrefer to sets of message types they send or receive.• Revised Action Language and its Grammar• Real-Time Coordination Patterns are now called Real-Time Coordination Protocols.• Added descriptions about buffers for incoming messages of a role of a Real-Time

Coordination Protocol• Connectors of Real-Time Coordination Protocols now specify quality of service

assumptions.• Real-Time Coordination Protocol: Multi-Roles are always considered to be ordered.

Since the ordered property is implicitly true, we removed it.• Revised and extended concept for specifying behaviors of multi roles, e.g., replaced

operations for exploiting the order of a multi role by keywords• Revised Real-Time Statecharts (new contents, new order, new images)• Real-Time Statechart: Synchronization Channels no longer define parameters because

synchronizations are part of the precondition for firing a transition.• Component Model: Hybrid Ports now only specify a sampling interval, but no Real-

Time Statechart because the Real-Time Statechart is always the same and is only neededfor model checking.• Continuous and hybrid ports define expressions for initialization.• Continuous and hybrid in-port instances can now fork the information they send.• Extracted the deployment section into a new document that defines the platform-specific

design method. We will publish this document as a technical report, too.• Revised Metamodel

Version 0.3

Version 0.3 includes the following major changes compared to the preceding version 0.2.

General

• Changed title from “The MechatronicUML Method – Process, Syntax and Semantics”to “The MechatronicUML Design Method – Process Syntax and Semantics”.• Added Changelog

Overview

• Change of process overview: If the formal use case specification is changed (Step 5b),instead of repeating only Steps 3, 4a, and 5a, the whole process needs to be repeated.

CONTENTS XIX

Modeling Languages

• Real-Time Coordination Protocol: Multi roles have a property ordered which impliesan order of the sub-role instances at run-time• Message Interfaces: Made concrete syntax of parameter definition consistent to the

concrete syntax of parameter definitions in Real-Time Statechart operations• Real-Time Statechart: Changed concrete syntax for trigger messages at a transition:

Parameters and their types are no longer displayed.• Added new Section about Action Language for Real-Time Statechart.• Revised and extended concept for specifying behaviors of multi roles, e.g., added

operations for exploiting the order of an ordered multi-role• Component parts of structured components now have a name.• Component instances are now typed over a component type and a component part.• Changed specification for deployment.• Adapted new concrete syntax to all figures

Development Process

• Adapted MECHATRONICUML process to use Modal Sequence Diagrams as a formalbasis for the application scenarios. Affected processes: integration into developmentprocess for advanced mechatronic systems, overall MECHATRONICUML process,determine coordination pattern, model new coordination pattern.• Distinguished between the principle solution and the system model.• Simplified the subprocess “model new coordination pattern”.

Complete Example

• Adapted new concrete syntax to all figures• Removed errors in the Real-Time Statecharts• Changed deployment example

Theoretical Background

• Updated description of the compositional verification approach

Related Work

• Added related work concerning “Contract-Based Design”• Added related work concerning “Behavioral Connectors”• Added related work concerning “Multi-Agent-Systems”• Extended again related work concerning “Specification Languages for Systems

Engineering”• Extended again related work concerning “Software Component Models”

XX CONTENTS

• Extended again related work concerning “Specifications of Self-Adaptive Systems”• Extended related work concerning “Formal Models for Modeling of Real-time

Behavior”

Meta-model Documentation

• Replaced use of EAttribute, EOperation, EParameter by own meta-classes for attributes,operations, and parameters• Added type model for defining simple data types and array data types• Added action language meta-model

Action Language XText Grammar

• Added this new appendix for the grammar of our action language

Version 0.2Version 0.2 includes the following major changes compared to the preceding version 0.1.

General

• Changed title from “MechatronicUML – Syntax and Semantics” to “TheMechatronicUML Design Method – Process Syntax and Semantics”.

Overview

• Added Chapter MECHATRONICUML Overview

Modeling Languages

• Rewrote section Real-Time Coordination Patterns to add further details and to improveunderstandability• Improved images and explanations in section Real-Time Statechart• Improved description for Component Model• Extracted Hardware Components from section Component Instance Configuration and

defined an own section for them

Development Process

• Defined an own chapter for the development process

Complete Example

• Corrected several errors

CONTENTS XXI

Theoretical Background

• Added chapter for describing the theoretical background

Related Work

• Extended related work concerning “Specification Languages for Systems Engineering”• Extended related work concerning “Software Component Models”• Extended related work concerning “Specifications of Self-Adaptive Systems”


• Improved package muml::model::component• Added Package muml::model::deployment• Deleted class Infinity from package muml::model::core• Improved package muml::model::instance• Improved package muml::model::pattern• Improved package muml::model::realtimestatechart

Version 0.1The initial version of this document.

Chapter 1.

Introduction

Nowadays, software drives all kinds of systems that interact with their physicalenvironment [GRS14]. Examples for such systems are autonomously driving cars or trains,self-coordinating robots, or production systems in smart factories. These systems are referredto as mechatronic systems or cyber-physical systems (CPS) [aca11]. The number of suchmechatronic systems in our world is growing rapidly [Pal08].

Mechatronic systems are developed in a joint effort by mechanical engineers, electricalengineers, control engineers, and software engineers [VDI04a]. Innovation in mechatronicsystems is largely driven by embedded software. For example, it has been estimated that thecurrent generation of upper class cars will contain about one gigabyte of software [PBKS07].

Mechatronic systems pose a challenge for software development as their software has toexecute in a safety-critical, real-time environment, i.e., human life may be harmed if thesoftware does not always produce correct results on time. As a consequence, the software mustbe correct in its first release. Therefore, incremental testing-based development approachesare not applicable to such software. Instead, a software engineering method for mechatronicsystems has to provide effective and efficient means to develop the software and prove itscorrectness.

The software development is further complicated by additional characteristics ofmechatronic systems.• Software controls continuous physical processes, e.g., the movement and braking of

a vehicle. Thus, the software is bound to physical laws that imply further real-timeconstraints.• Mechatronic and especially cyber-physical systems involve several autonomous,

coordinating subsystems, e.g., in a platoon of vehicles. Such systems are not workingin isolation but heavily interact and coordinate each other. This requires asynchronousmessage communication realized by discrete, state-based software, which needs to becarefully integrated with continuous controllers [Kil05] for controlling the dynamicbehavior of the physical system parts.• Mechatronic systems have to adapt flexibly to changing environments, e.g., additional

autonomous vehicles willing to join a platoon, or failing hardware systems. Thisrequires the integration of self-X behavior [CdLG+09], such as self-adaptation, self-optimization, self-organizing, and self-healing.

1

2 CHAPTER 1. INTRODUCTION

• Finally, the software runs on embedded devices that limit the available hardwareresources.

A software engineering method for mechatronic systems needs to treat the combination ofthese characteristics.

All these trends lead to complex mechatronic systems whose structure and behavior cannotbe fully determined a priori. The key issue for the successful development of such systems ishandling the inherent complexity. Consequently, developers require appropriate developmentmethods and languages as well as development tools.

The key principles for handling the complexity are abstraction and reuse. Model-drivendevelopment approaches enable abstraction from technical implementation details and, thus,allow for verification and validation, e.g., concerning safety and availability. Further, recurringsolutions are stored as reusable development artifacts.

With MECHATRONICUML, we provide a model-driven method for the developmentof the software embedded in mechatronic systems. MECHATRONICUML takes up theaforementioned principles of abstraction and reuse and provides a modeling language andprocess based on concepts of the well-known UML [Obj09]. Thereby, MECHATRONICUMLsupports the development of structural as well as behavioral aspects of mechatronic software.It adapts the component-based approach [Szy98] for software development. The behavior ofcomponents is specified in a state-based manner using Real-Time Statecharts, which are acombination of UML state machines and Timed Automata.

MECHATRONICUML particularly focuses on the software for the real-time coordinationof mechatronic systems. The coordination is achieved by exchanging messages betweensystems which amounts to complex discrete state-based behavior in each of the systems. Inaddition, the coordination affects the dynamic behavior of the physical parts of the systems,which are controlled by continuous control software. Consequently, MECHATRONICUMLprovides means for the safe integration of the discrete state-based coordination behavior withthe continuous software of feedback controllers. MECHATRONICUML introduces reusableReal-Time Coordination Protocols as first-class modeling constructs for formalizing the real-time coordination and for separating it from the rest of the system behavior. Thereby, Real-Time Coordination Protocols facilitate the reuse of established solutions and help to reducedevelopment time and effort.

In order to allow mechatronic systems to adapt to a changing environment and to coordinateand communicate with changing communication partners, MECHATRONICUML supportsmodeling the exchange of software components at runtime. MECHATRONICUML therebylays the ground for explicitly modeling self-X behavior.

Besides the precise modeling of embedded software, another major aim ofMECHATRONICUML is the formal verification of safety critical properties of mechatronicsystems, which often operate in safety-critical contexts. However, even a single, isolatedmechatronic system cannot be formally verified with respect to safety properties by classicaltechniques in reasonable time. The problem increases when verifying modern mechatronicsystems, which coordinate and communicate with other systems in an ad-hoc fashionand/or integrate self-X behavior. MECHATRONICUML again draws on the separation of

1.1. EXAMPLE 3

coordination behavior from the single component behavior. This separation enables acompositional verification by partitioning the system’s state space into verifiable chunks, i.e.,Real-Time Coordination Protocols and single component behavior. Real-Time CoordinationProtocols and single component behavior can be verified independently of each otherusing the model checker UPPAAL1. Thus, by reusing Real-Time Coordination Protocols,MECHATRONICUML enables reusing the verification results without repeatedly reverifyingcommunication behaviors.

This technical report extends the previous versions [BBB+12, BBD+12, BDG+11]. Itconsolidates the older publications [Bur02, Gie03, GB03, GST+03, GTB+03, BGT05,GHH+08, EHH+13, SSGR11, HPB12] and theses [Hir04, Bur06, Hir08] in a single document.In [GS12], a consolidated version of MECHATRONICUML up to 2007 is presented whoseconcepts are continuously merged into this technical report. We present the current version ofMECHATRONICUML in detail and give formal specifications for abstract and concrete syntaxas well as an informal description of its semantics.

The report is structured as follows. In the next section, we introduce a running example. InChapter 2, we provide a brief overview of the MECHATRONICUML method. This overviewincludes a short description of the development process as well as the modeling languagesof MECHATRONICUML. Chapter 3 describes informally the syntax and the semantics of themodeling language used in MECHATRONICUML based on the running example. Chapter 4extends the modeling language by run-time reconfiguration of software component structures.In Chapter 5, we illustrate the development process of MECHATRONICUML. The completemodels of the running example are presented in Chapter 6. After a discussion of relatedapproaches in Chapter 7, we conclude with an outlook on future work in Chapter 8.Appendix A contains a thorough definition of the abstract syntax. Finally, appendix B containsthe Xtext grammar for the action language of our Real-Time Statecharts.

1.1. Example

In this document, we will use an environment exploration scenario as an ongoing example inwhich several autonomous robots have to explore an unknown environment.

As robots, we will use the intelligent miniature robot BeBot2 (see Figure 1.1). The BeBot isa test carrier for intelligent machines and cooperative networks developed at the Heinz NixdorfInstitute at the University of Paderborn3.

As shown in Figure 1.1, the BeBot uses two chain-drives with DC motors to move around.It has twelve infrared-sensors and a front camera to sense its environment. The BeBot mayutilize a Bluetooth and a wireless LAN module for communicating with other BeBots. Thefunctionality of the BeBot may be extended using the USB ports. In our example, we extend

1http://www.uppaal.com2http://wwwhni.uni-paderborn.de/en/priority-projects/intelligent-miniature-robot-bebot3http://wwwhni.uni-paderborn.de/en/

http://www.uppaal.com


the functionality of the BeBot by a GPS-Receiver for detecting the current position of theBeBot.

Figure 1.1.: BeBot

In our scenario, several BeBots explore an unknown area as shown in Figure 1.2. Forreasons of simplicity, we assume that the area is unbounded and contains no obstacles. Wewill enhance our example with obstacles in future versions of this document in order to makethe scenario more realistic. At present, the BeBots only have the task to explore the areawithout colliding with each other.

The BeBot performs a step-wise movement instead of moving at a constant speed. In eachstep, the BeBot performs the following operations: it chooses randomly a target positionwithin a fixed distance around it to move to. Then, the BeBot turns and moves to this position.After reaching the target position, the BeBot stops and performs another step as describedbefore.

A BeBot may only move to its intended target position if it cannot collide with anotherBeBot while moving there. That decision requires knowledge about the positions of the otherBeBots in the area. While a BeBot may use its GPS sensor for obtaining its current position,it cannot sense the position of the other BeBots by itself. Therefore, one of the BeBots acts asa position distributor. Each BeBot transmits regularly its own current position to the positiondistributor. The position distributor stores the current positions of all BeBots and sends themregularly to all BeBots. This ensures that each BeBot receives regular updates of the currentpositions of all BeBots in the area.

The BeBot uses the position data of the other BeBots to avoid collisions. In each step, theBeBot compares its calculated target position to the positions of the other BeBots and decideswhether a collision may occur or not. If a collision can occur, the BeBot does not move to itstarget position, but remains at its current position.

In principle, the position distributor may be elected during run-time. In case of a failurein the position distributor, the position distributor may also be reelected during run-time. Atpresent, we restrict ourselves to a preset position distributor and support no reelection at run-

1.2. BENEFITS FOR THE DEVELOPER 5

Figure 1.2.: Area of the Exploration scenario

time. However, we plan to extend our example to capture such behavior in a future version ofthis document.

1.2. Benefits for the Developer

Using MECHATRONICUML, the developer benefits from all advantages of model-baseddevelopment: abstraction, reuse, decomposition, verification, and simulation. The real-timebehavior of components and their real-time communication protocols are specified and verifiedon type level. Components and communication protocols (connecting the components) maybe instantiated multiple times and thereby used multiple times. For example, the protocolwhich specifies the exchange of position data is specified only once, but instantiated on allpairs of BeBots that need to exchange position data.

Behavior is modeled by state-machines that are extended by clocks and constraints overthe clock to allow for the specification of timed behavior. The state-based modeling of thebehavior and the component-based architecture provide an abstraction from the source code.This, in turn, allows for an overview of the whole system in different levels of abstraction andthereby facilitates the understanding of the system.

The verification helps the developer guaranteeing all required safety and liveness propertiesof the embedded software including timing properties. An example of such a property is thesuccessful avoidance of collisions by guaranteeing a safe and timely exchange of position data.


Source code may be generated from the MECHATRONICUML models and then used in asimulation to check, for example, if reaction times are short enough to stop a BeBot on timebefore a collision happens.

Chapter 2.

MECHATRONICUML Overview

The MECHATRONICUML method supports the model-driven design of the discrete-eventand continuous time software of self-adaptive mechatronic systems. The key conceptsof MECHATRONICUML are a component-based system model which enables scalablecompositional verification [GTB+03] of safety-properties, the model-driven specification andverification of reconfiguration operations, and the integration of the discrete software withthe continuous software of the feedback controllers of mechatronic systems. Therefore,MECHATRONICUML provides a set of domain specific visual languages (DSVL) as well as adefined development process.

Figure 2.1 provides an overview of the development process of MECHATRONICUML whichwe will briefly illustrate in the following. For a detailed description of the developmentprocess, please refer to Section 5.

Formal Use

Cases

Requirements

Platform-

Independent

Software Model

Software Artifacts

(Code, Binary)

Artifact Process Step Integrated Analysis Step

Legend

Derive

Components

2.1

Determine

Coordination Protocols

Timed Model

Checking

2.2

Determine

Component Behavior

2.3

Timed Refinement

Check

Integrate with Controller

and Environment

2.4

Integrated System

Simulation

Design Platform-

Specific Software

4

Design SW/HW

Platform

3Design Platform-

Independent Software

Model

2

Specify Formal

Requirements

1

Figure 2.1.: Overview of the MECHATRONICUML Process

The starting point of system development is typically a set of informal natural languagerequirements. Natural language requirements are not formally analyzable due to variouspossible interpretations of natural language. Consequently, Step 1 of MECHATRONICUML isthe translation of informal requirements into formal use cases, which are modeled by ModalSequence Diagrams [HM07]. Modal Sequence Diagrams are a formalized variant of UMLsequence diagrams [Obj09] and specify the interactions among system elements as well asreal-time constraints on these interactions. Modal Sequence Diagrams are used to analyze

7

8 CHAPTER 2. MECHATRONICUML OVERVIEW

inconsistencies and contradictions by using synthesis or simulation based approaches [Gre11].A detailed description of how to use Modal Sequence Diagrams in MECHATRONICUML willbe added to future versions of this document.

In Step 2, the formal use cases of Step 1 are used to derive the platform-independentsoftware model. Step 2 consists of four substeps.

In Step 2.1, we derive the initial set of components that describes the system structure.A component is a software entity that encapsulates a part of the system behavior, whichimplements a certain function. Each component defines a set of external interaction points,called ports, for accessing its functionality. In contrast to other component-based approaches[Szy98, LW07], MECHATRONICUML employs active components that execute a behaviorspecification in a single task. The component model is structured hierarchically: Componentsare either atomic components, i.e., they are implemented directly (atomic components) orthey are structured components, i.e., they are decomposed into further components. Onlyatomic components have a behavior. For a description of the component model, please referto Section 3.6.

Feedback controllers are integrated as continuous components into the component model.MECHATRONICUML provides no behavior specification for feedback controllers. Instead,we assume that this behavior is specified by a control engineering tool like CamelView orMATLAB/Simulink.

In Step 2.2, the Real-Time Coordination Protocols are specified. Real-TimeCoordination Protocols define the communication between components and consist ofmultiple communication partners, called roles. Roles are linked by connectors. For adescription of Real-Time Coordination Protocols, please refer to Section 3.3.

Components and Real-Time Coordination Protocols are instantiated in component instanceconfigurations as component instances and port instances. The port instances the roles ofReal-Time Coordination Protocols and thereby the connectors between the respective rolesconnect the refining port instances. In this way, a software architecture is defined which isrepresented by a component instance configuration. For a description of component instanceconfigurations, please refer to Section 3.7.

The behavior of the roles of a Real-Time Coordination Protocol is specified by Real-TimeStatecharts. Real-Time Statecharts are a combination of UML state machines [Obj09] andtimed automata [DM01, BY03, AD94]. In Real-Time Coordination Protocols, Real-TimeStatecharts specify the message exchange of the roles with respect to the real-time propertiesthat the roles must obey. The safety and liveness properties of each Real-Time CoordinationProtocol is verified formally using timed model checking [GTB+03, BGHS04]. For a detaileddescription of Real-Time Statecharts, please refer to Section 3.4.

In Step 2.3, the Real-Time Coordination Protocols of Step 2.2 are used to determine thebehavior of the components that were identified in Step 2.1. First, roles of Real-TimeCoordination Protocols are assigned to the components’ ports which then refine the rolebehavior. This means, the ports implement the external behavior of the components asspecified in the role behavior. The refinement has to respect rot role behavior (must not addpossible behavior or block guaranteed behavior) and additionally das to respect the guaranteed

9

behavior of the roles given by their [GTB+03]. The correct refinement is verified automaticallyby a refinement check [BHSH13].

The internal behavior of atomic components is derived from the Real-Time Statecharts oftheir ports. Each atomic component has exactly one Real-Time Statechart that specifies itsinternal behavior, which for example resolves dependencies between the port behaviors. Fora detailed description of the behavior of atomic components, please refer to Section 3.6.1.4.The component is then formally verified for deadlock freedom to ensure that all ports of acomponent communicate safely with each other.

We now apply the compositional verification approach of MECHATRONICUML. Real-TimeCoordination Protocols have already been verified in Step 2.2. In this step, the verifiedcorrectness of the Real-Time Coordination Protocols with respect to the safety properties isused to verify each component separately. Compositional verification enables the verificationof Real-Time Coordination Protocols and components isolated from each other and therebyavoids verifying a large system in a single step which is, in general, infeasible. Forbackground information on the compositional verification theorem, we refer to the definitionof Giese [Gie03].

In Step 2.4, the model of the discrete behavior is integrated with the feedback controllersof the mechatronic system. The formal verification of a correct integration of the controllers,however, is not feasible for real-world systems [ERNF12]. Instead, we simulate the systemmodel in the respective control engineering tools [HPR+12, HRS13, PDM+14]. Suchsimulation requires a complete instance of the specified system including its controllers.MECHATRONICUML supports such instances by means of component instance configurationswhich are discussed in detail in Section 3.7.

If the verification of the components or the simulation of the whole system fails, either thesystem model or the formal requirements need to be changed. This requires the repetition ofSteps 1 to 2.4.

The model-driven design and verification of reconfiguration is not explained in thisdocument. For now, we refer to [EHH+13, HPB12, THHO08, BGO06] for information onreconfiguration. A detailed description, however, will be added to future versions of thisdocument.

Figure 2.2 summarizes the modeling languages that are used during the developmentand their relationships. Modal Sequence Diagrams define the formal requirements of Real-Time Coordination Protocols. Real-Time Coordination Protocols are used to model thecommunication behavior of the components of the system. We use Real-Time Statechartsto define the behavior of the roles of Real-Time Coordination Protocols. The messages thatare exchanged between the roles are declared formally by message types (cf. Section 3.2).

The components’ ports instantiate and refine Real-Time Coordination Protocols by addinginternal computations. We distinguish components into atomic components and structuredcomponents. Structured components are composed of a set of other components while atomiccomponents have a behavior. This behavior is, again, specified by Real-Time Statecharts.Components are instantiated in a component instance configuration.

10 CHAPTER 2. MECHATRONICUML OVERVIEW

MechatronicUML Requirements Language

MechatronicUML Design Language

for Platform-Independent Modeling (PIM)

Component

Structured

Component

Atomic

Component

Real-Time

Coordination

Protocol

Real-Time

Statechart

Message Type

Specification

Component

Instance

Configuration

instantiate

+

refine

behavior

define

communication

behavior of

define

behavior of type

asynchronous

messages using

composed

of

instantiate

define

behavior of

Modal

Sequence

Diagrams

define formal

requirements for

Modeling Language... Artifact Relationship

Legend

Figure 2.2.: Overview of the Modeling Languages used in MECHATRONICUML

In conclusion, MECHATRONICUML provides a component-based system model thatseparates components and their interactions by means of Real-Time Coordination Protocols.This separation is the key enabler for the compositional verification theorem which permitsthe formal verification of large systems. MECHATRONICUML supports the developmentof discrete event and time continuous software for mechatronic systems and the integrationof models of feedback controllers by means of continuous components. Furthermore, thecorrect timing behavior of reconfiguration of feedback controllers at runtime may be analyzedformally [Bur06, Hir08].

Chapter 3.

Modeling LanguageIn this chapter, we will introduce the different modeling formalisms that MECHATRONICUMLoffers. First, we introduce our data type concept in Section 3.1. Then, we introducemessage types that may be used for the asynchronous communication. In Section 3.3, weintroduce our contract-specification for the asynchronous message-based coordination calledReal-Time Coordination Protocols. The behavior of the coordinating entities is specifiedby Real-Time Statecharts (cf. Section 3.4), a combination of UML Statemachines [Obj09]and (UPPAAL) timed automata [AD94]. For specifying executable behavior expressions andboolean evaluations, we introduce our action languge in Section 3.5. In Section 3.6, weintroduce the MECHATRONICUML component model, which uses Real-Time CoordinationProtocols and Real-Time Statecharts. Finally, MECHATRONICUML provides an instancemodel to specify concrete system configurations which we explain in Section 3.7.

3.1. Data Type SpecificationMECHATRONICUML has an own data type concept. We distinguish between (i) primitivedata types, (ii) ranged primitive data types, (iii) array data types, and (iv) component modeldata types (i.e., data types that originate from our component model).

3.1.1. Primitive Data TypeIn the following, we list the primitive data types that MECHATRONICUML currently supports.They are based on the primitive types of Java. All primitive data types have the default value0.

Void Allows no values and is only used to define that an operation returns without a value.

Boolean Allows the values true false

Byte Contains by default a 8 Bit signed Integer from -128 to 127

Short Contains by default a 16 Bit signed Integer from -32,768 to 32,767

Int Contains by default a 32 Bit signed Integer from -2.147.483.648 to 2.147.483.647

11

12 CHAPTER 3. MODELING LANGUAGE

Long Contains by default a 64 Bit signed Integer from -9.223.372.036.854.775.808 to9.223.372.036.854.775.807

Double Contains by default a 64 Bit floating point number (1 bit for sign, 11 bits for theexponent, 52 for the fraction) with 15 significant decimal digits precision.

3.1.2. Ranged Primitive Data Type

A developer may define ranged primitive data types. Such a data type consists of a primitivedata type that has a lower and upper bound. The lower and upper bound may only constrainthe default value range, but not extend it.

3.1.3. Array Data Type

An array data type enables to store an indexed value list of a defined MECHATRONICUMLdata type, i.e., each value has the same data type.

The number of values is defined by the cardinality of the array. The values of thearray are accessed by their indexes. For a cardinality of n, the indexes range from 0 ton − 1. The developer can define a cardinality between 1 and the maximum value of Long(9.223.372.036.854.775.807).

As an array data type is a data type itself, the developer can define multi-dimensional arrays.Each dimension of an array may specify an own cardinality. As an restriction all dimensionsof one level need to reference the same data type.

3.1.4. Component Model Data Type

The components that are created as part of a MECHATRONICUML model (cf. Section 3.6)provide a set of data types, called component model data types.

A developer may use component model data types for (1) message parameters, (2) variablesin Real-Time Statecharts, and, in particular, (3) for specifying reconfigurations by componentstory diagrams (cf. Section 4.3). In the following, we list the elements of our componentmodel that also serve as component model data types:

Role A developer can use this data type for synchronization inside the behavior of a multi-role (cf. Section 3.4.11) and for reconfiguring the multi-role (cf. Section 4).

Port A developer can use this data type for synchronization inside the behavior of a multi-port (cf. Section 3.4.11), for reconfiguring the multi-port (cf. Section 4.2.1.2), and fortyping port variables in a component story diagram (cf. Section 4.3).

Component A developer can use this data type for typing variables referring to componentsin a component story diagram (cf. Section 4.3).

3.1. DATA TYPE SPECIFICATION 13

Component Part A developer can use this data type typing variables referring to embeddedcomponent parts of a structured component in a component story diagram (cf.Section 4.3).


3.2. Message Type Specification

Message types are types of messages that may be exchanged between the roles of Real-TimeCoordination Protocols (cf. Section 3.3) and the ports of components (cf. Section 3.6).Therefore, each role and port refers to a set of message types that it sends or receives. Sincemessages are always attached to a role or port, they are considered as second class objects inMECHATRONICUML. Message types can be grouped into message type repositories, e.g., forcollecting all message types used in a Real-Time Coordination Protocol in a single container.Besides their grouping function, message type repositories have no further semantics.

3.2.1. Message Type Repository

A message type repository contains a set of message types for asynchronous messages thatmay be exchanged between the roles of a Real-Time Coordination Protocol or between theports. Each message type repository specifies a name. The names of all message typerepositories are recommended to be unique with a project although it is not required. Amessage type repository must contain at least one message type.

Concrete Syntax of a Message Type Repository

Figure 3.1 shows an example of a message type repository Delegation containing threemessage types with a varying number of parameters. The message type repository groupsall message types that may be used in a Real-Time Coordination Protocol for delegating a taskand receiving an answer if the task was successful or not.

Delegation

check(int[2] target, bool priority)

accepted()

declined(int errorID)

message type

repository

message

type

name of

message type repository

parameter

Figure 3.1.: Concrete Syntax Example of a Message Type Repository and Message Types

Message type repositories are visualized as rectangles with two compartments that areseparated by a horizontal line. The upper compartment contains the name of the message typerepository, the lower compartment contains a list of message types where each line containsone message type.

3.2. MESSAGE TYPE SPECIFICATION 15

3.2.2. Message TypeA message type declares a name and an ordered parameter list for an asynchronous message.The names of all message types need to be unique within a system.

Each parameter specifies a name and its concrete type. The parameter names of a messagemust be unique. The parameter list is optional, i.e., a message type may also declare noparameters.

Concrete Syntax of a Message TypeIn our concrete syntax, a message type is represented as a string adhering to the followingEBNF. Elements which have the prefix “#” are references to the meta model elements of classMessageType.

< message type > : : = #name ’ ( ’ [ ] ’ ) ’ : : = | ’ , ’ : : = # p a r a m e t e r s [ i ] . t y p e . name # p a r a m e t e r s [ i ] . name

In Figure 3.1, the message type repository Delegation contains the message types check,accepted, and declined. The message type check specifies two parameters named targetand priority. target is of type integer array with length 2. priority is of data type Boolean.The message type accepted specifies no parameters. The message type declined defines theparameter errorId which is of data type Int.

Thus, the concrete syntax of a message type is similar to the concrete syntax of a methoddeclaration in UML [Gro10b].


3.3. Real-Time Coordination Protocol

The discrete interaction of components in MECHATRONICUML takes place via discrete portsthat exchange asynchronous messages. Due to the asynchronicity, discrete ports must notblock while sending and receiving messages. Furthermore, by storing incoming messages intoa buffer first, discrete ports may delay to consume the message. However, the developer maydefine hard deadlines for consuming messages. For enabling a loose coupling between thediscrete ports, MECHATRONICUML does not just provide message interfaces that define themessages the discrete port can send and receive. Instead, MECHATRONICUML provides richcontracts that focus on the whole coordination via message-based communication includinghard real-time constraints and safety-critical aspects. We call these contracts Real-TimeCoordination Protocols. Components that agree to this contract must always obey it.

Real-Time Coordination Protocols define – at application level – the behavior of thecoordination that is defined using communication, e.g., when must which message be sentor received. Thus, they are at a more abstract level than communication protocols like TCP/IPthat define basic application-independent data exchange. For the remainder of this section, wewill use the term “coordinate” for addressing the application-specific communication.

A Real-Time Coordination Protocol consists of the participants of the coordination – we callthem roles (cf. Section 3.3.2) – and the role connector that defines the message transmissionassumptions (cf. Section 3.3.3). For example, a Real-Time Coordination Protocol fordistributing position data defines the coordination aspects between the roles distributor andclient. The definition of Real-Time Coordination Protocols1 is as follows: A Real-TimeCoordination Protocol unambiguously describes for each role its assumed and guaranteed(1) structure, (2) real-time behavior, and (3) message-based interaction as well for the roleconnector the assumed quality of service characteristics of the message transmission. Weclassify Real-Time Coordination Protocols on the direction of coordination and on the formof coordination (cf. Section 3.3.4).

A developer has to instantiate a Real-Time Coordination Protocol for specifying acoordination among two or more role instances (cf. Section 3.3.5 ). The developer, forexample, can define a coordination between one role instance that acts as the server andmultiple role instances that act as a client.

The behavior of each role is described by a Real-Time Statechart (cf. Section 3.3.6).

Furthermore, a developer can apply real-time model checking to analyze a Real-TimeCoordination Protocol. As a prerequisite, the developer has to specify verification propertiesregarding the coordination (cf. Section 3.3.7).

1The definition of Real-Time Coordination Protocol is similar to the contract definition of Giese andVilbig [GV03].

3.3. REAL-TIME COORDINATION PROTOCOL 17

3.3.1. Example of a Real-Time Coordination Protocol

A simple example for a real-time coordination use-case is as follows: A system consists of upto nine BeBots. The BeBots shall coordinate the exchange of their current position. One BeBotis the distributor and one to eight BeBots are the clients. The distributor periodically receivesthe position of all clients, combines all positions into a list (including its own position), anddistributes the list of all positions to all clients using a multicast. If one of the clients does notsend its position within a certain time, the distributor informs all clients, that a safety-criticalsituation occurred, because collisions are possible now. As soon as all clients have sent theirposition again within the same period, the safety-critical situation ends.

For modeling this coordination, the developer defines a Real-Time Coordination Protocolwith the name Distribution. The two types of roles in this coordination are distributor and client.Each instance of role distributor can coordinate with up to eight instances of role client. Thecoordination is bidirectionally. Furthermore, each instance of role client can coordinate onlywith the one instance of role distributor. The instances of role client cannot coordinate eachother. The formal behavior of each role is defined by a Real-Time Statechart (cf. Section 3.4.Section 6.1.3 shows and describes the Real-Time Statecharts of these roles in detail.

distributor client

role connector

Distribution

role cardinality role cardinality

protocol name

role name role name

role role[1..8] [1]

Figure 3.2.: The Real-Time Coordination Protocol Distribution

Concrete Syntax of a Real-Time Coordination ProtocolFigure 3.2 shows the Real-Time Coordination Protocol Distribution in concrete graphicalsyntax. A dashed ellipse contains the name of the protocol. Furthermore, a protocol consistsof additional concrete syntax elements, which are defined in the next section. A dashed(cascaded) square represents a role. The square is cascaded if the role is a multi role. Adashed line connects each role with the protocol ellipse. A label at the dashed line showsthe name of the role. The solid line, which represents the role connector, connects the roles.The two triangles within both roles define that they coordinate bidirectionally with each other.If the protocol supports one-to-many coordination, then a label at each role (under the roleconnector) defines the so-called role-cardinality – the number of connections a role may have.

3.3.2. Role

A role is a discrete interaction endpoint and represents the type of a coordination participantof a Real-Time Coordination Protocol. Each role of a Real-Time Coordination Protocol has aunique name within a system specification. A role instance represents a concrete coordinationparticipant and is typed over a role.

Instances of roles can coordinate each other via discrete, asynchronous messages. A rolemay reference two unsorted sets of discrete, asynchronous messages that are typed over amessage type (cf. Section 3.2). We call these sets sender message types and receiver messagetypes. The sender message types define which types of messages the role sends; the receivermessage types define which types of messages the role receives. The sender message types ofone role must be equal to the receiver message types of its opposite role, and vice versa.

In the following, we will distinguish roles (i) by their coordination direction and (ii) bytheir cardinality. Afterwards, we will define the incoming message buffer specification, whichMECHATRONICUML currently supports.

Concrete Syntax of a Role

Figure 3.3 shows the concrete syntax of roles. We illustrate roles by dotted squares. A dashedline connects the role to the protocol ellipse, which contains the name of the protocol (cf.Figure 3.2). In addition, the name of the role is shown next to the dashed line and is positionedon the outside of the protocol.

single role multi role

in-role

in/out-role

out-role

receiver

message

types

sender

message

types

<role>

[1]

<role>

[1]

<role>

[1]

<role>

[1]

<role>

[i..j]

<role>

[i..j]

<role>

[i..j]

<role>

[i..j]

Figure 3.3.: Concrete Syntax of Roles and their Messages Type Specification


3.3.2.1. Coordination Direction of Roles

The direction of a role specifies that a role may (i) send, (ii) receive, or (iii) send and receivemessages. A role that may only send messages is an out-role. A role that may only receivemessages is an in-role. A role that may send and receive messages is an in/out-role.

The direction of a role can be derived from its message type specification (cf. Section 3.2).We illustrate this with the Figure 3.3. If a role references only sender message types, it is anout-role; if it references only receiver message types, it is an in-role; if it references both, it isan in/out-role.

An out-role instance can only send one message at a time; an in-role instance can onlyconsume one message at a time2. However, an in/out-role instance can send and receive onemessage at the same time.

Concrete Syntax of a Coordination DirectionAs depicted in Figure 3.3, the concrete syntax of the out-role has a filled isosceles trianglewithin its square (the so-called out-triangle) whose top points to the connector of the protocol.The in-role has a triangle (the so-called in-triangle) whose top points away from the connectorof the protocol. The in/out-role is visualized with two triangles. The top of the upper onepoints to the left and the top of the lower one points to the right.

3.3.2.2. Cardinality of Roles

For establishing the message-exchange between role instances, each instance of a role has oneor more connections to other role instances. For each connection, a so-called subrole instanceexists within the role instance. Therefore, each connection consists of exactly two subroleinstances of different role instances. The number of connections and therefore the number ofsubrole instances, a role instance may have, is limited. Therefore, each role has a cardinalitythat defines the minimum and maximum number of subrole instances of a multi role instance.

We describe the role-cardinality by the Min-Max-Notation [Abr74]. Developers shouldbe aware that the Min-Max-Notation is contrary to the multiplicity notation of the UML.The Min-Max-Notation defines for each entity of type x how many associations of type y(at minimum and at maximum) to entities of type z it may have. In contrast to this, themultiplicity notation of the UML defines how many entities of type x may be (at minimumand at maximum) associated over associations of type y to one entity of type z.

By using the Min-Max-Notation, a developer has to determine for each role howmany subrole instances an instance of this role may have at minimum and at maximum.Consequently, we can derive the minimum and maximum number of connections of this roleinstance.

2This constraint could change in the future if we we allow that the atomic component execution behavior isexecutable with more than one task that run in parallel.


The role-cardinality may be variable or fixed. If it is variable, then the minimum-cardinalityand the maximum-cardinality are different. If it is fixed, then minimum and maximum areequal.

If the role-cardinality has a fixed value of 1, which means this role coordinates with exactlyone other role instance, we call this role a single role. If the role-cardinality has an upperbound greater than 1, which means this role can coordinate more than one other role instance,we call this role a multi role.

The subrole instances of a multi role are always ordered in a list. A developer can usethe order within the behavior specification of the multi role to define the order of messagesequences. We explain this in detail in Section 3.4.11.

Concrete Syntax of a Role CardinalityA square with a dashed, single borderline visualizes the single role; a square with a dashed,cascaded borderline visualizes the multi role (cf. Figure 3.3). The role-cardinality is depictedas a label that is located next to the role under the role connector. The label consists of squarebrackets and one number or two numbers separated by two dots within. If the cardinalityis fixed, then only one number shows the value of the fixed cardinality; if the cardinality isvariable, then two numbers are shown: the lower bound is the first number, the upper bound isthe second number.

3.3.2.3. Incoming Message Buffer

An instance of an in-role buffers all incoming messages first, before it consumes the messages.Therefore, an in-role must specify at least one incoming message buffer.

A message buffer is a strict queue with a fixed size, i.e., it follows the FIFO (First In, FirstOut) principle. A message buffer enqueues a received message at the back of the queue anddequeues messages at the front of the queue. Consequently, a message buffer sorts messagesregarding their arrival time.

In MECHATRONICUML, a message buffer must not overflow, i.e., it may never be the casethat the buffer is full but still enqueues a message. However, the developer can choose if thebuffer is allowed to displace messages. If displacement is desired then the developer has tochoose between two different displacement strategies:• OldIsBetter: Discard arriving messages as long as the buffer is full (the buffer stays the

same).• NewIsBetter: Delete the oldest message in the buffer (i.e., the message at the head of

the queue) and enqueue the new arriving message. As an important note, this is theonly possibility in MECHATRONICUML to delete a message from the buffer withoutconsuming it.

A developer may specify a message filter for each buffer by defining a blacklist. If a messagetype is on the blacklist, the buffer will not enqueue this message, but will immediately removeit. This feature is especially important if the sender of this message is a legacy component thatmust not be changed.


An in-role may have more than one message buffer, but each message type is associated toexactly one message buffer. Therefore, the developer has to define which buffer stores whichincoming message type.

If the developer specifies more than one buffer for a role, it is possible that more than onemessage buffer contains at least one message at runtime. Then, the associated Real-TimeStatechart may enqueue from all message buffers. Thus, there is no priority defined amongthe message buffers of an in-role. A developer should be aware that having no buffer prioritiesresults in non-determinism.

Buffer AssumptionsWe assume that underlying software layers (i.e., the middleware) handle the details of theasynchronous message exchange. Thus, we assume the following statements:• The middleware buffers incoming messages in FIFO style.• All messages of the protocol have the same time to live (TTL), i.e., the message is

deleted if it exceeds its maximum transmission delay. A message is not handed overto the level of MECHATRONICUML (i.e., the application layer) before its minimumtransmission delay or after its maximum transmission delay. Therefore, the buffermay only contain messages that were transmitted within the assumed transmission timerange.• The middleware hands the message over to the level of MECHATRONICUML when

the scheduler of the application layer starts the task of updating the role buffers. Themessage will be processed as described above (it will be enqueued or discarded).• The middleware cannot change the buffer during enabling and firing a transition.• The developer must not specify outgoing message buffers on the level of

MECHATRONICUML because we assume that the message is handed over to themiddleware immediately, which does the job of sending the message and – if needed– buffering the message.

In upcoming versions of MECHATRONICUML, we plan to provide an adapter layer whichfulfills our assumptions. This layer can be used to deploy MECHATRONICUML componentsto different software platforms, e.g., CORBA-based middleware [Gro11b].

Concrete Syntax of an Incoming Message BufferThe message buffer specifications is an optional label that is placed next to the role. Thelabel consists of the name of the buffer, its size, and its displacement strategy. Figure 3.4shows an exemplary message buffer specification for the in-role receiver. Here, the role hasone incoming message buffer. It contains one message and displacement of messages is notallowed.

3.3.3. Role Connector

A role connector connects the roles of a Real-Time Coordination Protocol. It represents acoordination connection between the roles. If two roles are connected then their role instances


client

Distribution

[1..8] [1]

distributor

buffer1size=1, no displacement

buffer1 size=1, no displacement

Figure 3.4.: Exemplary Message Buffer Specification for Role receiver

can exchange messages. For each connection between two role instances, an instance of therole connector is used.

Concrete Syntax of a Role ConnectorA role connector is a dashed line that connects the roles.

3.3.3.1. Steps of a Message Transmission

In MECHATRONICUML, transmitting a message contains the following steps:1. The transmission starts by raising the message (including its parameters) within the

application layer.2. The message is delivered to the middleware.3. The middleware decides if the receiver is deployed on the same or another system (at the

PIM level we must assume that both is possible). If it is deployed on the same system,we continue with step 6, otherwise with step 4.

4. The middleware delivers the message to OSI layer 1 and sends it to the other system viathe physical connection (this can contain several hops).

5. The other system receives the message and delivers it to its own middleware.6. The middleware of the receiver delivers the message to the application layer of the

receiver, which will enqueue it into the appropriate buffer.

3.3.3.2. QoS Assumption of the Role Connector

Concerning the connector behavior, the developer has to define the following quality of service(QoS) assumptions:• The minimum and maximum message transmission delay that is accepted by the

connector.• The probability that a message will arrive at the buffer of the receiver role. We

distinguish three cases:

0% The message eventually arrives at the application layer of the receiving role

> 0% The message may arrives at the application layer of the receiving role. However,it might by the case that the message does not arrive before the maximumtransmission delay, e.g., due to message loss or too long transmission time.


100% The message will never arrive at the buffer

Furthermore, MECHATRONICUML has some fixed QoS assumptions that the middlewaremust always guarantee:• If a message arrives before the accepted lower transmission delay, then the receiver’s

middleware will delay the enqueueing until the lower delay is reached.• The accepted maximum transmission delay is equal to the time to live (TTL) of the

message. Thus, if the TTL exceeds during transmission, the message will be deleted,e.g., by the receivers’ middleware. Consequently, it will never reach the level ofMECHATRONICUML. From the viewpoint of MECHATRONICUML, it is transparentwhere the message is deleted because we are only interested if it could be the case thatthe message does not arrive at the receiver buffer within the minimum and maximumtransmission delay.• We do not state explicitly if a message can get lost during transmission and if the sender

middleware tries (several times) to resend it. As stated before, this is transparent fromthe viewpoint of the MECHATRONICUML level• The receiver’s middleware handles corrupt messages. Consequently, corrupted

messages will not be enqueued into the buffer.• The sending message order is the same as the receiving message order. This means if

the sender role sends message m1 first and then message m2, then the receiver role willnot enqueue m2 first and m1 afterwards. However, if m1 does not fulfill its maximumtransmission delay, then the receiver role may enqueue m2 without enqueueing m1 first.As a consequence, the receivers’ middleware must know the correct message order andmust be able to delay the enqueueing, e.g., the middleware must delay the enqueueingof m2 as long as m1 arrives or its maximum transmission delay is violated.

In former version of MECHATRONICUML, the developer had to describe the connectorbehavior via Real-Time Statecharts [Bur06]. The current version of MECHATRONICUMLdoes not support this because the behavior description is generic. Thus, describing thebehavior with a Real-Time Statechart has no benefits in our opinion.

Concrete Syntax of a Role ConnectorWe visualize the role connector by a black line between the two squares for the roles (cf.Figure 3.5). Optionally, the QoS assumptions defined by the developer can be annotated as atextual label next to the role connector. The range of the transmission delay is defined usingthe keyword delay; the probability that a message will arrive the buffer of the receiver role isdefined using the keyword failure ratio.

3.3.4. Classification of Real-Time Coordination Protocols

We classify Real-Time Coordination Protocols on the direction of coordination (unidirectionalor bidirectional) and on the form of coordination (one-to-one or one-to-many). Figure 3.6shows the five kinds of a Real-Time Coordination Protocol: a) unidirectional, one-to-one, b)


Distribution

[1..8] [1]

QoS assumptionsdelay = [2 ms, 5 ms],

fail. ratio = 0%

Figure 3.5.: Role Connector with annotated Quality of Service Assumptions

unidirectional, one-to-many, c) unidirectional, many-to-one, d) bidirectional, one-to-one, ande) bidirectional, one-to-many. We describe them in the following.

3.3.4.1. Directions of Coordination

A unidirectional coordination means that only one role can send messages and the other rolecan only receive messages. Therefore, this coordination consists of an out-role and an in-role.Figures 3.6 a), b) + c) show the three possibilities for this coordination.

A bidirectional coordination means that all roles can send and receive messages. Thus,all roles must be in-out-roles. Figures 3.6 d) + e) show the two possibilities for such acoordination.

3.3.4.2. Forms of Coordination

In MECHATRONICUML, two possible forms of coordination exist: one-to-one and one-to-many. These forms of coordination define to how many other instances one role can coordinateand how many instances participate in this coordination.

One-to-one means that two roles coordinate each other and both roles have only one roleinstance per instantiated Real-Time Coordination Protocol. Both roles have a role-cardinalityof 1. Therefore, both roles must be single roles. Figures 3.6 a) + d) show the two possibilitiesfor a one-to-one coordination.

One-to-many means that two roles coordinate each other and one role has only one instanceand coordinates itself with multiple instances of the other role. The role with one instancemay have multiple subrole instances and can therefore coordinate multiple instances of theother role. The role, which may have multiple instances, has a role-cardinality of 1, becausethere is only one instance of the other role. A protocol, which specifies such a coordinationhas one multi role and one single role. Figures 3.6 b), c) + e) show the three possibilities forspecifying a one-to-many form of coordination.

<protocolName> <protocolName>

<roleName> <roleName>

<protocolName>


a) unidirectional, one-to-one d) bidirectional, one-to-one



e) bidirectional, one-to-many

<protocolName>

c) unidirectional, many-to-one


<protocolName>

[1][i..j]

b) unidirectional, one-to-many

[1]

[i..j]

[i..j]

[1]

Figure 3.6.: The Five Classes of a Real-Time Coordination Protocol

3.3.5. Real-Time Coordination Protocol Instance

An instance of a Real-Time Coordination Protocol consists of (i) a set of role instances thatare typed over the roles specified in the Real-Time Coordination Protocol and (ii) a set ofrole connector instances that are typed over the role connector of the Real-Time CoordinationProtocol.

The variable parts of the Real-Time Coordination Protocol are determined duringinstantiation. If the Real-Time Coordination Protocol has the form one-to-one, there existno variable parts, because the protocol consists of two single roles that are both connected toan instance of each other. Consequently, the only possible protocol instance consists of oneinstance per single role and one connector instance that connects the two role instances.

If the Real-Time Coordination Protocol has the form one-to-many, the variable parts includethe variable role-cardinality of the multi role and the number of role instances of the singlerole. A developer determines both parts at the same time, because they depend on each other:A specific role-cardinality defines of how many subrole instances a multi role instance mayconsists. Each subrole instance of a multi role is connected to a different single role instance.Thus, in a one-to-many coordination, there exists only one multi role instance but severalsingle role instances, where the number of single role instances depends on the specific role-


cardinality of the multi role instance. Each pair of a subrole instance and a single role instanceis connected by a different role connector instance.

For example, an instance of Real-Time Coordination Protocol Distribution (cf. Figure 3.2)specifies a coordination between four role instances. One instance is typed over the roledistributor and contains three subrole instances. Each of these three is connected via differentrole connector instances to one of the three role instances which are typed over the roleclient. This instance of the Real-Time Coordination Protocol Distribution is valid becausethe maximum role-cardinality of role distributor is eight and the current role-cardinality ofthe role instance, which is typed over role distributor, is three. To conclude, this instantiationdefines a 1:3 coordination with one distributor and three clients.

:client

:distributor :client

:client

:Distribution

protocol instance label

role instance labelrole instance label

role connector instance

single role instance

multi role instance

subrole instance

Figure 3.7.: Instance of Real-Time Coordination Protocol Delegation

Concrete Syntax of a Real-Time Coordination Protocol InstanceFigure 3.7 shows the aforementioned instance of Real-Time Coordination Protocol Distributionin concrete graphical syntax. All concrete syntax elements of the example are annotated ingray. A dashed ellipse contains the protocol instance label which consists of the name of theprotocol. The name is underlined and prefixed by a colon. Each instance of a single rolehas its own dotted square and its own dashed line, which connects the ellipse. A multi portinstance contains a fixed number of subrole instances, which are framed by a dashed line.Each subrole instance has its own dotted square. A multi port instance connects the ellipse viaa dashed line. A label is placed next to the dashed line of each role instance (single and multi)and consists of the name of the role that is underlined and prefixed with a colon. Single roleinstances and subrole instances contain triangles to show the direction of the role instance.The solid line, which represents the role connector instance, connects a single role instanceand a subrole instance. We use the same graphical syntax for the role connector instance if aprotocol instance has a one-to-one form of coordination where two single role instances areconnected.


3.3.6. Protocol Behavior Specification

The concurrent execution of the roles of a Real-Time Coordination Protocol specifies theexecution behavior of the Real-Time Coordination Protocol. Therefore, the developer hasto specify the coordination behavior for each role. This role behavior specification can beseen as a contract that a port must fulfill, when a role is applied to it. If a role is applied to aport of an atomic component, the port has to fulfill the role behavior specification directly. Ifthe developer applies a role to a port p of a structured component, the behavior specificationof the role must be fulfilled by the port the port p delegates to.

The behavior of a role is state-based and is subject to real-time restrictions (e. g., themaximum time the system dwells within a certain state). The developer specifies the behaviorof a role by a Real-Time Statechart (cf. Section 3.4). The concurrent execution of all roleinstances of an instantiated Real-Time Coordination Protocol determines its overall behavior.

Within the Real-Time Statechart of a role, only asynchronous messages can be used (cf.Section 3.4.9) to specify the message exchange between the roles. These message eventsare typed over the message types declared in the message type specification of the role (cf.Section 3.2. Asynchronous messages may not be used for coordination within the role (e. g.,to coordinate between several regions of the role statechart).

A role may define variables to store information concerning the coordination (e. g., thecurrent physical position of the system). The Real-Time Statechart of the role can read andwrite the values of these variables, e.g., in conditions and effects of transitions. The Real-Time Statechart of the role cannot access the variables that are defined by other role instances.Furthermore, a role can define operations (e. g., to calculate the current position of the system).The Real-Time Statechart of the role instance can call its defined operations, but cannot calloperations that are defined by other role instances.

adaptation sub-role [k]

distributor_main

distributor client

client

Distribution

[1..8] [1]

distributor

Figure 3.8.: A Multi Role and a Single Role Specified by Real-Time Statecharts


Figure 3.8 shows the Real-Time Coordination Protocol Distribution with its roles distributorand client. The behavior of the single role client is defined by a Real-Time Statechart withoutfurther restrictions. The behavior of the multi role distributor is separated into an adaptationbehavior and a subrole behavior. This separation results from the one-to-many coordinationwhere the multi role has to coordinate several instances of the single role. The behavior ofeach instance of the single role has to be identical and is defined by one common subrolebehavior. The adaptation behavior defines an order of the different coordination behaviorsto each instance of the other role and will be used for specifying run-time adaptations of thecoordination as introduced in [EHH+13] in future versions of this document. We introducethe different parts of a Real-Time Statechart for a multi role in more detail in Section 3.4.11.

3.3.7. Real-Time Model Checking of Protocol PropertiesThe behavior specification of a Real-Time Coordination Protocol usually has to fulfillrequirements that are important for the safety of the real-time system under development.Analyzing the system using tests or simulation is typically not enough, because these analysistechniques only check a subset of all possible execution traces. Hence, it might be the casethat an execution trace that violates (safety-critical) requirements is not analyzed by testing.This may result in a critical system failure.

A formal analysis technique that checks all possible execution traces w.r.t. a formalrequirement is model checking [BK08]. For each requirement of the accepted requirementlanguage, the model checker is able to state if the requirement is fulfilled on all executiontraces or not. This raises the trust in the model significantly. Furthermore, a model checkeris able to present a counter example that shows the execution path for a (un-)satisfiedrequirement.

For the domain of real-time systems, a specialized form of model checking, called real-timemodel checking, exists. Real-time model checking uses as inputs timed automata and a real-time constraint language (e.g., the Timed Computation Tree Logic, TCTL [ACD93]). Oneexemplary real-time model checker is UPPAAL [BDL04].

In MECHATRONICUML, we support the real-time model checking of Real-TimeCoordination Protocols via a model transformation to UPPAAL in a transparentmanner [Ger13]. We achieve this by a model translation to UPPAAL, the automated executionof UPPAAL, and a back-translation to MECHATRONICUML. Therefore, the developer doesnot need to understand the technical details of the transformations (translation and back-translation) nor UPPAAL and its model checking itself.

Until now, MECHATRONICUML does not provide an own verification property language.Thus, a developer has to specify its verification properties using UPPAAL’s TCTL subset.Moreover, the specified properties must be applicable to the translated timed automata ofUPPAAL and not to the Real-Time Coordination Protocol of the level of MECHATRONICUML.As this is a major obstacle for a fully transparent model checking, we will define aMECHATRONICUML verification property language in upcoming revisions of this document.This property language will be translatable into the properties supported by UPPAAL.

Concrete Syntax of a Protocol Verification PropertiesFigure 3.9 visualizes the Real-Time Coordination Protocol Distribution and shows theUPPAAL-specific properties for its role distributor and for the protocol itself. A black-linedrectangle contains all verification properties of a role or a protocol. The rectangle links via ablack line to the dashed square of a role (here: to the role distributor) or to the black-dashedellipse, which displays the name of the protocol (here: to the protocol Distribution). If a roleor a protocol has no verification properties (like the role client), the rectangle and its link arenot shown.

distributor client

[1..8] [1]A[] adaptation.c0 <= 50

A[] not deadlock

distributor.adaptation.Error --> (client_1.receive.Error and … and client_8.receive.Error)

Distribution

Figure 3.9.: The Real-Time Coordination Protocol Distribution with Verification Propertiesfor the Role distributor and for the whole Protocol

In our example, two TCTL-properties are specified for the protocol Distribution usingthe verification property language of the model checker UPPAAL: The first property statesA[] no deadlock, which expresses that there exists no deadlock within this protocol. Thesecond property states distributor.adaptation.Error –> (client_1.receive.Error and . . . andclient_8.receive.Error), which expresses that if role distributor is in state Error (which isembedded in region adaptation), then all clients will eventually enter state Error of regionreceive. In other words, if the distributor cannot collect the position data of all clients, then theclients will be informed so that they can react to this error. Additionally, the role distributorspecifies the verification property A[] adaptation.c0 <= 50ms, which formally expresses thatthe clock c0 of region adaption never exceeds 50 ms. If this constraint always holds, then thedeveloper can ensure that the distributor can distribute its information every 50 ms.


3.4. Real-Time StatechartReal-Time Statecharts are state-based behavior specification models that are used for definingthe behavior of atomic components (cf. Section 3.6.1.4), discrete ports (cf. Section 3.6.1.3),or roles (cf. Section 3.3.6).

Both syntactically and semantically, Real-Time Statecharts are a combination of Harel’sstatecharts [Har87], UML state machines [Gro10b], and (UPPAAL) timed automata [BDL04,AD94, DM01]: Concepts and syntactical elements for supporting hierarchy are derived fromstatecharts and state machines, while notions and notations from timed automata allow fordefining time-based behavior. Giese and Burmester [GB03] defined a previous versionof Real-Time Statecharts in the year 2003, defining the semantics by mapping Real-TimeStatechart to hierarchical timed automata [DM01]. Within this document, we refine theexecution semantics further (cf. Section 3.4.12).

A Real-Time Statechart has a name. For describing behavior, a Real-Time Statechart maycontain several different types of modeling elements. Like in timed automata, time-basedbehavior is modeled using clocks (cf. Section 3.4.1) that are stored within a Real-TimeStatechart.

Certain situations within the system are modeled as states (cf. Section 3.4.2). Forkeeping the behavior model compact, Real-Time Statecharts additionally support hierarchicaland orthogonal states [Har87]. A change of the active state is modeled using transitions(cf. Section 3.4.3). Moreover, Real-Time Statecharts support state connection points (cf.Section 3.4.4) to chain transitions between different hierarchy levels.

Within a Real-Time Statechart, effects (cf. Section 3.4.5) define an executable behavior.One type of an effect is executing actions (cf. Section 3.4.6), e.g. for specifying an assignment.Moreover, a Real-Time Statechart can store values within variables (cf. Section 3.4.7) and cancall operations (cf. Section 3.4.8).

Real-Time Statecharts enable an asynchronous message exchange (cf. Section 3.4.9)between (i) atomic components of different systems and (ii) atomic components within asystem. Similar to timed automata, within a state orthogonal Real-Time Statecharts maysynchronize the firing of their transitions using synchronization (cf. Section 3.4.10).

For specifying the behavior of multi roles and multi ports, we define a strict structure of theReal-Time Statechart (cf. Section 3.4.11).

Concrete Syntax of a Real-Time StatechartFigure 3.10 shows a template for the concrete syntax of a Real-Time Statechart: Thevisual representation of a Real-Time Statechart is a rectangle with the name of thestatechart (rtscNameLabel) shown in the upper left corner. In the upper right corner,the rtscDefinitionLabel shows the defined variables, operations, and clocks of a statechart.Concerning the defined operation, only the operation signatur is visualized. The remainderof the Real-Time Statechart’s rectangle may contain state compartments, the visualrepresentation of states and their transitions.

3.4. REAL-TIME STATECHART 31

<rtscDefinitionLabel><rtscNameLabel>

StateCompartment

Figure 3.10.: Concrete Syntax Template of a Real-Time Statechart

The following EBNF grammar defines the default notation of the rtscDefinitionLabel. Itreuses the EBNF grammars for defining variables (cf. Section 3.4.7), operation signatures (cf.Section 3.4.8), and clocks (cf. Section 3.4.1).

< r t s c D e f i n i t i o n L a b e l > = [ < r t s c V a r i a b l e D e f i n i t i o n >][ < r t s c O p e r a t i o n S i g n a t u r e >][ < r t s c C l o c k D e f i n i t i o n > ] ;

< r t s c V a r i a b l e D e f i n i t i o n > = ’ v a r i a b l e ’ < v a r i a b l e D e f i n i t i o n >[ ’ , ’ < v a r i a b l e D e f i n i t i o n > ]∗ ;

< r t s c O p e r a t i o n S i g n a t u r e > = ’ o p e r a t i o n ’ < o p e r a t i o n S i g n a t u r e >[ ’ , ’ < o p e r a t i o n S i g n a t u r e > ]∗ ;

< r t s c C l o c k D e f i n i t i o n > = ’ c l o c k ’ < c l o c k D e f i n i t i o n >[ ’ , ’ < c l o c k D e f i n i t i o n > ]∗ ;

Figure 3.11 shows an example of the concrete syntax for Real-Time Statecharts, except forthe state compartments. For a description of the concrete syntax for states, see Section 3.4.2.

Statechart1 variable int[10] a, string s

operation int op1(int i, boolean b)

clock c1, c2

StateCompartment

Figure 3.11.: Concrete Syntax Example of a Statechart

3.4.1. Clock

Like a timed automaton, a Real-Time Statechart has a finite number of clocks. A clock modelsthe elapsing of time during the execution of a system. Since time elapses continuously and notin discrete steps [AD94], we consider clock values from the set R of real numbers. All clockswithin a Real-Time Statechart have a unique name. The initial value of a clock is zero.

Concrete Syntax of a Clock DefinitionThe following EBNF grammar clockDefinition defines the default notation for defining .Elements which have the prefix “#” are references to the meta model elements of class Clock.

< c l o c k D e f i n i t i o n > = #name ;

3.4.1.1. Time Value

A time value represents a concrete system time. It consists of an expression and a timeunit. The expression (e.g., an algorithmic expression) may reference variables and operations.Furthermore, the value must evaluate to a natural number from the set N. We support thetime units of the Java class java.util.concurrent.TimeUnit: nanoseconds (ns),microseconds (µs), milliseconds (ms), seconds (s), minutes (min), hours (h), and days (d).

Concrete Syntax of a Time ValueThe time value label consists of a value label and a time unit label. Valid concrete syntaxexamples are 15 ms, (2 · i+ j + 3) ns, and (op1(i, 5)− j) d

3.4.1.2. Clock Constraint

A clock constraint restricts the values of a particular clock to a certain range. A developeruses clock constraints for defining a state invariant (cf. Section 3.4.2.1) or for restricting theenabling conditions of a transition.

We only allow clock constraints that compare the current value of a clock to an expression(cf. Section 3.5.3) representing a natural number from the set N. In general, we allow thefollowing comparison operators: less (<), less or equal (≤), equal (==), greater or equal (≥),and greater (>). Elements that use clock constraint, e.g., invariants, may further constraintthis.

Concrete Syntax of a Clock ConstraintThe following EBNF grammar defines the default notation for defining clock constraints.Elements which have the prefix “#” are references to the meta model elements of classClockConstraint.

< c l o c k C o n s t r a i n t > = # c l o c k . name # operator <upperBound >;<upperBound > = # bound . v a l u e [# bound . u n i t ] ;

The clock constraint label consists of a clock name, a comparison operator, and a timevalue including an optional time unit. Valid concrete syntax examples are c1 > 15 ms andc2 ≤ (2 · i+ j + 3) ns.

3.4.1.3. Clock Reset

A developer may force a clock to start running from zero again. We refer to this as a clockreset. A clock reset is an effect. A set of clock resets is either part of a state’s entry or exitevent (cf. Section 3.4.2.2), or part of a transition effect 3.4.3. Thus, a clock’s value is alwaysrelative to its last reset time. There is no possibility to change the value of a clock other thanresetting it to zero.

Concrete Syntax of a Clock ResetThe following EBNF grammar defines the default notation for defining clock resets. Elementswhich have the prefix “#” are references to the meta model elements of class Clock.

< c l o c k R e s e t > = ’ r e s e t ’ #name [ ’ , ’ #name ] ∗ ;

The clock reset label consists of the keyword reset and a clock label. Valid concrete syntaxexamples are reset c1 and reset c1, c2.

3.4.2. State

A state refers to a certain situation within the system. At runtime, a state may be active orinactive. If it is active, then the system currently resides in this situation; if it is inactive, thenthe system does currently not reside in this situation.

A Real-Time Statechart contains a non-empty set of states with a unique name for eachstate. Typically, all states of a Real-Time Statechart define distinct situations. Thus, while arunning Real-Time Statechart is active, at most one state is active, too. If no state is active,then a transition (cf. Section 3.4.3) of this Real-Time Statechart must be active.

A state change within a Real-Time Statechart describes a deactivation of the currentlyactive state (the source state) and the activation of a currently inactive state (the targetstate). Transitions (cf. Section 3.4.3) describe all possible state changes within a Real-TimeStatechart.

A developer may constrain the duration that a state is active using an invariant (cf.Section 3.4.2.1). Furthermore, a state may have state events. These events define effectsthat are executed at certain points of time while the state is active, e.g. on state entry or stateexit (cf. Section 3.4.2.2).

The initial state of a Real-Time Statechart is the first state that is active when the containingReal-Time Statechart is active itself (cf. Section 3.4.2.3). Moreover, a state may be final, i.e.,a subsequent state change on this hierarchy level is not allowed (cf. Section 3.4.2.4).

States differ in their support of hierarchy. We distinguish between (i) simple states (cf.Section 3.4.2.5) that do not support hierarchy, and (ii) composite states (cf. Section 3.4.2.6)that support hierarchy by using the concept of regions that embed Real-Time Statecharts(called embedded statecharts). As an embedded statechart can contain embedded statechartsitself, the hierarchical structure of a Real-Time Statechart can be graphically represented as atree. We refer to the root of the tree as the root statechart.

Concrete Syntax of a StateFigure 3.12 shows the template for the concrete syntax of a state. In general, we visualizea state by means of a rectangle with rounded corners, showing the state name inside therectangle. Please note that we will define extensions for the concrete syntax of a state inthe following.

<stateNameLabel>

Figure 3.12.: Concrete Syntax Template of a State

3.4.2.1. Invariant

For specifying hard real-time constraints concerning a specific state, a developer may assignan invariant for constraining the time that a state may be active. An invariant must always holdas long as the state is active. In contrast to the invariants of UPPAAL, MECHATRONICUMLonly supports clock-based state invariants which restrict the time this state may be active,whereas UPPAAL supports all possible expressions that result to true or false (including dataconditions).

A developer specifies an invariant by means of a non-empty set of clock constraints (cf.Section 3.4.1.2). All clock constraints must be always true as long as the state is active.However, each clock constraint may only use the operators < and ≤. Therefore, the clockconstraints can only define an upper bound of the clock. An invariant requires the system toleave the corresponding state at the latest when its upper time bound is reached.

A situation where the specification of a Real-Time Statechart enforces to remain in acertain state longer than the upper time bound of its invariant is called a time-stoppingdeadlock [DMY02a], because time in the model can not progress anymore as this wouldviolate the invariant. Time-stopping deadlocks constitute serious problems in the behavioraldesign, and thus require detection and elimination before implementing a real system. Thus,in Real-Time Statecharts, time-stopping deadlock must not occur. Detecting these deadlocksis possible by means of exhaustive formal verification techniques such as UPPAAL modelchecking. Formal verification, however, will only prove the system correct under the followingassumptions: (i) all concrete models – including platform-specific models and the generatedplatform code – refine the Real-Time Statechart-model correctly and (ii) the platform canguarantee that all defined invariants will always hold.

Concrete Syntax of an InvariantThe following EBNF grammar defines the default notation for an invariant. It references theEBNF grammar of clock constraints. = ’ i n v a r i a n t ’ < c l o c k C o n s t r a i n t > [ ’ , ’ < c l o c k C o n s t r a i n t > ]∗ ;

3.4.2.2. State Events

A state may have state events that are triggered at certain points in time. We support threedifferent kinds of state events: (i) entry, (ii) do, and (iii) exit. For each state event, a developermay define effects that are invoked when the event is triggered. All events are only triggeredif an effect is defined. The effects cannot be canceled nor interrupted and are executedsynchronously and not in a task that runs in parallel, i.e., a state change must not happenwhile executing the effect.

Entry EventThis event is triggered whenever the associated state gets activated due to a firing transition.The effect may consist of an action (cf. Section 3.4.6) and a set of clock resets (cf.Section 3.4.1.3). The action is executed before resetting the concerning clocks.

Concrete Syntax of an Entry EventThe following EBNF grammar specifies the default notation for an entry event definition.Here, we reuse the EBNF grammar for clock resets. Elements which have the prefix “#” arereferences to the meta model elements of class State:< e n t r y E v e n t > = ’ e n t r y / ’ [ < e n t r y E f f e c t >] ’ ’ [ < e n t r y C l o c k R e s e t > ] ;< e n t r y E f f e c t > = ’ { ’ (# e n t r y E v e n t . a c t i o n . e x p r e s s i o n s |

# e n t r y E v e n t . a c t i o n . name ) ’ } ’ ;< e n t r y C l o c k R e s e t > = ’ { ’< c l o c k R e s e t > ’ } ’ ;

Do EventThis event is triggered periodically as long as the state is active. The effect may only consistof an action. Within each period, the action is executed once.

The period is strict. We define the period by means of a time value (cf. Section 3.4.1.1). Weassume that the worst case execution time of the effect is shorter than the period. Furthermore,the effect does not have to start at the beginning of the period, but has to end before the end ofthe period. A scheduler may define the starting time individually.

Concrete Syntax of a Do EventThe following EBNF grammar defines the default notation for a do event definition. Elementswhich have the prefix “#” are references to the meta model elements of class State:<doEvent > = ’ do / ’ [ < d o E f f e c t > ] ;< d o E f f e c t > = ’ { ’ (# doEvent . a c t i o n . e x p r e s s i o n s |

# e x i t E v e n t . a c t i o n . name ) ’ } ’’ [ p e r i o d : ’ # doEvent . p e r i o d . v a l u e [ ’ ’ # doEvent . p e r i o d . u n i t ] ’ ] ’ ;

Exit EventThis event is triggered whenever the associated state gets deactivated due to a firing transition.The effect may consist of an action (cf. Section 3.4.6) and a set of clock resets (cf.Section 3.4.1.3). The action is executed before the clock resets.

Concrete Syntax of an Exit EventThe following EBNF grammar defines the default notation for an exit event definition. Here,we reuse the EBNF grammar for clock resets. Elements which have the prefix “#” arereferences to the meta model elements of class State.

< e x i t E v e n t > = ’ e x i t / ’ [ < e x i t E f f e c t >] ’ ’ [ < e x i t C l o c k R e s e t > ] ;< e x i t E f f e c t > = ’ { ’ (# e x i t E v e n t . a c t i o n . e x p r e s s i o n s |

# e x i t E v e n t . a c t i o n . name ) ’ } ’ ;< e x i t C l o c k R e s e t > = ’ { ’ < c l o c k R e s e t > ’ } ’ ;

3.4.2.3. Initial State

For each Real-Time Statechart, the developer has to declare exactly one state as the initialstate. This state is the first one that is active if the parent Real-Time Statechart is active itself.

Concrete Syntax of an Initial StateFigure 3.13 shows the template for an initial state. If a state is an initial state, a black-filledcircle and a directed edge from the black-filled circle to the initial state are shown at the topleft border of this state.

<stateNameLabel>

Figure 3.13.: Concrete Syntax Template of an Initial State

3.4.2.4. Final State

The developer may declare one or more states of a Real-Time Statechart as final. This denotesthat a statechart is in a stable configuration. This implies that the embedding statechart of thestate cannot change its state or variables anymore (clocks will go on nevertheless). Thus, afinal state has no outgoing transitions. Furthermore, a final state is always a simple state (cf.Section 3.4.2.5). We demand this to prevent changes to the stable configuration.

In contrast to the UML, reaching a final state in a Real-Time Statechart does not lead tothe statechart’s termination. Another distinction to the UML is that a developer may definean entry-event (cf. Section 3.4.2.2) to a final state. We allow this, because the semanticsof our entry-events differ from the UML’s: in a Real-Time Statechart, a state is active afterexecuting the entry event. In UML statemachines, the state is already active while executingentry events. However, like the UML, a final state must not have a do-event or exit-event toensure the stable configuration.

A deactivation of a parent composite state is the only possibility to leave a final state.

Concrete Syntax of a Final StateFigure 3.14 shows a final state. A final state is shown as a state with a border drawn as adouble line.

<stateNameLabel>

Figure 3.14.: Concrete Syntax Template of a Final State

3.4.2.5. Simple State

A state in a Real-Time Statechart is called a simple state if it does not contain any furtherstates, i.e., it does not have any substates. A simple state may have invariants and state events.Additionally, it may be an initial or final state.

Concrete Syntax of a Simple StateFigure 3.15 shows the concrete syntax template of a simple state. A simple state consistsof three compartments: (i) the name compartment, (ii) the invariant compartment, and (iii)the state event compartment. Compartments (ii) and (iii) are only visualized if the developerdefines an invariant or state events for this state. If more than one compartment is used, solidborders separate the compartments.

<stateNameLabel>

<stateEventLabel>

<invariantLabel>

Figure 3.15.: Concrete Syntax Template of a Simple State

The stateNameLabel contains the name of the state. The invariant compartment containsthe invariantLabel, which reuses the concrete syntax definition of an invariant. The state eventcompartment contains the stateEventLabel. The following EBNF grammar defines the defaultnotation for a stateEventLabel. The stateEventLabel reuses the concrete syntax definition ofentry, do, and exit events.< s t a t e E v e n t L a b e l > = [ < e n t r y E v e n t >] [ ’ \ n ’ <doEvent >] [ ’ \ n ’ < e x i t E v e n t > ] ;

Figure 3.16 shows an example of a simple state. The name of the state is SimpleState1. Astate invariant is defined for this state which defines that as long as this state is active clock c1must be smaller than 15 seconds and clock c2 must be smaller or equal to 2 ·i−5 milliseconds.Moreover, all three kinds of state events are defined. The entry event executes action action1and resets the clock c0; the do event executes action action2 periodically (the period is 50milliseconds); the exit event executes action action3 and resets the clocks c1 and c2.

SimpleState1

invariant c1 < 15 s, c2 <= 2∙i-5 ms

entry / {action1} {reset: c0}

do / {action2} [period: 50 ms]

exit / {action3} {reset: c1,c2}

Figure 3.16.: Concrete Syntax Example of a Simple State

3.4.2.6. Composite State

A state in a Real-Time Statechart is called a composite state if it contains further states, i.e. ifit has substates. A composite state is an extension of a simple state. Thus, it may also haveinvariants and state events, and it may be an initial or final state.

To enable the composition of states within a composite state, we use the concept of regions.Each region contains exactly one Real-Time Statechart (the so-called embedded statechart)that contains the substates. As composite states may contain more than one region, compositestates do not only enable hierarchical statecharts, but also concurrent behavior within a Real-Time Statechart.

We distinguish non-orthogonal composite and orthogonal composite states. A non-orthogonal composite state contains exactly one region. An orthogonal composite statecontains two or more orthogonal regions and defines concurrent behavior.

Each region of a composite state has a name, which is the same as the name of the embeddedReal-Time Statechart. Hence, the names of all regions of an orthogonal composite state andthus of all embedded statecharts at this level must be unique.

In contrast to the submachine states defined in the UML, we do not permit to referencethe same Real-Time Statechart from more than one region [Gro10b, p. 551]. We imposethis restriction to avoid additional complexity concerning the scopes of clocks and variables.As we already offer explicit support for re-using components and Real-Time CoordinationProtocols, we consider a reuse of single Real-Time Statecharts as unnecessary. Thus, anembedded statechart has exactly one embedding region. As a consequence, the structure of aReal-Time Statechart is always a tree with one root.

Currently, the regions of an orthogonal composite state may not be executed in parallelbecause we currently assume that the root Real-Time Statechart is executed within one task.Thus, we enforce sequential semantics as defined by Zündorf [Zü01, p. 159]. Therefore, adeveloper has to define the processing sequence of the regions for each composite state. Forthis purpose, each region has a fixed priority defined by means of a natural number (excludingzero). A larger number indicates a higher priority. Thus, the lowest priority is 1. The highestpossible priority is the number of regions of the affected composite state.

Within an orthogonal composite state, embedded statecharts can synchronize the firing oftheir transitions via synchronization channels (cf. Section 3.4.10). A developer defines these

channels within the orthogonal composite state that (indirectly) contains the transitions thatshall synchronize.

Concrete Syntax of a Non-Orthogonal Composite StateFigure 3.17 shows the concrete syntax template of a non-orthogonal composite state.Compared to the concrete syntax template of a simple state (cf. Figure 3.15), a non-orthogonalcomposite state has an additional compartment for displaying the embedded statechart for itssingle region and the corresponding embedded statechart. The name of the region is displayedin the upper left corner of the statechart compartment. The region’s priority is not displayed,because in case of a single region, there is no order to represent. Moreover, defined variables,operations, and clocks of the embedded statechart are shown within the rtscDefinitionLabel inthe top right corner of the compartment. As this is the same label that is defined for Fig. 3.10),the same definition applies.

<stateNameLabel>

<stateActionLabel>

<invariantLabel>

StateCompartment

<regionNameLabel> <rtscDefinitionLabel>

Figure 3.17.: Concrete Syntax Template of a Non-Orthogonal Composite State

Figure 3.18 shows an example of a composite state named NonOrtogonalCompositeState1.Compared to the example for a simple state (cf. Figure 3.16), a region and a correspondingReal-Time Statechart are added. As the Real-Time Statechart’s name is rtsc_a, the regionhas this name, too. The corresponding Real-Time Statechart defines a variable and a clock.Moreover, the statechart contains two simple states and a transition.

NonOrthogonalCompositeState1

variable int i1 clock c4rtsc_a





State1a State1b

Figure 3.18.: Concrete Syntax Example of a Non-Orthogonal Composite State

Concrete Syntax of an Orthogonal Composite StateFigure 3.19 shows the template for an orthogonal composite state, which is an extension ofthe non-orthogonal composite state template (cf. Figure 3.17).

The state’s channels are shown within a channelDefinitionLabel below the stateActionLabeland separated by a solid line. The following EBNF grammar defines the default notation for achannelDefinitionLabel. Elements which have the prefix “#” are references to the meta modelelements of class State:

< c h a n n e l D e f i n i t i o n L a b e l > = ’ c h a n n e l ’ < channe l > ’ , ’ [ < channe l > ]∗ ;< channe l > = # c h a n n e l s . name ’ [ ’ # c h a n n e l s . s e l e c t o r T y p e ’ ] ’ ;

Like non-orthogonal composite states, orthogonal composite states have additionalcompartments for showing the regions. For each region, an own compartment exists. A solidline separates the compartments for the orthogonal regions from the rest of the state (thecompartments for name, invariant, state events, and channel definitions). The compartmentsare separated horizontal by dashed lines. A small circle in the upper right corner of the region’sarea contains the priority value. Like non-orthogonal composite states, each compartmentconsists of a regionNameLabel, a rtscDefinitionLabel, and a compartment for showing thestates and transitions.

<stateNameLabel>

<stateActionLabel>

<invariantLabel>

<channelDefinitionLabel>

StateCompartment_1

StateCompartment_n

...

1

n

<regionNameLabel>

<regionNameLabel> <rtscDefinitionLabel>

<rtscDefinitionLabel>

Figure 3.19.: Concrete Syntax Template of an Orthogonal Composite State

Figure 3.20 shows an example for an orthogonal composite state with two regions. Thestate’s name is OrthogonalCompositeState1. In addition to the example of Fig. 3.18, asecond region rtsc_b and a corresponding Real-Time Statechart (including two variables, anoperation, two states, and one transition) were added to the state. Region rtsc_b has a lowerpriority than rtsc_a. Moreover, two synchronization channels ch1 and ch2 are added thatenable the regions to synchronize their transition firing.

3.4.3. Transition

A transition represents a change of the active state inside a Real-Time Statechart. Sincetransitions are directed, every transition connects a source vertex to a target vertex. Vertices


OrthogonalCompositeState1

rtsc_a

rtsc_b 1

2

channel ch1, ch2

variable int i1, float f1

operation bool p1()

variable int i1 clock c4





State1a State1b

State2a State2b

Figure 3.20.: Concrete Syntax Example of an Orthogonal Composite State with two Regions

may be states (cf. Section 3.4.2) or state connection points (cf. Section 3.4.4). We distinguishbetween different types of transitions according to the types of their sourve and target vertices(cf. Section 3.4.3.1). When a transition is involved in a state change, it is said to fire. However,a transition may only fire if it is enabled according to specific enabling conditions that restrictthe circumstances for firing (cf. Section 3.4.3.2). The urgency value of an enabled transitiondetermines whether it starts to fire without delay (cf. Section 3.4.3.3). When a transition fires,it may cause certain effects (cf. Section 3.4.3.4). In addition, a transition may have deadlinesto specify requirements concerning the firing duration (cf. Section 3.4.3.5).

3.4.3.1. Types of Transitions

The different types of vertices in Real-Time Statecharts give rise to various types of transitions,distinguished according to the types of their source and target vertices. Figure 3.21 illustratesthe eight types of possible transitions in Real-Time Statecharts. The standard case for atransition is to connect two states on the same hierarchy level, as depicted in Figure 3.21(a).Two states on the same hierarchy level may also be connected indirectly using an exit pointas source or an entry point as target. We illustrate these types of transitions in Figure 3.21(b)to 3.21(d). In addition, by using entry or exit points as source or target, transitions mayalso indirectly connect states on different hierarchy levels. However, this type of transition isrestricted to the case that one of the affected states is a direct substate of the other one. InFigure 3.21(e) to 3.21(h), we illustrate these types of transitions.

All other types of transitions not depicted in Figure 3.21 are invalid inside Real-TimeStatecharts. In particular, this applies to so-called inter-level transitions that directly connecttwo states on different hierarchy levels (without using entry or exit points). In particular, wealso prohibit the case that a transition connects directly from an entry point to an exit point.


State1 State2

(a) State to State

State1 State2

(b) State to Entry Point

State1 State2

(c) Exit Point to State

State1 State2

(d) Exit Point to Entry Point

State1

State2

(e) Entry Point to State

State1

State2

(f) State to Exit Point

State1

State2

(g) Entry Point to Entry Point

State1

State2

(h) Exit Point to Exit Point

Figure 3.21.: Possible Types of Transitions in Real-Time Statecharts

Composite Transition

A special type of transition is a so-called composite transition. A transition is compositeif its source or target vertex is a composite state (cf. Section 3.4.2.6). Such transitions areabbreviations for compositions of numerous ordinary transitions. In Figure 3.22, we illustratethis abbreviating role of composite transitions. In Figure 3.22(a), an incoming compositetransition (depicted in purple) is a shorthand for an entry point that connects to the initialstates of every embedded statechart. In contrast, an outgoing composite transition (depicted ingreen) is a shorthand for an exit point which all substates in all embedded statecharts connectto. In Figure 3.22(b), we illustrate how the same abbreviation logic applies to a compositetransition that is both incoming and outgoing.


State2region2

region1 1

2

State2a State2b

State2c State2d

[g2] / {a2} State3[g1] / {a1}State1

State1 State3

State2region2

region1 1

2

State2a State2b

State2c State2d

[g1] / {a2} / {a1} [g2]

[g2]

(a) Incoming/Outgoing Composite Transitions

State2region2

region1 1

2

State2a State2b

State2c State2d

[g3] / {a3}

State2

region2

region1 1

2

State2a State2b

State2c State2d

/ {a3} [g3]

[g3]

(b) Incoming and Outgoing Composite Transition

Figure 3.22.: Composite Transitions as Shorthand Notation


Syntactic RestrictionsAlthough state connection points (i.e., entry or exit points) act as source or target of transitions,a system may not reside in a state connection point (as opposed to a state). Hence, a chain oftransitions with intermediate connection points is considered as a single transition step.

As a consequence, a particular transition leading to a state connection point only representsa leading part of an entire transition step and is therefore restricted to not involve any effectslike action, raise message, or clock resets. In addition, a transition leading to a state connectionpoint must not specify deadlines.

Analogously, a particular transition originating from a state connection point only representsa trailing part of an entire transition step. Therefore, it is restricted to not involve anyconditions like guard, trigger message, synchronization, or clock constraints.

3.4.3.2. Conditions

If the source of a transition is a state, the developer may specify additional enabling conditions.All of them must be fulfilled in order to fire the transition. As a crucial prerequisite for theenabling, the source state must be active. We describe the additional enabling conditionsbelow:

GuardA guard is a boolean expression that restricts the enabling of a transition to specific variablevalues. If a transition specifies a guard, it may only be enabled if the guard evaluates to true.Guards are expressions without side effects, specified using the action language describedin Section 3.5.3. The guard expression may refer to all variables and operations inside thetransition’s statechart or one of its direct or indirect parent statecharts.

Clock ConstraintA clock constraint is a boolean expression that restricts the enabling of a transition to specificclock values. We refer to Section 3.4.1.2 for a general description of clock constraints. Atransition may specify an arbitrary number of clock constraint. All of them must hold at thesame time in order to enable the transition. A transition may refer to all clocks defined in adirect or indirect parent statechart.

SynchronizationA synchronization causes a transition to fire only in combination with another transitionthat belongs to an orthogonal Real-Time Statechart. In order to associate transitions,every synchronization refers to a particular synchronization channel. Two transitions mayonly synchronize if their synchronizations refer to the same channel. In addition, theirsynchronizations must specify a complementary synchronization kind: there must be a uniquesender transition denoted by ! and a complementary receiver transition denoted by ?.Optionally, a synchronization comprises a selector expression, which restricts synchronization


to take place only between two transitions for which the evaluation results of the selectorexpressions are equal. We refer to Section 3.4.10 for a detailed description of synchronization.

Trigger MessageA transition that specifies a trigger message may only be enabled if a message of a particulartype has been received by the associated role (cf. Section 3.3.2) or discrete port (cf.Section 3.6.1.2). We describe message types in Section 3.2. The respective message mustbe available from the buffer for received messages. We refer to Section 3.3.2.3 for a detailedexplanation of message buffers. Section 3.4.9 illustrates the exchange of asynchronousmessages in general.

PriorityThe priority of a transition is represented by a fixed natural number greater than 0, whereas alarger number indicates a higher priority. If the enabling conditions described above apply tomore than one transition within the same Real-Time Statechart, we consider only the transitionas enabled which has got the highest priority.

3.4.3.3. Urgency

If an urgent transition fires, it does so immediately when it is enabled, i.e., no time passesbetween enabling and firing. In contrast, a non-urgent transition may postpone the firingeven if it is enabled. Consequently, it may also become disabled again, especially due toanother transition with a higher priority becoming enabled. In MECHATRONICUML, non-urgent transitions enable the modeling of uncertain situations in which the firing of a transitionis beyond the developer’s control. Verification techniques such as UPPAAL model checkingare required to resolve the above non-determinism by considering all possible points in timeat which the transition may fire.

In addition, urgent transitions have precedence over non-urgent transitions, i.e., as long as anurgent transition is enabled, no non-urgent transition may fire. If two transitions synchronizevia a synchronization channel, then they only fire urgently if both transitions are urgent.

3.4.3.4. Effects

If an enabled transition fires, it may involve specific effects. In Section 3.4.12, we define theexecution order for the different types of effects described below:

ActionIf a transition specifies an action, the firing causes its execution. On execution, the action maymanipulate dedicated variables, or call dedicated operations, defined in a direct or indirectparent statechart. We refer to Section 3.4.6 for further details on actions.


Raise MessageA transition that specifies a raise message will generate and release a message of the specifiedtype if it fires. This implies that the message is sent over a connector attached to the associatedrole or discrete port. If the message type has parameters, the raise message comprisesadditional parameter bindings given in terms of expressions. We refer to Section 3.4.9 fordetails on the exchange of asynchronous messages.

Clock ResetA firing transition may cause resets for one or more clocks which reside in a direct or indirectparent statechart. We describe the general concept of clock resets in Section 3.4.1.3.

3.4.3.5. Deadlines

Real-Time Statecharts are not restricted to the assumption that transitions fire withoutconsuming time [Lee09]. A typical reason for time-consuming transitions is the execution ofeffects as described in Section 3.4.3.4. Consequently, deadlines may be attached to a transitionin order to define a time interval in which the firing needs to be finished. We distinguishbetween relative and absolute deadlines. A transition may either specify one relative deadline,or an arbitrary number of absolute deadlines. If there is no deadline, a transition is consideredto fire without consuming additional time.

Relative DeadlineA relative deadline defines the interval where the firing of a transition needs to be finishedrelatively to the point in time when the firing started. The lower bound specifies the minimumtime the transition may take to fire and the upper bound specifies the maximum time it maytake.

Absolute DeadlineAn absolute deadline defines an interval for the values of a specific clock, in which the firingof the associated transition needs to be finished. The lower bound defines the minimum clockvalue at which the firing must terminate. The upper bound defines the maximum clock valueaccordingly.

Concrete Syntax of a TransitionA transition is drawn as a line with an open arrowhead. A solid line depicts an urgenttransition, whereas non-urgent transitions use a dashed line. The arrow originates at the borderof a source vertex and ends at the border of a target vertex. The priority value is displayedwithin a circle at the origin of the transition. If the source is not a state, the transition’s priorityis of no semantic relevance and is therefore omitted. Elements annotated to a transition arevisualized within a transitionLabel that splits into a conditionLabel, a slash, and a effectLabel.The only exception is the definition of a deadline for which a special deadlineLabel is used.Figure 3.23 shows a template for the transition syntax.

<conditionLabel> / <effectLabel>

<conditionLabel> / <effectLabel>

<deadlineLabel>

<deadlineLabel>

transition priority

source

vertex

urgent transition

target

vertex

non-urgent transition

1

2

transition label

Figure 3.23.: Concrete Syntax Template of a Transition

The following EBNF grammar defines the default notation for a transitionLabel. Elementswhich have the prefix “#” are references to the meta model elements of class Transition:

< t r a n s i t i o n L a b e l > = [ < c o n d i t i o n L a b e l > ] [ ’ / ’ < e f f e c t L a b e l > ] ;

< c o n d i t i o n L a b e l > = [ < c l C o n s t r a i n t s >][ < guard >][ < r e c e i v e r M e s s a g e >][ < sync > ] ;< c l C o n s t r a i n t s > = ’ [ ’ < c l o c k C o n s t r a i n t > [ ’ , ’ < c l o c k C o n s t r a i n t > ] ∗ ’ ] ’ ;<guard > = ’ [ ’ # gua rd ’ ] ’ ;< r e c e i v e r M e s s a g e > = # r e c e i v e r M e s s a g e T y p e . name ;<sync > = < r e c e i v e d S y n c > | < sen tSync >;< r e c e i v e d S y n c > = syncExpr ’ ? ’ ;< sen tSync > = syncExpr ’ ! ’ ;<syncExpr > = # s y n c h r o n i z a t i o n . name [ ’ [ ’ # s e l e c t o r E x p r e s s i o n ’ ] ’ ] ;

< e f f e c t L a b e l > = [ < a c t i o n >] [ < senderMessage >] [ < c l o c k R e s e t s > ] ;< a c t i o n > = ’ { ’ (# t r a n s i t i o n A c t i o n . e x p r e s s i o n s |

# t r a n s i t i o n A c t i o n . name ) ’ } ’ ;<senderMessage > = # senderMessageType . name [ ’ ( ’ ’ ) ’ ] ;

 = # p a r a m e t e r V a l u e [ ’ , ’ # p a r a m e t e r V a l u e ] ∗ ;

The following EBNF grammar defines the default notation for a deadlineLabel. Elementswhich have the prefix “#” are references to the meta model elements of class Transition:

< d e a d l i n e L a b e l > = [ < r e l D e a d l i n e L a b e l >] | [ < a b s D e a d l i n e L a b e l >]∗ ;

< r e l D e a d l i n e L a b e l > = ’ [ ’ # r e l a t i v e D e a d l i n e . lowerBound . v a l u e ’ ; ’# r e l a t i v e D e a d l i n e . upperBound . v a l u e ’ ] ’ ;

< a b s D e a d l i n e L a b e l > = # a b s o l u t e D e a d l i n e . c l o c k . name ’∈ ’’ [ ’ # a b s o l u t e D e a d l i n e . lowerBound . v a l u e ’ ; ’# a b s o l u t e D e a d l i n e . upperBound . v a l u e ’ ] ’ ;

Figure 3.24 shows an example of an urgent transition. The condition label defines (i) a clockconstraint that clock c1 must be smaller or equal to 10, (ii) restricts the integer variable i to avalue less than 5, (iii) a message of type msg1 being be at the head of the associated messagebuffer, and finally (iv) that another transition with a complementary sent synchronization overchannel ch1 must be able to fire. For synchronizing, the selector expression must evaluate to

5 (we refer to the forthcoming Section 3.4.10.1 for details on synchronizations with selector).The effect label comprises (i) an increment of variable i, (ii) the sending of a message with typem2 and parameter value i, and (iii) the reset of clock c0 to zero. The deadline label comprisesan absolute deadline which states that the value of clock c1 must be between 5 and 15 secondswhen the firing finishes.

State1 State2

[c1<=10] [i<5] msg1 ch1[5]?

/ {i++;} m2(i) {reset: c0}

clock

constraint guard

trigger

message

synchronization with

selector expression

raised

message with

parameter value

action clock

reset absolute

deadline

c1∈ [5s;15s] 1

Figure 3.24.: Concrete Syntax Example of a Transition

3.4.4. State Connection Point

The activation and deactivation of composite states via composite transitions faces certainlimitations. On activation of a composite state using an incoming composite transition, allembedded statecharts are activated by setting their initial states active. Thus, there is onlyone possible initial configuration of active substates, regardless of which transition causes theactivation. As an example, the composite state State2 in Figure 3.25 can be entered via State0or State1. However, in both cases, the internal start configuration corresponds to the initialsubstates State2a and State2c.

State0 State3

State2

region1

region2 1

2

State2a State2b

State2c State2dState1

Figure 3.25.: Activation and Deactivation via Composite Transitions

On deactivation of a composite state using an outgoing composite transition, all embeddedstatecharts are deactivated as well. The deactivation is independent from the internal stateconfiguration, i.e., the combination of currently active substates. In Figure 3.25, State2 can


be deactivated by firing the transition to State3 independently from the currently active statesin region1 and region2.

To overcome the above limitations, Real-Time Statecharts support state connection pointsfor composite states. Each state connection point of a particular composite state has a uniquename. State connection points enable chaining of transitions between different hierarchylevels, enabling more flexible activation and deactivation of composite states. For thesepurposes, we distinguish between entry and exit points similar to the UML. Both variantsare shown in Figure 3.26.

State0 State3

State2

region1

region2 1

2

State2a State2b

State2c State2dState1

Figure 3.26.: Usage of Entry and Exit Points

3.4.4.1. Entry Point

An entry point of a composite state serves as target for transitions activating the compositestate by means of a specific initial configuration of active substates. In order to do so, an entrypoint specifies exactly one outgoing transition to each embedded statechart. A firing transitionleading to an entry point activates a specific state in each embedded statechart according tothe entry point’s outgoing transitions. This results in a specific initial state configuration,which usually differs from the default set of initial states. Especially, in case of an orthogonalcomposite state with more than one region, an entry point forks the control flow and activatesa specific combination of substates.

For example, the transition leading from State0 to the entry point of State2 in Figure 3.26corresponds to an activation of the substates State2a and State2d, which differs from thedefault initial configuration consisting of State2a and State2c. Although multiple transitionsare involved, activating a composite state via an entry point is carried out as an atomic step,i.e., the composite state and the substates are activated altogether. To avoid superflous entrypoints, there must be at least one incoming transition to the entry point.

Concrete Syntax of an Entry PointWe depict an entry point by means of a small circle on the border of a composite state. Asillustrated in Figure 3.27, the name of an entry point is not part of the concrete syntax.


State1

Figure 3.27.: Concrete Syntax Example of an Entry Point

3.4.4.2. Exit Point

An exit point of a composite state serves as source for transitions deactivating the compositestate, provided a specific final state configuration. The deactivating transition originating fromthe exit point can only fire, if the currently active states in all embedded statecharts have anenabled transition leading to the exit point. Hence, in case of an orthogonal composite statewith more than one region, an exit point joins the control flow of all embedded statecharts,before deactivating the composite state.

For example, the transition leading to State3 in Figure 3.26 can only fire and deactivateState2 if the substates State2b and State2d are active. Although multiple transitions areinvolved, deactivating a composite state via an exit point is carried out as an atomic step,i.e., the substates and the composite state are deactivated altogether. Obviously, to avoid exitpoints with outgoing transitions that can never fire, each embedded statechart must connect toeach exit point at least once.

Concrete Syntax of an Exit PointWe depict an exit point by means of a small circle on the border of a composite state. Incontrast to an entry point, the circle is supplemented by a cross as depicted in Figure 3.28.The name of an exit point is not part of the concrete syntax.

State1

Figure 3.28.: Concrete Syntax Example of an Exit Point

3.4.5. EffectAn effect defines an executable behavior that is part of a state or a transition inside a Real-TimeStatechart. We distinguish the following effect types: executing actions (cf. Section 3.4.6),


resetting clocks (cf. Section 3.4.1.3), sending asynchronous messages (cf. Section 3.4.9), andconsuming asynchronous messages (cf. Section 3.4.9). Depending on the concrete modelingelement that defines a particular effect, not all effect types are available. For example, theeffect of an entry event may only execute actions and reset clocks, but may not send anasynchronous message.

Concerning execution semantics, an effect can be neither canceled nor interrupted.Moreover, the execution of an effect is synchronous, i.e., the Real-Time Statechart executiondoes not continue until the effect execution is done. The types of an effect are executed in astrict order. This order is defined separately for each Real-Time Statechart modeling elementthat may define effects.

3.4.6. Action

A developer may define actions that execute a behavior, e.g., to manipulate the values ofvariables (cf. Section 3.4.7). An action has a fixed name and contains an ordered list ofarbitrary implementation expressions. For example, an implementation expression may be ablock of the action language (cf. Section 3.5) or a reconfiguration rule (cf. Section 4.2.1.2).

An action may only be part of an effect (cf. Section 3.4.5). Regarding the executionsemantics, we currently assume that an action can neither be canceled nor interrupted.Moreover, expressions are executed according to the ordered list they are contained.

Concrete Syntax of an ActionWe encapsulate an action within curly brackets. There are two possibilities to visualize anaction: (i) we show the name of the action, or (ii) we directly show the expressions of theaction, e.g., using our action language (cf. Section 3.5).

3.4.7. Variable

A variable is a storage location with a unique name that is used to reference the stored value. Avariable is defined within a Real-Time Statechart. The value of a variable may be manipulatedby an action (cf. Section 3.4.6). The scope of a variable is the Real-Time Statechart thatdefines the variable and all embedded statecharts. A variable has a fixed data type that restrictsits possible values. All data types of MECHATRONICUML (cf. Section 3.1) are available asvariable data types.

Optionally, the developer can define an initial value for a variable. We define the initialvalue using an expression from our action language (cf. Section 3.5). Moreover, a variablemay be a constant, i.e. it must have an initial value and this value may not change at runtime.

Concrete Syntax of a VariableThe following EBNF grammar variableDefinition specifies the default notation for defining avariable. Elements which have the prefix “#” are references to the meta model elements ofclass Variable:

< v a r i a b l e D e f i n i t i o n > = [ ’ c o n s t ’ ] # da taType ’ ’ #name[ ’ := ’ # i n i t i a l i z e E x p r e s s i o n ] ;

The keyword const is shown if the variable is a constant.An exemplary variable definition is const int i := 5.

3.4.8. Operation

An operation is a callable behavioral feature of a Real-Time Statechart that encapsulates animplementation. The definition of an operation consists of a signature and its implementation.

An operation is callable from the Real-Time Statechart that defines it and from all embeddedstatecharts of this statechart. Only an action’s implementation (cf. Section 3.4.6) may call anoperation.

The operation signature consists of the name of the operation, an ordered set of inputparameters, and one return type. All operations of a Real-Time Statechart must have uniquenames. Each input parameter is defined by a data type and a name which uniquely identifiesthe parameter in the set of parameters of an operation. Moreover, the return type is also definedby a data type. All available data types of MECHATRONICUML (cf. Section 3.1) are validreturn data types, whereas a parameter must not be of type void.

Like actions, the implementation of an operation is defined by an expression using ouraction language (cf. Section 3.5.5).

In future versions of this document, we will also enable to specify operations by means ofstory diagrams [FNTZ00a, vDHP+12] that combine UML Activity Diagrams [Gro10b] andgraph rewrite rules [Roz97].

Concrete Syntax of an Operation SignatureThe following EBNF grammar defines the default notation for a operationSignature. Elementswhich have the prefix “#” are references to the meta model elements of class Operation:

< o p e r a t i o n S i g n a t u r e > = # r e t u r n T y p e ’ ’ #name’ ( ’ < o p e r a t i o n P a r a m > [ ’ , ’ < o p e r a t i o n P a r a m >]∗ ’ ) ’ ;

< o p e r a t i o n P a r a m > = # p a r a m e t e r s [ i ] . t y p e ’ ’ # p a r a m e t e r s [ i ] . name ;

An exemplary operation definition is int operation1 ( int i , int j ).The action language (cf. Section 3.5) defines a concrete syntax for implementing an

operation (cf. Section 3.5.5) and calling an operation (cf. Section 3.5.4).

3.4.9. Asynchronous Messages Exchange

Messages enable the asynchronous communication between two discrete interaction endpointsthat are assembled by means of a connector. A discrete interaction endpoint either correspondsto the role of a Real-Time Coordination Protocol (cf. Section 3.3.2) or to a discrete port (cf.Section 3.6.1.2) that refines a role’s behavior. Each discrete interaction endpoint refers to


specific message types (cf. Section 3.2) that it may send or receive. In addition, it may declarean arbitrary number of message buffers to store received messages.

In MECHATRONICUML, we use Real-Time Statecharts to specify the behavior of discreteinteraction endpoints. In particular, to control the sending and receiving of asynchronousmessages, the transitions inside Real-Time Statecharts may specify raise messages and triggermessages .

3.4.9.1. Raise Message

A raise message is one of the possible effects when firing a transition. Thus, if the transitionfires, a message of a specified type is sent via the associated discrete interaction endpoint, andtransferred over an attached connector. After successful transmission, the message is storedinto an associated message buffer of the receiving discrete interaction endpoint.

A message type may specify parameter types for transferring additional information fromthe sender to the receiver of a message. Thus, the developer can specify for each parameterof a raise message an expression that defines the parameter binding. For example, the actionlanguage (cf. Section 3.5) enables to define parameter binding expressions. A transitionthat raises a parametrized message binds concrete values to the parameters by evaluating theparameter binding expression. After successful transmission, the concrete parameter valuesare accessible to the receiver of the message.

3.4.9.2. Trigger Message

A trigger message is one of the conditions for enabling a transition. A transition may only beenabled if the defined trigger message of the specified type is available in a message bufferof the associated discrete interaction endpoint. This implies that a message of the specifiedtype has been successfully transferred over the connector and stored in the associated messagebuffer. We refer to Section 3.3.2.3 for details on message buffers.

If a transition specifies a trigger message, it consumes the respective message when firing,i.e., it removes this message from the respective message buffer. As a consequence, everymessage may only be consumed by one firing transition. The firing transition may also accessthe message’s parameters. More precisely, the concrete parameter values may be processedinside the transition action, and may be used to specify the concrete parameter values for thetransition’s own raise message. For example, using the action language (cf. Section 3.5), thedeveloper can access the parameter values.

3.4.10. Synchronization

A common use case when modeling orthogonal composite states is to allow two statecharts(embedded in orthogonal regions) to change their state only in an atomic way. Therefore, inMECHATRONICUML, a developer may constraint that a transition may not fire alone, but only


with a second transition of another orthogonal Real-Time Statechart. We call such a constrainta synchronization.

For defining a synchronization, the developer has to specify a synchronization channel atan orthogonal state. This state must be a common ancestor state of the orthogonal Real-TimeStatecharts that embed the transitions that shall synchronize (cf. Section 3.4.2). Per orthogonalcomposite state, the developer may define more than one channel. For distinguishing channels,each channel has name.

If a synchronization channel is defined, the developer can specify a synchronization byadding the channel to the condition part of the transitions. Additionally, the developer hasto define the firing order of the two transition that shall synchronize. For doing this, thedeveloper has to define the synchronization kind for each transition. The transition that shallfire first, must be of kind sender (we call it the sender transition); the transition that shall fireafterwards, must be of kind receiver (we call it the receiver transition). Thus, two transitionsthat shall synchronize must specify a complementary synchronization kind. Noteworthy, weallow only one synchronization channel (receiving or sending) per transition.

Optionally, a synchronization comprises a selector, which restricts synchronization totake place only between two transitions for which the evaluation results of the selector’sexpressions are equal (cf. Section 3.4.10.1). Thus, we distinguish between plainsynchronization (synchronizations without selector) and synchronization with selector.

Applying synchronization may change the prioritization and execution order of orthogonalReal-Time Statecharts. We define the execution semantics of synchronizations inSection 3.4.10.2.

Concrete Syntax of a Plain SynchronizationA synchronization is part of the condition label of a transition. For a sending transition, wewrite the name of the channel followed by an exclamation mark (!); for a receiving transition,we write the name of the channel followed by a question mark (?).

Figure 3.29 shows a concrete syntax example for a plain synchronization. The orthogonalcomposite state A1 defines the channel sync. This channel is used to synchronize the twotransitions of the regions B and C. Thus, the transition with source state B1 is the sendertransition and the transition with the source state C1 is the receiver transition.

3.4.10.1. Synchronization with Selector

A synchronization with selector extends a plain synchronization by an additional condition forthe firing. Selectors are a generalization of UPPAAL’s synchronization channel arrays, whichessentially are ordinary arrays containing synchronization channels [BDL04].

In the case of using a selector, the synchronization channel defines a type for the selector.Then, each synchronization using this synchronization channel needs to provide a selectorexpression that resolves to this type. In addition to the conditions for synchronization asdefined for plain synchronization in the previous section, synchronizations with selectors may


A1

B 2

channel sync

B1sync!

B2

C 1

C1sync?

C2

Figure 3.29.: Concrete Syntax Example for a Plain Synchronization

only synchronize if both, the sending and the receiving synchronization, provide the samevalue in their selector expression.

In general, we support the selector expressions of types Boolean and Integer. In case ofmulti roles, we also support to use selector expressions of type Role and Port as explained inSection 3.4.11.

Using the selector type Integer, we can model UPPAAL’s synchronization arrays. Asmentioned before, a synchronization channel array of a given size is an ordinary array whoseelements are synchronization channels.

Concrete Syntax of a Synchronization with SelectorThe concrete syntax of a synchronization with a selector extends the concrete syntax of a plainsynchronization. If a selector type is defined for a synchronization channel, then we write thetype in square brackets after the name of the channel.

For example, Figure 3.30 shows a Real-Time Statechart that has one state A1 and a variablei of type int with the initial value zero. The state A1 defines a synchronization channel namedsync with the selector type Int.

A specific synchronization channel can be used by specifying an integer expression insquare bracket just like the selector expression used in Figure 3.30. In contrast to UPPAAL,however, our specification does not require to specify a number of channels as an array size,because we only use one channel with a condition that may use arbitrary integers.

3.4.10.2. Execution Semantics of Synchronizations

In contrast to older publications, the synchronizing transitions do not get the minimum(absolute) priority of both (cf. [GB03, p. 18]). Instead a synchronization affects theprioritization and execution order of orthogonal Real-Time Statecharts as described in thefollowing.


A1

B 3

channel sync[int]

B1sync[i]!

B2

C 2

C1sync[0]?

C2

D 1

D1sync[1]?

D2

variable int i = 0;

Figure 3.30.: Concrete Syntax Example for Synchronization with Integer Selector

Sender Transition Fires First Despite Region PriorityPer default, the region priority defines the execution order of the regions of an orthogonalstate. However, synchronization may overrule region priorities when the sender transition is ina region with a lower priority than the region of the receiver transition. Then, the region withthe sender transition is executed first and the region with the receiver transition is executedafterwards (without any other region execution inbetween) because a synchronization isdirected from sender to receiver. Thus, the effects of the sender transitions are executedcompletely before executing the effects of the receiver transition.

An example for this special case is shown in Figure 3.31. It consists of an orthogonalcomposite state A1 that embeds the two regions B and C. Moreover, A1 defines the channelsync. In region B, the transition from initial state B1 to state B2 waits for / receives asynchronization via the channel sync and assigns the value 1 to variable i while firing.Similarly, in region C, the transition from initial state C1 to state C2 sends a synchronizationvia the same channel and assigns the value 2 to i while firing. The initial active stateconfiguration is (A1,B1,C1). Without the synchronization, the transition B1→B2 would beexecuted before C1→C2 because of the higher priority of region B. This would result in theassignment order i:=1; i:=2;. However, due to the synchronization, the sender transition isexecuted first leading to the assignment order i:=2; i:=1; instead. This results in the final value1 for i and the final state configuration (A1,B2,C2).

Receiver Transition Are Only Indirectly Evaluated For EnablingReceiver transitions are not evaluated directly if they may get enabled. Instead, they arechecked immediately (in descending priority order) as soon as a sender transition of anorthogonal region with the same channel is evaluated.

Figure 3.32 gives an example for this behavior. The initial composite state A1 declares thesynchronization channels syncBE and syncCD and contains the four regions B, C, D and E with


A1

B 2

B1sync? / {i := 1;}

B2

C 1

C1sync! / {i := 2;}

C2

variable int i

channel sync

Figure 3.31.: Example for: Synchronizations May Overrule Execution Order Defined byRegion Priorities Priorities

descending priorities. In each region there are two states with a transition between them. Thetransitions have no conditions except for one sending or receiving synchronization at each andthus are all enabled. The transition B1→B2 with the highest region priority of 4 is a receivertransition via channel syncBE while the transition E1→E2 with the lowest region priority of 1is the sender transition. The transitions with region priorities in between – C1→C2 with regionpriority of 3 and D1→D2 with region priority of 2 – send respectively receive synchronizationsvia syncCD. When executing the Real-Time Statechart, region B is not evaluated because itonly could fire a receiver transition. Next, region C is evaluated because it could fire a sendertransition. As the transition of region D has a receiver transition for the same channel, bothtransitions will fire. Afterwards, region E will fire with region B. This results in the final stateconfiguration (A1, B2, C2, D2, E2).

Only One-To-One SynchronizationWe allow only one-to-one synchronizations and in particular no broadcast synchronizations.This means in case of more than one sending and/or receiving transition only pairs of onesender and one receiver transition are executed.

The example given in Figure 3.33 illustrates this. It differs from Figure 3.32 insofar asstate A1 declares only the single synchronization channel sync which all four transitionsuse. Because only one-to-one synchronizations are allowed this results in the four differentsynchronization combinations C1→C2 and B1→B2 or C1→C2 and D1→D2 or E1→E2 andB1→B2 or E1→E2 and D1→D2. The sender transition with the highest region priority(C1→C2) synchronizes with the receiver transition with the highest region priority (B1→B2).

Synchronization May Overrule Transition Priorities (Part 1)A synchronizing transition in a region with higher priority may overrule the outgoing transitionpriorities in a region with lower priority. This can happen by requiring a transition to be


A1

B 4

channel syncBE, syncCD

B1syncBE?

B2

C 3

C1syncCD!

C2

D 2

D1syncCD?

D2

E 1

E1syncBE!

E2

Figure 3.32.: Example for: Receiver Transition Are Only Indirectly Evaluated For Enabling

A1

B 4

channel sync

B1sync?

B2

C 3

C1sync!

C2

D 2

D1sync?

D2

E 1

E1sync!

E2

Figure 3.33.: Example for: Only One-to-One Synchronization


executed which has conflicting outgoing transitions from the same source state but with higherpriority.

An example for this is shown in Figure 3.34. The initial composite state A1 declares thesynchronization channel sync and contains the two parallel regions B and C. In region B thereexist two outgoing transitions from initial state B1. The one with the higher transition prioritytargets state B2 and sends a synchronization via the channel sync, and the other transitionsimply targets state B3. Similarly in region C there exist two outgoing transitions from initialstate C1. Here, the lower prioritized transition to state C3 receives a synchronization overchannel sync and the other one simply targets state C2. Without the synchronization andstarting with the active state configuration (A,B1,C1) the transitions B1→B2 and C1→C2would be executed because of their respective higher priorities. However, caused by thesynchronization, the transition C1→C3 is executed instead of C1→C2. As shown in theexample of Figure 3.32, this would not be the case if transition B1→B2 is the receivertransition. In the end, the final state configuration is (A1,B2,C3).

A1

B 2

channel sync

B1sync!

B2

B3

C 1

C1 C2

sync?C3

2

1

2

1

Figure 3.34.: Example for: Synchronization May Overrule Transition Priorities (Part 1)

Synchronization May Overrule Transition Priorities (Part 2)The principle that transitions with the higher located source state have higher priority thantransitions with a lower located source state (see Section 3.4.3) may be overruled when usingsynchronizations. A synchronizing transition in a region with higher priority may require atransition to be executed which is inside the source state of another transition, which wouldnormally have the higher priority because of its higher located source state.

This case is illustrated in the example shown in Figure 3.35. It differs from Figure 3.34insofar as it defines a variable i of type int, which is set by the entry action of state A1 to1 and contains a different region C. In region C, there is only a transition from the initialstate C1 to state C2, which increments the value of variable i. C1 is a composite state now


which contains region D with the states D1 and D2 and the transition from D1 to D2 whichreceives a synchronization via channel sync and assigns variable i with value 2. Withoutsending and receiving synchronizations via channel sync and starting with the active stateconfiguration (A1,B1,C1,D1) the transitions B1→B2 and C1→C2 would be executed becauseof their higher priority respectively higher located source states leading to the final value 2of variable i. However, caused by the synchronization, the transitions B1→B2 and D1→D2are executed first – resulting in the value 2 of variable i – and afterwards transition C1→C2 –resulting in the final value 3 of i and the final state configuration (A1,B2,C2).

A1

C1

B 2

entry / {i := 1;}

B1sync!

B2

B3

C 1

/ {i++;}C2

2

1

variable int i

D1sync? / {i := 2;}

D2

D

channel sync

Figure 3.35.: Example for: Synchronization May Overrule Transition Priorities (Part 2)

3.4.11. Multi Role and Multi Port Real-Time StatechartThe behavior of multi roles and multi ports is defined by Real-Time Statecharts that adhere toa strictly defined structure. The rules that apply to multi roles and multi ports are the same.Therefore, we will only define the structure of a Real-Time Statechart that defines the behaviorof a multi role.

As defined in Section 3.3.6, the behavior of a multi role consists of an adaptation behaviorand a subrole behavior. The subrole behavior specifies the behavior that is executed foreach coordination with a connected single role instance. The adaptation behavior is used toresolve ordering constraints between the subroles and to specify an adaptation of the subrolesinstances during run-time. Please refer to Section 4.2 for a description of the actual adaptationwith a multi role.

The exemplary Real-Time Statechart in Figure 3.36 outlines the standard structure ofa Real-Time Statechart of a multi role. The Real-Time Statechart of the multi role,Distribution_distributor in the example, contains only one hierarchical state, which is theinitial state. That state contains exactly two regions, which are called adaptation and subrole-template. The region adaptation contains the adaptation behavior while the region subrole-template defines a template for the subroles. For each subrole, the template is instantiated asan additional orthogonal region to adaptation region. For example, if role distributor has twosubroles, then the state Distribution_distributor_Main has three regions: adaptation, subrole-1,and subrole-2.

Distribution_distributor variable int[2] myPos, int[8][2] posArray, bool error := false

Distribution_distributor_Main

adaptation

sub-role-template

2

1

channel receive[distributor], send[distributor], rcv_done, send_done

clock c_period, c

Active

Waiting

invariant c_period ≤ 50 ms

entry / {reset: c_period}

exit / {posArray[0][0]:=myPos[0];

posArray[0][1]:=myPos[1]; error:=false;}

Sending

invariant c ≤ 15 ms

entry / {reset: c}

send[first]!

send_done?

[c_period ≥ 50 ms] receive[first]!

Receiving


entry / {reset: c}

All_Received


entry / {reset: c}

[error==true] rcv_done?

2

1

[error==false] rcv_done?

send

receive

1

2

Idle

position receive[self]? / {posArray[id][0]:=position.xy[0];

posArray[id][1]:=position.xy[1];}

Receivedreceive[self]? / {error:=true}

2

1

Idle send[self]? / positions(posArray) Sent

[self==last] send_done!

[self<>last] send[self.next]!12

[self==last] rcv_done!

[self<>last] receive[self.next]!12

Figure 3.36.: Example of a Real-Time Statechart of a Multi Role

For example, the general behavior specified by the Real-Time Statechart of Figure 3.36 is asfollows. The adaptation Real-Time Statechart periodically triggers the first subrole to receivenew position information. After the first subrole received the information, it triggers the nextsubrole and so forth. The last subrole then reports that all data has been received by using thercv_done synchronization channel. Then, the same iteration is repeated for sending the newposition information to all single roles that are connected to the subroles.


The synchronization channels used for synchronizing the adaptation Real-Time Statechartand the subrole Real-Time Statecharts use selectors as specified in Section 3.4.10.1. Sincewe specify the behavior of a multi role, we may use the type Role as the selector type forsynchronization channels, e.g., for the channels receive and send. Then, two transitions cansynchronize using the synchronization channel, if they use a selector expression that evaluatesto the same subrole instance at run-time.

The subrole instances of a multi role are always ordered as a list. As a result, there is onesubrole instance which is the first (or last) inside the multi role. For each subrole instance,we may also retrieve the next (or previous) one in the order. We exploit the order by definingadditional keywords for referring to subrole instances within the specification of a multi roleReal-Time Statechart:• self

This keyword may only be used inside the subrole Real-Time Statechart. It refers to thesubrole instance executing the Real-Time Statechart. self will never refer to null.• first

Refers to the first subrole instance of the multi role. If no subrole is instantiated, thekeyword refers to null.• last

Refers to the last subrole instance of the multi role. If no subrole is instantiated, thekeyword refers to null.• next

This keyword must always be bound to a role, either specified by a variable or by anotherkeyword. Examples are role1.next where role1 is a variable of type Role or self.next.Then, the keyword refers to the subrole instance located after the subrole instance it isbound to. If the subrole instance that next is bound to is the last one in the multi role,next refers to null.• prev

This keyword must always be bound to a role, either specified by a variable or by anotherkeyword. Examples are role1.prev where role1 is a variable of type Role or self.prev.Then, the keyword refers to the subrole instance located before the subrole instance it isbound to. If the subrole instance that prev is bound to is the first one in the multi role,prev refers to null.

In the example of Figure 3.36, the transition from Waiting to Sending uses the keywordfirst as a selector expression for the synchronization send. As a result, the transition onlysynchronizes with the first subrole instance. The upper transition from Sent to Idle in thesubrole Real-Time Statechart uses the keyword next bound to self in the selector expression tosynchronize via send with the next subrole instance.

If one or both selector expressions refer to null, no synchronization is possible. Besidesbeing used in a selector expression, the keywords may also be used as part of guard expressionsor in the right side of an assignment.

For example, as shown in Figure 3.36, the keywords self and last have been used in the guardexpression of the transitions from Sent to Idle in the subrole Real-Time Statechart. The guards


A

(a) Source vertex is astate

B

(b) Source vertex is an entrypoint

C

(c) Source vertex is an exitpoint

Figure 3.37.: Enabling Transitions inside Real-Time Statecharts

are used to ensure that only the last subrole instance synchronizes via channel send_done withthe adaptation Real-Time Statechart.

3.4.12. Execution Semantics

The execution behavior of Real-Time Statecharts is basically given in terms of firingtransitions. The firing implies that the system changes its active combination of states. InSection 3.4.12.1, we describe the crucial prerequisites for firing a transition in terms of itsenabling conditions. The subsequent Section 3.4.12.2 illustrates our criteria for the selectionof transitions to fire among all enabled transitions. Finally, in Section 3.4.12.3, we describethe consequences of firing transitions in detail.

3.4.12.1. Enabling Transitions

A transition can only fire if it is enabled. The crucial prerequisite for enabling a transitiondepends on its source vertex. Figure 3.37 illustrates these enabling prerequisites, depictingactive states in green and enabled transitions in red.• If the source vertex is a state, it must be active to enable the transition (cf.

Figure 3.37(a)). In addition, the state must be prepared for deactivation: none of thedo actions defined for the state or one of its substates must currently execute.• If the source vertex is an entry point, the transition is enabled if there exists an incoming

transition which is enabled in turn (cf. Figure 3.37(b)).• If the source vertex is an exit point, the transition is enabled if for all regions of the

concerning composite state, there exists an incoming transition which is enabled in turn(cf. Figure 3.37(c)).

The above enabling policies give rise to join semantics for exit points, as also applied to theHierarchical Timed Automata formalism [DM01]. Hence, leaving a state via an exit point isonly possible, if all regions provide an enabled transition to the exit point. Analogously, we


apply fork semantics to entry points: a single enabled transition leading to an entry point issufficient to enable all its outgoing transitions into orthogonal regions.

Beside the above prerequisites, the fact whether a transition is enabled or not may be furtherrestricted by additional conditions described in Section 3.4.3.2. If guards or clock constraintsare defined for a transition, all of them must evaluate to true. If the transition specifies asynchronization, there must be another transition with a complementary synchronization overthe same channel which is enabled in turn. For a more detailed description of synchronization,refer to Section 3.4.10. Transitions with an asynchronous trigger message may only be enabledif a message of the specified type is available at the head of the associated message buffer ofthe concerning role or discrete port (cf. Section 3.4.9). If the above conditions apply to morethan one transition within the same Real-Time Statechart, we consider only the transition asenabled, which has got the highest priority.

3.4.12.2. Selection Criteria for Firing Transitions

The enabling rules described in Section 3.4.12.1 give rise to at most one enabled transitionper Real-Time Statechart. However, due to the hierarchical and orthogonal composition ofReal-Time Statecharts by means of composite states (cf. Section 3.4.2.6), there may still bemultiple enabled transitions at the same time. In the following, we describe our criteria forthe selection of the enabled transitions to fire in a particular execution step. The default caseis the selection of a single transition that fires in isolation. However, specific circumstanceslike synchronization (cf. Section 3.4.10) or state connection points (cf. Section 3.4.4) requiremultiple transitions to fire in combination. Thus, we extend our selection criteria to sets oftransitions, which also covers the default case of a single transition to fire. In the following,we consider only transitions which are syntactically valid in the sense of Section 3.4.3.1. Thefollowing conditions must be given to fire a set of enabled transitions:• If none of the transitions specifies a synchronization, the set of enabled transitions must

build a directed acyclic graph which is connected, as illustrated in Figure 3.38. Thisimplies that the affected transitions are entirely connected by means of single vertices,i.e., there is no transition without an immediate connection to the rest. In case ofsynchronization between two of the affected transitions, there must be a partition forthe graph into two strongly connected components.• For each of the connected graphs, all start- and endpoints must be states. In Figure 3.38,

this applies to the startpoints v1, v2, and v3, as well as to the endpoints v7 and v8. At thesame time, according to our enabling rules described in Section 3.4.12.1, the remainingvertices between two or more enabled transitions can only be entry or exit points. Thisapplies to the vertices v4, v5, and v6 in Figure 3.38.• The set of enabled transitions must be maximal, i.e., it must not be possible to extend a

graph by any further enabled transition.The above conditions ensure that firing a set of enabled transition causes a system to switch

seamlessly from one combination of states to another, traversing only entry/exit points inbetween. In the simplest case, the above conditions apply to a single enabled transition


v5 v6

v4

v1

v2

v3

v7

v8

Figure 3.38.: Connected Transition Graph

between a source state and a target state, which may fire in isolation. More complex casesare sequences or trees of enabled transitions, which are connected via entry or exit points andfire as a whole. Figure 3.39 illustrates an exemplary graph of enabled transitions which canfire according to the above rules. All start- and endpoints are states, whereas only entry andexit points are used to interconnect the transitions.

If the above characteristics apply to different sets of transitions at the same time, weapply a depth-first strategy for selection of the transition(s) to fire next. To resolve conflictsbetween transitions inside orthogonal regions, we traverse the regions circularly in descendingpriority order. Thus, every region may successively fire at most one of the transitionsinside its embedded Real-Time Statechart. However, according to our depth-first approach,an embedded Real-Time Statechart that is not able to fire any transition itself will handover the ability to any active embedded statechart. This strategy implies that a transitioninside a particular Real-Time Statechart has priority over any other transition in a sub-statechart. In general, synchronizations between orthogonal regions may result in exceptions(cf. Section 3.4.10) to our priority-based preference rule.

In general, the above selection criteria for firing transitions do not completely prevent non-determinism in the execution behavior of Real-Time Statecharts. Whereas syntactic elementssuch as deadlines, do events, or non-urgent transitions induce a non-deterministic timingbehavior, this may also affect the ability to fire particular transitions.

3.4.12.3. Firing Transitions

Once selected for execution, a set of enabled transitions is fired in sequence. Accordingto the transition direction, every transition will be fired before its successor transition. Incase of branches inside the structure of firing transitions, we pursue a depth-first strategy that


A

1

2

E

F

1

2

G

H

B

C

D

Figure 3.39.: Example for the Selection of Enabled Transitions to Fire

considers the region priorities. Thus, all transitions directly or indirectly contained in a high-priority region will fire before any transition in an orthogonal region with a lower priority.

Considering the exemplary transitions in Figure 3.39, the firing order is as follows: C toexit(B), exit(B) to exit(A), E to exit(A), exit(A) to entry(F), entry(F) to G, entry(F) to H. Incase of synchronization, we consider the synchronization direction from sender to receiver.Thus, the entire transition structure containing the sending synchronization denoted by !fires first. Afterwards, all transitions fire which are part of the structure that contains thecomplementary receiving synchronization denoted by ?. The firing of a single transition hascertain consequences as described below:

1. State DeactivationIf the source vertex is a state or exit point, the concerning state changes its statusfrom active to inactive. If the source vertex is a composite state, this also causes thedeactivation of all its currently active substates. We apply a depth-first strategy thatconsiders the region priorities and deactivates every substate before its parent state. Thedepth-first strategy implies that all states directly or indirectly contained in a particularregion will be entirely deactivated, before deactivating the orthogonal region with thenext lower priority. In general, the deactivation of a particular state implies processingof its exit event (cf. Section 3.4.2.2), including the execution of the entire exit actionand subsequent resets of the associated clocks.

2. Transition EffectsAfter the deactivation of all affected states, the trigger message of the transitionis consumed (i). Whereas the message gets removed from its message buffer, themessage’s parameter values become accessible. Thus, (ii) the transition action isexecuted and may refer to the parameter values of the trigger message. Subsequently(iii), the transition’s raise message is generated and sent over the connector attached tothe associated discrete port or role. The parameter values of the trigger message may


be used to specify the parameter values for the raise message. Finally (iv), all clocksassociated with the firing transition are reset.

3. State ActivationFinally, if the target vertex is a state or entry point, the concerning state changes itsstatus from inactive to active. If the target vertex is a composite state, this also causesthe activation of all its initial substates. We apply a depth-first strategy that considers theregion priorities and activates every state before its substates. The depth-first strategyimplies that all states directly or indirectly contained in a particular region will beentirely activated, before activating the orthogonal region with the next lower priority.In general, the activation of a particular state implies processing of its entry event(cf. Section 3.4.2.2), including the execution of the entire entry action and subsequentresets of the associated clocks. In case of a composite state, variables declared insidesub-statecharts are initialized first by means of their dedicated initial values, beforeactivating any initial substates.The effective activation of a particular state does not take place before the activatingtransition has completely finished its firing process, including the activation of allaffected states. The following incidents take place when a particular state becomeseffectively active:• Clocks declared inside sub-statecharts start to run.• The state’s invariant must hold.• The do action is released for periodic execution.

In general, the effective state activation is assumed to finish within the time restrictionsinduced by the firing transition’s deadlines. This implies that the effective time ofactivation fulfills all specified deadlines. On the one hand, an absolute deadline isfulfilled if the time value of the respective clock is within the specified interval at thetime of the target state’s effective activation. On the other hand, a relative deadlineis fulfilled if the overall firing duration is within the specified interval. When firing aconnected graph of transitions in the sense of Section 3.4.12.2, the firing duration isconsidered as the overall time from deactivation of the first affected state to the effectivestate activation.


3.5. Action Language

In MECHATRONICUML, we define an action language for specifying executable behaviorsand Boolean evaluations. Especially, we use our action language for defining guards andclock constraints at transitions (cf. Section 3.4.3) and to define any kind of actions (cf.Section 3.4.6). The action language consists of a well-defined abstract syntax in form of ameta-model and a textual concrete syntax in form of an EBNF grammar.

Our action language supports the specification of assignments, comparison expressions,arithmetic expressions, logic expressions, and unary expressions. Expressions can becombined into a block and blocks can be included into control structures like loopsor conditional statements. The action language is based on OMG Alf [Gro11a] andUPPAAL [BDL04], which both have a largely “C like" syntax.

3.5.1. Block

A block is used to group expressions. Therefore, it consists of a list of expressions in a linearorder. The braces ‘{’ and ‘}’ are used to encapsulate a code block and a new scope. Such alist of expressions may be attached to a loop as a body or represent a path of a conditionalstatement (cf. [Gro11a, p.97]).

Example

{ / / b l o c k b e g i n

} / / b l o c k end

3.5.2. Local Variable Declaration and Initialization

A local variable declaration enables to declare a local variable inside a Block. Local variablesare declared according to the C-rule. This means they are visible and usable after thedeclaration within their block and in containing sub-blocks.

Local variables may not have the same name as a variable that is declared in the real-timestatechart or another block which has a similar scope to avoid masking.

A local variable and a statechart variable share the following same characteristics: (1) Thedata type of the variable is specified by referencing the name of the data type that should beused. The developer can choose between all externally defined data types. (3) A local variablemay be constant.

It is not allowed to declare new local variables typed over a component model data type (cf.Section 3.1.4). Further, it is not possible to define new data types within the action language.

3.5. ACTION LANGUAGE 69

Example

{/ / l o c a l v a r i a b l e d e c l a r a t i o n and i n i t i a l i z a t i o nc o n s t INT varA := 3 ;

/ / l o c a l v a r i a b l e d e c l a r a t i o n and a r r a y i n i t i a l i z a t i o nP o s i t i o n A r r a y varB := [ 2 3 , 4 2 ] ;

}

3.5.3. Expression

An expression specifies a behavior and can be evaluated to a value of a certain data type, whichcan also be void. Expression is the abstract super type of all elements in the action language(cf. [Gro11a, p.25]).

Expressions, which change the value of a variable or parameter, are called assignments.We use the TypedNamedElementExpression, which has a reference to a concreteTypedNamedElement, e.g., variable, parameter hybrid port, to perform an action on a valueof a TypedNamedElement. If the referenced TypedNamedElement is a variable array orparameter array, a concrete array element can be referenced via specifying the indices insquared brackets (‘[’indexExpression‘]’)*. To refer to a concrete value, we use literalexpressions, which represents a value of a primitive data type. The unary expression isan expression with only one operator and one operand. The operator performs its actionon the evaluated result of the operand. A binary expression is an expression with oneoperator and two operands. We distinguish between three types of binary expressions: (i) Thearithmetic expressions use the ArithmeticOperator as operator, (ii) comparison expressions usethe ComparingOperator as operator, and (iii) binary logic expressions use the LogicOperatoras operator.

Example

{/ / l o c a l v a r i a b l e d e c l a r a t i o n s and i n i t i a l i z a t i o n sINT varA := 3 ;INT varB := 2 ;BOOLEAN varC := f a l s e ;

/ / Types o f E x p r e s s i o n s

/ / a s s i g n m e n t o f an a r i t h m e t i c e x p r e s s i o n r e s u l t t o a v a r i a b l evarA := varA + varB ;

/ / a s s i g n m e n t o f a compar i son e x p r e s s i o n r e s u l t t o a v a r i a b l evarC := varA < varB ;

/ / a s s i g n m e n t o f a l o g i c e x p r e s s i o n r e s u l t t o a v a r i a b l evarC := ( varC | ( varA < varB ) ) ;

/ / a s s i g n m e n t o f a unary e x p r e s s i o n t o a v a r i a b l evarC := not varC ;

/ / a s s i g n m e n t o f a l i t e r a l t o a h y b r i d p o r tmyHybr idPor t := 5 ;

/ / a s s i g n m e n t o f a t r i g g e r message parame te r ’ s v a l u e t o a v a r i a b l e/ / message t y p e name i s msg1 , parame te r name i s p1 , p1 i s parame te r o f msg1varC := msg1 . p1 ;

}

3.5.3.1. Selector Expressions

The action language contains selector expressions for specifying Real-Time Statechartbehavior for multi-ports. They are described in Section 3.4.10.1 as they are only used withinReal-Time Statecharts.

3.5.4. Operation Call

An operation can be called/invoked from the action language by an operation call. Theoperation call is written by a reference on the unique operation name followed by roundedbrackets ‘()’ which enclose the parameter bindings for the operation call. The parameterbinding is specified by parameter_name := expression. The operation call is closed byan white space followed by a semicolon.

Example

{/ / l o c a l v a r i a b l e d e c l a r a t i o n and i n i t i a l i z a t i o nINT varA := 0 ;

/ / a s s i g n e x p r e s s i o n w i t h an o p e r a t i o n c a l l/ / which g e t s two bound p a r a m e t e r svarA := a d d O p e r a t i o n ( parameterNameA := varB , parameterNameB := varC ) ;

}

3.5.5. Operation Implementation

A developer implements an operation of a Real-Time Statechart (cf. 3.4.8) by a block ofour action language. The return value of an operation is specified by the keyword return

followed by one return expression. Within the operation implementation, the variables ofthe embedding Real-Time Statechart are available by reference, the parameter variables areavailable by value. Local variables are only available within the operation. It is not allowedthat statechart variables, parameters, hybrid ports, and local variables have the same name.

In a future version of MECHATRONICUML, we plan to additionally enable call-by-reference parameters.

ExampleFor an operation signature addOperation(INT parameterNameA, Int parameterNameB), the followingoperation implementation may be defined using the action language.

{INT varC := 0 ; / / l o c a l v a r i a b l e d e c l a r a t i o n and i n i t i a l i z a t i o n

/ / a s s i g n m e n t o f an a r i t h m e t i c e x p r e s s i o n r e s u l t t o a v a r i a b l evarC := parameterNameA+parameterNameB ;re turn varC ; / / r e t u r n s t a t e m e n t

}

3.5.6. Assignment

An assignment is used to assign a value to an attribute. An assignment is a binary expression.Therefore, it has a left-hand-side and a right-hand-side. The left-hand-side of an assignmentmust be a single variable, parameter, or hybrid port and must not be another expression. Theright-hand-side expression evaluates to a value which is assigned to the left-hand-side element(cf. [Gro11a, p.92]). A simple assignment is made using the <ASSIGN> Operator ‘:=’. Wehave four more assign operators, which are used as abbreviated syntax form (cf. Section 3.5.9).

Example

{varA := varB ; / / a s s i g n m e n t e x p r e s s i o nvarA := varB [ varA ] ; / / a s s i g n m e n t e x p r e s s i o n

}

3.5.7. Loop

A loop statement executes a block until the Boolean value of loop test expression is false. Theaction language supports three kinds of loops. The while-statement first evaluates the looptest expression (i.e., the loop condition) and afterwards, if the expression evaluates to true, itexecutes the block. The do-while- statement first executes the block and afterwards it evaluatesthe loop test expression. If the expression evaluates to true, it executes the block again. Thefor-loop-statement first initializes a loop variable by the initialize expression and afterwards

assigns variable by the counting expression to successive values of a sequence during eachloop run (cf. [Gro11a, p.117 ff.]).

Example

{/ / l o c a l v a r i a b l e d e c l a r a t i o n s and i n i t i a l i z a t i o n sINT varA := 0 ;INT loopVar := 1 ;BOOLEAN l o o p T e s t := t rue ;

/ / w h i l e loopwhi le ( l o o p T e s t ) {

varA := varA + 1 ;}

/ / do−w h i l e loopdo {

/ / a s s i g n m e n t e x p r e s s i o nvarA := varA + 1 ;

} whi le ( l o o p T e s t ) ;

/ / f o r−l oopf o r ( INT loopVar : = 1 ; loopVar < 2 2 ; l o o p T e s t ++) {

/ / a s s i g n m e n t e x p r e s s i o nvarA := varA+ loopVar ;

}}

3.5.8. If-Statement

An if-statement is used when the referenced block should be executed only under certainconditions. An if-statement always has one if-condition and a corresponding if-block, anynumber of elseif-conditions and a corresponding elseif-blocks, and at most one else-block (cf.[Gro11a, p.112]).

Example

{/ / l o c a l v a r i a b l e d e c l a r a t i o n s and i n i t i a l i z a t i o n s

BOOLEAN i f C o n d i t i o n := t rue ;BOOLEAN e l s e i f C o n d i t i o n := f a l s e ;INT varC := 0 ;

/ / c o n d i t i o n a l i f −b l o c ki f ( i f C o n d i t i o n ) {

/ / a s s i g n m e n t e x p r e s s i o nvarC := 1 ;

}/ / c o n d i t i o n a l e l s e i f −b l o c ke l s e i f ( e l s e i f C o n d i t i o n ) {


}/ / e l s e−b l o c ke l s e {


}}

3.5.9. Operator

This section defines the different kinds of operators and the symbols for all operators. Theaction language distinguishes between assign operators, increment decrement operators,logic operators, arithmetic operators, comparing operators, and unary operators. Eachoperator kind can only be used in its corresponding expression, e.g., AssignOperator inan assignment (cf. Section 3.5.6) or ComparingOperator in a comparison expression (cf.Section 3.5.3).

< A s s i g n O p e r a t o r > = <ASSIGN> | <PLUS_EQUAL> | <EQUAL_PLUS> |<MINUS_EQUAL> | <EQUAL_MINUS>;

<ASSIGN> = ’ := ’ ;<PLUS_EQUAL> = ’+= ’ ;<MINUS_EQUAL> = ’−= ’ ;

< L o g i c O p e r a t o r > = <AND> | <OR> | <XOR> | <IMPLY> |<EQUIVALENT>;

<AND> = ’&’ ;<OR> = ’ | ’ ;<XOR> = ’ xor ’ ;<IMPLY> = ’=> ’ ;<EQUIVALENT> = ’<=> ’ ;

< A r i t h m e t i c O p e r a t o r > = <PLUS > | <MINUS> | <TIMES> | <DIVIDE> | <MODULO>;<PLUS> = ’+ ’ ;<MINUS> = ’− ’ ;<TIMES> = ’∗ ’ ;<DIVIDE> = ’ / ’ ;<MODULO> = ’%’ ;

<Compar ingOpera tor > = <LESS> | <LESS_OR_EQUAL> | <EQUAL> |<GREATER_OR_EQUAL> | <GREATER> | <UNEQUAL>;

<LESS> = ’< ’ ;

<LESS_OR_EQUAL> = ’<= ’ ;<EQUAL> = ’== ’ ;<GREATER_OR_EQUAL> = ’>= ’ ;<GREATER> = ’> ’ ;<UNEQUAL> = ’<> ’ ;

 = <INCREMENT> | <DECREMENT>;<INCREMENT> = ’++ ’ ;<DECREMENT> = ’−− ’ ;

< UnaryOpera to r > = <NOT> | <MINUS> ;<NOT> = ’ n o t ’ ;<MINUS> = ’− ’ ;

3.5.10. TerminalThis section defines the possible terminal symbols.<NUMBER> = ( ’ 0 ’ . . ’ 9 ’ )+ ( ’ . ’ ( ’ 0 ’ . . ’ 9 ’ ) + ) ? ;<BOOLEAN> = ’ t r u e ’ | ’ f a l s e ’ ;

3.5.11. GrammarThe concrete textual syntax and grammar is defined using Xtext3 in Appendix B.

3http://www.eclipse.org/Xtext/

http://www.eclipse.org/Xtext/

3.6. COMPONENT MODEL 75

3.6. Component Model

In MECHATRONICUML, the system structure is specified by a component model. Acomponent represents a software entity with high cohesion and clearly defined interfaces thatit exposes via its ports. The component encapsulates its inner structure and behavior, i.e., itmay not be accessed directly by other components [Obj09].

In contrast to the definition of Szyperski [Szy98], we explicitly distinguish betweencomponent types and component instances. The component types are instantiated tocomponent instances to specify a concrete system, e.g., for simulation. In the remainder of thisdocument, we will refer to component types simply as components. Instances of a componentto be used in a concrete system specification are denoted as component instances. In thissection, we will focus on the definition of components while the instantiation of componentswill be described in the subsequent Section 3.7.

In our component model, we distinguish between atomic components and structuredcomponents. Atomic components which we will introduce in Section 3.6.1 contain a statefulbehavior specification. Depending on their implementation and purpose, we will distinguishbetween two kinds of atomic components: discrete atomic components and continuous atomiccomponents. Structured components that will be introduced in Section 3.6.2 are assembledby embedding other components. Therefore, they carry no explicit behavior specification bythemselves. Again, we will distinguish between two kinds of structured components: discretestructured components and hybrid structured components.

3.6.1. Atomic Component Type

In this section, we will introduce atomic components which form the lowest level of theMECHATRONICUML component model.

3.6.1.1. Atomic Component

An atomic component is a component that contains a behavior specification directly. Thebehavior specification includes a definition of the internal behavior of the component aswell as the externally visible behavior that it exposes via its ports. The components ofMECHATRONICUML operate according to the Active Object Pattern [SSRB00], i.e., eachatomic component instance is executed concurrently in its own task.

Additionally, a component contains a set of port types, simply denoted as ports, to interactwith other components.

As mentioned before, we distinguish two kinds of atomic components based on theirimplementation and purpose. The two kinds are discrete components and continuouscomponents.


Discrete ComponentA discrete component is a software component whose behavior is specified by a discretecomponent behavior specification (cf. Section 3.6.1.4). As defined in Section 3.3, discretecomponents interact by means of message passing only. A discrete atomic component mayonly have discrete and hybrid ports (cf. Section 3.6.1.2).

Continuous ComponentA continuous component represents a feedback (closed-loop) or feed-forward (open-loop)controller [Kil05] of a mechatronic system. In our component model, we only specify theinterface of the continuous component, i.e., its ports, but not its internal behavior [BGH+07].The internal behavior of a continuous component is assumed to be specified in a controlengineering tool like CamelView4 or Matlab/Simulink 5. A continuous atomic componentmay only have continuous ports (cf. Section 3.6.1.2).

Concrete Syntax of an Atomic ComponentFigure 3.40 shows the concrete syntax of the two kinds of atomic components. They arevisualized uniformly as a rectangle with a component icon in the upper right corner and ahorizontally left aligned and vertically centered name label. The concrete syntax of ports willbe explained in the subsequent Section 3.6.1.2.

a) discrete b) continuous

MotionCtrl

speed_in speed_out

angle_in angle_out Navigation

speed_target

turnAngle_target

positionsender

provider

Navigation.provider

PositionTransmission.sender

Figure 3.40.: Concrete Syntax of Different Kinds of Atomic Components

3.6.1.2. Port

A port is a directed, external interaction point of a component. A component may only interactwith other components via its ports. On the type level, all possible connections betweencomponents are specified by assemblies (cf. Section 3.6.2.5) connecting the ports of thecomponents. The ports are then instantiated to port instances of component instances andmay be connected during run-time complying to the assemblies (cf. Section 3.7).

Based on the direction, we distinguish in-ports, out-ports, and in/out-ports. Informationenters the component at an in-port. At an out-port, information leaves the component. At

4http://www.ixtronics.com/ix_hist/English/CAMeLView.htm5http://www.mathworks.de/

http://www.ixtronics.com/ix_hist/English/CAMeLView.htm

http://www.mathworks.de/


in/out-ports, both is possible. Each port of a component has a name which uniquely identifiesthe port within the respective component.

We distinguish between optional and mandatory ports. If a port is optional then an instanceof the port is not always active during runtime, i.e., it does not always send or receive values.If a port is mandatory, then an instance is always active during runtime.

Based on the kind of information a port processes, we distinguish three kinds of ports.These are discrete, continuous, and hybrid ports. It depends on the kind of component whichport types it may use.

Discrete PortA discrete port is used by discrete atomic components for sending or receiving discrete,asynchronous messages that are typed over a message type (cf. Section 3.2.2). Discrete portsmay be in-ports, out-ports, and in/out-ports. That means they may receive messages, sendmessages, or both.

The behavior of a discrete port is specified by its port behavior specification as described inSection 3.6.1.3. A developer has to assign a role of a Real-Time Coordination Protocol to adiscrete port. Then, the behavior specification of the discrete port must be a correct refinementof its role.

Similar to a role, a discrete port defines a message buffer for incoming messages (cf.Section 3.3.2.3). Typically, the port and the role use the same message buffer definition, butthe port may also use a larger buffer for enabling more sophisticated refinements of the portbehavior (cf. Section 3.6.1.3, [BHSH13]).

Discrete ports may have a sender and a receiver message type specification (cf. Section 3.2).Thus, the direction of a discrete port can be derived from its message type specification. Asender message type specification defines which types of messages may be sent via this port.A receiver message type specification defines which types of events may be received via thisport. If a discrete port has only a sender message type specification, it is a discrete out-port.If it has only a receiver message type specification, it is a discrete in-port. If it has both, it isa discrete in/out-port. A discrete port may only send or receive one message at a particularpoint in time.

Analogously to roles of a Real-Time Coordination Protocol, discrete ports specify acardinality with a lower and upper bound. This is similar to the concept of replicated portsin ROOM [SGW94]. For an upper bound of 1, we call it a single port. For an upper boundgreater than 1, we call it a multi port [EHH+13].

The cardinality is given in terms of the Min-Max-Notation [Abr74], i.e., it specifies thenumber of connections a port may have. For a discrete port, each connection is managed bya subport instance of the port during run-time. Then, the lower bound defines the minimumnumber of subport instances that each instance of the port must have. Accordingly, the upperbound defines the maximum number of subport instances.

Based on the lower bound, we distinguish if a discrete port is mandatory or optional. Adiscrete port is optional if it has a lower bound of 0. A discrete port is mandatory if it has a


lower bound greater or equal to 1, because in this case at least one instance of the discrete portis mandatory for each instance of the component.

The structure and the behavior specification of a discrete multi port is analogous to multiroles of a Real-Time Coordination Protocol (cf. Section 3.3.6). The behavior specificationof a discrete multi port consists of an adaptation behavior and a subport behavior [EHH+13].The adaptation behavior controls the creation and deletion of the subport instances at run-time (using reconfiguration) and is responsible for resolving dependencies between thesubport instances. The subport behavior defines the behavior of the subport instances. Allsubport instances share the same behavior specification as defined in Section 3.6.1.3. Thereconfiguration, i.e. creation and deletion of subport instances, is defined in [EHH+13]. Ashort description is given in Section 4.2.1.2 and will be added in a future version of thisdocument.

As mentioned before, a developer has to assign a role of a Real-Time Coordination Protocolto each discrete port of a component. Such assignment is only allowed if both, the role andthe port, have exactly the same message type specification. In addition, a single role of a Real-Time Coordination Protocol may only be assigned to a discrete single port while a multi roleis typically assigned to a discrete multi port. In case of a discrete multi port, the cardinality ofthe discrete multi port must either be equal to the cardinality of the multi role or it must restrictthe cardinality. As a special case, the port may restrict the cardinality to an upper bound of1 which, in essence, allows that discrete multi roles are assigned to single ports. The lowerbound of the cardinality may be relaxed from 1 to 0 if the discrete port must not be presentin all scenarios and if, thus, the corresponding Real-Time Coordination Protocol is not alwaysinstantiated.

Continuous PortA continuous ports may only be used at continuous atomic components. They send or receivesignal values. As defined for MATLAB/Simulink “a signal is a time varying quantity that hasvalues at all points in time”6.

A continuous port is either an in-port or an out-port, but never an in/out-port. The type ofthe signal being processed by a continuous port is defined by a data type. The data type iseither a primitive data type (Boolean, Short, Int, Long, Float, Double; cf. Section 3.1.1), aranged primitive data type (cf. Section 3.1.2), or an array data type (cf. Section 3.1.2).

Hybrid PortA hybrid port acts as a bridge between continuous components (e.g., controllers) and discretecomponents. It may be used at discrete atomic components. A hybrid port emits or receivesa signal value like a continuous port. In contrast to a continuous port, the hybrid portdiscretizes the signal value in given time intervals (by specifying a concrete time value (cf.Section 3.4.1.1)) and provides the value as variable to the behavior specification of the atomiccomponent. The hybrid port does not define message interfaces.

6http://www.mathworks.de/help/toolbox/simulink/ug/f15-99132.html

http://www.mathworks.de/help/toolbox/simulink/ug/f15-99132.html


Concrete Syntax of a Port of an Atomic ComponentThe concrete syntax of ports of an atomic component is depicted in Figure 3.41. Thevisualization depends on the kind of the port and the direction of the port. In general, ports areplaced on the border of the component such that the center of the port lies on the border lineof the component as shown in Figure 3.40. In addition, the name of the port is shown next tothe component and positioned outside of the component.

Discrete ports are depicted by squares and embed small isosceles triangles that denote thedirection of the port. For an in-port, the top of the triangle points inwards, for an out-portit points outwards. A dashed line represents the role of a Real-Time Coordination Protocolwhich is assigned to the discrete port. The name of the Real-Time Coordination Protocol andthe name of the assigned role are annotated at the dashed line (cf. Figure 3.40).

in-port out-port in/out-port

discrete

continuous

hybrid

n/A

n/A


discrete

continuous

hybrid

n/A

n/A

a) Mandatory Port b) Optional Port

Figure 3.41.: Concrete Syntax of Ports

Continuous ports are depicted by isosceles triangles. For a continuous port, the triangle“points” into the component for an in-port and out of the component for an out-port.

A hybrid port is depicted by a square that embeds one isosceles triangle. The triangle isfully inscribed into the square. Thus, the base of the isosceles triangle resembles one edge ofthe square and the point of the triangle that is opposite to the base touches the opposite edgeof the square.

In our concrete syntax (cf. Figure 3.41), we use filled triangles to denote mandatory portsand unfilled triangles to denote optional ports.

The concrete syntax of discrete multi ports is shown in Figure 3.42. A multi port hasa cascaded double border line and it positioned like a single-port. Again, a filled triangledenotes a mandatory discrete multi port while an unfilled triangle denotes an optional discretemulti port.

3.6.1.3. Port Behavior Specification

The port behavior specification specifies the run-time behavior of a port. In this section wedescribe the behavior specification for all three kinds of ports.



discrete

continuous

hybrid

n/An/An/A

n/A n/A n/A


discrete

continuous

hybrid

n/An/An/A

n/A n/A n/A

a) Mandatory Port b) Optional Port

Figure 3.42.: Concrete Syntax of Discrete Multi Ports

Discrete Port Behavior Specification

The behavior of a discrete port is specified by means of a Real-Time Statechart. In case ofa discrete single port, the behavior is defined by a single Real-Time Statechart. In case of adiscrete multi port, the behavior is defined by a Real-Time Statechart which follows the rulesintroduced in Section 3.4.11.

The Real-Time Statechart of a discrete port may be obtained in three ways. Firstly, a roleof a Real-Time Coordination Protocol may be assigned to the port by a developer. Then,the port behavior must guarantee to behave according to the behavior of the assigned role.This can be achieved by copying the Real-Time Statechart of the role to the port and refineit afterwards [HH11]. Secondly, if no suitable Real-Time Coordination Protocol exists forthe intended communication, a Real-Time Statechart for the port may be specified directly.Then, this Real-Time Statechart has to be abstracted by the developer to a role of a Real-Time Coordination Protocol before connecting the port to a port of another component in astructured component or in a component instance specification. The abstraction removes allelements from the Real-Time Statechart that are implementation specific for the port like,e.g., synchronizations with the internal component behavior (cf. Section 3.6.1.4). Thirdly,both, the Real-Time Statechart of the port and the role of a Real-Time Coordination Protocolmay exist. In all three cases, the Real-Time Statechart of the port has to be checked for acorrect refinement of the role behavior [HH11]. If the check is successful, the port is said toimplement the role behavior.

Essentially, a discrete port is a correct refinement of a role if it neither adds nor removesexternally visible behavior. The externally visible behavior consists of the messages that aresent and received via the respective port and the time intervals in which they are sent andreceived. Thus, it is allowed to add states, transitions, and actions which specify internalbehavior like implementation specific computations or synchronizations. Furthermore, therefinement definition introduced in [HH11] exploits the fact that ports may buffer incomingmessages until they are processed by the Real-Time Statechart of the discrete port. Thatenables to delay the reception of messages, but requires an alternating sequence of sent andreceived messages.


Within the Real-Time Statechart of the discrete port, only asynchronous messages thatare typed over the message types declared in the message type specification of the portmay be used. Asynchronous messages may only be used for interaction with anothercomponent and they may not be used for interaction with the internal behavior of thecomponent (cf. Section 3.6.1.4). Then, messages typed over message types declared in thereceiver message type specification may only occur in trigger messages of the Real-TimeStatechart. Accordingly, messages typed over message types declared in the sender messagetype specification may only occur as raised messages (cf. Section 3.4.9).

In addition to asynchronous messages, the discrete port Real-Time Statechart may usesynchronizations as defined in Section 3.4.10 to interact with the internal behavior of thecomponent (cf. Section 3.6.1.4). The discrete port Real-Time Statechart may only usesynchronizations that are typed over synchronization channels which are defined by thedeveloper within the component behavior specification of the containing component (cf.Section 3.4.10). Such synchronizations are used to exchange data with the internal componentbehavior and to resolve dependencies between different discrete port Real-Time Statecharts.

Continuous Port Behavior SpecificationA continuous port emits or receives a signal value which “is a time varying quantity thathas values at all points in time”7. As such, a continuous port only specifies a data typefor the signal, but no behavior specification. The behavior which controls the signal isimplemented as part of a continuous component whose behavior is not considered to be partof a MECHATRONICUML specification (cf. Section 3.6.1.4).

For ensuring that a model can be initialized correctly, continuous out-ports may define aninitialize expression that defines an initial signal value that is emitted by the port. Continuousin-ports do not receive an initialize expression, because their initial value is determined by theout-port that they are connected to.

Hybrid Port Behavior SpecificationA hybrid port enables the interaction of discrete and continuous components at run-time. Suchinteraction is necessary for setting new reference values to the controllers of the system or forretrieving current sensor value, e.g., of the current position. Like a continuous port, it emits orreceives a signal value and specifies a data type for the signal value. The conditions for datatypes and initialize expressions are the same as for continuous ports.

In contrast to a continuous port, a hybrid port can only be specified for discrete atomiccomponents. The signal value of the hybrid port can then be used in the component behaviorspecification (cf. Section 3.6.1.4). In case of a hybrid in-port, the value may be read. In caseof a hybrid out-port, the value may be written. In both cases, the value is accessed by usingthe name of the hybrid port like a variable of the Real-Time Statechart of the component.

In order to support model checking of hybrid ports, the value of a hybrid port may onlychange in predefined intervals. If we omitted this restriction, we would have to consider

7http://www.mathworks.de/de/help/simulink/ug/signal-basics.html

http://www.mathworks.de/de/help/simulink/ug/signal-basics.html


defining the changes of the signal value. These changes of a signal value are typically definedby differential equations. A verification of a model including differential equations is calleda hybrid model checking problem [ACH+95]. Model checking such hybrid specifications isonly feasible for very small models [Alu11]. Therefore, we assign a sampling interval to thehybrid port. The sampling interval specifies that the value of the hybrid port only changeseach x units of time which allows to perform standard timed model checking.

3.6.1.4. Discrete Component Behavior Specification

The behavior specification of a discrete atomic component is given by means of a Real-Time Statechart. The MECHATRONICUML process offers two possibilities to obtain thatcomponent behavior specification. Both possibilities consider the port Real-Time Statechartas the implementation of the port behavior, i.e., the port behavior is a part of the componentbehavior.

According to our process (cf. Section 5.2.4), the first possibility for obtainingthe component behavior is using the synthesis approach introduced by Eckardt andHenkler [EH10]. The synthesis composes all port Real-Time Statecharts into a single Real-Time Statechart for the component. Additionally, a set of state restrictions may be specifiedthat forbids certain combinations of states of the synthesized Real-Time Statecharts. If thesynthesis algorithm successfully generates a Real-Time Statechart for the component, thisReal-Time Statechart is a correct refinement of all port Real-Time Statecharts by construction.If no such Real-Time Statechart exists, the synthesis fails and does not return a Real-TimeStatechart for the component. This approach can only be applied if the whole behavior of thecomponent is specified within its ports and if no data has to be exchanged between the portsof the component.

The second possibility for obtaining the component behavior is the manual, but structuredcreation of a Real-Time Statechart for the component. This approach can be applied inany situation. Then, the Real-Time Statechart of the component consists of one state onlythat contains a set of regions and declares a set of synchronization channels that may beused for communication inside the component, but not for communication between differentcomponent instances. We obtain one region for each discrete port of the atomic componentthat contains the Real-Time Statechart of that port. In addition, the developer may define anarbitrary number of regions containing internal behavior of the component.

Figure 3.43 shows an example of the component behavior specification of the componentNavigation containing one state Navigation_Main. The regions for the state of the componentReal-Time Statechart are constructed as follows. For each discrete single port, there exists oneregion containing the Real-Time Statechart of the port. For each discrete multi port, there existone region containing a Real-Time Statechart which in turn has one state with two regions.These two regions contain a type definition of the Real-Time Statechart of the subports and theadaptation Real-Time Statechart. The Real-Time Statechart for the subport will be instantiatedonce for each subport instance thereby resolving the parameters of the Real-Time Statechart(cf. Section 6.1.3). This instantiation is performed by the reconfiguration which will be


explained in a future version of this document. Additionally, the state may contain arbitrarilymany so-called synchronization statecharts. These synchronization statecharts represent theinternal behavior of the component.

Navigation_Main

provider

sender

Synchronization1

Sender_Main

adaptationsub-port

a) Atomic Component Navigation b) Component Behavior Specification

for Navigation

Navigation

sender

provider

Navigation.provider


speed_target

turnAngle_target

position

Figure 3.43.: Structure of the Statechart of the Component Behavior of an Atomic Component

The compositional verification approach described by Giese et al. [GTB+03] requires torestrict synchronization within an atomic component. The compositional verification approachverifies the Real-Time Coordination Protocols and the atomic components separately fromeach other. In order to obtain valid verification results, the dependencies between the differentReal-Time Coordination Protocols must be resolved by the synchronization statechart in astructured way.

For a single-port, synchronization is only allowed between the port statechart and thesynchronization statecharts of the component behavior specification. For a multi port,synchronizations are allowed between the adaptation statechart and the subport statechart.Since a multi port may be instantiated multiple times, there exist multiple instances of thesubport Real-Time Statechart. Then, synchronization is also allowed between the subportinstances. The adaptation statechart may synchronize with the synchronization statecharts andall synchronization statecharts may synchronize with each other. All other synchronizationbetween the different regions are not allowed.

The synchronization statecharts may access the attributes that are defined within the Real-Time Statechart of the component, but they must not access the attributes specified in theReal-Time Statecharts of the ports directly. Additionally, the Real-Time Statechart of thecomponent may specify a set of operations that implement the actions of the states and theside effects of the transitions (cf. Section 3.4.6). The synchronization statechart may not calloperations defined in the Real-Time Statecharts of the ports.


3.6.2. Structured Component TypeThis section describes the specification of structured components that introduce the modelingof hierarchical components into MECHATRONICUML.

3.6.2.1. Structured Component

A structured component is assembled by embedding other components by means of so-called component parts. A component part is either typed over an atomic componentor an other structured component. The behavior of the structured component is thendefined by the component behavior specifications of the component parts. Therefore, thestructured component does not contain a component behavior specification itself. If thecomponent is reconfigurable, it additionally defines a reconfiguration controller that containsits reconfiguration behavior (cf. Section 4.2).

For a structured component, the MECHATRONICUML component model only supportstwo kinds. These are discrete structured components and hybrid structured components.Structured continuous components are not supported. Whether a structured component isdiscrete or hybrid depends on the types of the embedded component parts (cf. Section 3.6.2.3).A structured component is a discrete structured component if all of its component partsare typed over discrete atomic components or discrete structured components. A structuredcomponent is a hybrid structured component if at least one of its component parts is typedover a continuous atomic component or a hybrid structured component. Moreover, a discretestructured component may only define discrete ports, while a hybrid structured componentmay define discrete and continuous ports.

Concrete Syntax of a Structured ComponentThe structured component is visualized as a rectangle with two horizontal compartments. Theupper compartment contains the left-aligned name of the component and the right-alignedcomponent icon. The lower compartment contains the embedded component parts.

Figure 3.44 shows an example for the concrete syntax of a structured component withname BeBot embedding three component parts which are typed over the atomic componentsEngineCtrl and PosData and a structured component BeBot_SW. Thus, BeBot is a hybridstructured component.

3.6.2.2. Port

A structured component specifies a set of ports as well, but in contrast to the ports of an atomiccomponent, the port of the structured component do not contain a behavior specification.Instead, the ports of the structured component delegate to ports of embedded component partsvia delegation connectors (cf. Section 3.6.2.4).

A structured component may define discrete and continuous ports but no hybrid ports. Incase of a discrete port, the port must have an assigned role of a Real-Time CoordinationProtocol in order to connect it to another component by using a Real-Time Coordination


BeBot

mc : MotionCtrl [1]

pos: PosData [1]

angle_in

pos_out

speed_in

bsw : Bebot_SW [1]

speed_target

turnAngle_target

position

server

client

Distribution.client

Distribution.distributor

Figure 3.44.: Concrete Syntax Example of a Hybrid Structured Component

Protocol. The rules for assigning a role of a Real-Time Coordination Protocol to a discreteport of a structured component are the same as the rules for atomic components which areintroduced in Section 3.6.1.2. Reconfigurable components may define additional port typesfor handling reconfigurations [HB13].

Hybrid ports are not allowed for structured components because a hybrid port defines thata signal provided by a continuous port is discretized at a fixed rate (cf. Section 3.6.1.3). Forthe interface of the structured component, however, it is only necessary to specify that a signalvalue is expected or provided. Whether this value is discretized or processed by a continuousatomic component is part of the inner behavior of the component and does not need to bespecified in it’s interface.

Concrete Syntax of a Port of a Structured ComponentThe ports of structured component use the same concrete syntax that is used for ports of anatomic component (cf. Section 3.40).

3.6.2.3. Component Part

A component part is a representation of a component that is embedded into a structuredcomponent. It describes the potentially multiple occurrences of a component in a structuredcomponent type. Thus, component parts are defined on the type level as well and mustbe typed over a component (either atomic or structured). The definition of structuredcomponents by using component parts corresponds to the definition of structured classifiersin the UML [Gro10b]. Accordingly, component parts define a type system for the contents ofthe structured component.

In analogy to the UML, a component part specifies a cardinality with a lower bound and anupper bound. This is also similar to the concept of replicated actors in ROOM [SGW94]. Thelower bound specifies the minimum number of instances of this part that must be present in

any instance of the structured component. Accordingly, the upper bound specifies a maximumnumber that may be instantiated. For an upper bound equal to 1, we call it a single part. For anupper bound greater than 1, we call it a multi part. Thus, the cardinality restricts the numberof instances of a component part that may occur in a structured component during run-time.

In a structured component, multiple component parts may be typed over the samecomponent. They are distinguished by the name of the component part. The names of allcomponent parts must be unique within a structured component. In any case, an embeddedcomponent part must not introduce a cycle in the component hierarchy. That means, astructured component A may not embed a component part that is directly or indirectly (bymeans of recursively embedded component parts) over A.

Concrete Syntax of a Component PartAn embedded component part is visualized similar to an atomic component. The componentpart is labeled with the name of the component part and the name of the component it is typedover. Additionally, the label contains the cardinality of the component part. The label of acomponent part is defined by the following EBNF grammar:

: : = # componen tPa r t . name ’ : ’ <componentName > < c a r d i n a l i t y ><componentName > : : = # componen tPa r t . componentType . name< c a r d i n a l i t y > : : = ’ [ ’ # componen tPa r t . lowerBound ’ . . ’

# componen tPa r t . upperBound ’ ] ’

If the lower bound equals the upper bound, we allow for an abbreviation that only indicatesthe upper bound as shown in Figure 3.44 where for all three component parts the lower boundand the upper bound are equal to 1. If the upper bound is not specified, it is indicated by anasterisk as shown in Figure 3.45.

Analogously to multi ports, a multi part is visualized by a cascaded double border line asshown in Figure 3.45.

StructuredComponent1

mult : Component2 [0..*]

Figure 3.45.: Concrete Syntax of a Multi-Part

The ports of component parts use the same concrete syntax that is used for ports of anatomic component (cf. Section 3.40).


3.6.2.4. Delegation Connector

A delegation connector connects a port of a structured component with a port of a componentpart. As a port of a structured component does not have a behavior specification (cf.Section 3.6.2.2), it delegates to a port of a component part. Then, the component partimplements the respective behavior of the port of the structured component.

Whether a delegation connector is valid depends on two conditions. First, the connectedports have to be structurally compatible according to Figure 3.46. Second, they must havecompatible interfaces. The two conditions will be explained in the following.

The structurally compatible combinations of single ports of a structured component andsingle ports of a component part are summarized in Figure 3.46. If a combination is markedwith a checkmark, it is possible, otherwise it is not possible.

in outin/

out

discrete continuous

in out

in

out

in/outdis

cre

te

in

out

in

out

co

ntin

uou

sh

yb

rid

Port of Structered

Component

Po

rt o

f C

om

po

ne

nt

Pa

rt

Figure 3.46.: Structurally Possible Delegation Connectors

For discrete ports, a structurally compatible combination also has to consider thecardinalities. A single port of a structured component may only be delegated to a singleport of a single part. Discrete multi ports of a structured component may be delegated tothree constructs. First, a discrete multi port may be delegated to a single part’s discretemulti port. Second, it may be delegated to a multi part’s discrete single port. Third, amulti port may be delegated to a multi part’s discrete multi port. Figure 3.47 summarizesthe possible combinations. The semantics of these combinations will be defined along withthe reconfiguration operations in Chapter 4 in a future version of this document.

As stated before, the second condition for creating a delegation connector is interfacecompatibility. If the delegation connector connects two discrete ports, then the interfaces arecompatible if both ports refer to the same role of the same Real-Time Coordination Protocol.


Single

Port

Multi

Port

Single

Port

Multi

Port

Single

Port

Multi

Port

Sin

gle

Part

Mu

lti P

art

Structered

Component

Com

po

ne

nt

Pa

rt

Figure 3.47.: Structurally Possible Delegation Connectors for Multi-Parts

If the delegation connector connects (i) two continuous ports or (ii) a continuous and a hybridport, the interface compatibility is fulfilled if both ports specify the same data type for thevalues the ports may send and receive.

Since the component parts of the structured component define a type system for the innerstructure of the component, a port of a structured component may be delegated to ports ofseveral component parts. Then, the delegation connectors define all embedded componentparts which may implement the port at some point in time during run-time. The concretecomponent part implementing the port of the structured component may be changed bya reconfiguration operation during run-time. However, each port instance of a structuredcomponent needs to be delegated to an instance of a component part at run-time

As a similar case, a port of a structured component may be delegated to more than one portof the same component part. However, at instance level, discrete ports may only be delegatedto one discrete port of a component part. Using reconfiguration, we can change the delegationat runtime.

Concrete Syntax of a Delegation Connector

A delegation connector is visualized via a solid black edge that connects two ports.Figure 3.48 shows the structured component BeBot_SW that has five ports that are delegated

to two embedded component parts nav and bbo of types Navigation and BeBot_Observer,respectively. The delegation link is represented by a solid line between the port of thestructured component and the port of the part. If a port of a component part is connectedto a port of the structured component by a delegation, then it does no longer visualize the roleit implements. Instead, the implemented role is only visualized by the port of the structuredcomponent using the same concrete syntax.


Bebot_SW

speed_target

nav : Navigation [1] turnAngle_target

position

bbo : BeBot_Observer [0..1]sender

server

client

server

client

sender

receiver

provider

speed_target

turnAngle_target

positionNavigation.provider


Distribution.client


AllPositionsTransmission.sender

PositionTransmission.receiver

Figure 3.48.: Concrete Syntax of a Delegation

3.6.2.5. Assembly Connector

In many cases, the component parts embedded in a structured component have to interact toimplement the functionality of the structured component. They interact by communicatingover their ports. The connections between the ports are specified by assembly connectors.

If the assembly connector connects two discrete ports, then they must have a role of a Real-Time Coordination Protocol assigned to it and the communication behavior is defined by thecorresponding Real-Time Coordination Protocol.

Whether an assembly connector is valid between two ports of embedded component partsdepends on two conditions. First, the refered ports have to be structurally compatible, i.e., theymust be of the same kind and have inverse directions as defined in Figure 3.49. Second, theymust have compatible message interfaces, i.e., the message types that a port can send, must bereceivable by the other port and vice versa. If both conditions are fulfilled, the assembly linkmay be created. The two conditions will be explained in the following.

The structurally possible combinations of ports of component parts are summarized inFigure 3.49. If a combination is marked with a checkmark, it is allowed, otherwise it is notallowed. In general, an in-port may only be connected to an out-port and vice versa such thatinformation may flow at run-time. In/out-ports may only be connected to other in/out-ports.

As stated before, the second condition for creating an assembly connector is interfacecompatibility. For discrete ports, the interface compatibility is fulfilled if both ports areassigned different roles of the same Real-Time Coordination Protocol. If the Real-TimeCoordination Protocol has only one role, both ports need to be assigned the same role. If


in outin/

out

discrete continuous hybrid

in out in out

in

out

in/outdis

cre

te

in

out

in

out

co

ntin

uou

sh

yb

rid

Port of Component Part

Po

rt o

f C

om

po

ne

nt

Pa

rt

Figure 3.49.: Structurally Possible Assembly Connectors

an assembly is created according to a Real-Time Coordination Protocol, we call it a Real-Time Coordination Protocol Part. For continuous ports, the interface compatibility is fulfilledif both ports have the same data type.

Since the component parts of the structured component define a type system for the innerstructure of the component, several assembly connectors may be specified for a port of acomponent part. Then, the assemblies define all possible assembly instances that may becreated inside a structured component instance. Intuitively, assembly instances may only becreated between component parts that are instantiated, i.e., if no instance for Collision_Controlof Figure 3.50 exists, no assembly instance may be created for an assembly ending at a portof Collision_Control (cf. Section 6.4.1). The concrete assembly instances are created byreconfiguration operations during run-time. Such reconfiguration operations will be definedin future versions of this document.

If one role of a Real-Time Coordination Protocol is a multi role, a Real-Time CoordinationProtocol part may involve several assembly connectors. In our example, the role sender of theReal-Time Coordination Protocol PositionTransmission is a multi role. The role receiver isassigned to the ports receiver of BeBot_Observer and Exploration, respectively. As visualizedin Figure 3.50, a Real-Time Coordination Protocol part of PositionTransmission involves twoassembly connectors.

Concrete Syntax of an Assembly ConnectorAn assembly connector is visualized via a solid black edge that connects two ports.

Figure 3.50 shows the complete definition of the structured component BeBot_SW. Theassembly connectors are visualized as solid lines between the ports of the component parts.In case of an assembly between discrete ports, the Real-Time Coordination Protocol defining


the communication behavior is visualized for the assembly. In the example, the multi port ofthe component part nav : Navigation is connected to the component parts exp : Explorationand bbo : BeBot Observer which means that the component part nav : Navigation maycommunicate with the component part exp : Exploration or the component part bbo : BeBotObserver or both.

speed_target

BeBot_SW

exp : Exploration [1]

cc : Collision_Control [0..1]


position

bbo : BeBot_Observer [0..1]

AllPositionsTransmission

PositionTransmission

Delegation

Navigation

master

slave

receiver

receiver

receiver

sender

sender

navigator provider

Distribution.client


receiver sender

slave

master

receiver

distributor

client

distributor

client

sender

receiver

providernavigator

speed_target

turnAngle_target

position

Figure 3.50.: Complete Example of a Discrete Structured Component including severalAssemblies connecting the Component Parts

In the example, an assembly from port navigator of the component part Exploration tothe port provider of the component part Navigation is possible. This is because both portsare discrete in/out-ports and they are assigned different roles of the Real-Time CoordinationProtocol Navigation. Then, we have a Real-Time Coordination Protocol Part Navigation whichis visualized by connecting the protocol ellipse to the corresponding ports by dashed lines. Thedashed lines are labeled with the name of the role. The assembly from port speed_left of thecomponent part BeBot_SW to the port speed_in of the component part EngineCtrl is possiblebecause both have the data type Integer.

Figure 3.51 shows the complete definition of the structured component BeBot. It embeds thediscrete structured component BeBot_SW of Figure 3.50 as a component part. Additionally, itembeds two component parts typed over the continuous components EngineCtrl and PosData.


Inside the component BeBot, the continuous ports of BeBot_SW are connected by assembliesto the continuous component parts.

bsw : BeBot_SW [1]

Distribution.

client

Distribution.

distributor

distributor client

position

turnAngle_target

speed_target

BeBot

Distribution.

distributor

Distribution.

client

distributor client

mo : MotionCtrl [2]speed_in

speed_out

pos : PositionSensor [1]pos_in

pos_out

turnAngle_in turnAngle_out

Figure 3.51.: Example of a Hybrid Structured Component

In our example, the components of type BeBot represent the top-most level of the modeledcomponent architecture. As shown in Figure 3.51, the BeBot offers the ports distributor andclient which are used in our example to connect to other BeBots. On this system level, we donot specify assembly connectors because the usage of the modeled BeBot in a larger systemis not part of the modeling in this case. Instead, components on the system level may beconnected with respect to the Real-Time Coordination Protocol that they offer on their portsand the respective cardinalities of the ports. In our example, a BeBot may be connected to anycomponent that also implements the Distribution protocol.

3.7. COMPONENT INSTANCE CONFIGURATION 93

3.7. Component Instance Configuration

A component instance configuration is a design-time specification of a concrete instantiated(sub-) system under construction. It is often the case that a (sub-) system under constructionhas more than one possible component instance configuration because it defines variable partswithin its structure, e.g., optional ports.

A component instance configuration (cf. Section 3.7.4) contains a set of componentinstances (cf. Section 3.7.1) that are typed over the components specified in theMECHATRONICUML component model (cf. Section 3.6). For assembling and structuring,component instances contain port instances (cf. Section 3.7.2) that are connected via connectorinstances (cf. Section 3.7.3).

3.7.1. Component Instance

A component instance is derived from a component type. It is is contained within a parentcomponent instance configuration and has a name.

During instantiation, the variable parts of the component type are determined. The variableparts include the set of port instances derived from port types (cf. Section 3.6.1.2) andembedded component instances derived from component parts (cf. Section 3.6.2.3) of astructured component type.

For each component part of a structured component, several instances of one componentpart may be created. The allowed number of component instances depends on the componentpart’s cardinality. The type of each embedded component instance is defined by both, thecomponent part as well as the component type referenced by the component part. That allowsto distinguish embedded component instances based on the component parts. We will exploitthat information for reconfiguration of structured component instances in future versions ofthis document (see also Section 4.3). A component instance which is not embedded in astructured component instance is only typed by a component type and does not refer to acomponent part.

Like on type level, we distinguish between atomic component instances and structuredcomponent instances that we introduce in the following.

3.7.1.1. Atomic Component Instance

An atomic component instance is a component instance that is typed over an atomiccomponent (cf. Section 3.6.1). Additionally, it references its component part if it is embeddedin a structured component instance.

An atomic component instance may not embed a component instance configuration.Instead, it executes the behavior specification, e.g. the Real-Time Statechart, which has beendefined by its component type.

3.7.1.2. Structured Component Instance

A structured component instance is a component instance that is typed over a structuredcomponent (cf. Section 3.6.1). Additionally, it may have an association to a component part.

A structured component instance embeds a component instance configuration that defines itsinner structure. Thus, a structured component instance embeds indirectly component instancesand connector instances.

Within a structured component instance, several instances of one component part may exist(within the embedded component instance configuration). The allowed number of componentinstances depends on the component part’s cardinality.

A structured component may define one or more constructors in terms of component storydiagrams [Tic09, THHO08] (cf. Section 4.3). The constructor defines which port instancesand which embedded component instances need to be instantiated for an instance of thecomponent. This is primarily important for reconfigurable components discussed in Section 4.If no constructor has been specified, initial instances of multi parts and multi ports are createdwith lowest cardinality.

In case of a structured component instance, assembly connector instances and delegationconnector instances may only be created between port instances if the corresponding port typesare connected by an assembly connector or delegation connector in the structured componenttype.

Concrete Syntax of a Component InstanceThe concrete syntax of a component instance is derived from the concrete syntax ofcomponents. In contrast to a component, the label of a component instance is underlinedand defined by the following EBNF grammar.

 : : = # c o m p o n e n t I n s t a n c e . name [ ’ / ’ <partName >] ’ : ’<componentName >

<partName > : : = # c o m p o n e n t I n s t a n c e . componen tPa r t . name<componentName > : : = # componen tPa r t . componentType . name

The label displays the name of the component instance first. If the component instance isembedded in a structured component instance, the name is succeeded by a slash and the nameof the corresponding component part. The last part of the label always displays a colon andthe name of the component type.

Figure 3.52 shows the concrete syntax of the structured component instance b1 that is typedby the component part bsw that is typed by the structured component type BeBot_SW (cf.Figure 3.44).

3.7.2. Port Instance

During instantiation, port instances are derived from the set of port types of the componenttype. Moreover, a port instance has a name. Like on type level, we distinguish betweendiscrete port instances, continuous port instances, and hybrid port instances.


b1 / bsw : BeBot_SWdist:Distribution.

distributor

d1:distributor

d2:distributor

:position

:speed_right

:speed_left

Figure 3.52.: Concrete Syntax Example of a Component Instance of the Component TypeBeBot_SW

3.7.2.1. Discrete Port Instance

A discrete port instance is an instance of a discrete port (cf. Section 3.6.1.2). It is containedeither (i) in an atomic component instance or (ii) in a structured component instance. Likeon type level, we distinguish between discrete single port instances and discrete multi portinstances.

Discrete Single Port InstanceA discrete single port instance is either (i) an instance of a discrete single port or (ii) a subportinstance that belongs to a multi port instance. In case (i), the discrete single port instanceexecutes the behavior that is defined within the port; in case (ii), it executes executes thesubport behavior that is defined within the multi port.

If a discrete single port instance belongs to an atomic component instance, it has exactlyone connector instance (assembly or delegation).

If a discrete single port instance belongs to a structured component instance, it hasexactly one delegation connector instance that leads to the inner structure of the component.Additionally, it may have either (i) one assembly connector instance that leads to anothercomponent instance of the same hierarchy level or (ii) one delegation connector instance thatleads to the embedding component instance.

Discrete Multi Port InstanceA discrete multi port instance is an instance of a discrete multi port. Figure 3.53 showsthe structure of a multi port instance. At runtime, there exists exactly one instance perdiscrete multi port which executes the adaptation behavior. The multi port instance has avarying number of subport instances, each subport instance has one connector instance andis responsible for communication over this connector instance. The actual number of subportinstances of a discrete multi port instance must comply with the cardinality of the respectivediscrete multi port type.


Noteworthy, a discrete multi port instance may have no subport instances at runtime. Then,only the adaptation behavior that is defined within the multi port is executed.

adaptation behavior

subpor tinstance1

subpor t instancek

discrete single port instance

discrete single port instance

subpor tinstancen

discrete singleport instance

discrete multi port instance

......

Figure 3.53.: Structural Schema of a Multi Port Instance being Connected via its SubportInstances to Several Single Port Instances

Since we only support one-to-one and one-to-many communication in the current version ofMECHATRONICUML, the following statement holds: If the subport instance is connected viaan assembly connector instance, then the other endpoint of the connector is a discrete singleport instance.

3.7.2.2. Continuous And Hybrid Port Instance

The port type of a continuous port instance must be a continuous port while the port type of ahybrid port instance must be a hybrid port.

For continuous instances, we allow multiple delegation connector instances that lead to theinner structure of the structured component instance. That enables to send the same signalvalues to several components at once thereby performing a fork of the signal.

For continuous and hybrid out-port instances, we allow multiple assembly connectorinstances. That enables to send the same signal values to several components at once therebyperforming a fork of the signal.

We forbid multiple assembly connector instances for continuous and hybrid in-portsbecause in that case the port instance receives several, potentially different values wherethe join condition is not defined. In such cases, the join condition needs to be defined byan additional continuous component. Moreover, we forbid multiple delegation connectorinstances for continuous and hybrid out-ports.

Concrete Syntax of a Discrete Port InstanceThe concrete syntax of discrete single port instances, continuous port instances, and hybridport instances are the same as for their corresponding port types.


Figure 3.52 on page 95 shows an example for the concrete syntax of port instances of astructured component instance. Instance b1 has the three continuous port instances speed_left,speed_right, and position.

The discrete multi port instance visualizes all its subport instances in their concrete syntaxand draws a dashed frame around them. For example, in Figure 3.52, the multi port instancedist of the component type BeBot_SW (cf. Figure 3.50) has two subport instances d1 and d2.

3.7.3. Connector Instance

A connector instance connects two ports instances with each other. Like on type level, wedistinguish two kinds: assembly connector instances and delegation connector instances.

3.7.3.1. Assembly Connector Instance

An assembly connector instance connects two port instances of the same hierarchy level. Atthe top hierarchy level, an assembly connector instance is not an instantiation of an assemblyconnector. However, on all other hierarchy levels, an assembly connector instance is aninstantiation of an assembly connector.

If an assembly connector instance is created between two discrete port instances, thecorresponding Real-Time Coordination Protocol is instantiated as well which results in a Real-Time Coordination Protocol instance (cf. Section 3.3.5).

3.7.3.2. Delegation Connector Instance

A delegation connector instance connects two port instances of adjacent hierarchy levels.Moreover, a delegation connector instance is always an instantiation of a delegation connector.

3.7.4. Component Instance Configuration

A component instance configuration contains component instances and connector instances.It has a name. Moreover, the names of the component instances within a component instanceconfiguration must be unique.

A component instance configuration may be embedded into a parent structured componentinstance. Then, we call it an embedded component instance configuration. Otherwise, if itis not embedded into a structured component instance, we call it a root component instanceconfiguration.

An embedded component instance configuration may only contain port instances andcomponent instances that are refer to the port types and component parts of the componenttype of the embedding structured component instance. In addition, connector instancesmust comply to the connectors specified by the component type of the embedding structuredcomponent instance.


Concrete Syntax of a Component Instance ConfigurationIn a component instance configuration, only the current level of structured componentinstances may be shown, i.e., all embedded component instances are hidden.

Figure 3.54 shows the concrete syntax for an exemplary root component instanceconfiguration. It shows the highest hierarchy level of the system, which consists of thecomponent instances bebot1:Bebot, bebot2:Bebot, and bebot3:Bebot. All three componentinstances are typed over the component type BeBot of Figure 3.44. Since the componentinstances of type BeBot are not embedded in a structured component instance, their label onlyindicates the instance name and the name of the component type. bebot2 and bebot3 areconnected to bebot1 by an assembly connector instance. They are connected by the instancedist of the Real-Time Coordination Protocol Distribution (cf. Section 3.3 and Figure 6.1) wherethe discrete port instances distributor1 and distributor2 of bebot1 implement the multi-roledistributor and the two ports named client of bebot2 and bebot3 implement the role client.

bebot2 : BeBot

bebot3 : BeBot

:client

:clientbebot1 : BeBot

:distributor

distributor1

distributor2

client

client

:position

:speed_right

:speed_left

:position

:speed_right

:speed_left

:position

:speed_right

:speed_left

dist:Distribution

Figure 3.54.: Concrete Syntax Example of a Root Component Instance Configuration

Figure 3.55 shows the embedded component instance configuration that specifies theinherent part structure of the BeBot_SW component instance of bebot1. The componentinstances nav:Navigation, pos:Position, and bbo:Bebot_Observer are connected to the portinstances of the next higher level component instance b1:Bebot_SW by delegation connectorinstances.


b1 / bsw : BeBot_SW

exp1 / exp

:Exploration

cc1 / cc

:Collision_Control

nav1 / nav

:Navigation

bbo1 / bbo

:BeBot_Observer

dist:Distribution.

distributor:receiver :sender

:slave

d1:distributord1:distributor

d2:distributor d2:distributor

:slave

:receiver

:sender

:master

:master

:receiver

s2:senders1:sender:receiver

:receiver

:sender:receiver

:provider

:provider:navigator

:navigator

:speed_left

:speed_right

:position :position

:speed_right

:speed_left

na1:Navigation

trans1:Position

Transmission

trans2:Distance

Transmission

del1:Delegation

Figure 3.55.: Concrete Syntax Example of an Embedded Component Instance Configuration

Chapter 4.

Modeling Extensions forReconfigurable Systems

Software is increasingly used in frequently changing environments. In many cases, thebehavior that the software needs to execute depends on the particular environmental situation.In the BeBot example presented in Section 1.1, a BeBot needs to operate as a distributoror a client if there are other BeBots in its environment. If there are no other BeBots in itsenvironment, the BeBot does not need to execute behavior for one of the roles as shown inSection 3.7. As a solution, the BeBot may perform a so-called reconfiguration at run-time andadapt its software architecture given by a component instance configuration (cf. Section 3.7)to the new environment conditions. We will refer to such systems as reconfigurable systemsthroughout this section. The BeBot, e.g., may instantiate the necessary component instancesfor operating as a client or distributor if it meets other BeBots. As a result, the BeBot can adaptits component instance configuration to the best one for operating in the current environmentwithout human interaction.

In general, a software system changes its software architecture as a response to changingsystem goals, changing system requirements, or a changing operation environment. To beable to detect such changes and to perform a run-time reconfiguration, the system first needsto monitor itself and its environment. Then, it needs to analyze the current situation andcompare it to the requirements and goals. If there is a deviation between the current situationand the intended goals and requirements, the system needs to plan how and when to adapt todissolve the deviation. Finally, the system needs to execute the change and monitor, again, theeffects of the applied change. This sequence of monitoring, analyzing, planning, and executinghas been introduced by the MAPE architecture [IBM06] in course of IBM’s autonomouscomputing initiative. If the system also gathers knowledge about its environment and theeffects of previous reconfigurations, the approach is called MAPE-K. It is also referred to asthe control loop of autonomous computing.

For executing a run-time reconfiguration, the system needs to be able to reason aboutitself and to reason about its architecture. In literature, this is sometimes referred as self-awareness [DDL+10]. The general way to achieve that a software system may reason aboutitself is maintaining a so-called model@run-time of a software [BBF09]. The model@run-

101

102 CHAPTER 4. MODELING EXTENSIONS FOR RECONFIGURABLE SYSTEMS

time, in case of MECHATRONICUML, contains the current component instance configurationof the whole system.

In our BeBot example, a BeBot needs to reconfigure its internal structure depending onthe other BeBots in its environment. If there is no BeBot in the environment, the BeBotdrives alone and does not perform a collision detection and position data exchange. If thereare other BeBots in the environment, a BeBot may interact as a position distributor or as aclient to a position distributor. In both cases, the BeBot needs to instantiate an embeddedcomponent instance of type CollisionControl and an embedded component instance of typeBeBot_Observer. Depending on whether the BeBot is distributor or client, it needs to create aport instance of type distributor or client, respectively, to fulfill its role.

In literature, there exist several more terms referring to reconfigurable systems that evolvedhistorically and distinguish the intent of the reconfiguration. Historically, the area ofreconfigurable systems rose from the research area of architecture description languages(ADLs), where Darwin [MK96] was the first approach supporting run-time reconfiguration.In the following, systems performing run-time reconfiguration were also known as self-adaptive [OGT+99, CdLG+09] or self-managing systems [BCDW04]. The ability of a systemto reason about itself is also referred as self-awareness. If a system tries to optimize itsbehavior in a given environment using optimization techniques, it is called a self-optimizingsystem [ADG+09]. If a system reacts to hardware failures and tries to recover from suchfailures, it is called a self-healing system [Sha02, CGP08]. Common to all these terms is that,at the end, the system performs a reconfiguration to adapt its behavior.

In this section, we explain how systems that may perform a run-time reconfigurationcan be modeled with MECHATRONICUML. Before describing how reconfigurable systemscan be modeled using MECHATRONICUML, we first discuss the requirements that weimpose on the modeling in Section 4.1. Thereafter, Section 4.2 introduces the extensionsof the MECHATRONICUML component model (cf. Section 3.6) that enable run-timereconfiguration. In Section 4.3, we introduce component story diagrams that enable to modelreconfiguration operations using the concrete syntax of MECHATRONICUML componentinstance configurations.

4.1. Requirements

We impose two kinds of requirements on our reconfiguration extensions: functional and non-functional requirements. The functional requirements specify the operations that we want toexecute on component instances at run-time while the non-functional requirements imposeconditions how we may specify and execute these operations.

We have the following functional requirements:FR1 Create and destroy port instances including sub-port instances of a multi-port instance

for atomic component instances and structured component instances.FR2 Create and destroy embedded component instances for a structured component instance.

4.2. COMPONENT MODEL EXTENSIONS 103

FR3 Create and destroy assembly instances between embedded component instances of astructured component instance.

FR4 Create and destroy delegation instances within a structured component instance.FR5 Invoke reconfigurations on embedded component instances if those reconfigurations are

required for the reconfiguration of a structured component instance.FR6 A component instance may trigger a reconfiguration on the parent component if it

detects a need for change.We can express a reconnection of assembly instances and delegation instances by one create

and one destroy operation. Therefore, we do not explicitly list this requirement.The extensions have been developed with the following non-functional requirements in

mind:NR1 Provide a separation of concerns between reconfiguration behavior and functional

behavior [MSKC04].NR2 Preserve the encapsulation property of components [Szy98], i.e., a component instance

may only reconfigure its internals, but never the system lying outside the component’sboundaries or, in case of a structured component, the internals of an embeddedcomponent instance.

NR3 Reconfiguration across several levels of hierarchy needs to respect Requirement NR2.NR4 Triggering a reconfiguration on the parent (FR6) needs to respect Requirement NR2,

i.e., the embedded component instance only informs a surrounding component aboutthe occurred situation.

NR5 Reconfigurations according to NR3 need to fulfill ACI-T properties [HB13], i.e.,Atomicity, Consistency, and Isolation as defined for database systems [BHG87] as wellas a correct Timing.

In the following subsections, we show how we treated these requirements inMECHATRONICUML.

4.2. Component Model Extensions

In this section, we introduce our extensions to the MECHATRONICUML componentmodel [EHH+13, HPB12, HB13]. These extension enable to perform a run-timereconfiguration of a system that has been developed with MECHATRONICUML.

It follows from the requirements in Section 4.1 that an atomic component instance may onlyreconfigure its own port instances, i.e., it may create and destroy port instances [EHH+13]. Astructured component instance may reconfigure its own port instances as well. In addition, astructured component instance may create and destroy embedded component instances andit may change the connector instances connecting its embedded component instances. Inparticular, a structured component may create and destroy delegation connector instancesfrom its own ports to ports of embedded component instances and it may create and destroyassembly connector instances between its embedded component instances [THHO08, HPB12,


HB13]. Due to Requirement NR2, however, a structured component instance may not createor destroy ports of its embedded component instances. At this point, we deviate from theproposal by Tichy [Tic09] in favor of a full component encapsulation.

In Section 4.2.1, we introduce the specification of reconfiguration in atomic componentsin more detail before defining the reconfiguration behavior of structured component inSection 4.2.2.

4.2.1. Reconfigurable Atomic Component

The reconfiguration of an atomic component instance involves the creation and destruction ofport instances during run-time. In the following, we describe how discrete single port instances(Section 4.2.1.1) and subport instances of a discrete multi port instance (Section 4.2.1.2)can be created and destroyed. We treat both cases differently, because in case of a multi-port, the reconfiguration behavior needs to be contained in the corresponding Real-TimeCoordination Protocol. The reconfiguration behavior needs to be contained in the Real-TimeCoordination Protocol for being able to verify the Real-Time Coordination Protocol becausethe reconfiguration behavior of the multi role is an essential part of the multi role’s behavior.

4.2.1.1. Reconfiguration of Single Port Instances

For reconfiguring the single-port instances of an atomic component instance, we may addcalls to component story diagrams to one of the component’s synchronization Real-TimeStatecharts. The reconfiguration operations then specify which port is created or destroyed. Aport instance can only be created or destroyed if it has cardinality 0..1. If is already exists, itcannot be created a second time.

In our BeBot example, the component instance Exploration needs to instantiate the portmaster if the BeBot becomes a distributor or a client (cf. Figure 3.55). Intuitively, we annotatethe modification of the port instances in the component instance as shown in Figure 4.1.

exp1 / exp

:Exploration

:master

:master

«create»

Figure 4.1.: Reconfiguration Creating a new Port Instance at an Atomic Component Instance.

4.2. COMPONENT MODEL EXTENSIONS 105

We formalize the specification of such reconfiguration operations by component storydiagrams in Section 4.3.

4.2.1.2. Reconfiguration of Multi Port Instances

Multi ports of a component and multi roles of a Real-Time Coordination Protocol share thesame kind of behavior specification consisting of an adaptation behavior and a subport (orsubrole, respectively) behavior (cf. Section 3.4.11). A multi port (or multi role) defines a one-to-many communication, i.e., the communication of one port instance (or role instance) withn instances of another port (or role). If the number n may vary during runtime, the multi port(or multi role) needs to perform a reconfiguration [EHH+13]. In particular, it may create anddestroy subport (or subrole) instances. In the following, we describe reconfiguration based onReal-Time Coordination Protocols which applies in the same way to multi ports of an atomiccomponent.

In our example in Section 3.4.11, the Distribution protocol describes the communication ofa distributor with several clients. Since the number of clients may vary during runtime, thenumber of subport instances of the distributor needs to be adapted to the current number ofclients by performing a reconfiguration.

The reconfiguration of the subrole instances of a multi role is triggered by the multi role’sadaptation Real-Time Statechart (cf. Section 3.4.11). In particular, the adaptation Real-Time Statechart contains calls to reconfiguration operations in its state or transition actionsfor modifying the subrole instances. Subrole instances itself may not call a reconfigurationoperation.

Distribution_distributor var: int[2] myPos, int[9][2] posArray, bool error := false;


adaptation

sub-role-template

2

1

ch: receive[Role], send[Role], rcv_done, send_done;

clock: c_period, c;

Waiting

c_period ≤ 50



{reset: c_period}

Sending

c ≤ 15

entry / {reset: c}

send[first]!

send_done?

[c_period ≥ 50] receive[first]!

Receiving

c ≤ 15

entry / {reset: c}

All_Received

c ≤ 0

entry / {reset: c}


2

1


[c_period ≤ 25]

{createSubRoleInstance(self)}

...

[25;25]

Figure 4.2.: An adaptation Real-Time Statechart of a Multi-Role including a ReconfigurationOperation Call


Figure 4.2 shows the adaptation Real-Time Statechart of the multi role distributor ofthe Real-Time Coordination Protocol Distribution. In contrast to Figure 3.36, we added aself-transition to the state Waiting. The self-transition calls the reconfiguration operationcreateSubRoleInstance. The parameter self refers to the multi role instance that thisadaptation Real-Time Statechart belongs to (cf. Section 3.4.11). The reconfigurationadds a new subrole instance which will be the last one in the order of the multi-role (cf.Section 3.4.11).

We formally specify reconfiguration operations in Real-Time Coordination Protocolsby story diagrams [FNTZ00b, Zü01, vDHP+12]. Story diagrams are UML 1.5 ActivityDiagrams [Gro03] whose activities are formally defined by graph transformations [Roz97].We refer to [vDHP+12] for a recent introduction to story diagrams.

last : SingleRoleInstance

inst

Create sub role instance at the end

createSubRoleInstance(MultiRoleInstance inst) : void

created : SingleRoleInstance

▼ last

next

►

last

►

subroles

►

«destroy»

«create»

«create»

«create»

«create»

Figure 4.3.: Reconfiguration Creating a new Subrole Instance.

Figure 4.3 shows a story diagram that formalizes the reconfiguration operationcreateSubRoleInstance used by the adaptation Real-Time Statechart in Figure 4.2. Based onthe MultiRoleInstance given as a parameter, it searches for the last subrole. Then, it destroysthe reference last to this subrole and creates a new one (created). The new subrole will isadded to the subroles of the multi role and it is the last one. In addition, it is connected bynext to the previously last subrole.

4.2.2. Reconfigurable Structured Component

A reconfigurable structured component specifies a set of reconfiguration rules that arespecified by component story diagrams (cf. Section 4.3). A detailed specification of thereconfiguration of structured components and especially the execution of reconfiguration canbe found in [HPB12, HB13] and will be integrated in future versions of this document.The peculiarities of reconfiguring continuous component instances, which are embedded ina structured component instance, are described in [BGO06, OMT+08] and [Bur06, Hir08]and will also be added to future version of this document.

4.3. COMPONENT STORY DIAGRAMS 107

4.3. Component Story Diagrams

Component Story Diagrams [THHO08],[Tic09] enable modeling reconfiguration operationsusing the concrete syntax of MECHATRONICUML component instance configurations.

The original Story Diagrams and Story Patterns [Zü01] allow defining transformationson object structures within a control flow. Using them would already allow to specify thetransformation of component instance structures on meta-modeling level. But this wouldmean that the developer of reconfiguration operations has to know the abstract syntax of thecomponent instance configurations as well. Thus, Component Story Diagrams are introducedwhich use the syntax elements of Story Diagrams and specify within the activities thetransformation of component instance configurations, called Component Story Patterns.

4.3.1. Component Story Pattern

A Component Story Pattern describes a single structural change of a MECHATRONICUMLcomponent instance configuration, i.e. the adding or removing of a component instance, portinstance or connector instance.

During the execution of a Component Story Diagram, variables are matched to elements ofthe component instance configuration. Elements are component instances, port instances, andconnections between the ports. Consequently, the same types of variables exist. Variables canbelong to the left-hand side, to the right-hand side or to both sides.• Variables that belong to the left-hand side, but not to the right-hand side, are red and

marked with the stereotype «destroy». This means that the elements matched by thesevariables are removed by the execution of the Component Story Pattern.• Variables that did not exist in the left-hand side, but in the right-hand side, are green

and marked with the stereotype «create». This means that the elements these variablesrepresent are created by the execution of the Component Story Pattern.• Variables that belong to both sides of the rule have no stereotype. Their matched

elements are not changed by the execution of the Component Story Pattern.A Component Story Pattern can be executed, if there is an isomorphism, which matches all

variables of the left-hand side to elements in the component instance configuration, the so-called host graph. It is important that the matching complies with the configuration predefinedby the variables. For example, a component variable and a port variable belonging to thecomponent have to be assigned to a component instance and a port instance belonging to thiscomponent instance. Furthermore, all variables are typed over the Component Model and,thus, only elements of the component instance structures of the same types of the componentmodel can be matched to a variable.

Finally, negative variables enable the specification of elements which are not allowed to bematched, i.e., a Component Story Pattern is only executable if the variables of the left handside are matched to elements of the component instance structure and none of the negativevariables can be matched to elements of the component instance structure.


We refer to [THHO08],[Tic09] for exact details about syntax and semantics of ComponentStory Diagrams.

4.3.2. Specification of the Control FlowComponent Story Diagrams use activity diagrams for the specification of the control flowconnecting Component Story Pattern. Different types of activities are supported which aremainly similar to the ones supported in original Story Diagrams [Zü01]:• Start- and Stopactivities specify the beginning and the end of the control flow.• Component Story Pattern activities contain the presented Component Story Patterns.• Iterated Component Story Patterns specify an execution of the contained Story Pattern

on all possible matchings (in contrast to a normal pattern which executes only on onematching.)• Special activities support calling other Component Story Diagrams.• Decision activities specify decisions and loops in the control flow. The conditions are

specified at the outgoing transitions. The successful application of the Component StoryPattern as well as boolean statements are allowed as conditions.

In order to use matchings of variables from a previous Component Story Pattern insubsequent ones, bound variables are used. If a Component Story Pattern contains a boundvariable, no matching will be searched for this variable during the execution but instead theprevious matching is reused.

Chapter 5.

Development Process

This chapter introduces the MECHATRONICUML software development process. Thesoftware of a mechatronic system is strongly interconnected with components of otherinvolved disciplines such as mechanical engineering, electrical engineering, and controlengineering. Therefore, MECHATRONICUML is integrated into an overall developmentprocess that coordinates the development among the different disciplines.

Schäfer et al. present a first coarse-grained description of the MECHATRONICUML process[SSGR11]. Becker et al. refine this coarse-grained process and introduce a first fine-grained variant of the MECHATRONICUML process [BDG+11]. In this chapter, we present afurther improved variant of the fine-grained MECHATRONICUML process. We derived mostimprovements from the evaluation that Sander and Bröker performed [San11, Brö11]. Theinteraction with the controller design process is described in [HSST13].

The goal of this process definition is to explain the MECHATRONICUML process in ahuman readable form that is as unambiguous as possible. The goal is not, however, todefine an automateable process. Thus, we use UML activity diagrams to describe theMECHATRONICUML process.

This chapter is structured as follows: First, the integration of MECHATRONICUMLwithin the overall development process is explained in Section 5.1. Second, theMECHATRONICUML process is described in detail in Section 5.2.

5.1. Process for Self-Optimizing Mechatronic Systems

Most development processes for mechatronic systems follow a variant of the V-Model such asdescribed by the VDI 2206 ”Design Methodology for Mechatronic” [VDI04b]. The VDI 2206defines a joint development process, a joint modeling formalism, and a joint use of toolsacross the different disciplines that are required for the development of mechatronic systems.However, the approach is only very coarse-grained and does, therefore, not sufficiently addressthe collaboration among the different disciplines.

In an ongoing effort within the Collaborative Research Center 614 (CRC 614), aninterdisciplinary, large-scale research project at the University of Paderborn, we have refinedthe V-Model of the VDI 2206 to improve the collaboration throughout the development of self-optimizing mechatronic systems [GFDK09a]. The macro structure of the development process

109

110 CHAPTER 5. DEVELOPMENT PROCESS

of the CRC 614 consists of three phases: the interdiciplinary conceptual design, the paralleldiscipline-specific development, and the system integration. The first two phases are shown inFigure 5.1. During the interdisciplinary conceptual design, a team of interdisciplinary expertsspecifies an initial system model with the CONceptual design Specification technique for theENgineering of complex Systems (CONSENS) which captures all interdisciplinary relevantaspects of the system. It includes the system’s requirements, the active structure that describesthe system’s logical and physical structure, its spatial properties (shape), and its behavior[GFDK09a].

In detail, the active structure consists of system elements that are similar to componentsin a UML component diagram. However, in contrast to UML components, system elementscan be connected to each other by three different kinds of flow relations, namely energy flow,material flow, and information flow.

The behavior can be modeled by behavior–activity, behavior–state, and behavior–sequencemodels that are similar to UML state machines, UML activity diagrams, and UML sequencediagrams [Gro10b]. Additionally, characteristic scenarios of the system’s interaction withthe environment are described by application scenarios. An application scenario consists of atextual description that explains the scenario and the system’s reaction, the system elements ofthe active structure that are relevant for the scenario, and the behavior for the communicationof those system elements.

This informal description of the application scenarios are likely to contain contradictionsand inconsistencies. During the step formal use case specification, the interaction of thecomponents and the interactions’ real-time constraints are specified by Modal SequenceDiagrams [HM07], a formal variant of UML sequence diagrams [Obj09]. In the same step theset of Modal Sequence Diagrams is analyzed to find the inconsistencies and contradictions.For the analysis, the synthesis or simulation approach of Greenyer is applied [Gre11]. Thesetwo steps are performed iteratively until the set of Modal Sequence Diagrams is free ofcontradictions and inconsistencies. The set of Modal Sequence Diagrams is then added tothe overall system model.

The overall result of the conceptual design is the principle solution, a milestone of theoverall system model that forms a common basis for the subsequent parallel development ofthe discipline-specific parts of the system within the discipline-specific development phase.

In the discipline-specific development phase all disciplines detail the system in a paralleldevelopment process by using their specific methods, formalisms and tools. Variousdependencies between the processes and the models usually exist in this phase that might resultin an inconsistent overall system model. Therefore, the parallel processes are coordinated andsynchronization techniques are used such that model-inconsistencies can be prevented. Inthe last phase, the results from all disciplines are integrated into an overall consistent systemmodel.

The MECHATRONICUML process is a vital part of the overall software developmentprocess during the discipline-specific development phase. As the principle solution is theresult of the former conceptual design phase, the partial models of the principle solutionform the basis of the MECHATRONICUML approach. In particular, the active structure and

5.1. PROCESS FOR SELF-OPTIMIZING MECHATRONIC SYSTEMS 111

discipline-specific development

development process in electrical engineering

development process in control engineering

development process in mechanical engineering

overall system model

specified by CONSENS

[principle solution]

development process in software engineering

interdisciplinary conceptual design

formal use case specification

MSDs for

application scenarios«transformation»

system model

MechatronicUML process

Legend

MSD = Model Sequence Diagram

Figure 5.1.: The Integration of the MECHATRONICUML Process into the DevelopmentProcess of Self-Optimizing Mechatronic Systems


the behavior models of the principle solution are the relevant initial models for the softwaredevelopment.

5.2. The MECHATRONICUML Platform-IndependentModeling Process

Figure 5.2 shows a diagram of the overall MECHATRONICUML process for platform-independent modeling. Based on the active structure, the set of the application scenarios’Modal Sequence Diagrams, and the behavior – state from the overall system model, thesoftware of the system is developed using MECHATRONICUML in 6 major steps and threesteps starting an iteration (Steps 9, 10 and 11).

MECHATRONICUML follows a top-down approach: the initial component model is derivedfrom the active structure in the principle solution during Step 1. In a later step (Step 4), thiscomponent model may be refined.

Step 1 starts with identifying the system elements, that are relevant for the softwaredevelopment. For each relevant system element a component is added to the componentmodel. A component can be a structured component or an atomic component. A structuredcomponent consist of parts that are typed by other components (cf. Section 3.6.2.1). An atomiccomponent has a behavior specification and cannot embed any parts (cf. Section 3.6.1).

In the active structure, system elements may form a hierarchical structure of further systemelements. Each further decomposed system element is represented by a structured componentin the component model. Inner system elements are transformed to parts. These parts aretyped by those components that represent the component type for the corresponding innersystem element. Afterwards, the information flow between all relevant system elements istransformed to connectors in the component model. This step can also be performed in a semi-automatic way [GSG+09]. If necessary, this model can be extended by further componentsand connectors. The result of this step is the initial version of the component model.

Based on the initial component model, the set of Modal Sequence Diagrams for theapplication scenarios, that are specified in the overall system model, are decomposed intosmaller specification parts that span a smaller set of components (Step 2). For thesesmaller specifications, that we will later transform into Real-Time Coordination Protocols,the behavior can be implemented more easily and verified more effectively. Each interactionmust fulfill certain real-time constraints. All constraints on the order of messages are includedin the set of Modal Sequence Diagrams of the application scenarios. But, there may bealso constraints on different operating states of the system that must be considered duringthe communication. These constraints are extracted from the set of behavior – state models.The result are the set of constraints for the components’ communications and a set of ModalSequence Diagrams for the external visible behavior of all components.

In Step 3, for each structural component a communication protocol for each connectoris derived from the according set of Modal Sequence Diagrams. The protocol behavior is

5.2. THE MECHATRONICUML PLATFORM-INDEPENDENT MODELING PROCESS 113

derive requirements for each communication

(2)

derive initial component model

(1)

determine coordination protocols

(3)

set of modal sequence diagrams for

application scenarios

active structure

set of structured

components

set of coordination

protocols

component model

«datastore»

component model

determine component’s behavior

(4)

set of components

set of behavior – state models

component model

«optional» RTSCs

«optional» binary code

«parallel»

«parallel»

non-platform specific

simulation of the system

(6)

[RTSCs for all components‘

behavior exist]

[the RTSC of at least one

component’s behavior does not

exist]

RTSCs

component

model

«datastore»

components‘ behavior

specified by

RTSCs

[simulation successful]

[simulation indicates flaws in

the modeled system]

redesign by other disciplines

(11)

other disciplines‘

models

[redesigned]

redesign formal use case

specification

(9)

[flaws originated

in other

discipline’s model]

[the flaws occured, due to a

missing requirement for the

software]

model initial component instance configuration

(5)

component instance

configuration

component instance

configuration

component

model

component model

application

scenarios

set of

constraintsset of MSDs for each

communication

set of MSDs

for application

scenarios

Process: MechatronicUML process

overall

system

model

(principle

solution) «datastore»

overall system

model

«transformation»

system model.active structure

«transformation»

system model.behavior – state

«transformation»

system model.behavior –

sequence

adapt component model

(10)

«transformation»

system model.

behavior-sequence

other

disciplines‘

models

«datastore»


models


models

other

disciplines‘

models

«transformation»

system model«transformation»

system model.

application scenario

Legend

MSD = Model Sequence Diagram RTSC = Real-Time Statechart

Figure 5.2.: Overall MECHATRONICUML Process


specified by Real-Time Statecharts, a variant of UML state machines with a formal semanticsbased on Timed Automata [AD94]. This allows the application of formal analysis techniquessuch as model checking to ensure certain safety and lifeness properties of the protocol.For each particpant in the protocol, the abstract role’s behavior is modeled by a Real-TimeStatechart to allow a flexible reuse of the protocol in other contexts. These Real-TimeStatechart are later (cf. Step 4) instantiated and refined in component ports. Additionally,temporal logic is used to define properties that hold for the protocol behavior. The propertiesare derived from the set of constraints that are extracted in step 2. The combination of theseproperties and the Real-Time Statecharts for one reusable, application independent protocolbehavior is called Real-Time Coordination Protocol (cf. Section 3.3). In Step 3, the Real-TimeCoordination Protocols for each connector of the structured components’ parts are determinedas described in detail in Section 5.2.1 and Section 5.2.2. This is performed for all structuredcomponents in parallel.

After Step 3, each component uses at least one Real-Time Coordination Protocol. For eachport of the components, a role of a Real-Time Coordination Protocol and the correspondingReal-Time Statechart are associated. This associated behavior of the roles specifies theexternal visible behavior of the components. In the next step (Step 4), for each component, thecomponent’s behavior is determined with respect to the external visible behavior. In particular,it must be ensured that the determined behavior is a valid refinement of all associated rolebehaviors.

Step 4 can be split into three alternatives as described in detail in Section 5.2.3: first,it must be decided if an appropriate component exists that can be reused. For existingcomponents, only the binary code may be available (e.g. the component may be deliveredby an external company that does not provide the source models). In such a case, the binarycode is the only output of Step 4 and no Real-Time Statechart exists for the component’sbehavior for the rest of the process. However, as described by Henkler et al. the Real-Time Statechart of the component’s external visible behavior can be derived with the helpof a learning approach such that a correct integration of the component can be ensured (cf.Section 5.2.3) [HBB+09, HMS+10].

Second, if the component is an atomic component, the component’s behavior is deriveddirectly from the parallel composition of the roles behavior (cf. Section 5.2.4). The result is aReal-Time Statechart for the component’s behavior.

Third, the component can be decomposed into further subcomponents to reduce thecomplexity. The component becomes a structured component and embeds parts whichrepresent the subcomponents. The behavior of the structured component is defined by theinteraction of the parts and the behavior of the subcomponents. For the development ofthe subcomponents, again communication protocols are defined and the determination ofthe behavior is repeated for each subcomponent (cf. Section 5.2.3). The subcomponentsmay, therefore, be decomposed until the complexity of the behavior is acceptable to derivethe behavior directly or an existing component can be integrated. The result consists of thecomponent model that is extended by subcomponents, and the behavior specification of allsubcomponents.


After Step 4, the structure and the behavior of the system’s software is specified completelywith respect to the safety properties specified for the Real-Time Coordination Protocols.But, it is not yet guaranteed that all relevant safety constraints are defined for the system.Furthermore, the models that are specified by other disciplines such as mechanical engineeringmay induce additional constraints for the behavior or contain flaws.

In the MECHATRONICUML approach, the software model is simulated together withmodels from other disciplines to identify missing constraints and flaws that result fromunforeseeable interaction of the results from the different disciplines (Step 6). At themoment, a simulation is only possible if the components’ behavior is specified by Real-TimeStatecharts. If for at least one component only the binary code exist, it is not possible tosimulate the system. In such a case the steps for the simulation (Steps 5 and 6) are skipped.

If a simulation is possible, an initial component instance configuration must be definedin Step 5. In MECHATRONICUML, the component model specifies various possiblestructures. This is necessary, because the MECHATRONICUML component model enablesthe specification of reconfigurable components in the component model. A reconfigurablecomponent can exchange, add, or delete parts, connectors and ports during run-time. For thesimulation, an initial instance of the structure must be chosen from the possible structures.This initial structure is specified with a component instance configuration as described inSection 3.7.

A simulation expert chooses from the set of application scenarios the relevant scenarios.For each of these relevant scenarios, a simulation of the system is performed in Step 6. First,the component model and the corresponding Real-Time Statecharts must be transformed tothe modeling formalism of an appropriate simulation tool. Additionally, also the models thatare developed in other disciplines such as the controller or the shape of the system must beintegrated into the simulation model. During the simulation, the behavior of the simulatedsystem is compared to the expected behavior as it is defined by the application scenarios.If the simulated behavior differs from the expected behavior, either the models from otherdisciplines contain flaws, or the application scenarios’ set of Modal Sequence Diagrams andthe constraints, that are adapted from the overall system model in Step 2, are incomplete. Theformer case must be handled within the development of the other disciplines (Step 11). Afterthe redesign of the other disciplines’ models, Step 6 is repeated.

If the application scenarios are incomplete, the set of Modal Sequence Diagrams areextended for the corresponding communication relation (Step 9). In the same step, the setof Modal Sequence Diagram is checked for contradictions and inconsistencies, until thespecification is correct again. It may be necessary to adapt the component model accordingto the changed set of Modal Sequence Diagrams (Step 10). The changes to the applicationscenarios and to the component model are reflected in the overall system model. If thechanges are relevant to other disciplines, they are synchronized with the models of thesedisciplines [RS12, RDS+12]. Finally, the development process is repeated for all dependingcomponents starting with step 2.


5.2.1. Determination of Coordination Protocols (Step 3)

For each structured component, the communication of its parts is precisely specified byReal-Time Coordination Protocols during Step 3. For Real-Time Coordination Protocolsit is assumed that each communication can be described independently. This does not,however, mean that no dependencies between different communications exist. But, it mustbe possible to decompose the communication behavior in such a way that the dependenciesof the communications can be modeled as a relationship between the roles of different Real-Time Coordination Protocols within a component. These dependencies are solved later inStep 4 where the components’ behaviors are to be defined.

Figure 5.3 shows the parallel determination of Real-Time Coordination Protocols of allconnectors in a structured component. Real-Time Coordination Protocols abstract from aconcrete implementation of the communication behavior to enable the reuse of the Real-Time Coordination Protocol in other contexts. In Step 3.1 it is decided, whether an earlierdefined Real-Time Coordination Protocol is reusable in the current context. Depending on theset of Modal Sequence Diagrams, an appropriate coordination protocol is identified for theconstraints of the communication.

set of coordination

protocols

Process: determine coordination protocols (3)

structured

component

find appropriate coordination protocol

(3.1)

coordination protocol

[previously specified coordination

protocol that fulfills the

requirements exists]

[previously specified coordination

protocol does not exist] model new coordination protocol

(3.2)

set of coordination

protocols

structured

component

coordination protocol

structured

component

«datastore»

structured component

«parallel»

set of

constraints

set of

constraints

set of

MSDs

set of

MSDsconstraints constraints

set of MSDs

for each

communication

set of MSDs

for each

communication

«datastore»

set of

coordination

protocol

coordination

protocol

Legend


Figure 5.3.: The Subprocess to Reuse or Model a new Real-Time Coordination Protocol forall Communications within one Structured Component

If it is not possible to find an existing coordination protocol, a new Real-Time CoordinationProtocol is modeled and saved for later reuse in Step 3.2. Based on the set of Modal SequenceDiagrams, the communication behavior is described by Real-Time Statecharts for the roles ofthe Real-Time Coordination Protocol. After formal safety constraints are derived from the set


of constraints, it is ensured that the communication behavior fulfills these safety constraints.Step 3.2 is described in more detail in Section 5.2.2.

The result of this step is a Real-Time Coordination Protocol that fulfills a set of safetyconstraints. For later reuse, the Real-Time Coordination Protocol is saved to a protocoldatabase [BGT05].

5.2.2. Modeling of a Real-Time Coordination Protocol (Step 3.2)

The steps to model a Real-Time Coordination Protocol are shown in Figure 5.4 in detail.A Real-Time Coordination Protocol is composed of different elements that are defined inthese steps. More specifically, a Real-Time Coordination Protocol consists of roles, theirmessage type specification and the roles’ behavior that is specified by Real-Time Statecharts,a connector that models the properties of the roles’ communication channels by a Real-Time Statechart, and a set of safety constraints that hold for the communication protocol.First, in Step 3.2.1, a set of formal safety constraints is derived from the the constraints ofthe communication. In parallel, the behavior of the coordination protocol is defined in theSteps 3.2.2 to 3.2.5.

During Step 3.2.2, the roles are derived from the set of Modal Sequence Diagrams. Mostly,the participating components correspond to a Lifeline in the Modal Sequence Diagrams. Anapplicable set of roles is found if all Lifelines can be associated with the roles easily.

For each role, the message type specification (cf. Section 3.2) is derived from the set ofModal Sequence Diagrams (Step 3.2.3). If the roles correspond to a Lifeline, all messages,that are sent from the Lifeline are added to the role’s message type specification.

In mechatronic systems, the communication of two components may be unreliable. Forinstance, messages that are transferred through a wireless connection may change their orderor get lost accidentally. The communication protocol must, however, guarantee a safebehavior. In Step 3.2.4, the quality is modeled by a Real-Time Statechart for the roles’connectors.

The effects that are introduced by the connector properties must be considered for the roles’behavior in Step 3.2.5. The set of Modal Sequence Diagrams is used to derive a Real-TimeStatechart for each role. This must be performed iteratively, because the roles depend oneach other. The behavior should be specified in such a way that the Real-Time CoordinationProtocol can be reused in a wide variety of applications. This often requires additional designeffort such as parameterizing time-intervals or adding foreseeable alternative flows of eventsin the form of non-determinism. The result of this step is a Real-Time Statechart that describesthe roles’ behavior such that formal analysis techniques can be used to verify the safetyproperties [HH11].

At last (Step 3.2.6), the specified behavior is verified against the safety and livenessconstraints that are specified in Step 3.2.2 [EHH+13]. If it is not possible to fulfill allconstraints, Steps 3.2.5 must be repeated to modify the roles’ behavior. If all constraintshold, Step 3.2 is performed and the result is a new Real-Time Coordination Protocol.


coordination

protocol

structured

component

derive message type

specification for each role

(3.2.3)

specify roles‘ behavior

(3.2.5)

set of message

types

set of message

types

derive roles

(3.2.2)structured component

set of roles

set of roles

structured

component

set of roles

«iterate»

«iterate»

specify connector properties

(3.2.4)

«parallel»

«datastore»

structured component

set of verification

constraints

«datastore»

set of

MSDs

formal verification of constraints

(3.2.6)

extract

formal constraints

(3.2.1)

set of connector

properties

set of

connectors

coordination

protocol candidate

set of verification

constraints

coordination

protocol

Process: model new

coordination protocol (3.2)

[verification successful

for all constraints]

[verification

failed]

structured

component

constraints

set of MSDs

set of MSDs

set of MSDs

set of MSDs

«datastore»

constraints

constraints

constraints

constraints

constraints

set of

MSDs

set of

message

types

Legend


Figure 5.4.: The Subprocess to Model a new Real-Time Coordination Protocol


5.2.3. Determination of the Components’ Behavior (Step 4)

The behavior of a component can be determined in three different ways as described inSection 5.2. The detailed steps for these alternative ways to determine the behavior of acomponent are highlighted by different colors in Figure 5.5. For all alternative ways todetermine the component’s behavior, the Real-Time Coordination Protocol, that is definedin Step 3, forms the basis. In particular, each component has a couple of roles associatedto the ports. The behavior of all roles must be refined by the component’s behavior[GTB+03, HH11]. During the blue step (Step 4.1), an existing component is reused andintegrated into the system. The three green steps (Steps 4.2, 3 and 4) are necessary todecompose the component into smaller subcomponents. A direct specification of the behavioris addressed in the orange step (Step 4.3).

Process: determine

component’s behavior (4)

Integrate existing component

(4.1)

derive component’s

behavior (4.3)

Does a component

exist that fulfills the

roles‘ behavior?

[yes]

[no]component

Roles‘ behavior

described by RTSCs

component

Roles‘ behavior

described by RTSCs

RTSC for the

component‘s

behavior

binary code

Has the

component

subcomponents or

is it necessary to

decompose the

component?

[no]

[yes]

component

Roles‘ behavior

described by RTSCs

decompose component

(4.2)

determine coordination protocol

(3)

component model

set of coordination

protocols

determine component‘s behavior

(4)

component model

set of coordination

protocolscomponent

set of coordination

protocols

«datastore»

component modelset of structured

components

set of

components«parallel»

«parallel»

component model«optional» RTSCs«optional» binary code

«optional»

RTSCs

«optional»

set of binary

code

«optional»

set of

RTSCs

set of informal

behavior

requirements

set of

constraints

Legend


specify reconfiguration behavior

(5)

«parallel»

set of

components

component model

«optional» Component Story Diagrams

Figure 5.5.: The Subprocess to Determine the Internal Structure or Behavior of a Component


At first, it must be decided if an existing component can be reused. If an appropriatecomponent is identified, the component is integrated (Step 4.1). The reuse and integrationof components is an ongoing research project. In particular, we are working on methods tointegrate legacy components into the system [HBB+09, HMS+10]. Most legacy componentsonly come with the binary code of the component. Although it is possible to learn the externalvisible behavior of the component, the internal behavior specification of the component isunknown [HBB+09, HMS+10]. The result of this step is, therefore, the binary code. AReal-Time Statechart for the components behavior is only produced, if it is available for thecomponent.

If no reusable component is available, a new component must be modeled. First, it must bedecided whether the component’s behavior can be defined directly, or the component must bedecomposed. In particular, the decision is depending on the complexity of the roles’ behaviorsand the dependencies between the roles. The roles’ behaviors and their inter-dependencies areconsidered to define the component’s behavior.

If the behavior is derived directly, Step 4.3 is performed. A detailed explanation is given inSection 5.2.4. Based on the roles’ Real-Time Statecharts, a parallel composition of Real-Time Statecharts for the component is defined. The component’s Real-Time Statechartrefines the behavior of the roles. For instance, times, that are parameterized in the Real-Time Coordination Protocol, are specified according to the concrete application. Gieseet al. defined construction rules for the refinement to ensure that the safety constraintsof the Real-Time Coordination Protocol are still fulfilled for the refined behavior of thecomponent [GTB+03, HH11]. According to these refinement rules, additional behavior isadded such as additional messages for the internal communication within the component.These additional messages are necessary to synchronize the behavior of dependent roles.The result of this step is a Real-Time Statechart for the component’s behavior that is a validrefinement of the roles behavior.

A component with a complex behavior, may be decomposed into smaller subcomponents.During Step 4.2, the component becomes a structured component that is composed of a setof parts (cf. Section 3.6.2). These parts represent the subcomponents that are added to thecomponent (cf. Section 3.6.2.3). The ports of the component are delegated to ports of theparts (cf. Section 3.6.2.4). At the end of the step, all structured component’s ports must bedelegated to a port of a part. The associated roles’ behaviors of each component’s ports is tobe refined by the subcomponent, it is delegated to.

Due to the dependencies between roles, the behavior can often not be decomposed such thatthe parts are independent from each other. Instead, connectors that represent communicationrelations of the parts must be added to deal with the dependencies. These extensions to thecomponent’s structure are added to the overall component model at the end of Step 4.2.

The communication protocols of interacting subcomponents are described in the same wayas in Step 2 of the overall MECHATRONICUML process (cf. Figure 5.2). Requirementsregarding the protocol behavior are usually specified informally. These requirements maybe described by text, sequence diagrams or behavior–state diagrams (as used in the principle


solution). Additionally, a set of safety constraints that must be fulfilled by the protocol isdefined in an informal manner.

As in the overall MECHATRONICUML process, the informal communication requirementsare first specified by Real-Time Coordination Protocols (Step 3) and the subcomponent’sbehavior is determined based on the Real-Time Coordination Protocol afterwards (Step 4).Note, that the last step is a recursion. This means that the subcomponents may be decomposedfurther, if it is necessary to tackle the complexity of the component’s behavior. The behaviorof the subcomponents and its interaction define the behavior of the decomposed component.The result of this step, therefore, consists of the architectural extensions and a set of behaviorspecifications for the components on the lowest architectural level. The behavior for all atomiccomponents is, thereby, specified by Real-Time Statecharts. For the behavior of an integratedcomponents, only the binary code may be provided.

Finally, we specify the reconfiguration behavior of our components. If a component needsto adapt its internal structure during runtime, we specify component story diagrams (cf.Section 4.3) that formally define the necessary reconfiguration. We refer to Heinzemann etal. [HSST13] and Heinzemann and Becker [HB13] for more information on this process step.

5.2.4. Modeling of the Components’ Behavior (Step 4.3)Initially, the behavior of the component is only specified by its externally observable behavior.This is specified for the different roles of the component by Real-Time Statecharts (cf.Section 3.6.1.3). The goal of Step 4.3 is to derive a Real-Time Statechart for the component’sbehavior (cf. Section 3.6.1.4). Figure 5.6 shows the detailed steps that are necessary to achievethis goal.

The first Steps 4.3.1 and 4.3.3 are performed in parallel. In Step 4.3.1, for each port aReal-Time Statechart is derived from the associated roles’ Real-Time Statechart. The Real-Time Statechart of the roles can usually be copied or referenced in this step. However, ifthe corresponding Real-Time Coordination Protocol is parametrized, it may be necessaryto identify the appropriate parameters for the application. Furthermore, application specificrefinements such as actions for side effects, additional internal messages, or states must beadded. These refinements can change the behavior of the roles and can, therefore, violate thesafety constraints of the Real-Time Coordination Protocol. Thus, in Step 4.3.2 the correctnessaccording to the approach proposed by Heinzemann et al. [HH11] is ensured . The result ofthese two steps is an independent parallel composition of Real-Time Statecharts.

Dependencies of the roles, that usually exist, are considered in Step 4.3.3. The dependenciesare extracted from the roles’ behavior and formalized by composition rules. Composition rulesare a combination of timed automata and Boolean logic formulate that are used to specifybehavior that must happen in a component or states that are forbidden [EH10].

The previously specified Real-Time Statecharts must be synchronized according to thecomposition rules. This is performed by an automatic synthesis technique in Step 4.3.4.The synthesis automatically generates a Real-Time Statechart that is correctly refined andsynchronizes the roles’ behavior according to the composition rules. This technique fails, if


the behavior specification or the composition rules are inconsistent or contain contradictions.The result of this step is, therefore, a consistent, correctly refined behavior of the componentspecified by a Real-Time Statechart.

Due to the inherent complexity of the synthesis, this technique cannot be applied tocomponents with a too complex behavior. In this situation, the synchronization behaviormust be modeled manually (Step 4.3.5). The synchronization is realized by an additionalReal-Time Statechart called synchronization statechart. The synchronization statechart isdeveloped based on the composition rules. It allows only non-conflicting behavior of theReal-Time Statecharts that are derived from the roles’ behavior in Step 4.3.1. These Real-TimeStatecharts are extended by messages that enable the communication with the synchronizationstatechart. It is the task of the developer to ensure the correctness of the refinement during thisextension step. An appropriate approach to guarantee a valid refinement by construction hasbeen proposed by Giese et al. [GTB+03].

At last, the refined roles’ Real-Time Statecharts and the synchronization statechart arecombined to one Real-Time Statechart (cf. Section 3.6.1.4). Each refined roles’ Real-Time Statechart is inserted into a parallel region of the component’s Real-Time Statechart.Additionally, a parallel region is added for the synchronization behavior.

The last step (Step 4.3.6) ensures that the component’s behavior is free from deadlocks.If deadlocks exist, the specification of the synchronized behavior must be modified andStep 4.3.5 must be repeated.

The result of the whole subprocess 4.3 is the discrete component’s behavior specified by aReal-Time Statechart.


Process: derive

components‘

behavior (4.3)

componentRoles‘ behavior described

by RTSCs

RTSC for the

component‘s behavior

specify dependencies between

component’s roles (4.3.3)

automatic synthesis of

synchronized behavior (4.3.4)

derive port behavior

for role (4.3.1)

model synchronized

behavior manually (4.3.5)

check for deadlock

freedom (4.3.6)

set of

RTSCs for port

behavior

composition

rules

«optional»

RTSC for

component’s

behavior

RTSC that

synchronizes the port

statecharts

set of RTSCs for

port behavior

composition

rules

«datastore»

composition rules

«datastore»

set of Real-Time

Statecharts for port behavior

«datastore»

RTSC

for component’s behavior

set of RTSCs for

port behavior

composition rules

RTSC for

component’s behavior

[deadlocks exist]

[no deadlocks exist]

[synthesis successful]

[synthesis not possible]

component

Roles‘ behavior

described by

RTSCs

Roles‘ behavior

described by

RTSCscomponent

check application-

specific refinement (4.3.2)

set of RTSCs for

port behavior

[refinement correct]

[refinement

incorrect]

Legend


Figure 5.6.: The Subprocess to Model the Behavior of a Component

Chapter 6.

Complete Example

In this chapter, we provide a complete, self-contained example. We model it withMECHATRONICUML. Our example is the environment exploration scenario using BeBotsas introduced in Section 1.1.

In the following, we describe the Real-Time Coordination Protocols including their rolebehaviors used for the scenario and summarize the message types used for the specificationof the Real-Time Coordination Protocols in Section 6.1. Afterwards, we introduce the BeBotcomponent architecture in Section 6.2. Then, the behavior of the components is described inSection 6.3 and the component instance configurations for the example scenario are introducedin Section 6.4.

6.1. Real-Time Coordination Protocols and MessageInterfaces

In this section, we introduce the five Real-Time Coordination Protocols that we use in ourexample (Figure 6.1) and their message types.

The Real-TimeCoordination Protocols Navigation, Delegation, and AllPositionsTransmission have the formof communication 1:1, i. e. there is one sender and one receiver. The Real-Time CoordinationProtocols Distribution and PositionTransmission have the form of communication 1:n, i. e.there is one sender and several receiver. Navigation, Delegation, and Distribution have abidirectional communication direction; PositionTransmission and AllPositionsTransmissionare unidirectional (cf. Section 3.3.4). We assume that these five Real-Time CoordinationProtocols have no message delay and no message loss. Furthermore, we assume one incomingmessage buffer of size 1 for each receiving message type of each role that may receivemessages.

The instantiations of these Real-Time Coordination Protocols are shown in Figure 6.18in Section 6.2. In the following sections, we introduce the functioning of the Real-TimeCoordination Protocols and the behavior of their roles. Furthermore, we introduce the messagetypes used by the Real-Time Coordination Protocols. A Real-Time Coordination Protocol useseach message type twice: once in the sender message type specification, once in the receiver

125

126 CHAPTER 6. COMPLETE EXAMPLE

receiversender

navigator provider

Navigation

master slave

Delegation

clientdistributor

Distribution

receiversender



[1]

[1]

[1]

[1]

[1]

[1]

[1][1..2]

[1]

[1..8]

Figure 6.1.: The Five Real-Time Coordination Protocols used in the BeBot Scenario

message type specification. Although it is not required, we recommend to collect the messagetypes used in one Real-Time Coordination Protocol in one message type repository. In thefollowing, we use the name of the Real-Time Coordination Protocol as a name for the messagetype repository.

6.1.1. Navigation Protocol and Message Interface

The Real-Time Coordination Protocol Navigation (1:1, bidirectional) transmits an intendedtarget position from a navigator role to a provider role that provides the navigation to thereceived position. After reaching the target position, the success is reported back to thenavigator. Figure 6.2 shows the two message types needed for this Real-Time CoordinationProtocol.

Navigation

moveTo(int[2] xy)

targetReached()

Figure 6.2.: Message Type Repository containing the Message Types for the Real-TimeCoordination Protocol Navigation

6.1. REAL-TIME COORDINATION PROTOCOLS AND MESSAGE INTERFACES 127

Both message types are grouped in the message type repository Navigation. The navigatorrole uses an instance of message type moveTo to transmit a position to the provider role.The parameter xy is a one-dimensional array of length 2 that contains the coordinates of theposition. An instance of the targetReached message type signals the navigator role that theBeBot has reached the intended target position.

6.1.1.1. Role Navigator

Figure 6.3 shows the Real-Time Statechart of the role navigator. It consists of two states, theinitial state Stop and the state Go. The transition from Stop to Go sends a target positionas a one-dimensional array with two entries, representing the x and y coordinates of a targetposition, via the message moveTo. The message targetReached triggers the transition fromGo back to Stop.

Navigation_navigator

Stop

/ moveTo(target)

Go

targetReached /

variable int[2] target

Figure 6.3.: Role Navigator of Protocol Navigation

6.1.1.2. Role Provider

Figure 6.4 shows the Real-Time Statechart of the role provider. It represents the counter-partto the Real-Time Statechart in Figure 6.3 and consists of the two states Polling, which is theinitial state, and Moving. The message moveTo triggers the transition from Polling to Moving.The message moveTo has a target position as a one-dimensional integer array with two entriesas parameter. The transition from Moving back to Polling sends the message targetReached.

Navigation_provider

moveTo / {target:=moveTo.target}

MovingPolling

/ targetReached


Figure 6.4.: Role Provider of Protocol Navigation


6.1.2. Delegation Protocol and Message InterfaceThe Real-Time Coordination Protocol Delegation (1:1, bidirectional) delegates the task ofchecking the validity of a target position from a master to a slave role. Figure 6.5 shows thethree message types which the Real-Time Coordination Protocol uses.

Delegation

check(int[2] target)

accepted()

declined()

Figure 6.5.: Message Type Repository containing the Message Types for the Real-TimeCoordination Protocol Delegation

All message types are grouped in the message type repository Delegation. An instance ofthe message type check transmits a 2D position information encoded as a one-dimensionalarray of length 2 to the slave. The slave signals success by an instance of message typeaccepted and signals that executing the task is not possible by an instance of message typedeclined.

6.1.2.1. Role Master

Figure 6.6 shows the Real-Time Statechart of the role master. It consists of the initial stateInactive and the state PositionCheck. The non urgent transition from Inactive to PositionChecksends a target position as a one-dimensional integer array with two entries via the messagecheck. Upon the activation of PositionCheck the clock c_wait is reset via an entry-action. Aninvariant using c_wait ensures that PositionCheck is left no later than 150 milliseconds afterits activation. There are two outgoing transitions leading back to state Inactive. The one withthe higher priority is triggered by the message declined, the other is triggered by the messageaccepted.

Delegation_master variable int[2] target clock c_wait

InactivePositionCheck

invariant c_wait ≤ 150 ms

entry / {reset: c_wait}/ check(target)

accepted /

declined / 2 1

Figure 6.6.: Role Master of Protocol Delegation


6.1.2.2. Role Slave

Figure 6.7 shows the Real-Time Statechart of the role slave. It represents the counter-part tothe Real-Time Statechart in Figure 6.6 and consists of the same states. The message checktriggers the transition from Inactive to PositionCheck and the target position is received asparameter. Upon the activation of PositionCheck, the clock c_work is reset via an entry-action.An invariant using c_work ensures that PositionCheck is left no later than 100 millisecondsafter its activation. There are two outgoing transitions leading back to state Inactive. The onewith the higher priority sends the message declined, the other sends the message accepted.Both transitions are non urgent.

Delegation_slave


invariant c_work ≤ 100 ms

entry / {reset: c_work}

check / {target:=check.target}

/ accepted

/ declined

variable int[2] target clock c_work

2 1

Figure 6.7.: Role Slave of Protocol Delegation

6.1.3. Distribution ProtocolThe protocol Distribution (1:n, bidirectional) transmits position data between the multi-roledistributor and one or more instances of the role client. The distributor collects the positionsof all clients and sends the collected positions and its own position back to each of them usinga multi-cast. Figure 6.8 shows the two message types used by the Real-Time CoordinationProtocol.

Distribution

positions(int[8][2] posArray)

position(int[2] pos)

Figure 6.8.: Message Type Repository containing the Message Types for the Real-TimeCoordination Protocol Distribution

Both message types are grouped in the message type repository Distribution. An instance ofthe message type positions is used to transmit the positions of all BeBots to the clients. Thepositions are contained in a two-dimensional array as a parameter. There exists one entry foreach of the at most 8 BeBots and for each entry it contains the x and y position.

The client uses the message type position to transmit its own position to the distributor. Theparameter pos is a one-dimensional array of length two that contains the x position as firstentry and y position as second entry.

6.1.3.1. Role Distributor

Figure 6.9 shows the Real-Time Statechart of the multi-role distributor. Since it specifies thebehavior of a multi-role, it follows the convention that there is only one initial compositestate, Distribution_distributor_Main, with the two regions adaptation and sub-role-template(cf. Section 3.3.6). The sub-role-template region contains a Real-Time Statechart that onlyconsists of the state Active. The state Active, in turn, consists of two regions, receive andsend, which are responsible for receiving data from or sending data to the clients.

Distribution_distributor variable int[2] myPos, int[8][2] posArray, bool error := false


adaptation

sub-role-template

2

1


clock c_period, c

Active

Waiting





Sending


entry / {reset: c}

send[first]!

send_done?

[c_period ≥ 50 ms] receive[first]!

Receiving


entry / {reset: c}

All_Received


entry / {reset: c}


2

1


send

receive

1

2

Idle

position receive[self]? / {posArray[id][0]:=position.xy[0];

posArray[id][1]:=position.xy[1];}

Receivedreceive[self]? / {error:=true}

2

1


[self==last] send_done!

[self<>last] send[self.next]!12


[self<>last] receive[self.next]!12

Figure 6.9.: Role Distributor of Protocol Distribution

The behavior of the multi-role is as follows. The execution starts in state Waiting of theregion adaptation and in the states Idle of receive and send. Periodically, the adaptationregion checks whether position data has been received from all clients by firing the transition


from Waiting to Receiving if c is greater than 50 thereby synchronizing with the first sub-role.If the message position is available upon the synchronisation receive[id], it is processed andthe position information is written to the variable posArray. If the sub-role has no message inits buffer, an error occurred and the sub-role switches to Received and sets the variable errorto true. In state Received, it synchronizes with the next sub-role using channel receive orit synchronizes with the adaptation statechart if it is the last sub-role of the ordered sub-role-list. If error is true, then the adaptation statechart switches to state Waiting without sendingthe position data to the clients, otherwise it switches to state All_Received. Section (cf.Section 3.4.11) describes the semantics of multi-role statecharts in detail.

If the distributor receives new position data from all of its clients, it will start sending thecollected position data back to the clients. Therefore, it fires the transition from All_Receivedto Sending, thereby synchronizing with the first sub-role using the synchronization channelsend. Then, the region send of the first sub-role switches to Sent and sends the messagepositions to the client. Thereafter, it synchronizes with the next sub-role using thesynchronization send if a next sub-role exists. Otherwise, this is the last sub-role that hasto synchronize with the adaptation. Then, the adaptation statechart switches to state Waitingand the behavior starts all over again.

6.1.3.2. Role Client

Figure 6.10 shows the Real-Time Statechart of the role client. It represents the counter-part tothe Real-Time Statechart in Figure 6.9, more precisely to the state Active in region sub-role,and consists of the initial composite state Distribution_client_Main with its two regions sendand receive.

Distribution_client

Distribution_client_Main

Blocked


[c ≥ 45 ms] /

position(pos)

Ready


entry / {reset: c}

positions /

{posArray:=positions.array;}

Error[c ≥ 50]

positions / {posArray:=positions.array;}

2

1

variable int[8][2] posArray clock c

variable int[2] pos clock c 2

1receive

send

Ready


entry / {reset: c}

[c ≥ 50 ms] / position(pos)

Blocked


[c ≥ 35 ms]

Figure 6.10.: Role Client of Protocol Distribution


Both regions start their execution in state Blocked. If c becomes exactly 35 milliseconds, theReal-Time Statechart switches to state Ready. In this state, it expects to receive new positiondata from the distributor every 50 milliseconds. If a message positions is received, the self-transition at state Ready in region receive is fired. As a side effect, the received position datais stored in the variable posArray. If no such message is received within 50 milliseconds, theinvariant of state Ready expires and the state is left by firing the transition leading to the stateError. The statechart remains in that state until new position data is received. Receiving thenew position data triggers the transition which leads back to Ready.

The statechart in region send initially sends its own position to the distributor when creaches the value of exactly 45 milliseconds. The position data is sent by means of the messageposition. In state Ready, the invariant enforces the state to be left every 50 milliseconds. Then,the self-transition is fired, which causes new position data to be sent to the distributor. Whenentering the state Ready again, the entry action sets the value of c back to 0.

6.1.4. PositionTransmission Protocol and Message Interface

The protocol PositionTransmission (1:n, unidirectional) transmits a position from the multi-role sender to one or more instances of the role receiver. Figure 6.11 shows the the messagetype used by the Real-Time Coordination Protocol.


position(int[2] xy)

Figure 6.11.: Message Type Repository containing the Message Types for the Real-TimeCoordination Protocol PositionTransmission

The message type is contained in the message type repository PositionTransmission. Themessage type position is used to transmit the position data. It contains a one-dimensional arrayof length two as a parameter containing the x and y position of the BeBot.

6.1.4.1. Role Sender

Figure 6.12 shows the Real-Time Statechart of the multi-role sender. Like the Real-Time Statechart in Figure 6.9 it follows the convention that there is only one initialcomposite state, PositionTransmission_sender, with the two regions adaptation and sub-role(cf. Section 3.3.6).

The execution starts in state Waiting of region adaptation and in state Idle of region sub-role. When c reaches the value of exactly 10 milliseconds the region adaptation changes its

PositionTransmission_sender


adaptation

sub-role-template

2

1

channel send[Role], done[Role]

Waiting


entry / {reset: c}

[c ≥ 10 ms] /

{curRole := first}Sending


[curRole <> last] done[curRole]? /

{curRole := curRole.next}

clock c

variable int[2] pos

Idle send[self]? / position(pos) Sent

done[self]!1

AwaitDone

send[curRole]! [curRole == last] done[curRole]?

Figure 6.12.: Role Sender of Protocol PositionTransmission

current state to Sending and then synchronizes with its first sub-role with the channel send.The sub-role sends the message position upon synchronization and synchronizes then with thenext sub-role transition from Sent to Idle. The last sub-role synchronizes with the adaptionstatechart with the channel send_done. Note that the adaption statechart has to exit its stateSending within 50 milliseconds, meaning the sending of the position data of all sub-roles hasto be performed within 40 milliseconds.

6.1.4.2. Role Receiver

Figure 6.13 shows the Real-Time Statechart of the role receiver. It represents the counter-partto the Real-Time Statechart in Figure 6.12, more precisely to the region sub-role. In the initialstate Active, a self-transition is fired upon receiving the message position, while the positiondata is stored in the variable pos. When entering the Active state, the clock c_period is reset.If the clock reaches exactly 100 milliseconds, the statecharts changes its state to Error. Fromthis state, a transition leads back to state Active when position is received.

PositionTransmission_receiver

Active



position / {pos:=position.xy;}

2

Error[c_period ≥ 100 ms]1

position / {pos:=position.xy;}

variable int[2] pos

clock c_period

Figure 6.13.: Role Receiver of Protocol PositionTransmission


6.1.5. AllPositionsTransmission Protocol and Message Interface

The protocol AllPositionsTransmission (1:1, unidirectional) transmits an array of all positionsfrom the role sender to the role receiver. It only uses one message type as shown inFigure 6.14.


allPositions(int[8][2] array)

Figure 6.14.: Message Type Repository containing the Message Types for the Real-TimeCoordination Protocol AllPositionsTransmission

The message type is contained in the message type repository AllPositionsTransmission.The message type allPositions is used to transmit the positions of all bebots. It contains atwo-dimensional array of length 8 for the at most 8 positions of the other BeBots.

6.1.5.1. Role Sender

Figure 6.15 shows the Real-Time Statechart of the multi-role sender. It consists of one stateActive. In this state it can send the message allPositions with a two-dimensional integer array,which contains the positions of the other BeBots as parameter.

AllPositionsTransmission_sender

Active/ allPositions(posArray)

variable int[8][2] posArray

Figure 6.15.: Role Sender of Protocol AllPositionsTransmission

6.1.5.2. Role Receiver

Figure 6.16 shows the Real-Time Statechart of the role receiver. It represents the counter-partto the Real-Time Statechart in Figure 6.15 and is nearly identical to the Real-Time Statechartin Figure 6.13. It differs from the latter only in the received message allPositions with a two-dimensional integer array as parameter, which is set to the variable posArray.

6.2. SYSTEM STRUCTURE 135

AllPositionsTransmission_receiver

Active



allPositions / {posArray:=allPositions.posArray;}

2

Error[c_period ≥ 100 ms]

1

allPositions / {posArray:=allPositions.posArray;}

variable int[8][2] posArray

clock c_period

Figure 6.16.: Role Receiver of Protocol AllPositionsTransmission

6.2. System Structure

In this section, we introduce the components specifying the system structure for the BeBotexample scenario. Firstly, we show the structured components representing the whole BeBotand the discrete BeBot software in Section 6.2.1. The structured components are composed bya set of atomic components which we introduce in detail in Section 6.2.2. Each of the atomiccomponents implements a specific part of the overall BeBot behavior. They are embedded ascomponent parts in the BeBot and interact with each other using the Real-Time CoordinationProtocol introduced in Section 6.1.

6.2.1. Structured Components

In our example, we use two structured components for the BeBot model: one to representthe BeBot as a whole including the continuous control software, the other one to model thediscrete BeBot software. In the following, we introduce the structured components in thatorder.

Figure 6.17 shows the structured component BeBot that represents the BeBot as a whole.It has the ports distributor and client, that exchange position data with other BeBots exploringthe environment. Note that the structured component of the BeBot implements the clientand the distributor port, whereas there may not be an instance configuration of the BeBotthat implements both ports at once, since a BeBot is either the distributor, that transmits thepositions of all BeBots, or a client, that receives the positions sent by the distributor. Thereforethe cardinality of the ports distributor and client of the BeBot is lower bounded by 0 and upperbounded by 1.

The component BeBot embeds a hybrid component part bsw of type BeBot_SW thatcontains the discrete BeBot software. Furthermore, it contains the hybrid component partmo of type MotionCtrl, that is responsible for controlling the speed of the chain drives and canalso let the BeBot rotate around its own axis by a certain angle, and the hybrid component partpos of type PosData, that provides the positioning data of the GPS. Further, the structuredcomponent BeBot has two discrete ports distributor and client which are connected via adelegation to the discrete ports with the same name of component part bsw.


bsw : BeBot_SW [1]

Distribution.

client

Distribution.

distributor

distributor client

position

turnAngle_target

speed_target

BeBot

Distribution.

distributor

Distribution.

client

distributor client

mo : MotionCtrl [1]speed_in

speed_out

pos : PosData [1]pos_in

pos_out

turnAngle_in turnAngle_out

Figure 6.17.: Structured Component Defining the BeBot

The component part bsw implements the ports distributor and client of the structuredcomponent BeBot. Additionally, it implements three continuous ports connected to thecontinuous component parts mo and pos.

The BeBot_SW component encapsulates the discrete BeBot software. The software needsto behave according to its role in the environment exploration scenario. More concrete,its behavior depends on whether it is the position distributor BeBot or a client BeBot.Additionally, the BeBot must implement behavior for navigation, collision control, and fordeciding on the target position.

In our example, we decompose the overall behavior of the BeBot into four atomiccomponents that are embedded into the BeBot_SW component by using component parts.This corresponds to Step 4.2 of the development process as shown in Figure 5.5 on Page 119.

Figure 6.18 shows the structured component BeBot_SW that represents the software of theBeBot.

The component specifies five ports: speed_target, turnAngle_target, position, client, anddistributor. The continuous port speed_target controls the speed for the chain drives of theBeBot by giving a target speed. The continuous port turnAngle_target sets the desired anglein the coordinate system of the environment. The continuous port position obtains the currentposition from the component PosData.

We specify the behavior of the remaining two discrete ports of BeBot_SW and thediscrete ports of the atomic components Navigation, Exploration, BeBot_Observer andCollision_Control by refining the roles of the Real-Time Coordination Protocols. We describe


speed_target

BeBot_SW

exp : Exploration [1]

cc : Collision_Control [0..1]


position

bbo : BeBot_Observer [0..1]



Delegation

Navigation

master

slave

receiver

receiver

receiver

sender

sender

navigator provider

Distribution.client


receiver sender

slave

master

receiver

distributor

client

distributor

client

sender

receiver

providernavigator

speed_target

turnAngle_target

position

Figure 6.18.: Component Diagram of the BeBot Software

them in Section 6.1. This corresponds to Step 4.3.1 of the development process as shown inFigure (cf. Figure 5.6) on Page (cf. Figure 5.6 on page 123).

The Real-Time Coordination Protocol Distribution is instantiated between the portsdistributor and client of the Bebot_SW. This is an example that communication betweencomponents of the same type is possible. Its multi-role distributor is assigned to the equallynamed multi-port distributor and its other role client is assigned to the equally named portclient. The distributor port is only active when the BeBot operates as the position distributor.In this case, there is one instance of this port for each client BeBot such that they can receiveposition data from all other clients and can send them to all other clients. Accordingly, theclient port is only used when operating as a client.

The Real-Time Coordination Protocol Navigation is instantiated between the port navigatorof the component part exp:Exploration and the port provider of the component partnav:Navigation. An instance of the Real-Time Coordination Protocol Delegation is assignedto the port master of the component part exp:Exploration and the port slave of thecomponent part cc:Collision_Control. The instantiated Real-Time Coordination ProtocolAllPositionsTransmission describes the communication between the ports sender of thecomponent part bbo:BeBot_Observer and receiver of the component part cc:Collision_Control.The instance of the Real-Time Coordination Protocol PositionTransmission describes the


communication between the multi-port sender of Navigation and the ports receiver ofbbo:BeBot_Observer and exp:Exploration. The single-role receiver is instantiated two timeshere. We describe the atomic components Navigation, Exploration, BeBot_Observer andCollision_Control in detail in the following section.

6.2.2. Atomic Components

In our example, we use the six atomic components shown in Figure 6.19 for modeling theBeBot. We use four discrete atomic components, and two continuous atomic components. Wedescribe their purpose in the following sections and explain their behavior in Section 6.3.

BeBot_Observer

Navigation

server

client

receiver

sender

speed_target

turnAngle_target

positionsender

provider

AllPositionsTransmission.sender


Distribution.client


Navigation.provider


Exploration

Collision_Control

Delegation.master

Delegation.slave

AllPositionsTransmission.receiver

Navigation.navigator

receiver

slave

master

receiver

navigator


MotionCtrl

speed_in speed_out

PosDatapos_in

pos_out angle_in angle_out

Figure 6.19.: The Atomic Components of the BeBot

6.2.2.1. Exploration

The component Exploration controls the exploration of the environment. It calculatesa next position for the BeBot randomly based on the current position. It receives thecurrent position from the Navigation component using the Real-Time Coordination ProtocolPositionTransmission. Before the Exploration component sends the new target position forthe BeBot to Navigation using the Real-Time Coordination Protocol Navigation, it is checkedwhether it is safe to move to the calculated position. Therefore, the Exploration sends thenew position to the Collision_Control using the Real-Time Coordination Protocol Delegation


to check for potential collisions. If no collision can occur, the position is sent to the Navigationin order to start moving the BeBot to the new position. The complete definition of the behaviorof the Exploration component is explained in Section 6.3.1.

6.2.2.2. Navigation

The component Navigation provides two services. Firstly, it receives and processes thecurrent position data from PosData. Then, it transmits the position data regularly via theReal-Time Coordination Protocol PositionTransmission to the components Exploration andBeBot_Observer. The component Exploration uses the data for calculating the next positionto move to and the component BeBot_Observer sends the position data to the other BeBotsand to Collision_Control. Secondly, the Navigation provides an interface to the chain drives ofthe BeBot. Given a target position, which is received via the Real-Time Coordination ProtocolNavigation, the Navigation sends the speed and the angle to the motion controller in order tomove from the current position to the target position. After reaching the target position, thesuccess is reported to the Exploration which then can compute the next position. The completebehavior definition of the Navigation component is explained in Section 6.3.2.

6.2.2.3. BeBot Observer

The component BeBot_Observer is responsible for maintaining the positions of all BeBotsin the environment. The BeBot_Observer may either operate as the position distributor or asa client of a position distributor via the Real-Time Coordination Protocol Distribution. As aclient, the BeBot_Observer regularly sends its current position to the distributor. Then, thedistributor answers with an array containing the current positions of all BeBots. Afterwards,the Bebot_Observer forwards this information to the Collision_Control via the Real-TimeCoordination Protocol AllPositionsTransmission in order to avoid collisions. When operatingas a position distributor, the BeBot_Observer waits for clients to report their position. If itreceives a new position of a client, the position data is updated internally and the updatedposition data is sent back to all the clients. Like a client, the position distributor forwardsall positions to the Collision_Control. In order to be able to communicate with a varyingnumber of clients, the distributor port of the BeBot_Observer is a multi-port which is delegatedfrom the BeBot_SW. It is delegated because the ports distributor and client are offered by theBeBot component to interact with other BeBots. The complete behavior definition of theBeBot_Observer component is explained in Section 6.3.3.

6.2.2.4. Collision Control

The component Collision_Control is responsible for avoiding collisions with other BeBotsexploring the environment. More specifically, the Collision_Control must decide for a giventarget position whether it is safe to move there. Therefore, it receives the intended targetposition from Exploration via the Real-Time Coordination Protocol Delegation. Additionally,


the Collision_Control receives the positions of all BeBots from the BeBot_Observer viathe Real-Time Coordination Protocol AllPositionsTransmission. From this information, theCollision_Control can decide whether moving to the target position is safe or not. If it is safe,an accept is sent to Exploration. Otherwise, a decline is sent. The complete behavior definitionof the Collision_Control component is explained in Section 6.3.4.

6.2.2.5. PosData

The continuous component PosData provides position data for the BeBot. It is connected tothe GPS hardware and continuously evaluates the incoming sensor signals. As an output,it provides a continuously updated position signal which may be used by the Navigationcomponent.

Since the behavior models for continuous components are not part of MECHATRONICUML,we do not describe the behavior of PosData any further in this document.

6.2.2.6. MotionCtrl

The continuous component MotionCtrl controls the engine of the BeBot. It is assumed to be aclosed-loop controller. The input speed_in is the current reference value for the engine, i.e.,the speed that it should provide. Then, the controller ensures that the desired speed will beprovided by the engine. The input angle_in is the angle that the BeBot shall reach.

Since the behavior models for continuous components are not part of MECHATRONICUML,we do not describe the behavior of MotionCtrl any further in this document.

6.3. Real-Time Statechart

In this section, we present in detail the complete behavior of the four atomic componentsExploration, Navigation, BeBot_Observer, and Collision_Control introduced in Section 6.2.2.Real-Time Statecharts specify the behavior of each component.

6.3.1. Exploration

The component Exploration controls the exploration of the environment by calculating newpositions for the BeBot, validating them via the component Collision_Control and sendingthem to the component Navigation. Figure 6.20 shows the Real-Time Statechart of Exploration.

Since it follows the standard structure for a Real-Time Statechart of a discrete component,it only consists of an initial composite state, Exploration_Main, whose parallel regions containthe Real-Time Statecharts of the component ports and one Real-Time Statechart namedInternalBehavior to synchronize them.

The Real-Time Statechart Exploration has three global variables: pos, target andpositionDataOk. pos stores the current position of the BeBot, target denotes the next


Exploration

Exploration_Main

InternalBehavior


Navigation_navigator

Delegation_master

DecideOnNextPosition


entry / {reset: c}

exit / {target:=playDice(pos);} {reset: c}

CheckPosition


entry / {reset: c}

driveComplete?

positionOk?

positionRejected?

[posDataOk] checkPosition!

4

3

2

1

operation int[2] playDice(int[2] currentPosition) clock c

channel checkPosition, positionOk, positionRejected, driveComplete, drive

variable int[2] pos, int[2] target, bool positionDataOk

2

1

Drive

PositionOk

drive!

Active



position / {pos:=position.xy; positionDataOk := true;}

2

Error[c_period ≥ 100 ms] / {posDataOk := false;}

1

position / {pos:=position.xy; positionDataOk := true;}

clock c_period

Stop

drive? / moveTo(target)

targetReached driveComplete! /

Go


invariant c_wait ≤ 150 ms

entry / {reset: c_wait}

checkPosition? /

check(target)

accepted positionOk! /

declined positionRejected! /

clock c_wait

2 1

Figure 6.20.: Real-Time Statechart of Component Exploration


target for the BeBot’s movement and positionDataOk is a boolean variable that describeswhether the position pos is up-to-date. Within the state Exploration_Main five channelsare declared: checkPosition, positionOk, positionRejected, which synchronize the regionsInternalBehavior and Delegation_master, driveComplete and drive, that synchronize theregions InternalBehavior and Navigation _navigator.

The logic of the bebot’s movement is modeled in the InternalBehavior region. When theposition data is up-to-date, the initial state DecideOnNextPosition is left and the transition tothe state CheckPosition is fired. When leaving the initial state, the next target for the movementis randomly chosen close to the current position of the BeBot, which is implementedby the call of the operation playDice(pos) as an exit event of DecideOnNextPosition.Furthermore, firing the transition from state DecideOnNextPosition to state CheckPositioncauses a synchronization to the Delegation_master region via the channel checkPosition. Thisprompts the region Delegation_master to check whether it is possible to move to the targetwithout colliding with other BeBots. The answer of this request is resubmitted to the regionInternalBehavior via the channels positionRejected or positionOk.

When a synchronization via channel positionRejected is received, the target is not safeand the InternalBehavior’s current state changes back to DecideOnNextPosition and this willeventually cause choosing a new target. When a synchronization via channel positionOk isreceived, the target is safe and the BeBot can move to it and the current state changes toPositionOk. The movement is requested by sending a synchronization via the channel drive tothe region Navigation_navigator. The InternalBehavior remains in state Drive until it receivesa synchronization via the channel driveComplete, which denotes that the chosen target wasreached. The InternalBehavior changes its current state to DecideOnNextPosition, where itwill eventually choose a new target.

As described in Section 6.2.1, the role receiver of Real-Time Coordination ProtocolPositionTransmission is assigned to the equally named port of this component so the Real-Time Statechart of region receiver is a refinement of the Real-Time Statechart of the role(cf. Figure 6.13). It is refined by adding assignments of positionDataOK. As long as theasynchronous message position is received from the Navigation component, positionDataOkis assigned to true, since the data is now up to date. This is denoted by the self-transitionof the initial state Active. If within 100 ms no message position is received, the positiondata is assumed to be no more up-to-date. Therefore the transition from Active to Error setsposDataOk to false. Furthermore, for the same reason as mentioned before, the posDataOk isset to true if in state Error the asynchronous message position is received.

The role navigator of Real-Time Coordination Protocol Navigation is assigned to the equallynamed port of this component, so the Real-Time Statechart of region navigator is a refinementof the Real-Time Statechart of the role (cf. Figure 6.3). We refine it by adding the receivingof a synchronization via channel drive to the transition from Stop to Go and the sending of asynchronization via channel driveComplete to the transition from Go back to Stop.

The role master of Real-Time Coordination Protocol Delegation is assigned to the equallynamed port of this component so the Real-Time Statechart of region master is a refinementof the Real-Time Statechart of the role (cf. Figure 6.6). We refine it by adding the


receiving of a synchronization via the channel checkPosition. The transition from Inactiveto PositionCheck uses in its raise message check the parameter target of checkPosition.Further, the lower prioritized transition from PositionCheck back to Inactive synchronizesvia the channel the positionRejected with the transition from the state CheckPosition to thestate DecideOnNextPosition in region InternalBehavior. The higher prioritized transitionsynchronizes via the channel positionOk with the transition from CheckPosition to PositionOk.

6.3.2. Navigation

The component Navigation transmits the current position to the components Exploration andBeBot_Observer and receives a target position from component Exploration. Furthermore, itcontrols the navigation to the target position. Figure 6.21 shows the Real-Time Statechart ofNavigation.

Since it follows the standard structure for a Real-Time Statechart of a discrete component,it only consists of an initial composite state, Navigation_Main, whose parallel regionscontain the Real-Time Statecharts of the discrete component ports and one Real-TimeStatechart named InernalBehavior to synchronize them. For the synchronization, the stateNavigation_Main declares the channels finished and go. These channels synchronize theregions Navigation_provider and InternalBehavior.

Moreover, a global integer array variable target, that stores the current target position, isdeclared. Besides, the hybrid output ports speed_target and turnAngle_target, and the inputport position are used. The signals of the hybrid ports can be accessed and modified by usingtheir port names in the Real-Time Statechart.

As described in Section 6.2.1, the role provider of Real-Time Coordination ProtocolNavigation is assigned to the equally named port of this component so the Real-TimeStatechart of region provider is a refinement of the Real-Time Statechart of the role (cf.Figure 6.4). It is refined by adding the sending of a synchronization via channel go to thetransition from Polling to Moving and the receiving of a synchronization via the channelfinished to the transition from Moving back to Polling.

The multi-role sender of Real-Time Coordination Protocol PositionTransmission isassigned to the equally named multi-port of this component so the Real-Time Statechart ofregion sender is a refinement of the Real-Time Statechart of the role (cf. Figure 6.12). TheReal-Time Statechart is refined by deleting the variable pos and setting the parameter valueof the message position at the transition from Idle to Sent in region sub-role-template to thehybrid port position. In this way the value of the input signal at port position is sent to allPositionTransmission-clients.

The region InternalBehavior models the actual movement strategy. It uses the operationcalcTurnAngle that calculates the angle between its input parameters currentPos and target.First, the BeBot turns by a certain angle in order to face the straight and direct way from itscurrent position to the target position. After that, it drives with a constant speed to the desiredlocation.

Navigation

InternalBehavior

Navigation_provider


Moving

3

1

channel finished, go

operation double calcTurnAngle(int[2] currentPos, int[2] target)

Polling

moveTo go! / {target := moveTo.xy;}

finished? / targetReached

Turn


entry / {turnAngle_target:=calcTurnAngle(position, target);}

{reset:c}

Stop

go? / Move

entry / {reset: c} {speed_target:=1;}

2

clock c


[position[0] == target[0] && position[1] == target[1]] finished! / {speed_target := 0;}

[c ≥ 1000 ms]


adaptation

sub-role-template

2

1

channel send[Role], done[Role]

Waiting


entry / {reset: c}

[c ≥ 10 ms] /

{curRole := first}Sending


[curRole <> last] done[curRole]? /

{curRole := curRole.next}

clock c

Idle send[self]? / position(position) Sent

done[self]!1

AwaitDone

send[curRole]! [curRole == last] done[curRole]?

Figure 6.21.: Real-Time Statechart of Component Navigation


Real-Time Statechart InternalBehavior defines three states: Stop, Turn, and Move.Starting in state Stop, the region InternalBehavior waits for a synchronization with theNavigation_provider via channel go. If it receives a synchronization, it switches to state Turn.Entering Turn, the angle between the target position and the current position is calculatedby calling calcTurnAngle and setting the output signal of hybrid port turnAngle_target tothe calculated value. Furthermore the clock c is reset. The MotionControl-component willnow adjust the angle of the BeBot relative to the coordinate system to the angle given byturnAngle_target. We assume that a complete turn needs at most 1000 ms. Therefore, theReal-Time Statechart stays exactly this amount of time in Turn until it changes its currentstate to Move. Entering Move, the hybrid port signal speed_target is set to 1, which causesthe MotionControl-component to adjust the speed to this value. When the position of theBeBot is equal to the target position, the Real-Time Statechart InternalBehavior synchronizeswith the Real-Time Statechart Navigation_provider via the synchronization channel finishedand the state Move is left to the initial state Stop. The synchronization via finished causesthe Navigation_provider to send the asynchronous message targetReached to the Exploration-component, which informs it about the arrival at the target.

6.3.3. BeBot Observer

The component BeBot_Observer is responsible for maintaining the positions of all BeBots inthe environment and for transmitting the positions of the other BeBots to Collision_Control.Figure 6.22 shows the Real-Time Statechart of BeBot_Observer.

Since it follows the standard structure for a Real-Time Statechart of a discrete component,it only consists of an initial composite state, BeBot_Observer_Main, whose parallel regionscontain the Real-Time Statecharts of the component ports. The BeBot_Observer does notneed any internal behavior, since the ports can synchronize each other and their is noneed for a superordinate behavior. Note that the Real-Time Statechart BeBot_Observerof Figure 6.22 contains the regions Distribution_client and Distribution_distributor, which isactually not correct, since a BeBot is either a client or the distributor, meaning that the Real-Time Statechart BeBot_Observer implements either the port client or distributor. Therefore,there should be two Real-Time Statecharts for the BeBot_Observer, one that implements theclient port and one that implements the distributor port. Since all other regions are not affectedby this, for the sake of simplicity these two regions are embedded in the BeBot_Observer.

The Real-Time Statechart BeBot_Observer defines three global variables: an integer arraymyPos, which denotes the current position of the BeBot, a two-dimensional integer arrayposArray, which stores the the current positions of all BeBots in the environment, and theboolean variable posDataOk, which specifies whether the position data stored in myPos isup-to-date.

For the synchronization of the ports senderand distributor, the regions AllPositionsTransmission_sender and Distribution_distributor shallsynchronize via the channel evalPos that is declared in BeBot_Observer_Main.

BeBot_Observer

BeBot_Observer_Main


AllPositionsTransmission_sender

Distribution_client

Distribution_distributor

4

3

2

1

channel evalPos

Distribution_client_Main

Blocked


[c ≥ 45 ms] [posDataOk] /

position(myPos)

Ready


entry / {reset: c}

positions evalPos! / posArray:= positions.posArray;

1

clock c

clock c 2

1receive

send

Ready


entry / {reset: c}

[c ≥ 50 ms] [posDataOk] /

position(myPos)

Blocked


[c ≥ 35 ms]

variable int[2] myPos, int[8][2] posArray, bool posDataOk := false

Active

invariant c_period ≤ 100


position / {myPos:=position.xy; posDataOk := true;}

2

Error

[c_period ≥ 100] / {posDataOk := false;}

1

position / {myPos:=position.xy; posDataOk := true;}

clock c_period

Active

evalPos? /

allPositions(posArray)

variable bool error:=false


adaptation

sub-role-template

2

1


clock c_period, c

Active

Waiting




{reset: c_period}

Sending


entry / {reset: c}

send[first]!

[c_period ≥ 50 ms][posDataOk] receive[first]?

Receiving


entry / {reset: c}

All_Received


entry / {reset: c}

[error] rcv_done?

2

1

variable int id

[not error] rcv_done?

send

receive

1

2

Idle

position receive[self]! / {posArray[id]:=position.xy;}

Receivedreceive[self]! / {error:=true}

2

1


[self==last] send_done![self<>last] send[self.next]!

12


[self<>last] receive[self.next]?12

EvaluatePosData send_done?evalPos!

Figure 6.22.: Real-Time Statechart of Component BeBot Observer


As described in Section 6.2.1, the role receiver of Real-Time Coordination ProtocolPositionTransmission is assigned to the equally named port of this component so the Real-Time Statechart of region receiver is a refinement of the Real-Time Statechart of the role(cf. Figure 6.13). It is refined by adding assignments of positionDataOK. As long as theasynchronous message position is received from the Navigation component, positionDataOkis assigned to true, since the data is now up-to-date. This is denoted by the self-transitionof the initial state Active. If within 100 ms no message position is received, the positiondata is assumed to be no more up-to-date. Therefore, the transition from Active to Error setsposDataOk to false. Furthermore, for the same reason as mentioned before, the posDataOk isset to true if in state Error the asynchronous message position is received.

The role sender of the Real-Time Coordination Protocol AllPositionsTransmission isassigned to the equally named multi-port of this component so the Real-Time Statechart ofregion sender is a refinement of the Real-Time Statechart of the role (cf. Figure 6.15).It is refined by adding the synchronization channel evalPos to the self-transition instate Active in order to synchronize with the client region or the distributor region,depending whether the BeBot is a client or the distributor. The synchronization causes theAllPositionsTransmission_sender region to send the current positions to the collision-control-component if and only if the variable posArray stores current data.

The multi-role distributor of the Real-Time Coordination Protocol Distribution is assignedto the equally named multi-port of this component. So the Real-Time Statechart of regionDistribution_distributor is a refinement of the Real-Time Statechart of the role (cf. Figure 6.9).It is refined by adding a guard [posDataOk] at the transition from Waiting to Receiving.This ensures that the distributor only starts collecting all the positions of the clients ifits own position data is up-to-date. Furthermore, the state EvaluatePosData is addedbetween the states Sending and Waiting. The transition between Sending and Waiting isreplaced by the transition from Sending to EvaluatePosData. Moreover, a transition fromEvaluatePosData to Waiting with synchronization channel evalPos is added. In this way, theDistribution_distributor region synchronizes with the AllPositionsTransmission_sender regionsuch that the positions of all BeBots are only transmitted to the collision control if they havebeen received from and sent to all client BeBots.

The role client of Real-Time Coordination Protocol the Distribution is assigned to the equallynamed port of this component, so the Real-Time Statechart of region Distribution_clientis a refinement of the Real-Time Statechart of the role (cf. Figure 6.10). It is refinedby adding the guard [posDataOk] to the transitions in the send region of the compositestate Distribution_client_Main. This ensures that the position data sent via the messageposition(myPos) to the distributor BeBot if it is up-to-date. Therefore, only current positioninformation is transmitted to the distributor and, hence, to all other client BeBots. Moreover,the synchronization channel evalPos is added to the self-transition of state Ready in thereceive region. This synchronization causes the region AllPositionsTransmission_sender totransmit the position data of all BeBots to the component collision-control only if it has beenreceived recently and is therefore up-to-date.


6.3.4. Collision Control

The component Collision_Control is responsible for avoiding collisions with other BeBots bydeciding whether a received target position from Exploration conflicts with the positions ofall other BeBots as received from the BeBot_Observer. Figure 6.23 shows the Real-TimeStatechart of Collision_Control.

CollisionControl

Collision_Control_Main

InternalBehavior

AllPositionsTransmission_receiver

Delegation_slave

3

2

1

clock c_period

clock c_work

channel checkPermission, granted, rejected

operation bool getApproval(int[2] target, int[8][2] posArray)

clock c variable bool permission

variable int[8][2] posArray, noPosData, int[2] target

Active



allPositions / {noPosData := false; posArray := allPositions.posArray;}

2Error[c_period ≥ 100 ms] / {noPosData := true;}

1

allPositions / {noPosData := false; posArray := allPositions.posArray;}


invariant c_work ≤ 100 ms

entry / {reset: c_work}

check checkPermission! /

{target := check.target}

granted? / accepted

rejected? / declined

21

Wait

checkPermission? /

{permission:=getApproval(target, posArray);}

[permission and not noPosData] granted!

[!permission or noPosData] rejected! 2

1PositionChecked

c ≤ 10 ms

entry / {reset: c}

Figure 6.23.: Real-Time Statechart of Component Collision Control

Since it follows the standard structure for a Real-Time Statechart of a discrete component,it only consists of an initial composite state, Collision_Control_Main, whose parallel regionscontain the Real-Time Statecharts of the component ports and one Real-Time Statechartnamed InternalBehavior to synchronize them. For synchronization, Collision_Control_Maindeclares the channels checkPermission, granted, and rejected. Moreover, the Real-TimeStatechart CollisionControl defines the variables posArray, a two-dimensional array that storesthe positions of the other BeBots and its own position, the boolean variable posData, that


denotes whether the position data of posArray is up-to-date, and the one-dimensional arraytarget, which stores the desired target of the Exploration component.

As described in Section 6.2.1, the role receiver of Real-Time Coordination ProtocolAllPositionsTransmission is assigned to the equally named port of this component so the Real-Time Statechart of region receiver is a refinement of the Real-Time Statechart of the role(cf. Figure 6.16). It is refined by adding the assignments for the variable noPosData to theReal-Time Statechart. The noPosData is set to false whenever the message allPositions isreceived, that is, at the self-transition of state Active and the transition from Error to Active. Ifin state Active no position data is received via the message allPositions within 100 ms, thenthe Active state is left via the transition to Error and the variable noPosData is set to true, sincethe position data of posArray is not up-to-date. These refinements ensure that the variablenoPosData describes whether the data of posArray is up-to-date.

The role slave of Real-Time Coordination Protocol Delegation is assigned to the equallynamed port of this component so the Real-Time Statechart of region slave is a refinementof the Real-Time Statechart of the role (cf. Figure 6.7). It is refined by adding thesending of a synchronization via channel checkPermission to the transition from Inactiveto PositionCheck. The receiving of synchronizations via channel rejected is added to thetransition from PositionCheck to Inactive and the synchronization via channel granted isadded to the transition from PositionCheck to Inactive. So the asynchronous messagesend by Delegation_slave depends on the result of the target-check that was made in theInternalBehavior region.

The region InternalBehavior defines the operation getApproval, which expects a one-dimensional int array as target and a two-dimensional position array containing BeBotpositions, and calculates whether it is permitted to move to the given target. Furthermore,it declares the boolean variable permission, which describes whether it is permitted to moveto a target. Moreover, the Real-Time Statechart contains two states. In the state Wait it waitsfor the synchronization via the channel checkPermission with the Delegation_slave region,which synchronizes when a desired target should be checked. When a synchronization isreceived, the transition from Wait to PositionCheck fires and the check of the target is executedby the call of the operation getApproval. The result is stored in the variable permission.Depending on the values of permission and noPosData it is allowed to move to the targetor not. Therefore, there are two transitions from PositionCheck back to Wait, which send asynchronization through the channel granted, if the BeBot can move to the target, or rejected,if it is not allowed to move.

6.4. Component Instance Configuration

In this section, we introduce the component instance configurations of our example. First, weshow in Section 6.4.1 the instance configuration for a single BeBot exploring the environment.In this case, the BeBot does not need to check for possible collisions with other BeBots.


Afterwards, Section 6.4.2 contains a description of component instance configurations forseveral BeBots exploring the environment.

6.4.1. Single BeBot

In this section, we introduce a component instance configuration for a single BeBot exploringthe environment in our example. That BeBot does not need to communicate with other BeBotsto avoid collisions because there are no other BeBots in this case.

Figure 6.24 shows a component instance of the type BeBot_SW that is not connected toother component instances of the type BeBot_SW. Consequently, it only has the continuousport instances speed_target, turnAngle_target and position that communicate with the motioncontroller.

b4 / bsw : BeBot_SW

:position

:turnAngle_target

:speed_target

Figure 6.24.: Concrete Syntax of a Component Instance of the Component Type BeBot_SWof a BeBot that is not Connected to other BeBots

Figure 6.25 shows the structure of the embedded component instances of the BeBot_SWof Figure 6.24. Since this BeBot does not communicate with other BeBots, it onlycontains the embedded component instances exp:Exploration and nav:Navigation that arespecified for the component type BeBot_SW in Figure 6.18. The component instancesexp:Exploration and nav:Navigation are connected by assembly connector instances that arederived from the Real-Time Coordination Protocols Navigation and PositionTransmission(cf. Figure 6.1). The discrete port instances navigator and receiver of the componentinstance exp:Exploration implement the single-roles receiver of the Real-Time CoordinationProtocol PositionTransmission and navigator of the Real-Time Coordination ProtocolNavigation. The discrete port instances sender and provider of the component instancenav:Navigation implement the single-roles sender of the Real-Time Coordination ProtocolPositionTransmission and provider of the Real-Time Coordination Protocol Navigation. Thehybrid port instances speed_target, turnAngle_target and position of nav:Navigation aredelegated to the continuous port instances of the same names of the lop-level componentinstance b4:BeBot_SW.

6.4.2. Networks of BeBots

In this section, we introduce component instance configurations for a BeBot for the case thatmore than one BeBot explores the environment. As described in Section 1.1, the BeBots


exp1 / exp

:Exploration nav1 / nav

:Navigation

:sender:receiver

:sender:receiver

:provider

:provider:navigator

:navigator

b4 : BeBot_SW

na1:Navigation

trans1:Position

Transmission

:turnAngle_target

:position

:position

:turnAngle_target

:speed_target:speed_target

Figure 6.25.: Concrete Syntax of a Component Instance Configuration of a Single BeBot

now have to exchange their position data to avoid collisions. In the following, we showone component instance configuration for the position distributor BeBot and one componentinstance configuration that applies for all client BeBots. Afterwards, we show how theseBeBot component instances have to be connected in our example.

In contrast to Figure 6.24, the component instances of the component BeBot_SW containadditional discrete ports for exchanging the position data. Figure 6.26 shows an instance ofthe discrete BeBot software for a BeBot operating as the position distributor for two clientBeBots. Figure 6.27 shows a component instance of the type BeBot_SW for a client BeBot.Both component instances implement different roles of the Real-Time Coordination ProtocolDistribution (cf. Figure 6.1).


distributor

d1:distributor

d2:distributor

:position

:turnAngle_target

:speed_target

Figure 6.26.: Concrete Syntax of a Component Instance of the Component Type BeBot

Component instance b1:BeBot_SW of Figure 6.26 has the two discrete port instancesdistributor1:distributor and distributor2:distributor that both implement the multi-role distributorof the Real-Time Coordination Protocol Distribution. Thus, this BeBot software executes the



client

:client

:position

:turnAngle_target

:speed_target

Figure 6.27.: Concrete Syntax of a Component Instance of the Component Type BeBot

behavior of a position distributor BeBot. Each of the two port instances is connected to a clientBeBot as shown in Figure 6.28.

Component instance b2:BeBot_SW of Figure 6.27 has a discrete port instance client thatimplements the single-role client of the Real-Time Coordination Protocol Distribution. Thus,this BeBot executes the behavior of a client to the position distributor.

In order to obtain a component instance specification for a BeBot, the component typeBeBot of Figure 6.17 must be instantiated and connected with other instances of typeBeBot. Figure 6.28 shows a component instance configuration consisting of the threecomponent instances of type BeBot, namely bebot1 : BeBot, bebot2:BeBot and bebot3:BeBot.bebot1:BeBot is the position distributor while bebot2:BeBot and bebot3:BeBot operateas clients. Thus, the assembly connector instances which are derived from the Real-Time Coordination Protocol Distribution connect the bebot2:BeBot and the bebot3:BeBot tobebot1:BeBot. The discrete port instances d1:distributor and d2:distributor of bebot1:BeBotimplement the multi-role distributor. The discrete port instances client of bebot2:BeBot andbebot3:BeBot implement the single-roles client.

Figure 6.28 also shows the embedded component instances of bebot1:BeBot:b1:BeBot_SW, ctrl/mo:MotionCtrl, and pd:PosData. The two discrete port instancesd1:distributor and d2:distributor of the component instance b1:BeBot_SW, that implementthe role distributor of the Real-Time Coordination Protocol Distribution, are delegatedto the discrete port instances distributor1 and distributor2 of bebot1:BeBot. Componentinstance ctrl_left:EngineCtrl and component instance ctrl_ right:EngineCtrl each have the twocontinuous port instances speed_in and speed_out. Component instance pd:PosData has thetwo continuous port instances pos_in and pos_out. The assembly connector instances betweenb1:BeBot_SW and ctrl_mo:MotionCtrl, b1:BeBot_SW and pd:PosData are not derived fromany Real-Time Coordination Protocol as they only connect continuous port instances.

Figure 6.29 and Figure 6.30 show the embedded component instances of the componentinstances b1:BeBot_SW and b2:BeBot_SW. Both component instances embed the componentinstances exp:Exploration and nav:Navigation as already explained for the component


b1 / bsw : BeBot_SW


:position

:speed_target

bebot1 : BeBot

:distributord2:distributor

ctrl / mo

: MotionCtrl

:speed_target :turnAngle_target

pd / pos : PosData

:pos_rawData:position

bebot2 : BeBot

:client

:client

bebot3 : BeBot

:client

:client

d1:distributor

:turnAngle_target

:pos_rawData

dist:Distribution

:speed_target :speed_target

Figure 6.28.: Concrete Syntax of a Component Instance Configuration of ThreeCommunicating BeBots

instance b4:BeBot_SW of Figure 6.25. b1:BeBot_SW and BeBot_SW additionally containthe component instances cc:Collision_Control and bbo:BeBot_Observer. An assemblyconnector instance derived from the Real-Time Coordination Protocol Distribution connectsexp:Exploration and cc:Collision_Control. The discrete port instance master of the componentinstance exp:Exploration implements the single-role master.

The discrete port instance slave of the component instance cc:Collision_Control implementsthe single-role slave. An assembly connector instance derived from the Real-TimeCoordination Protocol AllPositionsTransmission connects the cc:Collision_Control and thebbo:BeBot_Observer. The discrete port instance receiver of the component instancecc:Collision_Control implements the single-role receiver. The discrete port instance senderof the component instance bbo:BeBot_Observer implements the role sender. An assemblyconnector instance derived from the Real-Time Coordination Protocol PositionTransmissionconnects the bbo:BeBot_Observer and the nav:Navigation. The discrete port instance receiverof the component instance bbo:BeBot_Observer implements the single-role receiver. Thediscrete port instances s1:sender and s2:sender implement a sub-role of the multi-role,respectively.

The component instances b1:BeBot_SW and b2:BeBot_SW differ by the communicationto other component instances of the type BeBot_SW. b1:BeBot_SW of Figure 6.29 acts asa distributor. It communicates to other component instances of the type BeBot_SW via amulti-port that implements the multi-role distributor of the Real-Time Coordination ProtocolDistribution. In our example, b1:BeBot_SW has two discrete port instances d1:distributorand d2:distributor that implement the multi-role distributor. This implies that b1:BeBot


b1 / bsw : BeBot_SW

exp1 / exp

:Exploration

cc1 / cc

:Collision_Control

nav1 / nav

:Navigation

bbo1 / bbo

:BeBot_Observer

dist:Distribution.

distributor:receiver :sender

:slave

d1:distributord1:distributor


:slave

:receiver

:sender

:master

:master

:receiver


:receiver

:sender:receiver

:provider

:provider:navigator

:navigator

:turnAngle_target

:position :position

:turnAngle_target

na1:Navigation

trans1:Position

Transmission

trans2:AllPositions

Transmission

del1:Delegation


Figure 6.29.: Concrete Syntax of a Component Instance Distributor

can distribute data to two client component instances of the type BeBot_SW. A delegationconnector instance delegates these discrete port instances to the two discrete port instancesd1:distributor and d2:distributor of the component instance bbo:BeBot_Observer. Further, itimplements the multi-role distributor of the Real-Time Coordination Protocol Distribution.

Component instance b2:BeBot_SW of Figure (cf. Figure 6.30) has the discrete single-port instance client to communicate with another component instance of the type BeBot_SW.This discrete port instance implements the single-role client of the Real-Time CoordinationProtocol Distribution. A delegation connector instance delegates to the discrete port instanceclient of the component instance bbo:BeBot_Observer.


b2 / bsw : BeBot_SW

exp1 / exp

:Exploration

cc1 / cc

:Collision_Control

nav1 / nav

:Navigation

bbo1 / bbo

:BeBot_Observer

dist:Distribution.

client:receiver :sender

:slave

client

:client

:slave

:receiver

:sender

:master

:master

:receiver


:receiver

:sender:receiver

:provider

:provider:navigator

:navigator

:turnAngle_target

:position :position

:turnAngle_target

na1:Navigation

trans1:Position

Transmission

trans2:AllPositions

Transmission

del1:Delegation


Figure 6.30.: Concrete Syntax of a Component Instance Client

Chapter 7.

Related Work

MECHATRONICUML is a language for modeling and analysis of component-based softwaredesigns of reconfigurable mechatronic systems. As mentioned earlier, mechatronic systemscontain elements developed by different engineering experts, namely electrical, control,mechanical and software engineering. While MECHATRONICUML is mainly focused onthe software engineering aspects, it nevertheless reflects relationships to other engineeringdomains to some extend. Examples are continuous components to model controllers orhardware components for mechanical and electrical elements.

MECHATRONICUML especially focuses on the specification of real-time behavior forcomponents and ports, communication protocols adhering to real-time requirements, and run-time reconfigurations. As a consequence, related work stems from the following areas:• Specification languages for coordination protocols• Integrated specification languages for systems engineering. Examples are SysML,

Modelica, or MATLAB/Simulink with Stateflow.• Process models for systems engineering• Software Component Models for embedded real-time systems like ROBOCOP, SOFA-

HI, or Progress.• Specifications of reconfigurable systems. Examples are Architecture Description

Languages (ADLs) for self-* systems like Dynamic Wright.• Formal models for specifying real-time behavior. Examples are Timed Automata or

Time Process Algebras.In the following, we will discuss each area in detail. However, please note that the

discussion is subject to further extensions in future versions of this document.

7.1. Contract-Based Design

As there exist several definitions for contracts, we follow the definition of Giese et al. [GV03]that states: “A contract unambiguously describes the assumed and guaranteed syntactical,behavioral, synchronization, and quality-of-service characteristics of an associated componentinterface.”

In contrast to Szyperski [Szy98], we do not distinguish between provided and usedcontracts, because in our application domain it is often the case that a component port provides

157

158 CHAPTER 7. RELATED WORK

and uses contracts. This leads to cyclic dependencies between components resp. their portswhich easily lead to deadlocks and must therefore be synchronized [GV03].

7.1.1. Contract Levels

Beugnard et al. [BJPW99] define four levels to distinguish between the several kindsof a contract. In the following, we will briefly describe these levels and state howMECHATRONICUML supports these levels.

The most basic level is the syntactical level that specify the operations a component canperform, the parameters a component requires, and exceptions a component may raise. InMECHATRONICUML, we support this level by specifying a sender and receiver message typespecification for each port. Moreover, MECHATRONICUML allows to define a message buffersize.

The second level is the behavioral level. It describes pre- and post-conditions as wellas invariants. For example, Meyer [Mey92] defines in its programming language Eiffelpreconditions and post-conditions for methods, and invariants for classes. Preconditions musthold before the execution of a method, post-conditions hold after the method execution, andinvariants of a class hold in all states of the class. MECHATRONICUML supports this levelby defining a Real-Time Coordination Protocol for specifying all legal sequences of messageexchange between the two roles. This behavior is defined by one Real-Time Statechart perrole. Furthermore, preconditions, post-conditions, and invariants can be further restricted byadding guards, clock constraints, and clock invariants to each Real-Time Statechart. Usingformal verification techniques (e.g., the Uppaal model checker), additional conditions andinvariants can be proven.

The third level is the synchronization level. It defines the dependencies between methodslike sequences and parallelism. In MECHATRONICUML, this level is supported by usingsynchronization channels to synchronize the port-statecharts of an atomic component.Therefore, the order of consuming and sending messages can be synchronized. Moreover, aReal-Time Coordination Protocol between two ports of two components may send and receivemessages in parallel. This can be synchronized using synchronization channels, too.

The forth level is the quality-of-service level. It covers aspects like availability, throughput,and latency. MECHATRONICUML currently allows to specify the connector-assumptionsmessage latency and message loss. A Real-Time Coordination Protocol that is used at thisconnector has to be compliant to these assumptions.

7.1.2. Automata Models for Supporting the Contract Levels

In the following, we present automata models that support at least the syntactical and thebehavioral level for specifying component contracts. First, we will present existing untimedautomata models. A second section for presenting timed automata models will be provided ina future release of this document.

7.1. CONTRACT-BASED DESIGN 159

7.1.2.1. Untimed Automata Models

De Alfaro and Henzinger propose Interface Automata [dAH05] that are defined asformalized rich message-based interfaces for software and hardware components. Theseautomata allow to check if two components are compatible with each other with respectto syntactical and behavioral characteristics. They further enriched these automataby synchronicity, fairness, resources [CdAHS03], permissiveness [HJM05], and real-time constraints. Therefore, they support the four levels of contracts. In contrast toMECHATRONICUML, they do not allow the reconfiguration of the automaton at run-time.modeled explicitly, which violates the separation of concerns.

I/O automata [LT87, LSV01] enable to specify the interfaces of concurrent and distributedevent systems that communicate synchronously. The behavior of each system component ismodeled by one flat I/O automation. An I/O automation is an automaton with action labelson each transition. They support three types of transition actions: inputs, outputs, and internalactions. Inputs and outputs are used to communicate with the other components; internalactions may only be executed within a component. The external communication happensinstantaneously. Inputs can not be blocked, thus the actions of the environment can not beblocked nor ignored. Therefore, the communication is synchronously. An output actions ishandled as a broadcast. An I/O automata may be non-deterministic. I/O automata enableto verify that certain trace properties are fulfilled or not fulfilled. They enable both, safety(nothing bad happens) and liveness (something good eventually happens) trace properties. Toconclude, they only support the syntactical and the behavioral level.

Team Automata [tBEKR03] are an extension of I/O automata. They only support thesyntactical and the behavioral level. They support formal verification regarding safety andliveness properties.

Component-Interaction Automata [BCVZ05] focus on the component-interaction, butalso on the synchronization. Thus, this automata definition supports the syntactical, thebehavioral, and synchronization level. They support formal verification regarding safety andliveness properties.

7.1.3. SPEEDS

Benveniste et al. [BCF+08] define mathematical foundations and the design methodology ofa contract-based model development for their framework that was developed in the SPEEDSproject. Their field of application is the embedded system design. They focus on consistencyand compatibility. In contrast to MECHATRONICUML that only focuses on the applicationlayer, they defined a contract layer that contains the functional layer, the ECU layer, andthe hardware layer. Like MECHATRONICUML, they use timed automata for describing theprotocol behavior, too. Moreover, they use refinement relations to weaken the assumptionsand strengthen the guarantees. Though, they do not focus on an automatic and scalableverification. Furthermore, they do not consider the reconfiguration of the protocol at run-time.


7.2. Behavioral ConnectorsIn MECHATRONICUML connectors specify a communication behavior using Real-TimeCoordination Protocols. This behavior must be implemented by the connected ports. Therelated work to this topic is presented in the following.

7.2.1. Higher-Order Architectural Connectors

Lau and Wang [LWF03] developed a notion of higher-order architectural connectors that takeother connectors as parameters. Therefore, they allow to compose connectors by services likeprotocols for asynchronous buffered message communication and fault-tolerance mechanisms.Their goal is to improve the reuse and the incremental development of connectors and to easecreating complex protocols.

In MECHATRONICUML, assemblies are linked with pre-defined Real-Time CoordinationProtocols. These protocols specify the state-based behavior of each role and define quality ofservice parameters like delay and message loss. The reusability of a Real-Time CoordinationProtocol is limited, because it assumes concrete timing-requirements. Though, we developeddesign patterns for our Real-Time Coordination Protocols [DHT12] to increase the reusabilityof reoccurring design problems regarding the protocol specification. Currently, there exists noapproach to compose a Real-Time Coordination Protocol by other Real-Time CoordinationProtocols. In contrast to Lau and Wang, MECHATRONICUML supports the reconfiguration ofthe connector at run-time.

7.2.2. Reo

The exogenous coordination language Reo [ABRS04, Arb06] enables the compositionalconstruction of component connectors. The authors have developed constraint automata tospecify the behavior of Reo connectors. The specification of components that are usingthe connectors for cooperation and communication is not the focus of Reo. Therefore,Reo regards them as black-box-components. MECHATRONICUML also supports theintegration of black-box-components, but the standard case are white-box-components. Asin MECHATRONICUML, component instances of Reo are running in parallel and do not knowthe component instances they are communicating to, but only that they comply to the protocol.

In the following, we will compare the the connector definition of MECHATRONICUML andReo. An assembly instance in MECHATRONICUML specifies the communication betweenexactly two component instances. But in Reo, a connector specifies the communicationbetween two or more component instances by composing atomic connectors (they are calledchannels and connect exactly two component instances) to hierarchical connectors. Amongothers, Reo channel support synchronization, asynchronous communication, buffering,ordering, computation, data retention, and data loss. Except of synchronization andcomputation, MECHATRONICUML also supports these services. Like MECHATRONICUML,Reo connectors do not inspect or change the communication content.

7.3. MULTI-AGENT-SYSTEMS 161

As in MECHATRONICUML, each connector of Reo is linked to a certain Real-TimeCoordination Protocol. Though, they have different semantics. In MECHATRONICUML,Real-Time Coordination Protocols have roles that specify the communication behavior aconnected port has to implement. Therefore, the connector has no own coordination behaviorbut assumes certain QoS-characteristics like message loss and message delay. In Reo,the connector has an own executable behavior specification that is described using theaforementioned constraint automata.

7.3. Multi-Agent-Systems

In the area of multi-agent systems, there exists the FIPA-ACL standard for describingthe agent communication [Fou02], which is based on speech-act theories and ontologies.A framework for this is Jade [BBCP05]. With AgentUML [BMO01], one can describecommunication patterns. These are reusable protocols that can be described in protocoldiagrams. Such diagrams extend UML sequence diagrams by agent roles, parametrizedlifelines, and concurrent lifelines. However, a formal analysis is not possible. Multi-agentsystems focus on autonomous problem-solving components. Though, they do not focus on thedevelopment of the network that is necessary for their communication or on the integration ofother mechatronic disciplines like control engineering.

7.4. Specification Languages for Systems Engineering

There are several specification languages for systems engineering that allow holistic andintegrated modeling of mechatronic systems. A recent survey on these approaches can befound in [GH06]. In the following the most related work to our approach is discussed.

7.4.1. SysML

SysML is an acronym which stands for Systems Modeling Language. It is developed by aninformal association of tool vendors and industry leaders, which firm under the name SysMLPartners1. The standard is currently available in SysML version 1.2 [Gro10a].

SysML is defined as a UML 2.x Profile which extends, reuses, refines, and tailors UML.SysML extends UML by requirement diagrams and parametric diagrams. Parametric diagramscan show mathematical relationships between parameters or variables of a block. SysMLreuses the UML concept of state machine, use case and sequence diagrams2. The syntax andsemantics of SysML activity diagrams is refined [JDB09].

SysML is developed to use model-based and driven systems engineering (MBSE,MDSE)[Fea98]. SysML addresses the holistic systems engineering development. SysML focuses

1http://www.sysmlforum.com2http://www.sysmlforum.com/faq/relation-between-SysML-UML.html

http://www.sysmlforum.com

http://www.sysmlforum.com/faq/relation-between-SysML-UML.html


on holistic modeling of mechatronic systems while MECHATRONICUML focuses onspecification and formal analysis of the discrete hard real-time software especially forsafety critical applications in software intensive distributed systems. Although, we modelthe integration with the remaining system elements, they are not included in our modelsat that level of detail. A “block" in SysML can be compared with a component inMECHATRONICUML. A main difference is that in SysML a “block” can be either a softwareor a hardware element and in MECHATRONICUML a component is always a software element.Since SysML is based on UML it inherits the problem of imprecise semantics from UML[HKRS05] in contrast to MECHATRONICUML which has well defined syntax and semantics.

7.4.2. MATLAB/Simulink Stateflow

MATLAB is a tool suite for computing in systems engineering [Col07]. Simulink is a toolboxfor graphical model-driven development of dynamic continuous and discrete systems, likean anti-lock brake system3. The system which should be developed can be constructed,dimensioned, simulated, and analyzed with Simulink. The goal is a model of a system whichrepresents its dynamic system behavior. A modeller models graphically block diagrams that“depicts time-dependent mathematical relationships among the system’s inputs, states, andoutputs”4.

Simulink block diagrams have a causal signal flow, which means that there is for eachsignal output a defined signal source and a time-dependent mathematical relationship. InMECHATRONICUML an atomic software component is the corresponding element of aSimulink block. An atomic component is in contrast to a Simulink block an independentunit, which encapsulates its functionality and behavior.

Stateflow is a toolbox which extends Simulink by a finite state machine concept (FSM). Thetoolbox enables modeling of event-based reactive behavior specifications. The Stateflow finitestate machines have concepts for hierarchical and parallel states and support the modeling ofcontrol flow as transitions between these Stateflow states. MATLAB functions can be invokedas actions when e. g. a state change is performed.

In contrast to MECHATRONICUML it is tedious to model asynchronous message-basedcommunication protocols with real-time requirements [HPR+12]. Although, message-poolsor buffers as described in Section 3.4.9 are not supported in Stateflow. The output eventsof Stateflow can only be used to exchange information between different Stateflow blockswithout the buffering by the Stateflow receiver block. As a consequence the event is lostif the receiver doesn’t directly use the received events and cannot be used to synchronisesystems. Message-buffering is very useful for the coordination of distributed mechatronicsystems, as they cannot coordinate via shared variables, because they are physically separated.Nevertheless, it is possible to encode asynchronous message-based communication with a

3http://www.mathworks.de/products/simulink/examples.html4http://www.mathworks.de/help/toolbox/simulink/ug/f7-5734.html

http://www.mathworks.de/products/simulink/examples.html

http://www.mathworks.de/help/toolbox/simulink/ug/f7-5734.html

7.4. SPECIFICATION LANGUAGES FOR SYSTEMS ENGINEERING 163

tedious combination of several linked Simulink and Stateflow blocks, but this is hard tomaintain [HPR+12].

Further, Stateflow has only features for simple temporal logic operators, like the after()and before() operators. It is only possible to specify the time elapsed since activation of theassociated state. Stateflow has no special constructs to specify clock variables which areindependent of special states and make it possible to mesarue time intervals since their lastreset like in Real-Time Statecharts.

Besides modeling features MATLAB/Simulink Stateflow provides simulators with solversfor ordinary differential equations (ODE). They support the discrete-time and continuous-time simulation of Simulink models. They offer to use variable time-step and fixed time-step integration methods. Further, code generators makes it possible to generate platformspecific target code. For example TargetLink [KTS01] from the dSPACE company supportsthe generation of code for a couple of embedded real-time platforms. MECHATRONICUMLcan benefit from these features as they can be mapped to MATLAB/Simulink Stateflow.Currently, we are working on an automatic transformation from MECHATRONICUML toMATLAB/Simulink Stateflow.

7.4.3. ModelicaModelica is a free object-oriented modeling and simulation language. The goal is to modelphysical phenomena with ordinary and differential algebraic equation, hierarchical systemstructures with a connection mechanism, and discrete system behavior with discrete events.The model can be automatically converted to sorted assignment statements as they are usedin standard programming languages like C to simulate the system model [Elm78]. Thelanguage targets systems from the domain of “. . . mechatronics, including cars, aircrafts andindustrial robots which typically consist of mechanical, electrical and hydraulic subsystemsas well as control systems.”[EMO99] The language itself is independent of a concretesimulation environment. Modelica models consist of compositions of sub-models connectedby connections that represent energy flow (undirected/ acausal) or signal flow (directed/causal) [Fri04]. Modelica is inspired by mathematics and uses the concept of declarativeprogramming by using equations.

Modelica does not contain a separated state-based modeling language like Stateflow orReal-Time Statecharts. It contains the library StateGraph2 which provides blocks to modelstate-based behavior [OME+09]. This is similar to statechart elements which would berepresented as UML classes. A concrete statechart is like a UML object diagram. As aconsequence for each state and also for each transition a separate object exists which canbe parametrised to encode e. g. guards. The resulting models have more objects than classicalstatecharts. Therefore, they are tedious to model and hard to maintain. Furthermore, likein Stateflow, it is very difficult to model asynchronous message-based communication anddiscrete behavior with real-time behavior.

Before Modelica code can be simulated it is compiled to some intermediate code, usually Ccode. This in turn will be compiled to machine code and executed together with a numerical


ordinary differential equation solver or differential algebraic equation solver to produce asolution for variables as a function of time. Currently, we are also working on an automatictransformation to Modelica to simulate MECHATRONICUML models in interaction with otherparts of a mechatronic system.

7.4.4. CHARON

CHARON is a high-level modeling language and design environment for embedded systems[ADE+01]. It allows for hybrid modeling, that is to model discrete as well as continuoussoftware for the embedded systems. It supports hierarchical composition in architecture and inbehavior. CHARON was developed at the Department of Computer and Information Scienceof the University of Pennsylvania under the direction of Rajeev Alur, with last activities in2003.

For hierarchical architecture, components are described as agents. Composition,instantiation, and hiding is possible. The hierarchic behavior is described as modes, which arebasically hierarchical state machines. Exceptions and history retention are supported. Eachmode describes a continuous behavior, modelled with analog variables that flow continuouslyduring continuous updates that model passing time [ADE+01]. The evolution of an analogvariable can be constrained by differential constraints, algebraic constraints, and invariants.Switching modes is possible with discrete control over the modes.

CHARON provides a formally defined semantics and a refinement definition. The semanticsis implementable because transition are non-urgent and in [AIK+03] time delays are assumedfor sensing, computation, and execution.

Predicate abstraction is used to apply a finite state model checking approach to hybridsystems. Compositional model checking like in MECHATRONICUML is possible due to theformal refinement definition. There was also research in accurate and efficient simulationtechniques.

In contrast to MECHATRONICUML reconfiguration as defined in [HPB12] is not possible.

7.4.5. Masaccio/Giotto

Masaccio [HMP01] is a high-level modeling language for hybrid system models (containingdiscrete as well as continuous parts) with the focus on formal verification against requirements.Giotto [Hor03] is a high-level programming language with the focus on schedulability analysisagainst resources. Both languages were developed within the project FRESCO (Formal REal-time Software COmponents) at the EECS of the University of California at Berkeley.

Masaccio allows the parallel and serial composition of components with arbitrary nesting.An atomic component can be either discrete or continuous. Formal verification of the real-timehybrid models is supported due to the formal semantics. A refinement definition exists basedon assume-guarantee reasoning. Thus, Masaccio supports compositional model checking likeMECHATRONICUML.

7.5. PROCESS MODELS FOR SYSTEMS ENGINEERING 165

Pure Giotto programs can be synthesized from a Masaccio model. It is a time-triggeredprogram with real-time semantics and consists of tasks, modes, and mode switches. Theprogram is annotated with information about platform, scheduling, and communication.Giotto can be compiled to a given platform to be executed on a virtual machine. Given apartially annotated Giotto program, the compiler can determine the missing information basedon schedulability analysis.

In contrast to MECHATRONICUML reconfiguration as defined in [HPB12] is not possible.

7.5. Process Models for Systems Engineering

A process model for the development of mechatronic systems is defined by the VDI2206 process which is a specialized adaptation of the V-model for mechatronic systemsdevelopment [VDI04b]. Based on the VDI 2206, the collaborative research centre SFB 614created a new process model for mechatronic systems development [GFDK09a].

7.6. Software Component Models

Following the definition of Lau, "the cornerstone of any component-based developmentmethodology [Szy98] is its underlying component model, which defines what components are,how they can be constructed and represented, how they can be composed or assembled, howthey can be deployed and how to reason about all these operations on components" [Lau06].

Lau and Wang [LW07] and Crnkovic et al. [CCSV07, CSVC11] survey software componentmodels and classify them according to common characteristics. They do not restrictthemselves to component models for a specific domain. However, Crnkovic et. al. [CSVC11]distinguish between general purpose component models, like e.g. CORBA or EJB, andspecialized component models for particular domains. According to this survey, approaches inthe second category usually aim at either business information systems or embedded real-timesystems. Since MECHATRONICUML targets the development of reconfigurable mechatronicsystems that adhere to real-time constraints, we will focus on component models supportingreal-time systems or run-time reconfiguration or both. The survey by Hošek et. al [HPB+10]exclusively focuses on component models of the latter kind.

A major influence for MECHATRONICUML is UML2 [Gro10b] which is reflected by thename of the language. MECHATRONICUML adopts concepts, terminology, and parts of itsconcrete syntax from the UML and enriches them with semantics and additional languagefeatures for the development of mechatronic systems. Since UML lacks formal semanticsas well as features for specifying the real-time constraints of embedded systems, it cannotbe used directly for developing the software of a mechatronic system. In literature, thereis no consensus whether UML is a component model. While [LW07] regards UML 2 as acomponent model, [CSVC11] does not. Following the definition presented above, UML lacks


the ability to reason about the operations on components and, therefore, often not consideredto be a component model.

A second major influence during the development of MECHATRONICUML wasROOM [SGW94], an object-oriented development methodology for real-time systems.The structure and behavior definition of ROOM are, as a result, very similar toMECHATRONICUML. In ROOM, a system is composed of actors which are defined by actorclasses. An actor specifies a port through which it may interact with other actors. Theinteraction is based on message exchange, the messages are defined by a protocol class. Actorscan be composed hierarchically of other actors. Then, the contained actors can interact bycreating bindings between their ports, ports of a contained actor are delegated to the outsideworld by using relay ports. The behavior of each actor is defined by a ROOMChart which isa variant of Harel statemachines [Har87]. In contrast to MECHATRONICUML, ROOMChartsonly support simple timer events, but no clock concept. In ROOM, each actor defines aset a data classes which are used to store information. ROOM supports a reconfigurationconcept by using replicated actors and replicated ports which are similar to multi-partsand multi-ports of MECHATRONICUML. The behavior of a hierarchical actor is definedby a special behavior component which also executes the reconfiguration. In contrast toMECHATRONICUML, ROOM does not provide a formal specification of replication actions,no controller integration, and no formal verification approach covering the real-time behaviorand reconfiguration. Support for developing with ROOM was included in several CASE tools,most notably RationalRose Real-Time, implementing ROOM as a UML 1.4-profile calledUML-RT [GS04]. Despite having had large influence on current approaches, ROOM was notexplicitly aimed at supporting component-based development and is not included in any of thesurveys mentioned above.

In the following subsection, we will present further related work on component models.First, we discuss related work on component models for business information systemssupporting run-time reconfiguration in Section 7.6.1. Thereafter, we present related workon component models for embedded and real-time systems in Section 7.6.2. We omitrelated work on component models for business information systems not supporting run-timereconfiguration, because they do not support the two core feature of MECHATRONICUML,which are real-time behavior and run-time reconfiguration.

7.6.1. Component Models for Business Information SystemsSupporting Run-Time Reconfiguration

The reconfiguration approach of MECHATRONICUML is inspired by the reconfigurationconcepts of Fractal [BCL+06] which have been extended to distributed executionin [BHR09]. In Fractal, components consist of a so-called membrane providingcontrol interfaces and a content area containing embedded components. The membranecontains controllers that delegate interfaces to embedded components and performreconfiguration. In [BHR09], the membrane is extended by a non-functional port to receive

7.6. SOFTWARE COMPONENT MODELS 167

reconfiguration calls. Reconfiguration operations are specified using a textual language calledFScript [DLLC09]. We adopted the concepts of a reconfiguration executor and of non-functional ports. We extended the remote reconfiguration invocation significantly. In contrastto their approach, we support a higher level modeling language for modeling reconfigurationrather than implementing it as a script. THINK [AHJ+09] provides a C-implementation ofthe Fractal component model which targets embedded real-time systems. THINK allows toannotate non-functional properties at architectural elements and defines a reconfiguration viewfor components. The necessary code for executing reconfiguration is provided by their codegeneration framework. They distinguish two conditions for quiescent states which are at avery low-level of abstraction and not directly applicable to MECHATRONICUML.

SOFA 2.0 [HP06, HPB+05] is a component model for business information systems. LikeMECHATRONICUML, it supports the definition of hierarchical components as well as theirreconfiguration at runtime. Runtime reconfiguration includes creating and deleting componentinstances and connector instances as well as interfaces of components.

7.6.2. Component Models for Embedded and Real-Time SystemsOne of the component models with the highest practical relevance in the domain of embeddedreal-time systems is the AUTomotive Open System Architecture (AUTOSAR )[GbR08,FMB+09]. AUTOSAR is an open industry standard for the development of automotivesystems. The standard is in ongoing development by all major automotive OEMs and theirsuppliers as well as other partners. AUTOSAR based systems can be developed with a lot ofdifferent tools like Vector DaVinci, dSPACE SystemDesk, Etas ASCET or Artop. Artop is animplementation of the common base functionality of AUTOSAR which is based on Eclipse.It is available for free for all AUTOSAR members. Like MECHATRONICUML, AUTOSARdefines a concrete development methodology and a component model. Components can beconnected via different ports specified by AUTOSAR Interfaces. AUTOSAR distinguishesbetween client-server Interfaces for set of operations and sender-receiver Interface for data-oriented communication. Specifying component behavior is out of the scope of AUTOSAR.Therefore, external tools like Matlab Simulink are required. In MECHATRONICUML, thebehavior specification is integrated in the development methodology and can be done throughthe use of Real-Time Statecharts.

EAST-ADL2 [CFJ+10] is an architecture description language for embedded systems. Itprovides modeling support for the system architecture, system requirements, variability interms of product line support, and an error model describing how errors propagate througha system. Requirements can be traced across the different levels of abstraction and phases.Each component references a behavior and may reference an external implementation, e.g., inSimulink. On the design level, EAST-ADL2 enables to specify a network of electronic controlunits (ECUs) and an allocation of software components to ECUs. On the implementationlevel, EAST-ADL proposes the use of AUTOSAR [GbR08, FMB+09] for representing theconcrete software architecture providing an automatic mapping of ADL components toAUTOSAR components. In contrast to MECHATRONICUML, EAST-ADL2 provides no


integrated support for specifying and verifying behavior, especially communication behavior.In addition, they do not support run-time reconfiguration.

SOFA-HI [PWT+08, PKH+11] is an extension of the SOFA 2.0 component model forembedded real-time systems which is specified as a profile of SOFA 2.0 (cf. Section 7.6.1).SOFA-HI adds the ability to model real-time behavior of components to SOFA 2.0, butit restricts the reconfiguration capabilities of SOFA 2.0. SOFA-HI supports run-timereconfiguration only by replacing components by other components. Component instancesmay also be replaced by a newer version of the component which still implements all necessaryinterfaces. In contrast to MECHATRONICUML or SOFA 2.0, modifications of the architecture,i.e. creating and deleting components and connectors, are not supported.

OpenCOM v2 [CBG+04] is a programming model for component-based development ofembedded systems. It supports primitive as well as composite components and enables toprogram run-time reconfiguration based on a reflective meta-model. Since it is a programmingmodel, it does not utilize models for specifying the structure and behavior of the system.Especially reconfiguration is not modeled. Consequently, the approach provides no analysesof the specified behavior, which is a major disadvantage compared to MECHATRONICUML.However, OpenCOM has been used to build the reconfigurable RUNES middleware fornetworked embedded systems [CCM+05].

SaveCCM is the component model of the SaveCCT component technology whichprovides a component-based development of embedded automotive software [ÅCF+07]. TheSaveCCM component model consists of components, switches, and assemblies. Componentsspecify a set of ports. The approach distinguishes between data ports that provide data tobe read or written and trigger ports that activate a component. As long as they are notactivated, components remain passive. A component is implemented by a C-function orseveral interacting tasks implemented in C. Switches enable to change the interconnectionof components. They specify guard conditions which cause data or control flow signals tobe delivered to another component. Assemblies are a hierarchical composition of connectedcomponents and switches. "An assembly generally does not satisfy the requirements ofa component" [ÅCF+07], but it provides a means for hierarchical structuring. SaveCCMsupports two types of connections: immediate connections that are loss-less with no delayand complex connections that may have information loss and delays. The formal semanticsof a SaveCCM model is defined by timed automata. Formal verification is achieved by amapping to timed automata and finite state process models. An implementation of SaveCCTis given by the Safe-IDE [SPCH08]. In contrast to MECHATRONICUML, SaveCCM doesnot support complete hierarchical components, message-based communication and structuralreconfiguration.

The commercial Rubus component model [HMTN+08] for embedded real-time softwarefor vehicles, which is developed by Arcticus Systems, is based on the same foundations asSaveCCM [ÅCF+07]. As in SaveCCM, components specify data and trigger ports with thesame semantics as in SaveCCM. The component model distinguishes between assemblies andcomposites. Assemblies are un-dividable units of deployment whereas composites consistof parts that may be deployed to different ECUs. As in SaveCCM, neither assemblies nor


composites are considered as components. Rubus uses so-called modes which define a modeof operation, e.g., initialization or shut-down. A mode applies to one ECU, only, and definesthe executed behavior. The supported real-time annotations cover deadlines, offsets and periodjitter for components. The approach enables to specify models in a graphical syntax. Formalverification and simulation are supported. In contrast to MECHATRONICUML, the approachdoes not consider complete hierarchical components, message-based communication andstructural reconfiguration.

CompoSE [KKTS09] is an approach for modeling embedded systems based using severalmodeling languages from different domains. It is based on a host language that is defined by acomponent model supporting basic and hierarchical components. The approach supports threekinds of unidirectional ports: flow ports (comparable to signals), event ports (asynchronousevents), and control flow ports. By using special guest language components, it is possible tointegrate components which a realized in other languages as, e.g., Simulink. In [ASTPH11],a reconfiguration approach based on CompoSE is introduced. There, each component hasa set of configurations. In a basic component, a configuration consists of a combinationof ports as well as a computation that defines its behavior. In a hierarchical component,a configuration consists of a combination of ports as well as a configuration of containedcomponent instances. A reconfiguration switches between these predefined configurations.Reconfiguration is only triggered based on the quality of the flow signals and it doesnot consider a fading or flat switching [OMT+08] between to output ports. In contrastto MECHATRONICUML, the approach does not consider message-based communicationprotocols or changing communication topologies.

MyCCM-HI [BFHP09] is a component model for embedded real-time systems that is basedon the Lightweight CCM standard which is now part of the OMG Corba Component Model(CCM, [Gro11b]). In contrast to MECHATRONICUML, models for MyCCM-HI can only bedefined using a textual syntax, not in a graphical IDE. These models are, on the one hand,used for direct C code generation of the application code and, on the other hand, they aretransformed into models of the architecture analysis and design language AADL [SAE09]for generating a middleware for the system. Special focus is put on the specificationanalysis of mode changes where the system switches between different configurations. Theapproach, however, does not consider reconfiguration of hierarchical component structures ora distributed execution of the reconfiguration.

Robocop [Maa05] is a robust component model for consumer electronic productsdesigned by ITEA project. The project targets the development of “an open-component-based framework for the middleware layer in high-volume embedded devices that enablesrobust and reliable operation, upgrading and extension, and component trading [Maa05].”MECHATRONICUML in contrast targets the development of the application layer in embeddeddevices. Robocop offers a infrastructure in form of frameworks for design, build, trade, andupdate of middleware. They provide a development-, a run-time-, a download-, and a resourcemanagement-framework. Robocop defines a component as a collection of model/view andrelations between these models. Anything which hold aspect information about a componentis called a model. Robocop differs the development level from the executable level of


components. At the development level the modeler defines the collection of models/viewson a component and the executable level the modeler defines explicit dependencies, dynamicthird party binding, and a lifecycle properties of a component. The executable componentmodel is based on OMG CORBA and Microsoft COM. An application at run-time consistsof a composition of several executable components and the Robocop run-time environmentwhich takes care of the creation component lifecycle. Interfaces define required and providesservices. In contrast to MECHATRONICUML the concrete development of components andsupport for a development language, a methodology, and tool support is out of scope inRobocop.

PECOS [GCW+02] is a component model for embedded real-time software of field-devices. Field-devices are devices which control local actors, e.g., valves, or monitor theirenvironment by collecting sensor values. A PECOS component can only be deployed on asingle hardware node. PECOS distinguishes so-called Active, Passive and Event Components.Active components run in an own thread, passive components do not have an own thread,and event components reacts on external triggers, like time ticks or interrupts from hardwarecomponents. Components have ports to get input data and ports to write output data. Incontrast to MECHATRONICUML, connected ports do not interact via messages. They havea shared memory with read and write access. A PECOS component is either directlyimplemented via C++/Java or it is composed of other components. PECOS does not supporthierarchical component types directly, but it offers the possibility to specify templates whichcontains abstract components which can be later filled with concrete components. Themodeller has to specify for each component a cycle time, which determines in which intervalthey have to be scheduled, and a worst case execution time (WCET), which specifies themaximum time that the execution of a component needs. As cycle time and WCETs are notplatform independent, the PECOS component model is also not platform independent likeMECHATRONICUML. PECOS uses Petri nets to represent the execution model of compositecomponents and to reason about real-time constraints and to generate schedules which meetdeadlines. The instance configuration of components, ports and connectors is fixed at compiletime. Therefore, components, ports, or connectors cannot be created or destroyed at run-timeto reconfigure the software. PECOS is not actively developed anymore and provides onlyincomplete tool support [HPB+10].

A component model for consumer electronic software developed by Philips isKoala [vOvdLKM00]. Koala supports a separation of components from the configurationdevelopment in one model. The component model differs between base components thatrealize functions and compound components, embedding other components. Both aredescribed by a component description language. Components are connected through requiresand provides interfaces, whereas each requires interfaces must be connected with one providesinterfaces. Furthermore, there are also option and diversity interfaces as well as switches,which are used for system configuration. The assemblies are fixed at compile time, so thatrun-time reconfiguration is not supported. In contrast to MECHATRONICUML, the systemconfiguration is done within the component model. Therefore, interfaces and switches areused to initialize components on the one hand and for component binding on the other hand.


BlueArX [KKHH08] is a component model developed by BOSCH for describing enginecontrol systems in the automotive domain. The component model defines atomic componentswhich have an implementation as well as structured components. The latter can consist ofseveral other atomic or structured components. The communication between componentsis accomplished by using import and export interfaces which defines global variables andaccess properties. The software behavior of components is described by signal flowswhich can depend on modes. These flows can be visualized for whole systems to foster abetter understanding of dependencies of interfaces. In MECHATRONICUML, the behaviorspecification can be done through the use of Real-Time Statecharts which allow a specificationof the internal component behavior and Real-Time Coordination Protocol for communicationbehavior. Modeling control flows are also supported by history elements, entry points, andexit points in the Real-Time Statecharts.

The ProCom [VSC+09, BCC+08] component model, developed within the Progressresearch center, targets the development of automotive applications. It defines two layersof components: on the lower-level layer passive components are defined, each offering a setof services that can be called through a "triggering port". The higher layer, on the other hand,consists of active components representing concurrently running subsystems, communicatingwith asynchronous messages over channels. Thus, this higher layer of ProCom is quite similarto our own notion of components, while we do not currently consider anything correspondingto the lower layer. For ProCom a prototypical Eclipse-based IDE is available, however[HPB+10] notes that analysis methods and deployment tools are not yet implemented.ProCom uses a behavior model called REMES [SVP09, VSCS10], which, like our Real-TimeStatecharts, is a hierarchical state-based language semantically relying on timed automata.Contrary to MECHATRONICUML, resource usage is explicitly modeled and analysed, usinga mapping to "priced" timed automata and a variant of the tool UPPAAL [BDL04] for modelchecking them. However, explicit support for dynamic reconfiguration is not provided.

Pin [HIPW05] is a component model for embedded real-time systems. Components consistof a container and a custom code section. The container is prefabricated by the frameworkand provides the interfaces of a component. The custom code is the user-specified componentbehavior which is modeled by UML Statecharts [Obj09]. The custom code must only specifyinterfaces to the container. Components are connected by assemblies which employ eithersynchronous or asynchronous communication. The assemblies are fixed at design time, i.e.,run-time reconfiguration is not supported. In contrast to MECHATRONICUML, the real-timebehavior is provided by an underlying, commercial run-time environment and not part of themodeling language.

COMDES-II [KSA07] provides a generative programming [CE00] approach to thedevelopment of components for embedded real-time systems. COMDES-II uses activehierarchical components that interact by exchanging messages as in MECHATRONICUML.The behavior specification is done, on the one hand, at the level of operating system tasksand explicitly considers the timing, scheduling, and execution times. On the other hand,function blocks implement the behavior of the tasks. Function block may contain non-


real-time state-machines as well as continuous controller implementations. In contrast toMECHATRONICUML, COMDES-II does not support run-time reconfiguration.

7.7. Specifications of Self-Adaptive Systems

In this section, we discuss related from the area of self-adaptive systems. Related work inthis area mainly originates from the research on architecture description languages (ADLs).First, we discuss the relationship of MECHATRONICUML to several reference architecturesin Section 7.7.1. Second, we relate MECHATRONICUML to modeling approaches for self-adaptive systems in Section 7.7.2. Finally, we introduce several run-time framework for self-adaptive systems in Section 7.7.3.

7.7.1. Reference Architectures for Self-Adaptive Systems

In the domain of mechatronic systems, Hestermeyer et. al introduced the operator-controller-module (OCM) as a reference architecture [HOG04]. The OCM consists of three layers: thecontroller, the reflective operator, and the cognitive operator. The controller layer containsall controllers of the mechatronic system that react to sensor inputs and produce actuatoroutputs. The elements of this layer are captured by continuous atomic components inMECHATRONICUML. The reflective operator monitors and reconfigures the controller layer.It operates event-based and adheres to hard real-time constraints. On this level, interactionbetween components that mandatory for the controllers are exchanged. The components ofthe reflective operator can be specified by MECHATRONICUML. On the top-most level, thecognitive operator is responsible for planning and self-optimizing the system operations. Thislevel operates in soft real-time, the communication between systems may be specified byMECHATRONICUML.

In [IBM06], IBM introduces the autonomic computing architecture also known as MAPE-K. In mainly targets the domain of business information systems although it was inspired byrobotic system designs. The lowest level contains the running system which is then managedby one or more autonomic managers. The autonomic managers implements an "intelligentcontrol loop" [IBM06, pg. 10]. It consists of the four steps monitor (M), analyze (A), plan (P),and execute (E). The autonomic manager monitors the running system, analyzes the monitoreddata, uses planning to determine whether a reconfiguration is needed to improve the systemsoperations, and finally executes the reconfiguration plan. In addition, the autonomic managermay use a knowledge source (K) which stores and provides domain knowledge which isgathered and used by the aforementioned steps. In this architecture, MECHATRONICUMLwould mainly be used for monitoring and executing the reconfiguration. Analysis andplanning is supported in a simple way by the manager of a structured component. Long-term planning operations, however, are not specified by MECHATRONICUML. In [HM08],Huebscher and McCann survey different applications of and contributions to MAPE-K.

7.7. SPECIFICATIONS OF SELF-ADAPTIVE SYSTEMS 173

Kramer and Magee describe a three layer reference architecture for self-adaptive systemsin [KM07]. The bottom layer is the component control layer where the functional/operationalbehavior of the system is located. The middle layer is the Change Management Layer wherechange operations are located that change the structure of the component control layer. Thechange management layer either reacts to events from the lower level or it reacts to goalchanges from the upper level. The upper level is the goal management layer where the goals ofthe system are managed and long-term planning and AI algorithms are located which computea solution on how to reach the goals. The architecture is similar to the OCM architecture. InMECHATRONICUML, we only consider the two lower levels which we distinguish for eachstructured component.

Caporuscio et.al. provide a meta-architecture for self-adaptive systems and a threelayer run-time architecture in [CFG10]. The meta-architecture is based on requirementswhich the application needs to fulfill during run-time. It contains monitors for sensing theenvironment and the application itself thereby producing run-time models of both. A decisionmaker ensures that the application meets its requirements and generates respective actionsto manipulate the application which are executed by an actuator. This is very similar toMAPE-K. The run-time architecture consists of three layers: implementation layer, proxylayer, and description layer. The description layer contains the models of the applicationand the environment as well as reconfiguration operation definitions. The implementationlayer contains the components that implement the systems functional behavior. Thesecomponents have a virtuals representation at the description layer. The proxy layer connectsthe implemented components with their virtual counterparts on the description layer. Areconfiguration changes the application model on the proxy level, the proxy level then choosesand executes the specific operations which need to be executed on the implementation level.The implementation is based on OSGi [All11].

In [WMA10], Weyns et. al. introduce the FORMS reference model for self-adaptivesystems. FORMS is a formal reference model which is formalized using Z. In the model,a self-adaptive system is embedded into an environment. It consists of several base-levelsubsystems and reflective subsystems. The base-level subsystems contain the functionalbehavior, the reflective subsystems manage (a set of) base-level subsystems and/or reflectivesubsystems. This is similar to atomic and structured components of MECHATRONICUML.Each base-level subsystem has a domain model representing the data, each reflectivesubsystem maintains a model@runtime using reflection for reasoning about and changingthe underlying subsystems. The authors show that they can model the MAPE-K architectureusing their approach.

In [DDF+06], Dobson et.al. survey approaches and research challenges for connecting self-x systems using a network topology. Their survey only treats the lower networking layersand discusses, e.g., the design and analysis of physical networks as well as trust and securityissues.


7.7.2. Modeling of Self-Adaptive Systems

In this section, we discuss modeling languages and methods for developing self-adaptivesystems that originated from the research area of architecture description languages (ADLs,[SG96]). An architecture description language defines the constituents of a software systemand their interconnections. In case of MECHATRONICUML, the architecture is given by thecomponent model.

A proposal for an ontology for ADLs which we also use in this section was given byGarlan et.al. [GMW00]. They defines the following terms: a component is the building blockof the architecture (although the term is less strictly defined as for component models), aconnector defines the interaction of components, a system is a configuration of componentsand connectors, a property defines extra-functional properties and corresponding analysistools, a constraint defines restrictions that the architecture needs to fulfill while it evolves,and styles are families of related systems.

A general approach towards the development and specification of self-adaptive systems ispresented in [ZC06]. There, an adaptive program consists of several state-based programsand an adaptation set that defines transitions between these programs. Using the adaptationset, the adaptive program may switch between the programs during run-time. In contrastto MECHATRONICUML, the approach does not explicitly use a component model, butMECHATRONICUML uses some of the presented ideas such as separation of the state-based programs and the adaptation behavior or the usage of quiescent states for adaptation.In [ZGC09], a modular verification approach for such systems is introduced which has asimilar objective as the compositional verification theorem introduced by Giese [Gie03].

In [GH04, RC10, RC09], several design patterns for self-adaptive system are introduced.These design patterns assume a separation of functional and adaptation behavior which isalso used by MECHATRONICUML. [RC10] classifies the patterns into monitoring, decision-making and reconfiguration patterns. Several patterns regarding decision-making andreconfiguration have been used for the design of reconfiguration in MECHATRONICUML.

Modeling languages for the specification of dynamic software architectures are surveyedin [BCDW04]. The survey investigates especially the modeling expressiveness of differentmodeling languages. The survey identifies four main classes depending on the formalsemantics of the approach. The considered classes are: graph transformation based languages,process algebra based languages, formal logics based languages, and languages that definean own semantics without using one of the aforementioned formalisms. Based on thisclassification, MECHATRONICUML belongs to the graph transformation based languages.

In the following subsections, we will investigate related work using the same classes as usedin [BCDW04]. Finally, we discuss run-time frameworks that enable adaptation of a software.

7.7.2.1. Graph Transformation based Approaches

There are several approaches for modeling dynamic software architectures via graphtransformations. Since MECHATRONICUML is also based on a graphs and reconfigurations


are specified by corresponding graph transformations, the approaches in this section are closestto MECHATRONICUML regarding the modeling of reconfiguration.

The approaches by Le Métayer [LM98] utilizes a graph grammar with terminal andnonterminal symbols whose production rules are specified as graph transformations. Thegrammar specifies an architectural style while the elements of the defined language arearchitectures. For runtime reconfiguration, the approach uses a special coordinator componentwhich executes all system reconfigurations. The reconfiguration operations are specified asgraph transformations. A verification procedure ensures that a valid architecture may onlybe transformed into another valid architecture w.r.t. the architectural style. The coordinatorcomponent is comparable to the reconfiguration execution controller of MECHATRONICUML.In contrast to Le Métayer, there does not exist a central instance executing all reconfigurationsof the system, but each structured component has its own reconfiguration controller.

The approach by Hirsch et. al. [HIM98] uses edge-labeled hypergraphs to represent softwarearchitectures. They use a graph grammar with three sets of rules for modeling architecturesand their evolution. The first set of rules defines the creation of a valid architecture. Thesecond set of rules defines the runtime evolution of the architecture. The third set of rules isused to coordinate the communication of components. The approach does not need a centralcontroller, but does not specify when to execute which reconfiguration.

The approach by Taentzer et. al. [TGM00, Tae02] differentiates between a network graphcontaining the system nodes and local graphs for each of the nodes. A change to a local graphrepresents a local change inside a node, a change of the network graph represents a changeof the system structure. The reconfiguration operations are specified by double pushout graphtransformation rules [EEPT06]. They consider quiescent states as proposed in [KM98], butthey do not specify a logic which determines when to execute which reconfiguration.

A special case of a graph transformation based approach is the Chemical Abstract Machine(CHAM, [IW95]). In CHAM, a system is called a solution which consists of severalmolecules. A solution may be transformed into another solution by applying a chemicalreaction rule. As in MECHATRONICUML, there exists an initial solution and a set ofreconfiguration rules specified a reactions. In contrast to MECHATRONICUML, there is noexplicit control on when to execute which reconfiguration.

CommUNITY [WF02, WLF01] uses components and connectors to define a systemarchitecture based on an architectural style. The system consists of componentsand connectors, each of them executes a CommUNITY program. Components mayinteract synchronously and asynchronously. The architecture is represented by a graph,reconfiguration is modeled by graph production rules that transform one architecture intoanother one. The approach supports basic reconfiguration commands to add and removecomponents as well as connectors. Basic reconfiguration commands are combined intocomposite commands and scripts that extend the basic commands by control flow includingconditions (if-then-else) and loops [WLF01]. Scripts define callable units of commands thatmay be called by the system or by users. The approach uses a textual syntax for programs andreconfigurations and does not consider real-time constraints. The textual scripts are translated


to formal graph production rule by on double pushouts automatically. An implementation ofCommUNITY not supporting reconfiguration is introduced in [OW07].

The approach by Kacem et.al. [KKJD06, KKJ12] uses UML 2.0 components to specifya system architecture and defines profile classes for modeling reconfiguration operations.The reconfiguration operations are guarded by OCL constraints and are specified by simplegraph transformation rules in a notation that uses the concrete syntax of UML componentdiagrams. That is similar to the concrete syntax of component story diagrams used byMECHATRONICUML, but the approach does not support control flow. Their model includesinvariants for the architecture in terms of OCL constraints. They translate their specificationinto in Z specification [Spi92] to prove that their architecture fulfills all invariants. Finally, theygenerate aspect code [KLM+97] out of the Z specification for implementing reconfiguration.Their approach, however, does not consider hierarchical components or real-time propertiesof the reconfigurations.

In [BG08], Becker and Giese identify several requirements to modeling approaches forself-adaptive systems. In MECHATRONICUML, we consider all these except modelingreconfiguration on different levels of abstraction. In their approach, the system architecturefollows the one proposed in [KM07] which distinguishes a component layer, a changemanagement layer, and a goal management layer. They use UML Class diagrams [Obj09]to model the system structure and story diagrams [FNTZ00a] to model behavior formally.On the component layer, story patterns are used. On the change management layer andgoal management layer, story diagrams are used. This is similar to MECHATRONICUMLwhich uses component story diagrams for modeling reconfiguration. They use the inductiveinvariants approach [BBG+06] for verifying their approach. Since their approach is basedon plain graphs, it does not necessarily preserve component encapsulation and it does notconsider quiescent states.

Bruni et. al. [BBGM08] summarize concepts and terms concerning dynamic softwarearchitectures and map them to a unifying framework based on typed hypergraph grammars.The considered terms are programmed dynamism, self-repairing, self-adaptive, ad-hocdynamism and constructible dynamism. Based on these terms, MECHATRONICUMLprovides a mixture of programmed dynamism where reconfiguration are preprogrammedat design time and self-adaptive behavior where reconfigurations are triggered based on achanging environment. The considered system model is component-based, a graph definesa configuration of the system and rules define the evolution of the system architecture.The approach distinguishes between reachable configurations and acceptable configurations.Regarding the application of a reconfiguration, the authors distinguish between constrainedand unconstrained reconfiguration as well as self initiation and external initiation of thereconfiguration. In a constrained reconfiguration, a reconfiguration may only be executedif architectural constraints are satisfied or the components are in a quiescent state. In thatsense, MECHATRONICUML provides constrained reconfiguration with self initiation.

All of the mentioned approaches share the problem that they do not consider real-timeaspects of reconfiguration. That means, they neither restrict the execution of reconfigurationto a specific time interval nor consider the time needed for executing the reconfiguration.


7.7.2.2. Process Algebra based Approaches

Approaches which utilize process algebras include Darwin [MK96], LEDA [CPT99],PiLar [CdlFBS01], Dynamic Wright [ADG98], and the approach by Bartels andKleine [BK11].

Darwin [MK96] is based on the π-calculus [MPW92]. In Darwin, reconfiguration is reducedto lazy instantiation of components and switching between several pre-defined connections,called bindings. Lazy instantiation means that a component is not loaded before its firstusage. Switching between predefined connections is achieved by flags which indicate thecomponent whose output is to be used (cf. [KM98]). In contrast to MECHATRONICUML, it isnot possible to load or unload components during run-time. The specification of componentsis also restricted to flat components. The specification of behavior and reconfiguration doesnot respect real-time properties.

In [GMK02], Darwin components are extended by a run-time architecture. A run-timecomponent consists of the component implementation, a configuration view, and a componentmanager. The component implementation contains the functional behavior of the componentand specifies the interfaces of the component. The configuration view maintained by eachcomponent contains a model@runtime of the whole system which is updated via broadcastevents after each reconfiguration. The configurations managers of each component performreconfiguration of the overall system (to avoid a single point of failure when using a centralreconfiguration manager). Then managers ensure that architectural constraints hold. Incontrast to MECHATRONICUML, the approach violates component encapsulation and doesnot support structured components.

LEDA [CPT99] is also based on the π-calculus and provides a hierarchical componentmodel in which components may be assembled by embedding instances of other components.In LEDA, each component implements a set of roles which may be used to connectcomponents with each other. During run-time, new components may be instantiated andexisting connections, called attachments, may be changed. The definition of attachmentscan be conditional, i.e., the current attachment depends on an if-then-else conditions. Bychanging the flags in the condition, the attachment may be changed during run-time. Sincecomposite components are assembled from instances of other components, LEDA provides noclear distinction between types and instances of components like MECHATRONICUML. Thereconfiguration capabilities of LEDA are comparable to MECHATRONICUML, but neitherbehavior nor reconfiguration respect real-time properties.

PiLar [CdlFBS01, CR10] uses a component-based approach which distinguishes singlecomponents and composite components which is similar to MECHATRONICUML. A singlecomponent is a collection of interfaces while a composite component is a configuration ofcomponent instances. Like MECHATRONICUML, PiLar explicitly distinguishes componenttypes and their instances. The external behavior of components is specified by constraintswhich are modeled by using the process algebra CCS (Calculus of CommunicatingSystems, [Mil82]). PiLar supports the creation and deletion of component instances andconnectors during run-time [CdlFBS01]. In addition, PiLar supports replacing a component


by a newer version during run-time thereby updating the type and all it’s instances [CR10].The adaptation operations are specified by constraints in terms of CCS as well. Thus,PiLar provides similar reconfiguration capabilities as MECHATRONICUML. In contrast toMECHATRONICUML, Pilar mixes component types and instances in different layers of thesystem. A component instances may occur on different layers within the system while theirrespective type is always part of the next higher level. Thus, types and instances may becontained in the same layer.

Dynamic Wright [ADG98] specifies architectures by architectural styles that define aset of flat component types and connector types which connect the components. Thebehavior of components and their ports is specified by CSP (Communicating SequentialProcesses, [Hoa85]). They provide a separation of port behavior and component internalcomputations which is comparable to the MECHATRONICUML component behaviorspecification. The definition of connectors, that specify two roles, is comparable to Real-Time Coordination Protocol. Dynamic Wright allows for creation and deletion of componentsduring run-time. In addition, connections between components may be changed by usingattach and detach operations. Reconfigurations are specified is a CSP-based textual language.Like in MECHATRONICUML, each component has an initial configuration and a set ofreconfiguration operations.

In [BK11], Bartels and Kleine introduce a CSP-based framework for the specification ofadaptive systems. The approach suggests a three layered system specification. On the firstlevel, adaptive behavior and functional behavior are specified separately in terms on CSP-processes. Then, they use the CSP-refinement definition for deriving a implementation ofthe adaptive behavior on Level 2 and a complete system implementation on Level 3. Eachconfiguration of the system is represented by a process which is guarded by a booleanpredicate. They implement adaptation by changing the variables used in the predicates.All processes may be verified on their own, but also in combination with other processes.In contrast to MECHATRONICUML, the framework does not allow to structure a systemhierarchically. For implementing reconfiguration, MECHATRONICUML uses a differentapproach by modifying the existing configuration instead of switching to a different processexecuting a new configuration. MECHATRONICUML, however, shares the idea of separatingfunctional and adaptation behavior.

Khakpour et.al. introduce PobSAM (Policy-based Self-Adaptive Model) for modelingself-adaptive systems in [KJT+11]. A system consists of managed actors implementingthe functional behavior of the system and autonomous managers that perform run-timeadaptation. Both behaviors are specified by policies that are defined using the processalgebra CA. Managers and actors interact via events which trigger the application of apolicy. The managers may add and remove actors as well as connections. In contrastto MECHATRONICUML, actors and managers cannot be composed hierarchically and theapproach does not consider real-time properties.

All of the process algebra based approach share that they define the architecture as well asthe reconfiguration operations in a textual syntax.


7.7.2.3. Formal Logic based Approaches

Aguirre et al. [AM02] define a declarative language for the specification and reasoning ofreconfigurable component-based systems. Components are represented by classes, units ofmodularization that contain data and behavior. Connectors, called “associations”, are definedby participants and a set of synchronization actions. The defnintion of hierachical subsystemsis supported. Properties over the system are defined a temporal logic for reactive systems[MP92] with extensions, e.g., a starting point in time. A calculus enables the reasoning abouteach level of subsystem.

Gerel by Endler et al. [EW92] is a language for the specification of selection forumlas onreconfigurations and reonconfiguration preconditions. The system consists of program andconfiguration components. Program and configuration components are types in the sense ofcommon types as used in MECHATRONICUML that can be nested. The program is specifiedusing a programming language, e.g., C++, that is extended by a common set of embeddedcommunication primitives and interaction interfaces to other components. An interface is a setof ports described in a common Interface Specification Language. Configuration componentsare constructed from interconnected instances of program and/or configuration components.The properties described in Gerel allow reasoning about the reliability of the reconfiguration.

These two appraoches [AM02, EW92] use a textual language to describe their system.The Restore Invariant Approach by Nafz et al. [NSS+11] provides a method to give

guarantees for the behavior of self-organizing systems. The most important concepts of thesystem behavior are specified using the Safety Analysis and Modeling Language (SAML)[GO10]. In SAML the system is described by finite state automata. These automata areexecuted synchronously with discrete time steps. State variables are updated according totransition rules. Transitions contain non-determinism and probabilistic choice. Constraints inthe form of predicate formula specify unwanted system states - the invariants. Thus a corridorfor the correct behavior of the system is defined. In the Restore Invariant Approach the systemstarts a self-organization whenever an invariant is violated such that the behavior stays in thecorridor defined by the invariants. Reconfiguration is applied in the form of role changes froma set of predefined roles that describe tasks in the system, e.g., tighten screw.

This approach uses a graphical model to specify the most relevant parts of the systembehavior.

In all approaches, constraints on the reconfigurations are specified formally to allowreasoning about the correctness or reliability of the reconfigurations is enabled.

7.7.2.4. Approaches Defining an Own Semantics

Acme by Garlan et.al. [GMW00] is an ADL with the intension to serve as a unifyingbasis for previously developed ADLs like Darwin or Wright. It uses components andconnectors to define systems and provides the possibility to annotate non-functional propertiesand design constraints for components. A design constraint defines structural propertiesfor the architecture using the Armani constraint language [Mon01]. Acme provides no


behavior definition on its own. Reconfiguration of Acme architectures is given by thePlastik extension [JBCG05]. It allows to specify conditions using Armani which enablethe execution of a reconfiguration. Reconfigurations are specified on the architecture levelusing Acme expressions and are mapped to reconfiguration scripts on the run-time level. Thereconfiguration operations are then executed by calls to the API of the OpenCOM componentmodel which provides an execution environment. The specifications in Acme, Armani, andPlastik rely on a textual syntax and enable to change the whole system architecture. Acme andPlastik, however, provide no support for hierarchical reconfiguration and real-time properties.

The approach by Chen et. al. [CHS01] provides adaptation for layered architectures andhas originally been designed for an adaptive network stack. The approach uses adaptivecomponents whose adaptation is controlled by an component adaptor module (CAM). TheCAM may switch seamlessly between several adaptation-aware algorithm modules (AAM)that provide different algorithms for solving the same task. The adaptation decision is basedon fitness-functions that rate for each AAM how suitable it is in the current situation. Theoverall coordination of the system is managed by an adaptation controller. In contrast toMECHATRONICUML, the approach by Chen et. al neither supports loading or unloadingof components nor allows reconnecting components during run-time. The use of a centraladaptation controller for the whole system is also not suitable for MECHATRONICUMLbecause it violates the encapsulation of the components. The adaptation controller, however,is comparable to the reconfiguration module of structured components.

Rainbow by Garlan et al. [CGS06] is a framework for the development of systemsthat improve themselves during run-time based on monitored system properties. So-calledstrategies for self-adaptation are specified by the textual language Stitch [CG12]. Adaptationis specified by operators that represent basic configuration commands. These operators areused to construct adaptation strategies.

7.7.3. Run-Time Frameworks for Self-AdaptationIn [DAO+11], Derakhshanmanesh et. al. introduce a run-time adaptation framework based ontyped attributed graph transformations. The framework consists of a middleware providingaccess to the adapted software, a run-time model layer maintaining a graph-based modelof the software, and an adaptation management layer storing the reconfiguration rules andcontrolling their application. The proposed architectural elements of the framework are similarto manager and executor used in MECHATRONICUML. In contrast to MECHATRONICUML,the framework is not component-based and it is implementation driven.

The framework by Vogel and Giese [VG10] proposes to use several models of the adaptivesystem at different levels of abstraction at run-time. Each model addresses a specific concern,e.g., performance or system failures. For each concern, several models at different levelsof abstraction may exist, e.g., a low-level one for performing the structural changes and ahigh-level one for reasoning about the system. They use triple graph grammars[Sch95] forsynchronizing the models and define a refinement between the different models that ensuresthat changes on abstract models are properly reflected on the more concrete ones. Using such

7.8. FORMAL MODELS FOR MODELING OF REAL-TIME BEHAVIOR 181

an approach would be a legal extension to the manager which only maintains a low-levelmodel of the components.

In [MBG+11], Ma et.al. introduce a framework for run-time reconfiguration that supportsa transactional semantics for distributed reconfigurations. If a reconfiguration affects severalcomponents in the system, the reconfiguration is either performed completely or all changesare rolled back. The framework only applies reconfiguration to a system element if it is in aquiescent state in which reconfiguration is safe.

7.8. Formal Models for Modeling of Real-time Behavior

This section covers formal models for the modeling of real-time behavior. Depending on theirrepresentation of time these models are sub-divided into two categories. The first categorycovers models that represent time as a sequence of discrete steps or ticks. This time model iscalled discrete time model. The second category contains models that are based on a notionof time which assumes that time is continuously increasing. Here, time is modeled as thepositive real numbers. This time model is called continuous or dense time model. For adeeper insight in time models the survey paper by [FMMR10] presents alternative definitionsof time and its specification in models. Following the provided classification of time, Real-Time Statecharts are based on a dense time domain, i.e., the values of the clock are elements ofR. As in UPPAAL, the time model is a metric time model that supports quantitative propertiesexplicitly referring to values of clocks.

7.8.1. Discrete time models

In [EMSS91] the authours use temporal structures to describe real-time behavior. Temporalstructures consist of states, a transition relation and a labeling function that labels the stateswith atomic propositions. Time is added to these temporal structures by the assumption thatevery transition represents one time step. An obvious shortcoming of this model is that if morethan one time step passes during the transition from one system state to another auxiliary stateshave to be introduced to mimic this passing of time.

In the paper [Lam05] with the provoking title Real-time model checking is really simpleLeslie Lamport introduces explicit-time descriptions. These descriptions are no newformalism to describe real-time behavior but rather a generally applicable concept to extendexisting formalisms and languages with time. The idea is to introduce a variable now thatrepresents time and a Tick action that increments now to represent the passage of time.Furthermore, lower time bounds for certain actions are expressed by allowing these actionsonly if now has a value greater than the bound. Upper time bounds are expressed by notallowing an action if the action would increment now such that the upper bound would beviolated. Lamport argues that explicit-time descriptions have the advantage that no newformalism has to be introduced for dealing with real-time. This, in turn, enables the re-useof existing theoretical frameworks, proofs and model checkers. The concept can deal with


discrete as well as with dense time where in a discrete time model the Tick action wouldincrement now by 1 and in the dense model by any positive real number.

7.8.2. Dense time modelsA common modeling formalism for the modeling of real-time behaviors are timedautomata [AD90] which have been applied successfully in the past. Concerning the semanticsof timed automata there is a broad variety of different interpretations. A thorough and recentsurvey over different kinds of timed automata is given in [WDR11]. MECHATRONICUMLitself utilizes the semantics of timed automata as implemented by the UPPAAL tool [BY03].In [DMY02b], the timed automata used by UPPAAL are extended to hierarchical timedautomata that are closest to the Real-Time Statecharts used in MECHATRONICUML. Inaddition to the concepts of hierarchical timed automata, Real-Time Statecharts support timeconsuming transitions as well as periodic do-actions for states.

In [HA05], a formalism called interface duration automata is presented. Several of theseautomata might communicate by sending and receiving actions when performing a transition.The time instants when a transition might be performed is restricted by attaching a timeinterval [l, u] to each transition where l and u are positive real numbers. These bounds areevaluated with respect to a configuration (s, d) where s is a state and d a positive real numberdescribing how long s has been active since the last time it was activated. A transition canbe performed if l ≤ d ≤ u. For these automata the authors present an algorithm for decidingthe emptyness problem to which the reachability and safety problem can be reduced. Theauthors argue that the most important advantage of the formalism is that it can be checkedfor emptyness with a complexity nearly the same as for the untimed case. Furthermore, theyclaim that altough their formalism is simpler then timed automata a lot of real-time systemscan be modeled and verified with it.

In [MFR06], a model checking approach is presented that uses CSP-OZ-DC, a combinationof concurrent sequential processes (CSP) [Hoa85], Object-Z (OZ) [Smi00] and durationcalculus (DC) [ZH04] to specify real-time systems. The part consisting of CSP and OZrepresents the system model and the DC part represents the specification. The semanticsof the model and the specification is defined by a mapping to phase event automata (PEA),a variation of timed automata that supports communication over events and variables withinfinite data domains.

Other approaches for modeling real-time behavior include timed process algebras like, e.g.,timed CSP [Oxf92].

Chapter 8.

Conclusions and Future WorkWe find a growing number of mechatronic systems in our world today. They facilitate ourlives by performing tedious and exhausting tasks like housework. Mechatronic systems likeair planes or high-tech trains make the world seem smaller by letting us move longer distancesin shorter times. A large part of these systems’ functionality is implemented by softwaremaking mechatronic systems smarter and more flexible. However, the use of software in suchsystems poses great challenges on software developers. The developers must guarantee anabsolutely correct software that satisfies the safety requirements of the mechatronic system.This challenge is growing continuously as mechatronic systems, and of course their software,become increasingly complex. As a consequence, developers require an elaborate designmethod for the development of the software of mechatronic systems. This method is providedby MECHATRONICUML.

MECHATRONICUML comprises a modeling language and a process that provides astrategy to work with the modeling language. In this technical report, we focus on theplatform-independent design of the software of mechatronic systems and in particular on theMECHATRONICUML component model and the message-based real-time coordination. Thereal-time coordination is specified using Real-Time Coordination Protocols. They enable thecompositional verification of arbitrary large systems with respect to safety properties.

We implemented a tool that supports the MECHATRONICUML design method in form ofa plugin for Eclipse1, which is available for download from our website2. Our tool includesformal verification with the UPPAAL model checker3 and export to MATLAB/SimuLink andStateflow4 for simulation.

The BeBot running example (we refer to [Dre11] for a detailed presentation) as wellas an industrial case study [Rie11] show that MECHATRONICUML is appropriate forthe model-driven development of safety-critical mechatronic systems – in particular forsystems of autonomous mechatronic systems. The compositional verification approach ofMECHATRONICUML has been successfully evaluated in [GST+03].

Several parts of MECHATRONICUML, which already exist, are currently not includedin this technical report. We plan to include these topics in future versions. For now,

1www.eclipse.org2https://trac.cs.upb.de/mechatronicuml3http://www.uppaal.org/4www.mathworks.com

183

www.eclipse.org

https://trac.cs.upb.de/mechatronicuml

http://www.uppaal.org/

www.mathworks.com

184 CHAPTER 8. CONCLUSIONS AND FUTURE WORK

we refer the interested reader to the related publications. We published a catalog ofReal-Time Coordination Protocols in [DBHT12, PDM+14]. The integration of softwareengineering with control engineering has been described in [HSST13]. The semanticsof a previous version of Real-Time Statecharts have been formally defined in [GB03].Code generation from MECHATRONICUML models has been presented in [BGS05].Furthermore, MECHATRONICUML supports the reconfiguration of component structureseither by embedding component structures in states [GBSO04] or by specifying operationalrules based on the graph transformation formalism [THHO08, EHH+13, HB13, ZH13].Finally, MECHATRONICUML supports a component-based hazard analysis approach [GT06,PSWTH11, PST13].

In the future, we plan to integrate MECHATRONICUML with domain-spanning techniquesfor systems engineering, i.e., CONSENS [GFDK09b] and SysML5. This integration requiresto consider domain-specific and platform-specific modeling and allocation. We furtherplan an extension of our compositional verification approach and new language featuresas for example message parameters. Moreover, we plan to create industry-specificversions of MECHATRONICUML, which include MECHATRONICUML for Automation andMECHATRONICUML for Automotive.

5http://www.sysml.org

http://www.sysml.org

Chapter 9.

Bibliography

9.1. Own Publications

[ADG+09] P. Adelt, J. Donoth, Jürgen Gausemeier, Jens Geisler, Stefan Henkler, SaschaKahl, Benjamin Klöpper, A. Krupp, Eckehard Münch, Simon Oberthür, C. Paiz,H. Podlogar, M. Porrmann, R. Radkowski, C. Romaus, Alexander Schmidt,Bernd Schulz, H. Vö, Ulf Witkowski, Katrin Witting, and O. Znamenshchykov.Selbstoptimierende Systeme des Maschinenbaus – Definitionen, Anwendungen,Konzepte., volume Band 234. HNI-Verlagsschriftenreihe, Paderborn, 2009.

[BBB+12] Steffen Becker, Christian Brenner, Christopher Brink, Stefan Dziwok, ChristianHeinzemann, Renate Löffler, Uwe Pohlmann, Wilhelm Schäfer, Julian Suck,and Oliver Sudmann. The mechatronicuml design method – process, syntax, andsemantics. Technical Report tr-ri-12-326, Software Engineering Group, HeinzNixdorf Institute, University of Paderborn, August 2012. Vers. 0.3.

[BBD+12] Steffen Becker, Christian Brenner, Stefan Dziwok, Thomas Gewering, ChristianHeinzemann, Uwe Pohlmann, Claudia Priesterjahn, Wilhelm Schäfer, JulianSuck, Oliver Sudmann, and Matthias Tichy. The mechatronicuml method– process, syntax, and semantics. Technical Report tr-ri-12-318, SoftwareEngineering Group, Heinz Nixdorf Institute, University of Paderborn, February2012.

[BBG+06] Basil Becker, Dirk Beyer, Holger Giese, Florian Klein, and Daniela Schilling.Symbolic invariant verification for systems with dynamic structural adaptation.In Proceedings of the 28th International Conference on Software Engineering(ICSE), Shanghai, China. ACM Press, May 2006.

[BDG+11] Steffen Becker, Stefan Dziwok, Thomas Gewering, Christian Heinzemann,Uwe Pohlmann, Claudia Priesterjahn, Wilhelm Schäfer, Oliver Sudmann, andMatthias Tichy. Mechatronicuml – syntax and semantics. Technical Report tr-ri-11-325, Software Engineering Group, Heinz Nixdorf Institute, August 2011.

185

186 9.1. OWN PUBLICATIONS

[BGH+07] S. Burmester, H. Giese, S. Henkler, M. Hirsch, M. Tichy, A. Gambuzza,E. Münch, and H. Vöcking. Tool support for developing advanced mechatronicsystems: Integrating the fujaba real-time tool suite with camel-view. InProc. of the 29th International Conference on Software Engineering (ICSE),Minneapolis, Minnesota, USA, 2007.

[BGHS04] Sven Burmester, Holger Giese, Martin Hirsch, and Daniela Schilling.Incremental design and formal verification with UML/RT in the FUJABAReal-Time Tool Suite. In Proceedings of the International Workshop onSpecification and Validation of UML Models for Real Time and EmbeddedSystems, SVERTS2004, Satellite Event of the 7th International Conference onthe Unified Modeling Language, UML2004, pages 1–20, October 2004.

[BGO06] Sven Burmester, Holger Giese, and Oliver Oberschelp. Hybrid uml componentsfor the design of complex self-optimizing mechatronic systems. In J. Braz,H. Araújo, A. Vieira, and B. Encarnacao, editors, Informatics in Control,Automation and Robotics I. Springer, March 2006.

[BGS05] Sven Burmester, Holger Giese, and Wilhelm Schäfer. Model-DrivenArchitecture for Hard Real-Time Systems: From Platform Independent Modelsto Code. In Proc. of the European Conference on Model Driven Architecture- Foundations and Applications (ECMDA-FA’05), Nürnberg, Germany, LectureNotes in Computer Science, pages 25–40. Springer Verlag, November 2005.

[BGT05] Sven Burmester, Holger Giese, and Matthias Tichy. Model-driven developmentof reconfigurable mechatronic systems with mechatronic uml. In Uwe Aßmann,Mehmet Aksit, and Arend Rensink, editors, Model Driven Architecture, volume3599 of Lecture Notes in Computer Science, pages 47–61. Springer Berlin /Heidelberg, 2005.

[BHSH13] Christian Brenner, Christian Heinzemann, Wilhelm Schäfer, and Stefan Henkler.Automata-based refinement checking for real-time systems. In Proceedings ofSoftware Engineering 2013 – Fachtagung des GI-Fachbereichs Softwaretechnik,volume P-213 of Lecture Notes in Informatics (LNI), pages 99–112. Gesellschaftfür Informatik e.V., March 2013.

[Bur02] Sven Burmester. Generierung von Java Real-Time Code für zeitbehaftete UMLModelle. Master’s thesis, University of Paderborn, Department of ComputerScience, Paderborn, Germany, September 2002.

[DBHT12] Stefan Dziwok, Kathrin Bröker, Christian Heinzemann, and Matthias Tichy. Acatalog of real-time coordination patterns for advanced mechatronic systems.Technical Report tr-ri-12-319, University of Paderborn, Germany, Paderborn,Germany, February 2012.

9.1. OWN PUBLICATIONS 187

[DHT12] Stefan Dziwok, Christian Heinzemann, and Matthias Tichy. Real-time coordination patterns for advanced mechatronic systems. InMarjan Sirjani, editor, Proceedings of the 14th International Conferenceon Coordination Languages and Models (COORDINATION 2012), IFIPInternational Federation for Information Processing (2012), LNCS 7274, pages166–180, June 2012.

[EH10] Tobias Eckardt and Stefan Henkler. Component behavior synthesis for criticalsystems,. In Architecting Critical Systems, volume 6150 of Lecture Notes inComputer Science, pages 52–71. Springer Berlin / Heidelberg, 2010.

[EHH+13] Tobias Eckardt, Christian Heinzemann, Stefan Henkler, Martin Hirsch,Claudia Priesterjahn, and Wilhelm Schäfer. Modeling and verifying dynamiccommunication structures based on graph transformations. Computer Science -Research and Development, 28(1):3–22, February 2013. Published online July2011.

[FNTZ00a] Thorsten Fischer, Jörg Niere, Lars Torunski, and Albert Zündorf. Storydiagrams: A new graph rewrite language based on the unified modelinglanguage and java. In Hartmut Ehrig, Gregor Engels, Hans-Jörg Kreowski,and Grzegorz Rozenberg, editors, TAGT’98: Selected papers from the 6thInternational Workshop on Theory and Application of Graph Transformations,volume 1764 of Lecture Notes in Computer Science, pages 296–309. Springer,2000.

[FNTZ00b] Thorsten Fischer, Jörg Niere, Lars Torunski, and Albert Zündorf. Storydiagrams: A new graph rewrite language based on the unified modelinglanguage and java. In Hartmut Ehrig, Gregor Engels, Hans-Jörg Kreowski,and Grzegorz Rozenberg, editors, Selected papers from the 6th InternationalWorkshop on Theory and Application of Graph Transformations (TAGT ’98),November 16-20, 1998, Paderborn, Germany, volume 1764 of Lecture Notes inComputer Science, pages 296 – 309. Springer Berlin / Heidelberg, 2000.

[GB03] Holger Giese and Sven Burmester. Real-time statechart semantics. TechnicalReport tr-ri-03-239, Software Engineering Group, University of Paderborn,Paderborn, Germany, June 2003.

[GBSO04] Holger Giese, Sven Burmester, Wilhelm Schäfer, and Oliver Oberschelp.Modular Design and Verification of Component-Based Mechatronic Systemswith Online-Reconfiguration. In Proc. of 12th ACM SIGSOFT Foundations ofSoftware Engineering 2004 (FSE 2004), Newport Beach, USA, pages 179–188.acmpress, November 2004.


[GH06] Holger Giese and Stefan Henkler. A survey of approaches for the visual model-driven development of next generation software-intensive systems. Journal ofVisual Languages and Computing, 17(6):528–550, December 2006.

[GHH+08] Holger Giese, Stefan Henkler, Martin Hirsch, Vladimir Roubin, and MatthiasTichy. Modeling techniques for software-intensive systems. In Dr. Pierre F.Tiako, editor, Designing Software-Intensive Systems: Methods and Principles.IGI Global, Hershey, PA, 2008.

[Gie03] Holger Giese. A formal calculus for the compositional pattern-based designof correct real-time systems. Technical Report tr-ri-03-240, Lehrstuhl fürSoftwaretechnik, Universität Paderborn, Paderborn, Deutschland, July 2003. 9

[GRS14] Jürgen Gausemeier, Franz-Josef Rammig, and Wilhelm Schäfer, editors. DesignMethodology for Intelligent Technical Systems. Lecture Notes in MechanicalEngineering. Springer, 2014.

[GS12] Holger Giese and Wilhelm Schäfer. Model-driven development of safe self-optimizing mechatronic systems with mechatronicuml. Technical Report tr-ri-12-322, Software Engineering Group, Heinz Nixdorf Institute, University ofPaderborn, April 2012.

[GSG+09] Jürgen Gausemeier, Wilhelm Schäfer, Joel Greenyer, Sascha Kahl, SebastianPook, and Jan Rieke. Management of cross-domain model consistency duringthe development of advanced mechatronic systems. In Proceedings of the 17thInternational Conference on Engineering Design (ICED’09), 2009.

[GST+03] Holger Giese, Daniela Schilling, Matthias Tichy, Sven Burmester, WilhelmSchäfer, and Stephan Flake. Towards the Compositional Verification ofReal-Time UML Designs. Technical Report tr-ri-03-241, Lehrstuhl fürSoftwaretechnik, Universität Paderborn, Paderborn, Deutschland, jul 2003.

[GT06] Holger Giese and Matthias Tichy. Component-Based Hazard Analysis:Optimal Designs, Product Lines, and Online-Reconfiguration. In Proc. of the25th International Conference on Computer Safety, Security and Reliability(SAFECOMP), Gdansk, Poland, Lecture Notes in Computer Science. SpringerVerlag, September 2006.

[GTB+03] Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Schäfer, and StephanFlake. Towards the compositional verification of real-time uml designs. InProceedings of the 9th European software engineering conference held jointlywith 11th ACM SIGSOFT international symposium on Foundations of softwareengineering (ESEC/FSE-11), pages 38–47. ACM Press, September 2003.

9.1. OWN PUBLICATIONS 189

[GV03] Holger Giese and Alexander Vilbig. Separation of non-orthogonal concernsin software architecture and design. Technical Report tr-ri-03-238, Lehrstuhlfür Softwaretechnik, Universität Paderborn, Paderborn, Deutschland, February2003.

[HB13] Christian Heinzemann and Steffen Becker. Executing reconfigurations inhierarchical component architectures. In Proceedings of the 16th internationalACM Sigsoft symposium on Component based software engineering, CBSE ’13,pages 3–12, New York, NY, USA, June 2013. ACM.

[HBB+09] S. Henkler, M. Breit, C. Brink, M. Böger, C. Brenner, K. Bröker, U. Pohlmann,M. Richtermeier, J. Suck, O. Travkin, and C. Priesterjahn. Fritscab: Fujabare-engineering tool suite for mechatronic systems. In Proceedings of the 7thInternational Fujaba Days, 2009.

[HH11] Christian Heinzemann and Stefan Henkler. Reusing dynamic communicationprotocols in self-adaptive embedded component architectures. In Proceedings ofthe 14th International Symposium on Component Based Software Engineering(CBSE-2011), June 2011.

[HMS+10] S. Henkler, J. Meyer, W. Schäfer, U. Nickel, and M. von Detten. Legacycomponent integration by the fujaba real-time tool suite. In Proceedings of the32nd ACM/IEEE International Conference on Software Engineering, 2010.

[HOG04] Thorsten Hestermeyer, Oliver Oberschelp, and Holger Giese. Structuredinformation processing for self-optimizing mechatronic systems. In HelderAraujo, Alves Vieira, Jose Braz, Bruno Encarnacao, and Marina Carvalho,editors, Proc. of 1st International Conference on Informatics in Control,Automation and Robotics (ICINCO 2004), Setubal, Portugal, pages 230–237.INSTICC Press, 8 2004.

[HPB12] Christian Heinzemann, Claudia Priesterjahn, and Steffen Becker. Towardsmodeling reconfiguration in hierarchical component architectures. InProceedings of the 15th ACM SigSoft International Symposium on Component-Based Software Engineering (CBSE 2012). ACM, June 2012. 164, 165

[HPR+12] C. Heinzemann, U. Pohlmann, J. Rieke, W. Schäfer, O. Sudmann, and M. Tichy.Generating simulink and stateflow models from software specifications. InProceedings of the International Design Conference, DESIGN 2012, Dubrovnik,Croatia, May 2012.

[HRS13] Christian Heinzemann, Jan Rieke, and Wilhelm Schäfer. Simulating self-adaptive component-based systems using matlab/simulink. In IEEE 7thInternational Conference on Self-Adaptive and Self-Organizing Systems, SASO’13, pages 71–80. IEEE Computer Society Press, September 2013.


[HSST13] Christian Heinzemann, Oliver Sudmann, Wilhelm Schäfer, and MatthiasTichy. A discipline-spanning development process for self-adaptive mechatronicsystems. In Proceedings of the 2013 International Conference on Software andSystem Process, ICSSP 2013, pages 36–45. ACM, New York, NY, USA, May2013.

[OMT+08] Semir Osmic, Eckehard Münch, Ansgar Trächtler, Stefan Henkler, WilhelmSchäfer, Holger Giese, and Martin Hirsch. Safe online-reconfiguration of self-optimzing mechatronic systems. In Jürgen Gausemeier, Franz J. Rammig,and Wilhelm Schäfer, editors, Selbstoptimierende mechatronische Systeme: DieZukunft gestalten. 7. Internationales Heinz Nixdorf Symposium für industrielleInformationstechnik, pages 411–426, February 2008.

[PDM+14] Uwe Pohlmann, Stefan Dziwok, Matthias Meyer, Matthias Tichy, and SebastianThiele. A modelica coordination pattern library for cyber-physical systems. InProceedings of the 7th International ICST Conference on Simulation Tools andTechniques, March 2014. Accepted.

[PST13] Claudia Priesterjahn, Dominik Steenken, and Matthias Tichy. Timed hazardanalysis of self-healing systems. In Javier Cámara, Rogerio de Lemos, CarloGhezzi, and Antonia Lopes, editors, Assurances for Self-Adaptive SystemsAssurances for Self-Adaptive Systems, volume 7740 of Lecture Notes inComputer Science (LNCS), pages 112–151. Springer-Verlag Berlin Heidelberg,2013.

[PSWTH11] Claudia Priesterjahn, Christoph Sondermann-Wölke, Matthias Tichy, andChristian Hölscher. Component-based hazard analysis for mechatronic systems.In Proceedings of the 2nd IEEE International Workshop on Model-BasedEngineering for Real-Time Embedded Systems Design, MoBE-RTES 2011.IEEE Computer Society, USA, March 2011.

[RDS+12] Jan Rieke, Rafal Dorociak, Oliver Sudmann, Jürgen Gausemeier, and WilhelmSchäfer. Management of cross-domain model consistency for behavioral modelsof mechatronic systems. In Proceedings of the 12h International DesignConference DESIGN 2012, 2012.

[RS12] Jan Rieke and Oliver Sudmann. Specifying refinement relations in verticalmodel transformations. In Proceedings of the 8th European Conference onModelling Foundations and Applications (ECMFA 2012), 2012.

[SSGR11] Wilhelm Schäfer, Oliver Sudmann, Joel Greenyer, and Jan Rieke. Themechatronic uml development process. In Engineering of Software. SpringerBerlin Heidelberg, 2011.

9.2. BACHELOR THESES, MASTER THESES AND PH.D. THESES 191

[THHO08] Matthias Tichy, Stefan Henkler, Jörg Holtmann, and Simon Oberthür.Component story diagrams: A transformation language for componentstructures in mechatronic systems. In Postproc. of the 4th Workshop on Object-oriented Modeling of Embedded Real-Time Systems (OMER 4), Paderborn,Germany, 2008. 94

[vDHP+12] Markus von Detten, Christian Heinzemann, Marie Christin Platenius, Jan Rieke,Dietrich Travkin, and Stephan Hildebrandt. Story diagrams – syntax andsemantics. Technical Report tr-ri-12-324, Software Engineering Group, HeinzNixdorf Institute, July 2012. Ver. 0.2.

[Zü01] Albert Zündorf. Rigorous Object Oriented Software Development. Habilitation,Software Engineering Group, University of Paderborn, 2001.

[ZH13] Steffen Ziegert and Christian Heinzemann. Durative graph transformation rulesfor modelling real-time reconfiguration. In Proceedings of the 10th InternationalColloquium on Theoretical Aspects of Computing, Lecture Notes in ComputerScience. Springer, 2013.

9.2. Bachelor Theses, Master Theses and Ph.D.Theses

[Brö11] Kathrin Bröker. Modellierung und Verifikation von Kommunikationsprotokollenfür den Betrieb des RailCab Systems. Master’s thesis, University of Paderborn,November 2011.

[Bur06] Sven Burmester. Model-Driven Engineering of Reconfigurable MechatronicSystems. PhD thesis, Universität Paderborn, Berlin, Deutschland, 2006.

[Dre11] Jannis Drewello. Musterbasierter Entwurf für das Verhalten von BeBot-Roboternmit MechatronicUML. Bachelor thesis, University of Paderborn, 2011. in German.

[Ger13] Christopher Gerking. Transparent uppaal-based verifcation of mechatronicumlmodels. Master’s thesis, University of Paderborn, May 2013.

[Gre11] Joel Greenyer. Scenario-based Design of Mechatronic Systems. PhD thesis,University of Paderborn, October 2011.

[Hen12] StefanHenkler. Ein komponentenbasierter, modellgetriebener Softwareentwicklungsansatzfür vernetzte, mechatronische Systeme. PhD thesis, University of Paderborn, June2012.

192 9.3. FOREIGN PUBLICATIONS

[Hir04] Martin Hirsch. Effizientes Model Checking von UML-RT Modellen und RealtimeStatecharts mit UPPAAL. Master’s thesis, University of Paderborn, June 2004.

[Hir08] Martin Hirsch. Modell-basierte Verifikation von vernetzten mechatronischenSystemen. PhD thesis, Universität Paderborn, Paderborn, Deutschland, 2008.

[Pri13] Claudia Priesterjahn. Analyzing Self-healing Operations in Mechatronic Systems.PhD thesis, University of Paderborn, Paderborn, 2013.

[Rie11] Stefan Riepe. Zustandsbasierte Verhaltensmodellierung von Steuerungssystemenmit Entwurfsmustern. Bachelor thesis, University of Paderborn, June 2011. inGerman.

[San11] Marcel Sander. Prozessevaluierung der Software-Konkretisierung nach ENTIME.Bachelor thesis, University of Paderborn, November 2011.

[Sch06] Daniela Schilling. Kompositionale Softwareverifikation mechatronischer Systeme.PhD thesis, Universität Paderborn, Paderborn, Deutschland, 2006.

[Sta08] Florian Stallmann. A Model-Driven Approach to Multi-Agent-Design. PhD thesis,Universität Paderborn, Paderborn, Deutschland, 2008.

[Tic09] Matthias Tichy. Gefahrenanalyse selbstoptimierender Systeme. Dissertation,Universität Paderborn, Warburger Str. 100, May 2009. 94

9.3. Foreign Publications

[Abr74] Jean-Raymond Abrial. Data semantics. In IFIP Working Conference DataBase Management, pages 1–60, 1974.

[ABRS04] Farhad Arbab, Christel Baier, Jan Rutten, and Marjan Sirjani. Modelingcomponent connectors in reo by constraint automata: (extended abstract).Electronic Notes in Theoretical Computer Science, 97(0):25 – 46, 2004.Proceedings of FOCLASA 2003, the Foundations of Coordination Languagesand Software Architectures, a satellite event of CONCUR 2003.

[aca11] acatech - National Academy of Science and Engineering. Cyber-Physical Systems: Driving force for innovation in mobility, health, energyand production (acatech POSITION PAPER). Springer-Verlag, Berlin,Heidelberg, 2011.

[ACD93] Rajeev Alur, Costas Courcoubetis, and David L. Dill. Model-checking indense real-time. Information and Computation, 104(1):2–34, 1993.

9.3. FOREIGN PUBLICATIONS 193

[ÅCF+07] Mikael Åkerholm, Jan Carlson, Johan Fredriksson, Hans Hansson, JohnHåkansson, Anders Möller, Paul Pettersson, and Massimo Tivoli. The saveapproach to component-based development of vehicular systems. Journal ofSystems and Software, 80(5):655 – 667, 2007.

[ACH+95] Rajeev Alur, C. Courcoubetis, N. Halbwachs, T. A. Henzinger, P. H. Ho,X. Nicollin, A. Olivero, J. Sifakis, and S. Yovine. The algorithmic analysisof hybrid systems. Theoretical Computer Science, 138(1):3 – 34, 1995.

[AD90] Rajeev Alur and David L. Dill. Automata for modeling real-time systems.In Proceedings of the Seventeenth International Colloquium on Automata,Languages and Programming, volume 443 of Lecture Notes in ComputerScience (LNCS), pages 322–335, New York, NY, USA, 1990. Springer-VerlagNew York, Inc.

[AD94] Rajeev Alur and David L. Dill. A theory of timed automata. TheoreticalComputer Science, 126:183–235, 1994.

[ADE+01] Rajeev Alur, Thao Dang, Joel M. Esposito, Rafael B. Fierro, Yerang Hur,Franjo Ivancic, Vijay Kumar, Insup Lee, Pradyumna Mishra, George J.Pappas, and Oleg Sokolsky. Hierarchical hybrid modeling of embeddedsystems. In Proceedings of the First International Workshop on EmbeddedSoftware, EMSOFT ’01, pages 14–31, London, UK, UK, 2001. Springer-Verlag.

[ADG98] Robert Allen, Rémi Douence, and David Garlan. Specifying and analyzingdynamic software architectures. Lecture Notes in Computer Science,1382:21–37, 1998.

[AHJ+09] M. Anne, Ruan He, T. Jarboui, M. Lacoste, O. Lobry, G. Lorant, M. Louvel,J. Navas, V. Olive, J. Polakovic, M. Poulhies, J. Pulou, S. Seyvoz, J. Tous,and T. Watteyne. Think: View-based support of non-functional properties inembedded systems. In Embedded Software and Systems, 2009. ICESS ’09.International Conference on, pages 147 –156, may 2009.

[AIK+03] Rajeev Alur, Franjo Ivancic, Jesung Kim, Insup Lee, and Oleg Sokolsky.Generating embedded software from hierarchical hybrid models. InProceedings of the 2003 ACM SIGPLAN conference on Language, compiler,and tool for embedded systems, LCTES ’03, pages 171–182, New York, NY,USA, 2003. ACM.

[All11] The OSGi Alliance. OSGi Service Platform Core Specification, release 4,version 4.3 edition, April 2011.

[Alu11] Rajeev Alur. Formal verification of hybrid systems. In Proceedings of theninth ACM international conference on Embedded software, EMSOFT ’11,pages 273–278, New York, NY, USA, 2011. ACM.

[AM02] Nazareno Aguirre and Tom Maibaum. A temporal logic approach tothe specification of reconfigurable component-based systems. AutomatedSoftware Engineering, International Conference on, 0:271–274, 2002.

[Arb06] Farhad Arbab. Coordination for component composition. Electronic Notesin Theoretical Computer Science, 160(0):15 – 40, 2006. Proceedings of theInternational Workshop on Formal Aspects of Component Software (FACS2005) Proceedings of the International Workshop on Formal Aspects ofComponent Software (FACS 2005).

[ASTPH11] Rasmus Adler, Ina Schaefer, Mario Trapp, and Arnd Poetzsch-Heffter.Component-based modeling and verification of dynamic adaptation in safety-critical embedded systems. ACM Trans. Embed. Comput. Syst., 10:20:1–20:39, January 2011.

[BBCP05] Fabio Bellifemine, Federico Bergenti, Giovanni Caire, and Agostino Poggi.Jade — a java agent development framework. In Rafael Bordini, MehdiDastani, Jürgen Dix, Amal Fallah Seghrouchni, and Gerhard Weiss, editors,Multi-Agent Programming, volume 15 of Multiagent Systems, ArtificialSocieties, and Simulated Organizations, pages 125–147. Springer US, 2005.

[BBF09] G. Blair, N. Bencomo, and R. B. France. Models@ run.time. Computer,42(10):22 –27, oct. 2009.

[BBGM08] Roberto Bruni, Antonio Bucchiarone, Stefania Gnesi, and Hernán Melgratti.Modelling dynamic software architectures using typed graph grammars.Electronic Notes in Theoretical Computer Science, 213(1):39 – 53, 2008.<ce:title>Proceedings of the Third Workshop on Graph Transformation forConcurrency and Verification (GT-VC 2007)</ce:title>.

[BCC+08] Tomas Bures, Jan Carlson, Ivica Crnkovic, Séverine Sentilles, and AnetaVulgarakis. Procom - the progress component model reference manual,version 1.0. Technical Report ISSN 1404-3041 ISRN MDH-MRTC-230/2008-1-SE, Mälardalen University, June 2008.

[BCDW04] Jeremy S. Bradbury, James R. Cordy, Juergen Dingel, and MichelWermelinger. A survey of self-management in dynamic software architecturespecifications. In WOSS ’04: Proceedings of the 1st ACM SIGSOFTworkshop on Self-managed systems, pages 28–33, New York, NY, USA,2004. ACM.


[BCF+08] Albert Benveniste, Benoît Caillaud, Alberto Ferrari, Leonardo Mangeruca,Roberto Passerone, and Christos Sofronis. Multiple viewpoint contract-basedspecification and design. In Frank de Boer, Marcello Bonsangue, SusanneGraf, and Willem-Paul de Roever, editors, Formal Methods for Componentsand Objects, volume 5382 of Lecture Notes in Computer Science, pages 200–225. Springer Berlin / Heidelberg, 2008.

[BCL+06] Eric Bruneton, Thierry Coupaye, Matthieu Leclercq, Vivien Quéma, andJean-Bernard Stefani. The fractal component model and its support in java.Software: Practice and Experience, 36(11-12):1257–1284, 2006.

[BCVZ05] Lubos Brim, Ivana Cerna, Pavlina Varekova, and Barbora Zimmerova.Component-interaction automata as a verification-oriented component-basedsystem specification. In Proceedings of the 2005 conference on Specificationand verification of component-based systems, SAVCBS ’05, New York, NY,USA, 2005. ACM.

[BDL04] Gerd Behrmann, Alexandre David, and Kim G. Larsen. A tutorial on uppaal.In M. Bernardo and F. Corradini, editors, International School on FormalMethods for the Design of Computer, Communication, and Software Systems,SFM-RT 2004. Revised Lectures, volume 3185 of Lecture Notes in ComputerScience, pages 200–237. Springer Verlag, 2004. 54

[BFHP09] Etienne Borde, Peter H. Feiler, Grégory Haïk, and Laurent Pautet. Modeldriven code generation for critical and adaptative embedded systems.SIGBED Review, 6:10:1–10:5, October 2009.

[BG08] Basil Becker and Holger Giese. Modeling of correct self-adaptive systems:a graph transformation system based approach. In Proceedings of the 5thinternational conference on Soft computing as transdisciplinary science andtechnology, CSTST ’08, pages 508–516, New York, NY, USA, 2008. ACM.

[BHG87] Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman. ConcurrencyControl and Recovery in Database Systems. Addison Wesley, 1987.

[BHR09] Boutheina Bennour, Ludovic Henrio, and Marcela Rivera. A reconfigurationframework for distributed components. In Proc. of the 2009 ESEC/FSEworkshop on Software integration and evolution @ runtime, SINTER ’09,pages 49–56. ACM, 2009.

[BJPW99] A. Beugnard, J.-M. Jezequel, N. Plouzeau, and D. Watkins. Makingcomponents contract aware. Computer, 32(7):38 –45, jul 1999.

[BK08] Christel Baier and Joost-Pieter Katoen. Principles of Model Checking. MITPress, 2008.


[BK11] Björn Bartels and Moritz Kleine. A csp-based framework for thespecification, verification, and implementation of adaptive systems. InProceedings of the 6th International Symposium on Software Engineeringfor Adaptive and Self-Managing Systems, SEAMS ’11, pages 158–167, NewYork, NY, USA, 2011. ACM.

[BMO01] Bernhard Bauer, Jörg P. Müller, and James Odell. Agent uml: A formalismfor specifying multiagent interaction. In P. Ciancarini and Michael J.Wooldridge, editors, Agent-Oriented Software Engineering, pages 91–103.Springer, 2001.

[BY03] Johan Bengtsson and Wang Yi. Timed automata: Semantics, algorithms andtools. In Jörg Desel, Wolfgang Reisig, and Grzegorz Rozenberg, editors,Lectures on Concurrency and Petri Nets, volume 3098 of Lecture Notes inComputer Science, pages 87–124. Springer, 2003.

[CBG+04] Geoff Coulson, Gordon Blair, Paul Grace, Ackbar Joolia, Kevin Lee,and Jo Ueyama. A component model for building systems software.In Proceedings of the IASTED Conference on Software Engineering andApplications, pages 684–689. IASTED/ACTA Press, November 2004.

[CCM+05] P. Costa, G. Coulson, C. Mascolo, G. P. Picco, and S. Zachariadis. Therunes middleware: a reconfigurable component-based approach to networkedembedded systems. In Personal, Indoor and Mobile Radio Communications,2005. PIMRC 2005. IEEE 16th International Symposium on, volume 2, pages806 –810 Vol. 2, sept. 2005.

[CCSV07] Ivica Crnkovic, Michel Chaudron, Séverine Sentilles, and Aneta Vulgarakis.A classification framework for component models. In Proceedings of the 7thConference on Software Engineering and Practice in Sweden, October 2007.

[CdAHS03] Arindam Chakrabarti, Luca de Alfaro, Thomas Henzinger, and MariëlleStoelinga. Resource interfaces. In Rajeev Alur and Insup Lee, editors,Embedded Software, volume 2855 of Lecture Notes in Computer Science,pages 117–133. Springer Berlin / Heidelberg, 2003.

[CdlFBS01] Carlos E. Cuesta, Pablo de la Fuente, and Manuel Barrio-Solárzano. Dynamiccoordination architecture through the use of reflection. In Proceedings of the2001 ACM symposium on Applied computing, SAC ’01, pages 134–140, NewYork, NY, USA, 2001. ACM.

[CdLG+09] Betty H. C. Cheng, Rogério de Lemos, Holger Giese, Paola Inverardi,Jeff Magee, Jesper Andersson, Basil Becker, Nelly Bencomo, Yuriy Brun,Bojan Cukic, Giovanna Di Marzo Serugendo, Schahram Dustdar, Anthony


Finkelstein, Cristina Gacek, Kurt Geihs, Vincenzo Grassi, Gabor Karsai,Holger M. Kienle, Jeff Kramer, Marin Litoiu, Sam Malek, RaffaelaMirandola, Hausi A. Müller, Sooyong Park, Mary Shaw, Matthias Tichy,Massimo Tivoli, Danny Weyns, and Jon Whittle. Software engineering forself-adaptive systems: A research roadmap. In Betty H. C. Cheng, Rogériode Lemos, Holger Giese, Paola Inverardi, and Jeff Magee, editors, SoftwareEngineering for Self-Adaptive Systems, volume 5525 of Lecture Notes inComputer Science, pages 1–26. Springer, 2009.

[CE00] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative Programming:Methods, Tools, and Applications. Addison-Wesley, 2000.

[CFG10] Mauro Caporuscio, Marco Funaro, and Carlo Ghezzi. Architectural issuesof adaptive pervasive systems. In Gregor Engels, Claus Lewerentz,Wilhelm Schäfer, Andy Schürr, and Bernhard Westfechtel, editors, GraphTransformations and Model-Driven Engineering, volume 5765 of LectureNotes in Computer Science, pages 492–511. Springer Berlin / Heidelberg,2010.

[CFJ+10] Philippe Cuenot, Patrick Frey, Rolf Johansson, Henrik Lönn, YiannisPapadopoulos, Mark-Oliver Reiser, Anders Sandberg, David Servat, RaminTavakoli Kolagari, Martin Törngren, and Matthias Weber. The east-adlarchitecture description language for automotive embedded software. InHolger Giese, Gabor Karsai, Edward Lee, Bernhard Rumpe, and BernhardSchätz, editors, Model-Based Engineering of Embedded Real-Time Systems,volume 6100 of Lecture Notes in Computer Science, pages 297–307. SpringerBerlin Heidelberg, 2010.

[CG12] Shang-Wen Cheng and David Garlan. Stitch: A language for architecture-based self-adaptation, 2012. Submitted for Publication.

[CGP08] Antonio Carzaniga, Alessandra Gorla, and Mauro Pezzè. Self-healing bymeans of automatic workarounds. In Proceedings of the 2008 internationalworkshop on Software engineering for adaptive and self-managing systems,SEAMS ’08, pages 17–24, New York, NY, USA, 2008. ACM.

[CGS06] Shang-Wen Cheng, David Garlan, and Bradley Schmerl. Architecture-basedself-adaptation in the presence of multiple objectives. In Proceedings of the2006 international workshop on Self-adaptation and self-managing systems,SEAMS ’06, pages 2–8, New York, NY, USA, 2006. ACM.

[CHS01] Wen-Ke Chen, Matti A. Hiltunen, and Richard D. Schlichting. Constructingadaptive software in distributed systems. In ICDCS ’01: Proceedings of the


The 21st International Conference on Distributed Computing Systems, pages635–643, Washington, DC, USA, 2001. IEEE Computer Society.

[Col07] R.D. Colgren. Basic MATLAB, Simulink, and Stateflow. AIAA educationseries. American Institute of Aeronautics and Astronautics, 2007.

[CPT99] Carlos Canal, Ernesto Pimentel, and José M. Troya. Specification andrefinement of dynamic software architectures. In WICSA1: Proceedings ofthe TC2 First Working IFIP Conference on Software Architecture (WICSA1),pages 107–126, Deventer, The Netherlands, The Netherlands, 1999. Kluwer,B.V.

[CR10] Carlos E. Cuesta and M. Pilar Romay. Elements of self-adaptive systems:a decentralized architectural perspective. In Proceedings of the Firstinternational conference on Self-organizing architectures, SOAR’09, pages1–20, Berlin, Heidelberg, 2010. Springer-Verlag.

[CSVC11] Ivica Crnkovic, Severine Sentilles, Aneta Vulgarakis, and Michel R. V.Chaudron. A classification framework for software component models. IEEETrans. Softw. Eng., 37:593–615, September 2011.

[dAH05] Luca de Alfaro and Thomas A. Henzinger. Interface-based design. InManfred Broy, Johannes Gruenbauer, David Harel, and Tony Hoare, editors,Engineering Theories of Software Intensive Systems, volume 195 of NATOScience Series, pages 83–104, 2005.

[DAO+11] Mahdi Derakhshanmanesh, Mehdi Amoui, Greg O’Grady, Jürgen Ebert, andLadan Tahvildari. Graf: graph-based runtime adaptation framework. InProceedings of the 6th International Symposium on Software Engineeringfor Adaptive and Self-Managing Systems, SEAMS ’11, pages 128–137, NewYork, NY, USA, 2011. ACM.

[DDF+06] Simon Dobson, Spyros Denazis, Antonio Fernández, Dominique Gaïti, ErolGelenbe, Fabio Massacci, Paddy Nixon, Fabrice Saffre, Nikita Schmidt, andFranco Zambonelli. A survey of autonomic communications. ACM Trans.Auton. Adapt. Syst., 1:223–259, December 2006.

[DDL+10] Schahram Dustdar, Christoph Dorn, Fei Li, Luciano Baresi, Giacomo Cabri,Cesare Pautasso, and Franco Zambonelli. A roadmap towards sustainableself-aware service systems. In Proceedings of the 2010 ICSE Workshop onSoftware Engineering for Adaptive and Self-Managing Systems, SEAMS ’10,pages 10–19, New York, NY, USA, 2010. ACM.

[DLLC09] Pierre-Charles David, Thomas Ledoux, Marc Léger, and Thierry Coupaye.Fpath and fscript: Language support for navigation and reliable


reconfiguration of fractal architectures. Annals of Telecommunications,64:45–63, 2009. 10.1007/s12243-008-0073-y.

[DM01] Alexandre David and M. Oliver Möller. From HUPPAAL to UPPAAL: ATranslation from Hierarchical Timed Automata to Flat Timed Automata.Number RS-01-11 in BRICS Report Series. BRICS, Department of ComputerScience, University of Aarhus, 2001.

[DMY02a] Alexandre David, M. Möller, and Wang Yi. Formal verification of umlstatecharts with real-time extensions. In Ralf-Detlef Kutsche and HerbertWeber, editors, Fundamental Approaches to Software Engineering, volume2306 of Lecture Notes in Computer Science, pages 208–241. Springer Berlin/ Heidelberg, 2002.

[DMY02b] Alexandre David, M. Oliver Möller, and Wang Yi. Formal verification ofuml statecharts with real-time extensions. In Fundamental Approaches toSoftware Engineering, volume 2306 of Lecture Notes in Computer Science,pages 208–241. Springer Berlin / Heidelberg, 2002.

[EEPT06] Hartmut Ehrig, Karsten Ehrig, Ulrike Prange, and Gabriele Taentzer.Fundamentals of Algebraic Graph Transformation. Monographs inTheoretical Computer Science. Springer, 2006.

[Elm78] Hilding Elmqvist. A Structured Model Language for Large ContinuousSystems. PhD thesis, Department of Automatic Control, Lund University,Sweden, May 1978.

[EMO99] H. Elmqvist, S.E. Mattsson, and M. Otter. Modelica-a language forphysical system modeling, visualization and interaction. In Computer AidedControl System Design, 1999. Proceedings of the 1999 IEEE InternationalSymposium on, pages 630–639. IEEE, 1999.

[EMSS91] E. Allen Emerson, Aloysius K. Mok, A. Prasad Sistla, and Jai Srinivasan.Quantitative temporal reasoning. In Proceedings of the 2nd InternationalWorkshop on Computer Aided Verification, CAV ’90, pages 136–145,London, UK, UK, 1991. Springer-Verlag.

[ERNF12] Andreas Eggers, Nacim Ramdani, NedialkoS. Nedialkov, and Martin Fränzle.Improving the sat modulo ode approach to hybrid systems analysis bycombining different enclosure methods. Software & Systems Modeling, pages1–28, November 2012.

[EW92] M. Endler and J. Wei. Programming generic dynamic reconfigurationsfor distributed applications. In International Workshop on ConfigurableDistributed Systems, pages 68–79, Mar 1992.


[Fea98] J. Fisher and et al. Model-based systems engineering: A new paradigm.INCOSE INSIGHT, 1:3–16, 1998.

[FMB+09] Simon Fürst, Jürgen Mössinger, Stefan Bunzel, Thomas Weber, FrankKirschke-Biller, Peter Heitkämper, Gerulf Kinkelin, Kenji Nishikawa, andKlaus Lange. Autosar - a worldwide standard is on the road. In Proceedingsof the 14th International VDI Congress Electronic Systems for Vehicles 2009,2009.

[FMMR10] Carlo A. Furia, Dino Mandrioli, Angelo Morzenti, and Matteo Rossi.Modeling time in computing: A taxonomy and a comparative survey. ACMComputing Surveys (CSUR), 42(4):1–59, February 2010.

[Fou02] Foundation for Intelligent Physical Agents (FIPA). FIPA ACL MessageStructure Specification, 2002.

[Fri04] Peter Fritzson. Principles of Object-Oriented Modeling and Simulation withModelica 2.1. John Wiley & Sons, 2004.

[GbR08] AUTOSAR GbR. Autosar - technical overview. Technical report, AUTOSARGbR, 07 2008.

[GCW+02] T. Genßler, A. Christoph, M. Winter, O. Nierstrasz, S. Ducasse, R. Wuyts,G. Arévalo, B. Schönhage, P. Müller, and C. Stich. Components forembedded software: the pecos approach. In Proceedings of the 2002international conference on Compilers, architecture, and synthesis forembedded systems, pages 19–26. ACM, 2002.

[GFDK09a] J. Gausemeier, U. Frank, J. Donoth, and S. Kahl. Specification techniquefor the description of self-optimizing mechatronic systems. Research inEngineering Design, 20:201–223, 2009. 10.1007/s00163-008-0058-x.

[GFDK09b] Jürgen Gausemeier, U. Frank, J. Donoth, and S. Kahl. Specification techniquefor the description of self-optimizing mechatronic systems. Research inEngineering Design, 20:201–223, 2009.

[GH04] H. Gomaa and M. Hussein. Software reconfiguration patterns for dynamicevolution of software architectures. In Software Architecture, 2004. WICSA2004. Proceedings. Fourth Working IEEE/IFIP Conference on, pages 79 – 88,june 2004.

[GMK02] Ioannis Georgiadis, Jeff Magee, and Jeff Kramer. Self-organising softwarearchitectures for distributed systems. In WOSS ’02: Proceedings of the firstworkshop on Self-healing systems, pages 33–38, New York, NY, USA, 2002.ACM.


[GMW00] David Garlan, Robert T. Monroe, and David Wile. Acme: architecturaldescription of component-based systems. In Gary T. Leavens and MuraliSitaraman, editors, Foundations of component-based systems, pages 47–67.Cambridge University Press, New York, NY, USA, 2000.

[GO10] M. Gudemann and F. Ortmeier. A framework for qualitative and quantitativeformal model-based safety analysis. In High-Assurance Systems Engineering(HASE), 2010 IEEE 12th International Symposium on, pages 132 –141,November 2010.

[Gro03] Object Management Group. OMG Unified Modeling Language Specification1.5, March 2003. Document – formal/03-03-01.

[Gro10a] Object Management Group. OMG Systems Modeling Language (OMGSysML) 1.2, June 2010. Document formal/10-06-02.

[Gro10b] Object Management Group. Unified Modeling Language (UML) 2.3Superstructure Specification, May 2010. Document formal/2010-05-05.

[Gro11a] Object Management Group. Action Language for Foundational UML (ALF)1.0 (2nd FTF), December 2011. Document formal/2010-10-05.

[Gro11b] Object Management Group. Common Object Request Broker Architecture(CORBA) Specification - Part 3: CORBA Component Model, November2011. Document formal/2011-11-03. 21

[GS04] Z. Gu and K. G. Shin. Synthesis of real-time implementation from uml-rt models. In In 2nd RTAS Workshop on Model-Driven Embedded Systems(MoDES ’04), 2004.

[HA05] Dang Van Hung and Bui Vu Anh. Model checking real-time componentbased systems with blackbox testing. In Proceedings of the 11th IEEEInternational Conference on Embedded and Real-Time Computing Systemsand Applications, RTCSA ’05, pages 76–79, Washington, DC, USA, 2005.IEEE Computer Society.

[Har87] David Harel. Statecharts: A visual formalism for complex systems. Scienceof Computer Programming, 8(3):231–274, 1987.

[HIM98] Dan Hirsch, Paolo Inverardi, and Ugo Montanari. Graph grammars andconstraint solving for software architecture styles. In ISAW ’98: Proceedingsof the third international workshop on Software architecture, pages 69–72,New York, NY, USA, 1998. ACM.


[HIPW05] Scott Hissam, James Ivers, Daniel Plakosh, and Kurt C. Wallnau. Pincomponent technology (v1.0) and its c interface. Technical Report CMU/SEI-2005-TN-001, Carnegie Mellon Software Engineering Institute, April 2005.

[HJM05] Thomas A. Henzinger, Ranjit Jhala, and Rupak Majumdar. Permissiveinterfaces. In Proceedings of the 10th European software engineeringconference held jointly with 13th ACM SIGSOFT international symposiumon Foundations of software engineering, ESEC/FSE-13, pages 31–40, NewYork, NY, USA, 2005. ACM.

[HKRS05] Z. Huzar, L. Kuzniarz, G. Reggio, and J.L. Sourrouille. Consistencyproblems in uml-based software development. UML Modeling Languagesand Applications, pages 1–12, 2005.

[HM07] David Harel and Shahar Maoz. Assert and negate revisited: Modal semanticsfor uml sequence diagrams. Software and System Modeling, 7(2):237–252,2007.

[HM08] Markus C. Huebscher and Julie A. McCann. A survey of autonomiccomputing – degrees, models, and applications. ACM Comput. Surv.,40(3):7:1–7:28, August 2008.

[HMP01] Thomas A. Henzinger, Marius Minea, and Vandana Prabhu. Assume-guarantee reasoning for hierarchical hybrid systems. In Maria DomenicaDi Benedetto and Alberto Sangiovanni-Vincentelli, editors, Hybrid Systems:Computation and Control. 4th International Workshop, HSCC 2001.Proceedings, pages 275–290. Springer Verlag, March 2001.

[HMTN+08] Kaj Hänninen, Jukka Mäki-Turja, Mikael Nolin, Mats Lindberg, JohnLundbäck, and Kurt-Lennart Lundbäck. The rubus component modelfor resource constrained real-time systems. In 3rd IEEE InternationalSymposium on Industrial Embedded Systems, June 2008.

[Hoa85] C. A. R. Hoare. Communicating Sequential Processes. Series in ComputerScience. Prentice-Hall International, 1985.

[Hor03] Benjamin Horowitz. Giotto: a Time-Triggered Language for EmbeddedProgramming. PhD thesis, University of California, Berkley, 2003. Chair-Thomas A. Henzinger.

[HP06] Petr Hnetynka and Frantisek Plasil. Dynamic reconfiguration and access toservices in hierarchical component models. In Ian Gorton, George Heineman,Ivica Crnkovic, Heinz Schmidt, Judith Stafford, Clemens Szyperski, and KurtWallnau, editors, Component-Based Software Engineering, volume 4063


of Lecture Notes in Computer Science, pages 352–359. Springer Berlin /Heidelberg, 2006.

[HPB+05] Petr Hnetynka, Frantisek Plasil, Tomas Bures, Vladimír Mencl, and LuciaKapová. Sofa 2.0 metamodel. Technical Report 2005/11, Dep. of SWEngineering, Charles University, December 2005.

[HPB+10] Petr Hosek, Tomas Pop, Tomas Bures, Petr Hnetynka, and Michal Malohlava.Comparison of component frameworks for real-time embedded systems. InProceedings of CBSE 2010, LNCS. Springer, 2010.

[IBM06] IBM. An architectural blueprint for autonomic computing. Autonomiccomputing white paper, IBM, June 2006.

[IW95] Paola Inverardi and Alexander L. Wolf. Formal specification and analysisof software architectures using the chemical abstract machine model. IEEETransactions on Software Engineering, 21:373–386, 1995.

[JBCG05] Ackbar Joolia, Thais Batista, Geoff Coulson, and Antonio Tadeu A.Gomes. Mapping adl specifications to an efficient and reconfigurable runtimecomponent platform. In Software Architecture, 2005. WICSA 2005. 5thWorking IEEE/IFIP Conference on, pages 131 –140, 2005.

[JDB09] Y. Jarraya, M. Debbabi, and J. Bentahar. On the meaning of sysml activitydiagrams. In Engineering of Computer Based Systems, 2009. ECBS 2009.16th Annual IEEE International Conference and Workshop on the, pages 95–105. IEEE, 2009.

[Kil05] Christopher Kilian. Modern Control Technology. Delmar Cengage Learning,3rd edition, 2005.

[KJT+11] Narges Khakpour, Saeed Jalili, Carolyn Talcott, Marjan Sirjani, andMohammadReza Mousavi. Formal modeling of evolving self-adaptivesystems. Science of Computer Programming, 2011.

[KKHH08] Ji Eun Kim, R. Kapoor, M. Herrmann, and J. Haerdtlein. Software behaviordescription of real-time embedded systems in component based softwaredevelopment. In Object Oriented Real-Time Distributed Computing (ISORC),2008 11th IEEE International Symposium on, pages 307 –311, may 2008.

[KKJ12] Slim Kallel, Mohamed Hadj Kacem, and Mohamed Jmaiel. Modeling andenforcing invariants of dynamic software architectures. Software and SystemsModeling, 11:127–149, 2012.


[KKJD06] Mohamed Hadj Kacem, Ahmed Hadj Kacem, Mohamed Jmaiel, and KhalilDrira. Describing dynamic software architectures using an extended umlmodel. In Proceedings of the 2006 ACM symposium on Applied computing,SAC ’06, pages 1245–1249, New York, NY, USA, 2006. ACM.

[KKTS09] Thomas Kuhn, Sören Kemmann, Mario Trapp, and Christian Schäfer. Multi-language development of embedded systems. In Matti Rossi, JonathanSprinkle, Jeff Gray, and Juha-Pekka Tolvanen, editors, Proceedings of the 9thOOPSLA Workshop on Domain-Specific Modeling (DSM ’09), pages 21–27,2009.

[KLM+97] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, CristinaLopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming.In Mehmet Aksit and Satoshi Matsuoka, editors, ECOOP’97 — Object-Oriented Programming, volume 1241 of Lecture Notes in Computer Science,pages 220–242. Springer Berlin Heidelberg, June 1997.

[KM98] J. Kramer and J. Magee. Analysing dynamic change in software architectures:A case study. In CDS ’98: Proceedings of the International Conference onConfigurable Distributed Systems, page 91, Washington, DC, USA, 1998.IEEE Computer Society.

[KM07] Jeff Kramer and Jeff Magee. Self-managed systems: an architecturalchallenge. In FOSE ’07: 2007 Future of Software Engineering, pages 259–268, Washington, DC, USA, 2007. IEEE Computer Society.

[KSA07] Xu Ke, Krzysztof Sierszecki, and Christo Angelov. Comdes-ii: A component-based framework for generative development of distributed real-time controlsystems. In Proceedings of the 13th IEEE International Conference onEmbedded and Real-Time Computing Systems and Applications, RTCSA ’07,pages 199–208, Washington, DC, USA, 2007. IEEE Computer Society.

[KTS01] Lutz Köster, Thomas Thomsen, and Ralf Stracke. Connecting simulinkto osek: Automatic code generation for real-time operating systems withtargetlink. In Proceedings of SAE Congress, 2001.

[Lam05] Leslie Lamport. Real-time model checking is really simple. October,3725(October):162–175, 2005.

[Lau06] Kung-Kiu Lau. Software component models. In Proceedings of the 28thinternational conference on Software engineering, ICSE ’06, pages 1081–1082, New York, NY, USA, 2006. ACM.

[Lee09] Edward A. Lee. Computing needs time. Communications of the ACM,52(5):70–79, May 2009.


[LM98] D. Le Métayer. Describing software architecture styles using graphgrammars. Software Engineering, IEEE Transactions on, 24(7):521–533, Jul1998.

[LSV01] Nancy Lynch, Roberto Segala, and Frits Vaandrager. Hybrid i/o automatarevisited. In Maria Di Benedetto and Alberto Sangiovanni-Vincentelli,editors, Hybrid Systems: Computation and Control, volume 2034 of LectureNotes in Computer Science, pages 403–417. Springer Berlin / Heidelberg,2001.

[LT87] Nancy A. Lynch and Mark R. Tuttle. Hierarchical correctness proofs fordistributed algorithms. In Proceedings of the sixth annual ACM Symposiumon Principles of distributed computing, PODC ’87, pages 137–151, NewYork, NY, USA, 1987. ACM.

[LW07] Kung-Kiu Lau and Zheng Wang. Software component models. SoftwareEngineering, IEEE Transactions on, 33(10):709 –724, october 2007.

[LWF03] Antónia Lopes, Michel Wermelinger, and José Luiz Fiadeiro. Higher-orderarchitectural connectors. ACM Trans. Softw. Eng. Methodol., 12(1):64–104,January 2003.

[Maa05] Hugh Maaskant. A robust component model for consumer electronicproducts. In Peter Stok, editor, Dynamic and Robust Streaming in andbetween Connected Consumer-Electronic Devices, volume 3 of PhilipsResearch Book Series, pages 167–192. Springer Netherlands, 2005.

[MBG+11] Xiaoxing Ma, Luciano Baresi, Carlo Ghezzi, Valerio Panzica La Manna,and Jian Lu. Version-consistent dynamic reconfiguration of component-based distributed systems. In Proceedings of the 13th European conferenceon Foundations of software engineering, ESEC ’11, pages 245–255. ACM,2011.

[Mey92] B. Meyer. Applying ’design by contract’. Computer, 25(10):40 –51, oct.1992.

[MFR06] Roland Meyer, Johannes Faber, and Andrey Rybalchenko. Model checkingduration calculus: A practical approach. In Kamel Barkaoui, Ana Cavalcanti,and Antonio Cerone, editors, Theoretical Aspects of Computing - ICTAC2006, volume 4281 of Lecture Notes in Computer Science, pages 332–346.Springer Berlin / Heidelberg, 2006. 10.1007/11921240_23.

[Mil82] Robin Milner. A Calculus of Communicating Systems. Springer-Verlag NewYork, Inc., Secaucus, NJ, USA, 1982.


[MK96] Jeff Magee and Jeff Kramer. Dynamic structure in software architectures.SIGSOFT Softw. Eng. Notes, 21(6):3–14, 1996.

[Mon01] Robert T. Monroe. Capturing software architecture design expertisewith armani. Technical Report CMU-CS-98-163R, Computer ScienceDepartment, School of Computer Science, Carnegie Mellon University,January 2001.

[MP92] Zoha Manna and Amir Pnueli. The Temporal Logic of Reactive andConcurrent Systems:Specification. Springer-Verlag, 1992.

[MPW92] Robin Milner, Joachim Parrow, and David Walker. A calculus of mobileprocesses. Information and Computation, 100(1):1–77, 1992.

[MSKC04] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and B. H. C. Cheng. Composingadaptive software. Computer, 37(7):56 – 64, july 2004.

[NSS+11] Florian Nafz, Hella Seebach, Jan-Philipp Steghöfer, Gerrit Anders, andWolfgang Reif. Constraining self-organisation through corridors of correctbehaviour: The restore invariant approach. In Organic Computing — AParadigm Shift for Complex Systems, volume 1 of Autonomic Systems,chapter 1.5, pages 79–93. Springer Basel, 2011.

[Obj09] Object Management Group. UML 2.2 Superstructure Specification, 2009.Document – formal/09-02-02.

[OGT+99] Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimbigner,Gregory Johnson, Nenad Medvidovic, Alex Quilici, David S. Rosenblum, andAlexander L. Wolf. An architecture-based approach to self-adaptive software.IEEE Intelligent Systems, 14(3):54–62, 1999.

[OME+09] Martin Otter, Martin Malmheden, Hilding Elmqvist, Sven Erik Mattsson,and Charlotta Johnsson. A new formalism for modeling of reactive andhybrid systems. In Francesco Casella, editor, Proceedings of the 7thModelica’2009 Conference, Como, Italy, pages 364–377. The ModelicaAssociation, Linköping University Electronic Press, 2009.

[OW07] Cristóvao Oliveira and Michel Wermelinger. The community workbench.Science of Computer Programming, 69(1–3):46 – 55, 2007.

[Oxf92] Oxford University Timed CSP Group. Timed CSP: Theory and practice. InJ. de Bakker, C. Huizing, W. de Roever, and G. Rozenberg, editors, Real-Time: Theory in Practice, volume 600 of Lecture Notes in Computer Science,pages 640–675. Springer Berlin / Heidelberg, 1992. 10.1007/BFb0032011.


[Pal08] Sanjay Kumar Pal. 21st century information technology revolution. Ubiquity,2008(June):9:3–9:3, June 2008.

[PBKS07] Alexander Pretschner, Manfred Broy, Ingolf H. Krüger, and Thomas Stauner.Software engineering for automotive systems: A roadmap. In Lionel C.Briand and Alexander L. Wolf, editors, FOSE, pages 55–71, 2007.

[PKH+11] T. Pop, J. Keznikl, P. Hosek, M. Malohlava, T. Bures, and P. Hnetynka.Introducing support for embedded and real-time devices into existinghierarchical component system: Lessons learned. In Software EngineeringResearch, Management and Applications (SERA), 2011 9th InternationalConference on, pages 3 –11, aug. 2011.

[PWT+08] Marek Prochazka, Roger Ward, Petr Tuma, Petr Hnetynka, and Jiri Adamek.A component-oriented framework for spacecraft on-board software. InProceedings of DASIA 2008, DAta Systems In Aerospace, Palma de Mallorca,European Space Agency Report Nr. SP-665, May 2008.

[RC09] Andres J. Ramirez and Betty H. C. Cheng. Developing and applying designpatterns for dynamically adaptive systems. Technical Report MSU-CSE-09-8, Department of Computer Science, Michigan State University, EastLansing, Michigan, March 2009.

[RC10] Andres J. Ramirez and Betty H. C. Cheng. Design patterns for developingdynamically adaptive systems. In Proceedings of the 2010 ICSE Workshopon Software Engineering for Adaptive and Self-Managing Systems, SEAMS’10, pages 49–58, New York, NY, USA, 2010. ACM.

[Roz97] Grzegorz Rozenberg. Handbook of graph grammars and computing by graphtransformation: volume I. foundations. World Scientific Publishing Co., Inc.,River Edge, NJ, USA, 1997.

[SAE09] SAE. Architecture Analysis & Design Language (AADL), January 2009.Standard AS5506A.

[Sch95] Andy Schürr. Specification of graph translators with triple graph grammars.In Ernst W. Mayr, Gunther Schmidt, and G. Tinhofer, editors, Graph-Theoretic Concepts in Computer Science, volume 903 of Lecture Notes inComputer Science, pages 151–163. Springer Berlin / Heidelberg, 1995.

[SG96] Mary Shaw and David Garlan. Software Architecture: Perspectives on anEmerging Discipline. Prentice Hall, 1996.

[SGW94] Bran Selic, Garth Gullekson, and Paul T. Ward. Real-Time Object-OrientedModeling. John Wiley & Sons, April 1994.


[Sha02] Mary Shaw. "self-healing": softening precision to avoid brittleness: positionpaper for woss ’02: workshop on self-healing systems. In Proceedings ofthe first workshop on Self-healing systems, WOSS ’02, pages 111–114, NewYork, NY, USA, 2002. ACM.

[Smi00] Graeme Smith. The Object-Z Specification Language. Advances in FormalMethods Series. Kluwer Academic Publishers, 2000.

[SPCH08] S. Sentilles, P. Pettersson, I. Crnkovic, and J. Hakansson. Save-ide: Anintegrated development environment for building predictable component-based embedded systems. In Proceedings of the 2008 23rd IEEE/ACMInternational Conference on Automated Software Engineering, ASE ’08,pages 493–494, Washington, DC, USA, 2008. IEEE Computer Society.

[Spi92] J. Michael Spivey. The Z Notation: A Reference Manual. Prentice HallInternational (UK) Ltd., Hertfordshire, UK, UK, 1992.

[SSRB00] Douglas C. Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann.Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrentand Networked Objects. Wiley, 2000.

[SVP09] Cristina Seceleanu, Aneta Vulgarakis, and Paul Pettersson. Remes: Aresource model for embedded systems. In In Proc. of the 14th IEEEInternational Conference on Engineering of Complex Computer Systems(ICECCS 2009). IEEE Computer Society, June 2009.

[Szy98] Clemens Szyperski. Component Software: Beyond Object-OrientedProgramming. Addison-Wesley, 1998.

[Tae02] Gabriele Taentzer. Visual modeling of distributed object systems by graphtransformation. Electronic Notes in Theoretical Computer Science, 51:304 –318, 2002. GETGRATS Closing Workshop.

[tBEKR03] Maurice H. ter Beek, Clarence A. Ellis, Jetty Kleijn,and Grzegorz Rozenberg. Synchronizations in team automata for groupwaresystems. Computer Supported Cooperative Work (CSCW), 12:21–69, 2003.10.1023/A:1022407907596.

[TGM00] Gabriele Taentzer, Michael Goedicke, and Torsten Meyer. Dynamic changemanagement by distributed graph transformation: Towards configurabledistributed systems. In Theory and Application of Graph Transformations,volume 1764 of Lecture Notes in Computer Science, pages 179–193.Springer-Verlag, London, UK, 2000.


[VDI04a] VDI. VDI 2206: Entwicklungsmethodik für mechatronische Systeme. VereinDeutscher Ingenieure, 2004.

[VDI04b] VDI, Verein Deutscher Ingenieure. VDI Guideline 2206, DesignMethodology for Mechatronic Systems. Berlin, 2004.

[VG10] Thomas Vogel and Holger Giese. Adaptation and abstract runtime models.In Proceedings of the 2010 ICSE Workshop on Software Engineering forAdaptive and Self-Managing Systems, SEAMS ’10, pages 39–48, New York,NY, USA, 2010. ACM.

[vOvdLKM00] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The koalacomponent model for consumer electronics software. Computer, 33(3):78–85, mar 2000.

[VSC+09] Aneta Vulgarakis, Jagadish Suryadevara, Jan Carlson, Cristina Seceleanu,and Paul Pettersson. Formal semantics of the procom real-time componentmodel. Software Engineering and Advanced Applications, EuromicroConference, 0:478–485, 2009.

[VSCS10] Aneta Vulgarakis, Séverine Sentilles, Jan Carlson, and Cristina Seceleanu.Connecting procom and remes. Technical Report ISSN 1404-3041 ISRNMDH-MRTC-244/2010-1-SE, Målardalen University, May 2010.

[WDR11] M. T. B. Waez, J. Dingel, and K. Rudie. Timed automata for the developmentof real-time systems. Technical Report 2011-579, Queen’s University, 2011.

[WF02] Michel Wermelinger and José Luiz Fiadeiro. A graph transformationapproach to software architecture reconfiguration. Science of ComputerProgramming, 44(2):133–155, August 2002.

[WLF01] Michel Wermelinger, Antónia Lopes, and José Luiz Fiadeiro. A graphbased architectural (re)configuration language. In Proceedings of the8th European software engineering conference held jointly with 9th ACMSIGSOFT international symposium on Foundations of software engineering,ESEC/FSE-9, pages 21–32, New York, NY, USA, 2001. ACM.

[WMA10] Danny Weyns, Sam Malek, and Jesper Andersson. Forms: a formal referencemodel for self-adaptation. In Proceedings of the 7th international conferenceon Autonomic computing, ICAC ’10, pages 205–214, New York, NY, USA,2010. ACM.

[ZC06] Ji Zhang and Betty H. C. Cheng. Model-based development of dynamicallyadaptive software. In ICSE ’06: Proceedings of the 28th internationalconference on Software engineering, pages 371–380, New York, NY, USA,2006. ACM.


[ZGC09] Ji Zhang, Heather J. Goldsby, and Betty H. C. Cheng. Modular verification ofdynamically adaptive systems. In Proceedings of the 8th ACM internationalconference on Aspect-oriented software development, AOSD ’09, pages 161–172, New York, NY, USA, 2009. ACM.

[ZH04] Chaochen Zhou and Michael R. Hansen. Duration Calculus. Springer, 2004.

Appendix A.


A.1. EPackage modelinstance

Overview The package modelinstance defines the base classes for the FUJABA xmi format.In detail, it defines a root node and model element categories in order to serialize themodel elements that may be contained in a FUJABA model.

RootNode

ModelElementCategory

key : EString

name : EString

isValidElement(EObject) : EBoolean

categories

0..*

Figure A.1.: Meta-Model of the modelinstance Package

A.1.1. EClass ModelElementCategory

Overview The ModelElementCategory contains all model elements of a FUJABA model thathave the same type and will be opened by the same editor. A ModelElementCategorymay only store subclasses of NamedElement.

EAttributes of ModelElementCategory

key : EString [0..1]

The uniquely identifying key of this category. The key of the category may be usedby editors to register for the model elements contained in this section.

name : EString [0..1]

A human readable name for this category.

EReferences of ModelElementCategory

211

212 APPENDIX A. META-MODEL DOCUMENTATION

modelElements : ExtendableElement [0..∗] see Section A.13.2 onPage 313

The ModelElements which are contained in this category. All model elementsmust be of the same type.

EOperations of ModelElementCategory

isValidElement : EBoolean [0..1]

Evaluates for the passed object whether it is a valid model element for thisModelElementCategory.

EParameters

object : EObject [0..1]

The object to be checked as a valid model element for thisModelElementCategory.

body (in Java)boolean v a l i d = f a l s e ;

M o d e l I n s t a n c e P l u g i n p l u g i n = M o d e l I n s t a n c e P l u g i n . g e t I n s t a n c e( ) ;

i f ( p l u g i n != n u l l ) {M o d e l E l e m e n t C a t e g o r y R e g i s t r y r e g i s t r y = p l u g i n .

g e t M o d e l E l e m e n t C a t e g o r y R e g i s t r y ( ) ;v a l i d = r e g i s t r y . i s V a l i d C a t e g o r y ( key , o b j e c t ) ;

}re turn v a l i d ;

OCL Constraints of ModelElementCategory

ExclusivelyContainsValidElements

s e l f . modelElements−> s e l e c t ( e | not i s V a l i d E l e m e n t ( e ) )−>isEmpty ( )

A.1.2. EClass RootNode

Overview The RootNode is the single root element of the XMI file which is generated forthe FUJABA model.

EReferences of RootNode

categories : ModelElementCategory [0..∗] see Section A.1.1 onPage 211

The model element categories which are contained in this RootNode.

A.1. EPACKAGE MODELINSTANCE 213

ecoreDataTypes : EDataType [0..∗]


A.2. EPackage muml::behavior

Overview This package contains classes that are needed to define behavioral aspects withinthe design.

Behavior BehavioralElementOperation

Parameter

ParameterBinding

TypedNamedElement

Variable

constant : EBoolean

behavioralElement0..1

operations0..*

variables0..*

behavior0..1

parameters0..*

parameter1

Figure A.2.: Meta-Model of the behavior Package

A.2.1. Abstract EClass Behavior

Overview Abstract super class for all elements that represent a behavior. Known sub-classes:RealtimeStatechart

EReferences of Behavior

behavioralElement : BehavioralElement [0..1] seeSection A.2.2 on Page 215

The behavioral element this statechart belongs to.

operations : Operation [0..∗] see Section A.2.3 on Page 215

A behavior may define a set of operations as signatures of helper functions.These operations may be called by the behavior specification and may accessthe variables of the behavior specification. The operations are contained in thebehavior.

variables : Variable [0..∗] see Section A.2.7 on Page 216

A behavior may define a set of variables in order to store data. The variables maybe accessed by various elements, e.g., operations and the behavior specificationitself. The variables are contained in the behavior.

A.2. EPACKAGE MUML::BEHAVIOR 215

A.2.2. Abstract EClass BehavioralElement

Overview Abstract super class for all elements that have a behavior.

EReferences of BehavioralElement

behavior : Behavior [0..1] see Section A.2.1 on Page 214

The behavior of this behavioral element.

A.2.3. EClass Operation

Overview An operation specifies a behavior that can be called with a list of concreteparameters and may return a return value.

ESuper Types of Operation

NamedElement see Section A.13.4 on Page 316

CommentableElement see Section A.13.1 on Page 313

EReferences of Operation

implementations : Expression [0..∗] see Section A.14.1 onPage 318

The implementation for this operation. MechatronicUML supports the annotationof multiple implementations for an operation to support different target languages.

parameters : Parameter [0..∗] see Section A.2.4 on Page 215

The ordered parameters of the operation. They define the values that need to bepassed upon calling the operation.

returnType : DataType [1..1] see Section A.10.2 on Page 294

The type of the return value of this operation.

A.2.4. EClass Parameter

Overview This is a general representation of a Parameter which is by all model elements thatreceive parameters. Examples include operations, message types, and synchronizationchannels. A parameter defines a data type.

ESuper Types of Parameter

TypedNamedElement see Section A.2.6 on Page 216



A.2.5. EClass ParameterBinding

Overview A parameter binding associates a parameter with a concrete value which is boundto this parameter by an invocation. As an example, an operation defines a set ofparameters. A call of this operation needs to provide concrete values for the parameterswhich are defined by a parameter binding. The value is represented by an expression.

ESuper Types of ParameterBinding

ExtendableElement see Section A.13.2 on Page 313

EReferences of ParameterBinding

parameter : Parameter [1..1] see Section A.2.4 on Page 215

The mandatory parameter to which the value needs to be associated.

value : Expression [1..1] see Section A.14.1 on Page 318

The mandatory value which is associated with the parameter. The value is definedby an expression.

A.2.6. Abstract EClass TypedNamedElement

Overview Abstract super class for all elements that have a name and a type.

ESuper Types of TypedNamedElement


EReferences of TypedNamedElement

dataType : DataType [1..1] see Section A.10.2 on Page 294

The data type of this element.

A.2.7. EClass Variable

Overview Implementation of a variable of a behavior which has a certain type. A variablehas a type, a name, and is commentable.

ESuper Types of Variable



EAttributes of Variable

constant : EBoolean [1..1]

It must be defined if a the variable is constant or not.

A.2. EPACKAGE MUML::BEHAVIOR 217

EReferences of Variable

initializeExpression : Expression [0..1] see Section A.14.1 onPage 318

A variable may have a value when it is initialized. The value is defined by anexpression.

OCL Constraints of Variable

ConstantMustBeInitialized

−− i f a v a r i a b l e i s a c o n s t a n t , t h e n i t must be i n i t a l i z e d( s e l f . c o n s t a n t = t rue ) i m p l i e s ( not s e l f . i n i t i a l i z e E x p r e s s i o n .

o c l I s U n d e f i n e d ( ) )


A.3. EPackage muml::component

Overview The package components contains all classes for modeling atomic and structuredcomponents. Components are defined on the type level and may be instantiated in acomponent instance configuration.

A.3.1. EClass AssemblyConnector

Overview This class represents an assembly connector. Assembly connectors connect theport parts of two component parts.

ESuper Types of AssemblyConnector

PortConnector see Section A.3.13 on Page 232

EReferences of AssemblyConnector

/coordinationProtocolPart : CoordinationProtocolPart[0..1] see Section A.3.7 on Page 225

The coordination protocol part that this assembly uses.

derivation

s e l f . p o r t P a r t s −> f i r s t ( ) . c o o r d i n a t i o n P r o t o c o l P a r t

/portParts : PortPart [1..2] see Section A.3.15 on Page 233

The port parts that the assembly connects. In case of a self-assembly, this willinclude only one port part.

derivation

s e l f . c o n n e c t o r E n d p o i n t s −> s e l e c t ( c | c . o c l I s K i n d O f ( P o r t P a r t ) ) .oclAsType ( P o r t P a r t )−>a s O r d e r e d S e t ( )

OCL Constraints of AssemblyConnector

SelfAssemblyOnlyForMultiPortsOrMultiParts

−− S e l f a s sembly on ly a l l o w e d f o r m u l t i p o r t s and m u l t icomponent−p a r t s

s e l f C o n n e c t o r i m p l i e sl e t p o r t P a r t : P o r t P a r t = p o r t P a r t s −> f i r s t ( ) i np o r t P a r t . p o r t T y p e . o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) and (

p o r t P a r t . p o r t T y p e . oclAsType ( component : : D i s c r e t e P o r t ) . m u l t i orp o r t P a r t . componen tPa r t . m u l t i P a r t )

−− a u t h o r : bingo , c g e r k i n g , s e e MUML #872

AssemblyBetweenDirectedTypedPortsRequiresSameDataType

A.3. EPACKAGE MUML::COMPONENT 219

Component

com

ponentK

ind :

Com

ponentK

ind

Port

Conti

nuousP

ort

Dis

crete

Port

isD

iscr

ete

InPo

rt :

EB

oole

an

isD

iscr

ete

OutP

ort

: E

Boole

an

isD

iscr

ete

InO

utP

ort

: E

Boole

an

mult

iPort

: E

Boole

an

Com

ponentP

art

mult

iPart

: E

Boole

an

Sta

ticS

truct

ure

dC

om

ponent

AtomicComponent

toStr

ing()

: E

Str

ing

Ass

em

bly

Connect

or

Dele

gati

onC

onnect

or

PortConnector

<<

enum

era

tion>

>C

om

ponentK

ind

SO

FTW

AR

E_C

OM

PO

NEN

T

CO

NTIN

UO

US_C

OM

PO

NEN

T

HYB

RID

_CO

MPO

NEN

T

Hybri

dPo

rt

<<

enum

era

tion>

>Po

rtD

irect

ionK

ind

IN OU

T

StructuredComponent

toStr

ing()

: E

Str

ing

Coord

inati

onPro

toco

lPart

DirectedTypedPort

kind :

Port

Dir

ect

ionK

ind

opti

onal :

EB

oole

an

outP

ort

: E

Boole

an

inPo

rt :

EB

oole

an

Port

Part

nam

e :

EStr

ing

Sta

ticA

tom

icC

om

ponent

StaticC

omponent

port

s0

..*

com

ponent

0..

1

port

Connect

ors

0..

*co

mponentT

ype

1

pare

ntC

om

ponent

1port

Part

s0

..*

coord

inati

onPro

toco

lPart 0..

1

port

Part

s2

port

Part

1

port1

pare

ntC

om

ponent

1

em

beddedC

om

ponentP

art

s1

..*

connect

ors

0..

*

allS

truct

ure

dC

om

ponents

0..

*

allA

tom

icC

om

ponents

0..

*co

ord

inati

onPro

toco

lPart

s0

..*

port

Part

s2

..*

port

Type

1co

mponentP

art

1

coord

inati

onPro

toco

lPart

0..

1

Figure A.3.: Meta-Model of the component Package

−− Assembly between D i r e c t e d T y p e d P o r t s r e q u i r e s same Data Typel e t d i r e c t e d T y p e d P o r t s : Sequence ( component : : D i r e c t e d T y p e d P o r t ) =

p o r t P a r t s . por tType−> s e l e c t ( o c l I s K i n d O f ( component : :D i r e c t e d T y p e d P o r t ) ) . oclAsType ( component : : D i r e c t e d T y p e d P o r t ) i n

d i r e c t e d T y p e d P o r t s −> f o r A l l ( p1 , p2 | p1 . da taType = p2 . da taType )−− a u t h o r : bingo , c g e r k i n g , s e e MUML #873

AssemblyBetweenDiscretePortsOrDirectedTypedPorts

−− Assembly may on ly c o n n e c t e x c l u s i v e l y D i s c r e t e P o r t s ore x c l u s i v e l y D i r e c t e d Typed P o r t s

( p o r t P a r t s . por tType−> f o r A l l ( o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) )or p o r t P a r t s . por tType−> f o r A l l ( o c l I s K i n d O f ( component : :

D i r e c t e d T y p e d P o r t ) ) )−− a u t h o r : bingo , c g e r k i n g , s e e MUML #874

ValidPortDirections

−− Assembly may on ly c o n n e c t D i r e c t e d Typed P o r t s w i th d i f f e r e n tP o r t D i r e c t i o n Kinds

p o r t P a r t s . por tType−> s e l e c t ( o c l I s K i n d O f ( component : :D i r e c t e d T y p e d P o r t ) ) . oclAsType ( component : : D i r e c t e d T y p e d P o r t )−>i s U n i q u e ( k ind )


AssemblyBetweenDiscretePortsRequiresSameCoordinationProtocol

−− Assembly may on ly c o n n e c t p o r t s r e f i n i n g r o l e s o f t h e samec o o r d i n a t i o n p r o t o c o l

p o r t P a r t s . r e f i n e d R o l e −> r e j e c t ( o c l I s U n d e f i n e d ( ) )−> f o r A l l ( r1 , r2 |r1 . c o o r d i n a t i o n P r o t o c o l = r2 . c o o r d i n a t i o n P r o t o c o l )


AssemblyBetweenDiscretePortsRequiresDifferentRoles

−− Assembly may on ly c o n n e c t p o r t s r e f i n i n g d i f f e r e n t r o l e sp o r t P a r t s . r e f i n e d R o l e −> r e j e c t ( o c l I s U n d e f i n e d ( ) )−>i s U n i q u e ( r | r )−− a u t h o r : bingo , c g e r k i n g , s e e MUML #877

AssemblyBetweenDiscretePortsCompatibleMessageTypes

−− Assembly may on ly c o n n e c t d i s c r e t e p o r t s w i th c o m p a t i b l emessage t y p e s ( a . senderMessageTypes = b . r e c e i v e r M e s s a g e T y p e s )

p o r t P a r t s . por tType−> s e l e c t ( o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) ) .oclAsType ( component : : D i s c r e t e P o r t )−>

f o r A l l ( p1 , p2 | p1 <> p2 i m p l i e s p1 . senderMessageTypes−>a s S e t ( ) =p2 . r e c e i v e r M e s s a g e T y p e s−>a s S e t ( ) )


A.3.2. Abstract EClass AtomicComponent

Overview This class represents an atomic component. Atomic components must not befurther sub-divided into component parts. In contrast to structured components atomiccomponents own a behavior in form of a realtime statechart.

The different component types are implemented as a variation of the composite designpattern. Concerning the composite pattern this class represents the role "leaf".

ESuper Types of AtomicComponent

Component see Section A.3.3 on Page 222

BehavioralElement see Section A.2.2 on Page 215

EOperations of AtomicComponent

toString : EString [0..1]

Redefinition of the Java toString method.

body (in Java)re turn " Atomic \ _Component \ _ " + getName ( ) ;

OCL Constraints of AtomicComponent

SoftwareComponentRequiresBehavior

−− S o f t w a r e component must have a b e h a v i o rs e l f . componentKind = component : : ComponentKind : : SOFTWARE\

_COMPONENT i m p l i e s ( not s e l f . b e h a v i o r . o c l I s U n d e f i n e d ( ) )

ValidComponentType

−− Atomic component must be o f t y p e SOFTWARE or CONTINUOUS .s e l f . componentKind = component : : ComponentKind : : SOFTWARE\

_COMPONENTor s e l f . componentKind = component : : ComponentKind : : CONTINUOUS\

_COMPONENT

SoftwareComponentValidPorts

−− S o f t w a r e component must on ly have h y b r i d p o r t s or d i s c r e t ep o r t s

s e l f . componentKind = component : : ComponentKind : : SOFTWARE\_COMPONENTi m p l i e s (

s e l f . p o r t s −> f o r A l l ( p | p . o c l I s K i n d O f ( c o n n e c t o r : :D i s c r e t e I n t e r a c t i o n E n d p o i n t ) or p . o c l I s K i n d O f ( component: : H y b r i d P o r t ) )

)

ContinuousComponentValidPorts


−− C o n t i n u o u s Component must on ly have c o n t i n u o u s p o r t s .s e l f . componentKind = component : : ComponentKind : : CONTINUOUS\

_COMPONENTi m p l i e s (

s e l f . p o r t s −> f o r A l l ( p | p . o c l I s K i n d O f ( component : :C o n t i n u o u s P o r t ) )

)

A.3.3. Abstract EClass Component

Overview This abstract class is the super class of all classes representing a concretecomponent type such as a structured, atomic or a continuous component.

Component types are implemented as a variation of the composite design pattern.Concerning the composite pattern this class represents the role "component".

ESuper Types of Component



ConstrainableElement see Section A.5.1 on Page 245

DataType see Section A.10.2 on Page 294

EAttributes of Component

componentKind : ComponentKind [1..1] see Section A.3.4 onPage 223

This attribute specifies the kind of the component. A component may be eitherdiscrete software component, a continuous component, a hybrid component or ahardware component.

EReferences of Component

ports : Port [0..∗] see Section A.3.12 on Page 232

The ports of a component represent the interaction points between the componentand its environment.

OCL Constraints of Component

UniquePortNames

−− P o r t names must be un iq ues e l f . p o r t s −>i s U n i q u e ( name )

UniqueComponentNames

−− The component ’ s name must be un iq ue .Component . a l l I n s t a n c e s ( )−> s e l e c t ( c | c<> s e l f )−> c o l l e c t ( name )−>

e x c l u d e s ( s e l f . name )−− a u t h o r : adann

A.3.4. EEnumeration ComponentKind

Overview The entries of the enumeration represent different kinds of components. These arediscrete software components, continous components containing controller code, andhybrid components that is a discrete software component which may have continuousinput signals.

ELiterals of ComponentKind

SOFTWARE_COMPONENT = 0

A component of this kind represent discrete software components. A discretesoftware component has a behavior specification which is given by means of areal-time statechart.

CONTINUOUS_COMPONENT = 1

A continuous component represents a continuous controller. Such components donot carry a behavior specification in MechatronicUML. Instead, we assume that thebehavior of such components is modeled by using a control engineering tool likeMatlab/Simulink, Dymola/Modelica or CamelView. In MechatronicUML, onlythe interface of these components is modeled. The interface is given by their ports.

HYBRID_COMPONENT = 2

A hybrid component bridges the gap between discrete software components andcontinuous control components. A hybrid component may be considered as adiscrete software component which has special ports for reading and writingcontinuous signals from and to continuous components, e.g., for setting a newreference value to a controller.

A.3.5. EClass ComponentPart

Overview This class represents a component part. Component parts are used to specifythe inner structure of a structured component. A component part represents anothercomponent that is embedded in a structured component. It is specified on the modellevel and is always typed over a component (either structured or atomic).

ESuper Types of ComponentPart

EAttributes of ComponentPart

/multiPart : EBoolean [0..1]

This derived attribute indicates if the part is a multi part. It is only used to simplifyOCL constraints.

derivation

i f ( not s e l f . c a r d i n a l i t y . o c l I s U n d e f i n e d ( ) and not s e l f .c a r d i n a l i t y . upperBound . o c l I s U n d e f i n e d ( ) ) then

s e l f . c a r d i n a l i t y . upperBound . v a l u e > 1 or s e l f . c a r d i n a l i t y .upperBound . i n f i n i t y

e l s e f a l s ee n d i f

EReferences of ComponentPart

cardinality : Cardinality [1..1] see Section A.11.1 on Page 296

The cardinality of a ComponentPart specifies how many instances of aComponentPart are allowed to exist at runtime.

componentType : Component [1..1] see Section A.3.3 on Page 222

The component type typing this component part.

parentComponent : StructuredComponent [1..1] seeSection A.3.19 on Page 235

The structured component type containing this component part.

portParts : PortPart [0..∗] see Section A.3.15 on Page 233

The ports of this part.

OCL Constraints of ComponentPart

CardinalityLowerBoundSet

−− Lower bound of c a r d i n a l i t y must be s e ti f s e l f . c a r d i n a l i t y . lowerBound . o c l I s U n d e f i n e d ( ) t h e nf a l s ee l s es e l f . c a r d i n a l i t y . lowerBound−>notEmpty ( )e n d i f

TypeNotEqualToParent

−− Component P a r t must have t h e same t y p e as i t s p a r e n ts t r u c t u r e d component

s e l f . componentType <> s e l f . pa ren tComponent


CardinalityUpperBoundSet

−− Upper bound of c a r d i n a l i t y must be s e ti f s e l f . c a r d i n a l i t y . upperBound . o c l I s U n d e f i n e d ( ) t h e nf a l s ee l s es e l f . c a r d i n a l i t y . upperBound−>notEmpty ( )e n d i f

A.3.6. EClass ContinuousPort

Overview This class represents a concrete port specification which provides the continuousfunctionality of a port. A continuous port emits a signal value. A signal value has a datatype and it has concrete values at all points in time.

ESuper Types of ContinuousPort

DirectedTypedPort see Section A.3.9 on Page 228

A.3.7. EClass CoordinationProtocolPart

Overview A coordination protocol (pattern) can occur within a structured component. Itdefines the communication behavior of an assembly connection that connects discreteports with each other.

ESuper Types of CoordinationProtocolPart


EReferences of CoordinationProtocolPart

coordinationProtocol : CoordinationProtocol [1..1] seeSection A.8.3 on Page 263

The coordination protocol (pattern) of this CoordinationProtocolPart.

portParts : PortPart [2..∗] see Section A.3.15 on Page 233

The discrete port parts that take part in this protocol part.

OCL Constraints of CoordinationProtocolPart

OnlyDiscretePortParts

−− C o o r d i n a t i o n P r o t o c o l P a r t must on ly have d i s c r e t e P o r t P a r t snot s e l f . p o r t P a r t s −>o c l I s U n d e f i n e d ( )i m p l i e ss e l f . p o r t P a r t s −> f o r A l l ( p : P o r t P a r t | p . p o r t T y p e . o c l I s K i n d O f (

D i s c r e t e P o r t ) )


A.3.8. EClass DelegationConnector

Overview This class represents a delegation connector. A delegation connector connects aport of a structured component type and a port part of component part the structuredcomponent contains. The delegation has no behavior. In a running system, the port ofthe structured component and the port of the component part will be the same objectlike interfaces of classes where interface and class are the same object at runtime.

ESuper Types of DelegationConnector

PortConnector see Section A.3.13 on Page 232

EReferences of DelegationConnector

/port : Port [1..1] see Section A.3.12 on Page 232

The delegating port for this delegation.

derivation

s e l f . c o n n e c t o r E n d p o i n t s −> s e l e c t ( c | c . o c l I s K i n d O f ( P o r t ) ) .oclAsType ( P o r t ) −> any ( t r u e )

/portPart : PortPart [1..1] see Section A.3.15 on Page 233

The port part that this delegation delegates to.

derivation

s e l f . c o n n e c t o r E n d p o i n t s −> s e l e c t ( c | c . o c l I s K i n d O f ( P o r t P a r t ) ) .oclAsType ( P o r t P a r t ) −> any ( t r u e )

OCL Constraints of DelegationConnector

DelegationBetweenDirectedTypedPortsRequiresSameDataType

−− D e l e g a t i o n between D i r e c t e d T y p e d P o r t s r e q u i r e s same Data Type( not p o r t P a r t . p o r t T y p e . o c l I s U n d e f i n e d ( ) and not p o r t .

o c l I s U n d e f i n e d ( ) and p o r t P a r t . p o r t T y p e . o c l I s K i n d O f ( component : :D i r e c t e d T y p e d P o r t ) and p o r t . o c l I s K i n d O f ( component : :D i r e c t e d T y p e d P o r t ) )

i m p l i e sp o r t P a r t . p o r t T y p e . oclAsType ( component : : D i r e c t e d T y p e d P o r t ) .

da t aType = p o r t . oclAsType ( component : : D i r e c t e d T y p e d P o r t ) .da t aType


DelegationBetweenDiscretePortsOrDirectedTypedPorts

−− D e l e g a t i o n may on ly c o n n e c t e x c l u s i v e l y D i s c r e t e P o r t s ore x c l u s i v e l y D i r e c t e d Typed P o r t s

( not p o r t P a r t . p o r t T y p e . o c l I s U n d e f i n e d ( ) and not p o r t .o c l I s U n d e f i n e d ( ) )


i m p l i e sl e t p o r t s : O r d e r e d S e t ( P o r t ) = O r d e r e d S e t { p o r t P a r t . por tType ,

p o r t } i n( p o r t s −> f o r A l l ( o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) ) or p o r t s −>

f o r A l l ( o c l I s K i n d O f ( component : : D i r e c t e d T y p e d P o r t ) ) )−− a u t h o r : bingo , c g e r k i n g , s e e MUML #880

DelegationBetweenDiscretePortsEqualMessageTypes−− D e l e g a t i o n may on ly c o n n e c t d i s c r e t e p o r t s w i th e q u a l message

t y p e s( not p o r t P a r t . p o r t T y p e . o c l I s U n d e f i n e d ( ) and not p o r t .

o c l I s U n d e f i n e d ( ) )i m p l i e sl e t p o r t s : O r d e r e d S e t ( P o r t ) = O r d e r e d S e t { p o r t P a r t . por tType ,

p o r t } i np o r t s −> s e l e c t ( o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) ) . oclAsType (

component : : D i s c r e t e P o r t )−> f o r A l l ( p1 , p2 | p1 .senderMessageTypes−>a s S e t ( ) = p2 . senderMessageTypes−>a s S e t ( )and p1 . r e c e i v e r M e s s a g e T y p e s−>a s S e t ( ) = p2 . r e c e i v e r M e s s a g e T y p e s−>a s S e t ( ) )


ValidPortDirections−− D e l e g a t i o n may on ly c o n n e c t D i r e c t e d Typed P o r t s w i th

d i f f e r e n t P o r t D i r e c t i o n Kinds( not p o r t P a r t . p o r t T y p e . o c l I s U n d e f i n e d ( ) and not p o r t .

o c l I s U n d e f i n e d ( ) )i m p l i e sl e t p o r t s : O r d e r e d S e t ( P o r t ) = O r d e r e d S e t { p o r t P a r t . por tType ,

p o r t } i n p o r t s −> s e l e c t ( o c l I s K i n d O f ( component : :D i r e c t e d T y p e d P o r t ) ) . oclAsType ( component : : D i r e c t e d T y p e d P o r t )−>f o r A l l ( p1 , p2 | p1 . k ind = p2 . k ind )


DelegationBetweenDiscretePortsRequiresSameRoles−− D e l e g a t i o n may on ly c o n n e c t p o r t s r e f i n i n g same r o l e s( not p o r t P a r t . p o r t T y p e . o c l I s U n d e f i n e d ( ) and not p o r t .

o c l I s U n d e f i n e d ( ) and s e l f . p o r t . o c l I s K i n d O f ( D i s c r e t e P o r t ) )i m p l i e ss e l f . p o r t . oclAsType ( D i s c r e t e P o r t ) . r e f i n e d R o l e = s e l f . p o r t P a r t .

r e f i n e d R o l e−− a u t h o r : bingo , c g e r k i n g , s e e MUML #883

DiscreteMultiPortDelegationRequiresMultiPortOrSinglePortAndMultiPart−− D e l e g a t i o n s t a r t i n g a t M u l t i P o r t must c o n n e c t t o a m u l t i p o r t

or s i n g l e p o r t a t m u l t i p a r t( not p o r t P a r t . p o r t T y p e . o c l I s U n d e f i n e d ( ) and not p o r t .

o c l I s U n d e f i n e d ( ) and s e l f . p o r t . o c l I s K i n d O f ( D i s c r e t e P o r t ) ands e l f . p o r t . oclAsType ( D i s c r e t e P o r t ) . m u l t i )


i m p l i e s( ( s e l f . p o r t P a r t . p o r t T y p e . o c l I s K i n d O f ( D i s c r e t e P o r t ) and s e l f .

p o r t P a r t . p o r t T y p e . oclAsType ( D i s c r e t e P o r t ) . m u l t i ) or s e l f .p o r t P a r t . componen tPa r t . m u l t i P a r t )


DelegateToEmbeddedPort

−− D e l e g a t i o n must d e l e g a t e t o a P o r t a t an embedded ComponentP a r t .

i f p o r t P a r t . o c l I s U n d e f i n e d ( ) or p o r t P a r t . componen tPa r t .o c l I s U n d e f i n e d ( ) or p o r t . o c l I s U n d e f i n e d ( ) t h e nt rue

e l s ep o r t P a r t . componen tPa r t . pa ren tComponent = p o r t . component

e n d i f

A.3.9. Abstract EClass DirectedTypedPort

Overview Directed typed port is the common super class of continuous and hybrid ports.A directed typed port has a direction (either IN or OUT) and specifies a data type. Atpresent, we only support primitive and array data types, where the array elements needto have a primitive type.

ESuper Types of DirectedTypedPort

Port see Section A.3.12 on Page 232


EAttributes of DirectedTypedPort

/inPort : EBoolean [0..1]

This derived attribute indicates if the port is an IN port

derivation

s e l f . k ind = component : : P o r t D i r e c t i o n K i n d : : IN

kind : PortDirectionKind [1..1] see Section A.3.14 on Page 233

Defines the direction of this directed typed port.

optional : EBoolean [0..1]

Decides if this port is optional. An optional port does not need to be instantiatedin all instances of the containing component.

/outPort : EBoolean [0..1]

This derived attribute indicates if the port is an OUT port

derivation

s e l f . k ind = component : : P o r t D i r e c t i o n K i n d : : OUT

EReferences of DirectedTypedPort

initializeExpression : Expression [0..1] see Section A.14.1 onPage 318

A initialize expression specifies the initial value that is emitted by the port after ithas been instantiated. Thus, we only provide initialize expressions for out-port.

OCL Constraints of DirectedTypedPort

InitializeExpressionOnlyForOutPorts

−− Only o u t p o r t s may have an i n i t i a l i z e e x p r e s s i o n .s e l f . k ind <> component : : P o r t D i r e c t i o n K i n d : : OUT i m p l i e s s e l f .

i n i t i a l i z e E x p r e s s i o n . o c l I s U n d e f i n e d ( )

A.3.10. EClass DiscretePort

Overview This class represents a concrete port specification which provides the discretefunctionality of a port.

ESuper Types of DiscretePort

Port see Section A.3.12 on Page 232

DiscreteInteractionEndpoint see Section A.4.5 on Page 240

EAttributes of DiscretePort

/isDiscreteInOutPort : EBoolean [0..1]

This derived attribute indicates if the discrete port is an IN OUT port

derivation

s e l f . r e c e i v e r M e s s a g e T y p e s −> s i z e ( ) >= 1 and s e l f .s enderMessageTypes −> s i z e ( ) >= 1

/isDiscreteInPort : EBoolean [0..1]

This derived attribute indicates if the discrete port is an IN port

derivation

s e l f . r e c e i v e r M e s s a g e T y p e s −> s i z e ( ) >= 1 and s e l f .s enderMessageTypes −> s i z e ( ) = 0

/isDiscreteOutPort : EBoolean [0..1]

This derived attribute indicates if the discrete port is an OUT port


derivations e l f . r e c e i v e r M e s s a g e T y p e s −> s i z e ( ) = 0 and s e l f .

s enderMessageTypes −> s i z e ( ) >= 1

/multiPort : EBoolean [1..1]

This derived attribute indicates if the port is a multi port.

derivations e l f . m u l t i

EReferences of DiscretePort

/coordinationProtocol : CoordinationProtocol [0..1] seeSection A.8.3 on Page 263

Derives the coordinationProtocol of the refined port.

derivationi f r e f i n e d R o l e . o c l I s U n d e f i n e d ( ) then

n u l le l s e

r e f i n e d R o l e . c o o r d i n a t i o n P r o t o c o l . o c l I s K i n d O f ( p r o t o c o l : :C o o r d i n a t i o n P r o t o c o l ) . oclAsType ( p r o t o c o l : :C o o r d i n a t i o n P r o t o c o l )

e n d i f

refinedRole : Role [0..1] see Section A.8.4 on Page 264

The role of a coordination protocol that this port refines.

OCL Constraints of DiscretePort

DiscretePortRequiresMessageTypes−− D i s c r e t e P o r t must d e f i n e s e n d e r or r e c e i v e r message t y p e ss e l f . senderMessageTypes−>notEmpty ( ) or s e l f . r e c e i v e r M e s s a g e T y p e s−>notEmpty ( )

DiscretePortRequiresBehavior−− A d i s c r e t e p o r t o f an a t omi c component must have a B e h a v i o r

S p e c i f i c a t i o n( not s e l f . component . o c l I s U n d e f i n e d ( ) and s e l f . component .

o c l I s K i n d O f ( component : : AtomicComponent ) )i m p l i e s not s e l f . b e h a v i o r . o c l I s U n d e f i n e d ( )

DiscretePortAtStructuredComponentHasNoBehavior−− D i s c r e t e P r o t a t S t r u c t u r e d Component must not have b e h a v i o r( not s e l f . component . o c l I s U n d e f i n e d ( ) and s e l f . component .

o c l I s K i n d O f ( component : : S t r u c t u r e d C o m p o n e n t ) )i m p l i e s s e l f . b e h a v i o r . o c l I s U n d e f i n e d ( )


DiscretePortRequiresRole

−− D i s c r e t e P o r t must r e f i n e a r o l es e l f . o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) i m p l i e s not s e l f .

r e f i n e d R o l e . o c l I s U n d e f i n e d ( )

DiscretePortAndRoleSameMessageTypes

−− D i s c r e t e P o r t must have t h e same message t y p e s as i t s r e f i n e dr o l e

not s e l f . r e f i n e d R o l e . o c l I s U n d e f i n e d ( ) i m p l i e s( s e l f . s enderMessageTypes = s e l f . r e f i n e d R o l e . sende rMessageTypes

ands e l f . r e c e i v e r M e s s a g e T y p e s = s e l f . r e f i n e d R o l e .

r e c e i v e r M e s s a g e T y p e s)

DiscretePortCardinalityMustComplyWithRefinedRoleCardinality

−− C a r d i n a l i t y o f d i s c r e t e p o r t and i t s r e f i n e d r o l e must match( ( not s e l f . c a r d i n a l i t y . o c l I s U n d e f i n e d ( ) ) and ( not s e l f .

r e f i n e d R o l e . o c l I s U n d e f i n e d ( ) ) )i m p l i e s( ( not s e l f . m u l t i ) or s e l f . c a r d i n a l i t y . lowerBound . g r e a t e r O r E q u a l (

s e l f . r e f i n e d R o l e . c a r d i n a l i t y . lowerBound ) and s e l f . c a r d i n a l i t y .upperBound . l e s s O r E q u a l ( s e l f . r e f i n e d R o l e . c a r d i n a l i t y . upperBound) )

MultiPortOfAtomicComponentRequiresRoleAndAdaptationBehavior

−− M u l t i p o r t o f a tom ic component r e q u i r e s a d a p t a t i o n B e h a v i o r andr o l e A n d A d a p t a t i o n B e h a v i o r

( s e l f . m u l t i P o r t and s e l f . component . o c l I s K i n d O f ( AtomicComponent ) )i m p l i e s( ( not s e l f . a d a p t a t i o n B e h a v i o r . o c l I s U n d e f i n e d ( ) ) and ( not s e l f .

r o l e A n d A d a p t a t i o n B e h a v i o r . o c l I s U n d e f i n e d ( ) ) )

A.3.11. EClass HybridPort

Overview This class represents a hybrid port which acts as a bridge between continuouscontrollers and discrete software. A hybrid port emits or receives a signal value whichhas a data type and a concrete value at all points in time. Then, the hybrid port discretizesthe signal value in given time intervals and provides the value as variable to its Real-Time Statechart. The hybrid port does not define message interfaces.

ESuper Types of HybridPort

DirectedTypedPort see Section A.3.9 on Page 228

EReferences of HybridPort


samplingInterval : TimeValue [1..1] see Section A.11.5 onPage 300

The sampling interval defines the time between two updates of the continuoussignal which is received or send by this hybrid port. If the port is an IN-port,the sampling interval defines how often the continuous signal is read and storedinternally. If the hybrid port in an OUT-port, the sampling interval defines howoften a new value is send via this port.

A.3.12. Abstract EClass Port

Overview Ports represent the interaction points between a component and the componentsenvironment.

ESuper Types of Port

ConnectorEndpoint see Section A.4.2 on Page 239



EReferences of Port

component : Component [0..1] see Section A.3.3 on Page 222

The component, this port belongs to. Theoretically the bounds should be 1..1,but that would prevent the possibility for ComponentPart.portsDerived to be acontainment reference (see ComponentPart.portsDerived)

/portConnectors : PortConnector [0..∗] see Section A.3.13 onPage 232

Derived reference that returns all connectors that are attached to the Port that areof type PortConnector.

derivation

s e l f . c o n n e c t o r s −> s e l e c t ( c | c . o c l I s K i n d O f ( P o r t C o n n e c t o r ) ) .oclAsType ( P o r t C o n n e c t o r )−>a s O r d e r e d S e t ( )

A.3.13. Abstract EClass PortConnector

Overview This abstract class is the common super class of delegations and assembliesbetween two ports.

ESuper Types of PortConnector

Connector see Section A.4.1 on Page 238


EReferences of PortConnector

parentComponent : StructuredComponent [1..1] seeSection A.3.19 on Page 235

The structured component this connector belongs to.

A.3.14. EEnumeration PortDirectionKind

Overview Decides the direction of a continous port.

ELiterals of PortDirectionKind

IN = 0

Represent an IN-Port of a continous port.

OUT = 1

Represent an OUT-Port of a continous port.

A.3.15. EClass PortPart

Overview PortParts are contained in ComponentParts. They represent a port of a componentin the part structure inside a structured component. PortParts are the endpoints forAssemblyConnectors and DelegationConnectors.

ESuper Types of PortPart


EAttributes of PortPart

/name : EString [0..1]

The name of the port type.

derivationi f p o r t T y p e . name . o c l I s U n d e f i n e d ( ) then

n u l le l s e

p o r t T y p e . namee n d i f

EReferences of PortPart

componentPart : ComponentPart [1..1] see Section A.3.5 onPage 223

The component part that contains this PortPart. The port reference by the portTypereference needs to be contained in the component that is referenced by thisreference.


coordinationProtocolPart : CoordinationProtocolPart[0..1] see Section A.3.7 on Page 225

If the port type refines a role, this part refers to the enclosing coordination protocol.

portType : Port [1..1] see Section A.3.12 on Page 232

The port of the component that is represented by this PortPart.

/refinedRole : Role [0..1] see Section A.8.4 on Page 264

The role of a coordination protocol that this partial instance of a port refines.

derivation

i f ( s e l f . p o r t T y p e . o c l I s K i n d O f ( D i s c r e t e P o r t ) ) thens e l f . p o r t T y p e . oclAsType ( D i s c r e t e P o r t ) . r e f i n e d R o l ee l s en u l le n d i f

A.3.16. EClass StaticAtomicComponent

Overview A static atomic component is an atomic component whose internal structureconsisting of its set of ports cannot be changed during run-time.

ESuper Types of StaticAtomicComponent

AtomicComponent see Section A.3.2 on Page 221

StaticComponent see Section A.3.17 on Page 234

A.3.17. Abstract EClass StaticComponent

Overview A static component is a component whose internal structure cannot be changedduring run-time.

ESuper Types of StaticComponent


OCL Constraints of StaticComponent

SoftwareComponentOnlyDiscreteOrHybridPorts

−− S t a t i c s o f t w a r e components must on ly have d i s c r e t e p o r t s andh y b r i d p o r t s .

s e l f . componentKind = ComponentKind : : SOFTWARE\_COMPONENT i m p l i e ss e l f . p o r t s −> r e j e c t ( p | p . o c l I s K i n d O f ( D i s c r e t e P o r t ) or p .o c l I s K i n d O f ( H y b r i d P o r t ) )−>isEmpty ( )


A.3.18. EClass StaticStructuredComponent

Overview A static structured component is a structured component whose internal structureconsisting of component part, ports, delegation, and assemblies cannot be changedduring run-time.

ESuper Types of StaticStructuredComponent

StructuredComponent see Section A.3.19 on Page 235

StaticComponent see Section A.3.17 on Page 234

OCL Constraints of StaticStructuredComponent

StaticStructuredComponentMustNotHaveWrongDiscreteInteractionEndpoints

−− S t a t i c S t r u c t u r e d Component must not have D i s c r e t e I n t e r a c t i o nE n d p o i n t s o t h e r t h a n D i s c r e t e P o r t s

p o r t s −> f o r A l l ( p | p . o c l I s K i n d O f ( c o n n e c t o r : :D i s c r e t e I n t e r a c t i o n E n d p o i n t ) i m p l i e s p . o c l I s K i n d O f (D i s c r e t e P o r t ) )

A.3.19. Abstract EClass StructuredComponent

Overview This class represents a structured component which is capable of includingarbitraryly many component parts.

ESuper Types of StructuredComponent


EReferences of StructuredComponent

/allAtomicComponents : AtomicComponent [0..∗] seeSection A.3.2 on Page 221

Transitive closure of all AtomicComponents which are used (specified as acomponentType for a ComponentPart) in the component hierarchy. Note:AtomicComponents from directly embeddedParts are NOT included

derivation

s e l f . a l l S t r u c t u r e d C o m p o n e n t s −> c o l l e c t (embeddedComponentPar ts−> s e l e c t (

componentType . o c l I s K i n d O f ( component : : AtomicComponent ))−> c o l l e c t ( componentType . oclAsType ( component : :

AtomicComponent ) ))−>a s O r d e r e d S e t ( )


/allStructuredComponents : StructuredComponent [0..∗]see Section A.3.19 on Page 235

Transitive closure of all StructuredComponents which are used (specified as acomponentType for a ComponentPart) in the component hierarchy.

derivations e l f −> c l o s u r e (

embeddedComponentPar ts−> s e l e c t (componentType . o c l I s K i n d O f ( S t r u c t u r e d C o m p o n e n t )

) . componentType . oclAsType ( S t r u c t u r e d C o m p o n e n t ))

connectors : PortConnector [0..∗] see Section A.3.13 on Page 232

The connectors this structured component contains. These can either bedelegations or assemblies.

coordinationProtocolParts : CoordinationProtocolPart[0..∗] see Section A.3.7 on Page 225

This reference is needed by GMF to visualize the CoordinationProtocols withinthe StructuredComponent.

embeddedComponentParts : ComponentPart [1..∗] seeSection A.3.5 on Page 223

The component parts this structured component contains.

EOperations of StructuredComponent


Redefinition of the Java toString method.

body (in Java)re turn " S t r u c t u r e d \ _Component \ _ " + getName ( ) ;

OCL Constraints of StructuredComponent

StructuredComponentAllowsNoHybridPorts−− A s t r u c t u r e d component a l l o w s no h y b r i d p o r t s .s e l f . p o r t s −> f o r A l l ( p o r t | not p o r t . o c l I s K i n d O f ( component : :

H y b r i d P o r t ) )

ValidComponentType−− S t r u c t u r e d components must be e i t h e r s o f t w a r e or h y b r i d

componentss e l f . componentKind = component : : ComponentKind : : SOFTWARE\

_COMPONENTor s e l f . componentKind = component : : ComponentKind : : HYBRID \

_COMPONENT


NoCyclicComponentPartHierarchy−− H i e r a r c h y of embedded component p a r t s must not i n c l u d e m ys e l fi f s e l f . a l l S t r u c t u r e d C o m p o n e n t s −>o c l I s U n d e f i n e d ( ) t h e nf a l s ee l s enot s e l f . a l l S t r u c t u r e d C o m p o n e n t s −> i n c l u d e s ( s e l f )e n d i f

DiscreteStructuredComponentValidParts−− S t r u c t u r e d s o f t w a r e component must on ly have s o f t w a r e

component p a r t si f ( not s e l f . a l lAtomicComponents−>o c l I s U n d e f i n e d ( ) ) t h e ns e l f . componentKind = component : : ComponentKind : : SOFTWARE\

_COMPONENTi m p l i e s−− c o l l e c t a l l a t om ic components from p a r e n t p a r t s and union

them−− wi th own a tom ic componentss e l f . a l lAtomicComponents−>union (

s e l f . embeddedComponentPar ts−> s e l e c t (componentType . o c l I s K i n d O f ( component : : AtomicComponent )

)−> c o l l e c t ( componentType . oclAsType ( component : :AtomicComponent ) )−>a s O r d e r e d S e t ( )

)−> f o r A l l ( componentKind = component : : ComponentKind : : SOFTWARE\_COMPONENT)

e l s et ruee n d i f

HybridStructuredComponentValidPorts−− S t r u c t u r e d h y b r i d component must on ly have d i s c r e t e or

c o n t i n u o u s p o r t ss e l f . componentKind = component : : ComponentKind : : HYBRID \_COMPONENT

i m p l i e s (s e l f . p o r t s −> f o r A l l ( p | p . o c l I s K i n d O f ( c o n n e c t o r : :

D i s c r e t e I n t e r a c t i o n E n d p o i n t ) or p . o c l I s K i n d O f ( component: : C o n t i n u o u s P o r t ) )

)

ComponentPartsHaveUniqueName−− Names of embedded component p a r t s must be un iqu es e l f . embeddedComponentPar ts −> i s U n i q u e ( name )

SoftwareComponentNoContinuousPorts−− S o f t w a r e component must not have c o n t i n u o u s p o r t ss e l f . componentKind = ComponentKind : : SOFTWARE\_COMPONENT i m p l i e s

s e l f . p o r t s −> f o r A l l ( p | not p . o c l I s K i n d O f ( C o n t i n u o u s P o r t ) )


A.4. EPackage muml::connector

Overview This package defines a set of abstract classes that form the basis for all connectorsthat we use in our meta-model. They define the connectors, different types of endpointsthat are connected by connectors, and their instances.

ConnectorEndpoint

Connector

selfConnector : EBoolean

ConnectorEndpointInstance

ConnectorInstance

DiscreteInteractionEndpoint

multi : EBoolean

DiscreteInteractionEndpointInstance

DiscreteSingleInteractionEndpointInstance

DiscreteMultiInteractionEndpointInstance

MessageBuffer

connectors0..*

connectorEndpoints1..2

connectorInstances0..*

type1

type0..1

connectorEndpointInstances2

receiverMessageBuffer0..*

multiInteractionEndpointInstance

0..1

next0..1

previous0..1

subInteractionEndpointInstances0..*

first0..1

last0..1

discreteInteractionEndpoint1

Figure A.4.: Meta-Model of the connector Package

A.4.1. Abstract EClass Connector

Overview A connector connects up to two connector endpoints. In case of a self-connector,there is only one endpoint.

ESuper Types of Connector


EAttributes of Connector

/selfConnector : EBoolean [1..1]

Indicates a self-connector, i.e., whether this connector connects one and the sameendpoint to itself.

A.4. EPACKAGE MUML::CONNECTOR 239

derivation

s e l f . c o n n e c t o r E n d p o i n t s −> s i z e ( ) = 1−− a u t h o r : bingo , c g e r k i n g , s e e MUML #872

EReferences of Connector

connectorEndpoints : ConnectorEndpoint [1..2] seeSection A.4.2 on Page 239

The endpoints connected by this connector.

A.4.2. Abstract EClass ConnectorEndpoint

Overview An endpoint that may be connected to other endpoints via connectors.

ESuper Types of ConnectorEndpoint


EReferences of ConnectorEndpoint

connectors : Connector [0..∗] see Section A.4.1 on Page 238

The connectors attached to this endpoint.

A.4.3. Abstract EClass ConnectorEndpointInstance

Overview An instance of a particular connector endpoint.

ESuper Types of ConnectorEndpointInstance



EReferences of ConnectorEndpointInstance

connectorInstances : ConnectorInstance [0..∗] seeSection A.4.4 on Page 240

The connector instances attached to this endpoint instance.

type : ConnectorEndpoint [1..1] see Section A.4.2 on Page 239

The connector endpoint that represents the type of this instance.


A.4.4. Abstract EClass ConnectorInstance

Overview An instance of a particular connector.

ESuper Types of ConnectorInstance


EReferences of ConnectorInstance

connectorEndpointInstances : ConnectorEndpointInstance[2..2] see Section A.4.3 on Page 239

The connector endpoint instances connected by this connector instance.

type : Connector [0..1] see Section A.4.1 on Page 238

The connector that represents the type of this connector instance. May beundefined in case of a top level connector instance, which does not refer to aparticular connector inside a structured component.

A.4.5. Abstract EClass DiscreteInteractionEndpoint

Overview An interaction point for discrete communication via asynchronous messages. Thisclass generalizes concepts of classes DiscretePort and Role.

ESuper Types of DiscreteInteractionEndpoint


BehavioralElement see Section A.2.2 on Page 215



EAttributes of DiscreteInteractionEndpoint

/multi : EBoolean [1..1]

This derived attribute indicates if the discrete interaction endpoint has a maximumcardinality greater than one .

derivation

i f not ( s e l f . c a r d i n a l i t y . o c l I s U n d e f i n e d ( ) ) then( s e l f . c a r d i n a l i t y . upperBound . v a l u e > 1) or s e l f .

c a r d i n a l i t y . upperBound . i n f i n i t ye l s e

f a l s ee n d i f

EReferences of DiscreteInteractionEndpoint


adaptationBehavior : Behavior [0..1] see Section A.2.1 onPage 214

If this port is a multi-port, this reference points to the real-time statechart thatcontains the adaptation behavior of the multi-port. Then, this real-time statechartis contained in the only state of the real-time statechart we is obtained by thereference roleAndAdaptationBehavior. If this port is a single-port, this referencewill be undefined.

cardinality : Cardinality [1..1] see Section A.11.1 on Page 296

The cardinality of a port specifies how many instances of a port are allowed toexist at runtime.

receiverMessageBuffer : MessageBuffer [0..∗] seeSection A.4.9 on Page 243

A role contains message buffers to store received messages. If this role can onlysend messages then no message buffer is allowed; otherwise at least one messagebuffer must be defined. The maximal number of message buffers is limited to thenumber of message this role may receive.

receiverMessageTypes : MessageType [0..∗] see Section A.7.1 onPage 259

The receiver message interface defines which messages this discrete portspecification receives.

roleAndAdaptationBehavior : Behavior [0..1] see Section A.2.1on Page 214

If this port is a multi-port, this reference points to the real-time statechart thatcontains the adaptation behavior and the sub-port behavior. Thus, this real-time statechart only contains one state which embeds the real-time statechartsspecifying the adaptation behavior and the sub-port behavior.

senderMessageTypes : MessageType [0..∗] see Section A.7.1 onPage 259

The sender message interface defines which messages this discrete portspecification sends.

OCL Constraints of DiscreteInteractionEndpoint

ReceivingInteractionEndpointRequiresMessageBuffer

−− R e c e i v e r message t y p e s need r e c e i v e r message b u f f e rs e l f . r e c e i v e r M e s s a g e T y p e s−>notEmpty ( )i m p l i e ss e l f . r e c e i v e r M e s s a g e B u f f e r −>notEmpty ( )

ReceiverMessageTypeMustBeAssignedToExactlyOneBuffer


−− Each r e c e i v e r message t y p e s h o u l d be a s s i g n e d t o e x a c t l y oneb u f f e r

s e l f . r e c e i v e r M e s s a g e T y p e s−> f o r A l l ( t y p e | s e l f .r e c e i v e r M e s s a g e B u f f e r −>one ( messageType−> i n c l u d e s ( t y p e ) ) )

A.4.6. Abstract EClassDiscreteInteractionEndpointInstance

Overview An instance of a discrete interaction endpoint.

ESuper Types of DiscreteInteractionEndpointInstance

ConnectorEndpointInstance see Section A.4.3 on Page 239

A.4.7. Abstract EClassDiscreteMultiInteractionEndpointInstance

Overview A discrete interaction endpoint instance that comprises multiple single sub-instances.

ESuper Types of DiscreteMultiInteractionEndpointInstance

DiscreteInteractionEndpointInstance see Section A.4.6 on Page 242

EReferences of DiscreteMultiInteractionEndpointInstance

first : DiscreteSingleInteractionEndpointInstance [0..1]see Section A.4.8 on Page 243

Refers to the first single instance of the corresponding multi discrete interactionendpoint.

last : DiscreteSingleInteractionEndpointInstance [0..1]see Section A.4.8 on Page 243

Refers to the last single instance of the corresponding multi discrete interactionendpoint.

subInteractionEndpointInstances :DiscreteSingleInteractionEndpointInstance [0..∗] seeSection A.4.8 on Page 243

These are all sub-interaction endpoint instances of the multi-interactionendpoint instance. The sub-interaction endpoint instances are represented byDiscreteSingleInteractionEndpointInstances. This reference may only be used ifthe corresponding DiscreteInteractionEndpoint has an upper bound greater 1 in itscardinality.


A.4.8. Abstract EClassDiscreteSingleInteractionEndpointInstance

Overview A single instance of a discrete interaction endpoint.

ESuper Types of DiscreteSingleInteractionEndpointInstance


EReferences of DiscreteSingleInteractionEndpointInstance

multiInteractionEndpointInstance :DiscreteMultiInteractionEndpointInstance [0..1] seeSection A.4.7 on Page 242

If this is an instance of a multi discrete interaction endpoint, refers to thecorresponding multi instance.

next : DiscreteSingleInteractionEndpointInstance [0..1]see Section A.4.8 on Page 243

If this is an instance of a multi discrete interaction endpoint, refers to the nextsingle instance.

previous : DiscreteSingleInteractionEndpointInstance[0..1] see Section A.4.8 on Page 243

If this is an instance of a multi discrete interaction endpoint, refers to the previoussingle instance.

A.4.9. EClass MessageBuffer

Overview A message buffer may contains message types. A message buffer has a specifiedsize and is associtated to a role of a coordination protocol. Message types are alwaysstored in FIFO order.

ESuper Types of MessageBuffer


EReferences of MessageBuffer

bufferSize : NaturalNumber [1..1] see Section A.11.2 on Page 296

The size of the message buffer.

discreteInteractionEndpoint: DiscreteInteractionEndpoint [1..1] see Section A.4.5 onPage 240

The role that contains this message buffer.


messageType : MessageType [1..∗] see Section A.7.1 on Page 259

The message types this message buffer can store.

A.5. EPACKAGE MUML::CONSTRAINT 245

A.5. EPackage muml::constraint

Overview The package constraint provides abstract super classes for modeling differentkinds of constraints that may be attached to ConstrainableElements of theMechatronicUML meta-model.

Constraint

correctness : Correctness

background : EBoolean

correct : EBoolean

<<enumeration>>Correctness

UNKNOWN

CORRECT

VIOLATED

ModelingConstraint VerifiableConstraint

TextualConstraint

ConstrainableElement

constrainableElement1

constraint0..*

Figure A.5.: Meta-Model of the constraint Package

A.5.1. Abstract EClass ConstrainableElement

Overview Abstract super class for all model elements that may carry a constraint.

EReferences of ConstrainableElement

constraint : Constraint [0..∗] see Section A.5.2 on Page 245

The constraint for this element.

A.5.2. Abstract EClass Constraint

Overview This class represents a constraint. A constraint defines certain properties a systemhas to fulfill. In terms of model checking, a constraint represents the specification of thesystem.

ESuper Types of Constraint


EAttributes of Constraint

background : EBoolean [0..1]

This attribute decides whether background checking is activated for this constraint.If it is activated the correctness of the constraint is checked whenever the modelchanges. These checks are performed in the background such that user interactionis not interrupted.


/correct : EBoolean [0..1]

This derived attribute is "true" if and only if this.correctness ==Correctness.CORRECT holds.

derivation

s e l f . c o r r e c t n e s s = c o n s t r a i n t : : C o r r e c t n e s s : : CORRECT

correctness : Correctness [0..1] see Section A.5.3 on Page 246

The correctness of this constraint encoded as a literal of the enum type"Correctness".

EReferences of Constraint

constrainableElement : ConstrainableElement [1..1] seeSection A.5.1 on Page 245

The element this constraint applies to.

A.5.3. EEnumeration Correctness

Overview This enumeration encodes the correctness result of a constraint. The correctnessis UNKNOWN if the constraint has not yet been verified or if the verification failed forsome reason. The constraint is CORRECT, if the verification returned true. Otherwisethe constraint is VIOLATED.

ELiterals of Correctness

UNKNOWN = 0

CORRECT = 1

VIOLATED = 2

A.5.4. Abstract EClass ModelingConstraint

Overview A modeling constraint is a static semantics constraint that restricts the model. Itcan be checked statically and will not be used for verification.

ESuper Types of ModelingConstraint

Constraint see Section A.5.2 on Page 245

A.5. EPACKAGE MUML::CONSTRAINT 247

A.5.5. EClass TextualConstraint

Overview This class represents all verifable constraints that can be entered as a string in apredefined constraint language like, e.g., CTL or TCTL. Therefore, it contains a textualexpression which is used to store the constraint text and the language.

ESuper Types of TextualConstraint

VerifiableConstraint see Section A.5.6 on Page 247


EReferences of TextualConstraint

textualExpression : TextualExpression [0..1] seeSection A.14.2 on Page 318

A textual expression which stores the constraint text and the language in which theconstraint is specified.

A.5.6. Abstract EClass VerifiableConstraint

Overview A verifiable constraint is a dynamic semantics constraint that will be used forverification of the model. This class serves as a super class for all types of verifiableconstraints.

ESuper Types of VerifiableConstraint

Constraint see Section A.5.2 on Page 245


A.6. EPackage muml::instance

Overview The package instance contains all classes for building configurations ofcomponent instances.

Component instances are built from component types and connected by connectors. Theresulting structure is a component instance configuration.

A.6.1. EClass AssemblyConnectorInstance

Overview This class represents an assembly connector at instance level.

ESuper Types of AssemblyConnectorInstance

PortConnectorInstance see Section A.6.12 on Page 256

EReferences of AssemblyConnectorInstance

/assemblyConnectorType : AssemblyConnector [0..1] seeSection A.3.1 on Page 218

The assembly that this assembly instance is built from.

derivation

s e l f . t y p e . oclAsType ( component : : AssemblyConnec tor )

OCL Constraints of AssemblyConnectorInstance

AssemblyConnectorInstanceNeedsTypeIfNotTopLevel

−− Assembly Connec to r I n s t a n c e needs type , i f not top− l e v e lp o r t I n s t a n c e s . c o m p o n e n t I n s t a n c e−> e x i s t s ( not pa ren tCIC .

p a r e n t S t r u c t u r e d C o m p o n e n t I n s t a n c e . o c l I s U n d e f i n e d ( ) ) i m p l i e snot as semblyConnec to rType . o c l I s U n d e f i n e d ( )

A.6.2. EClass AtomicComponentInstance

Overview An atomic component instance is a component instance which has been derivedfrom an atomic component. An atomic component instance has no embeddedcomponent instance configuration and executes the behavior specification which hasbeen defined by its type.

ESuper Types of AtomicComponentInstance

ComponentInstance see Section A.6.3 on Page 250

A.6. EPACKAGE MUML::INSTANCE 249

ComponentInstance

PortConnectorInstance

PortInstance

AssemblyConnectorInstance

DelegationConnectorInstance

ComponentInstanceConfiguration

ContinuousPortInstance

HybridPortInstance

DiscretePortInstance

DiscreteSinglePortInstance

DiscreteMultiPortInstance

CoordinationProtocolIn

stance

StructuredComponentInstance

AtomicComponentInstance

portInstances

0..*

parentCIC

1

portInstances

0..*

componentInstance

0..1

portConnectorInstances

0..*

componentInstances

0..*

portConnectorInstances

0..*parentPortInstances

0..*

parentStructuredComponentInstance

0..1

portInstances

1..*

embeddedCIC

1

Figure A.6.: Meta-Model of the instance Package


A.6.3. Abstract EClass ComponentInstance

Overview This class represents a component instance. It is an instantiation of a component.

ESuper Types of ComponentInstance


EReferences of ComponentInstance

componentPart : ComponentPart [0..1] see Section A.3.5 onPage 223

If the component instance is contained in a structured component instance, thenthe corresponding structure component has has component part that was used toinclude the component type of this instance. Then, this reference points to thiscomponent part. We can use this reference for deciding how many instances of aparticular part exist in a structured component instance such that we can enforcethe cardinalities of the component part during run-time.

componentType : Component [1..1] see Section A.3.3 on Page 222

The component type of which this instance is derived.

parentCIC :ComponentInstanceConfiguration [1..1] see Section A.6.4 onPage 250

The component instance configuration that contains this component instance.

portInstances : PortInstance [0..∗] see Section A.6.13 onPage 257

The port instances that belong to this component instance.

A.6.4. EClass ComponentInstanceConfiguration

Overview This class encapsules represents a configuration. It contains all componentinstances and connector instances that belong to a concrete configuration.

ESuper Types of ComponentInstanceConfiguration



EReferences of ComponentInstanceConfiguration

componentInstances : ComponentInstance [0..∗] seeSection A.6.3 on Page 250

The set of component instances of a component instance configuration.


/parentPortInstances : PortInstance [0..∗] see Section A.6.13on Page 257

The port instances of the containing component instance.

derivation

i f s e l f . p a r e n t S t r u c t u r e d C o m p o n e n t I n s t a n c e . o c l I s U n d e f i n e d ( )then O r d e r e d S e t {}e l s e s e l f . p a r e n t S t r u c t u r e d C o m p o n e n t I n s t a n c e . p o r t I n s t a n c e se n d i f

parentStructuredComponentInstance: StructuredComponentInstance [0..1] see Section A.6.14 onPage 258

A structured component instance embeds a component instance configurationthat defines its inner structure. For such component instance configuration,this reference points to the containing structured component instance. If thiscomponent instance configuration is not contained in a structured componentinstance, this reference is null.

portConnectorInstances : PortConnectorInstance [0..∗]see Section A.6.12 on Page 256

The set of connector instances of a component instance configuration.

OCL Constraints of ComponentInstanceConfiguration

UniqueComponentInstanceNames

−− Component i n s t a n c e s o f a component i n s t a n c e c o n f i g u r a t i o nmust have un i qu e names on t o p l e v e l .

s e l f . c o m p o n e n t I n s t a n c e s−>i s U n i q u e ( name )

A.6.5. EClass ContinuousPortInstance

Overview This class represents a continuous port at instance level. The port type of acontinuous port instance must be a continuous port.

ESuper Types of ContinuousPortInstance

PortInstance see Section A.6.13 on Page 257

A.6.6. EClass CoordinationProtocolInstance

Overview An instance of a coordination protocol part. It specifies the behavior of discrete(single/multi) port instances that are connected with each other.

ESuper Types of CoordinationProtocolInstance



EReferences of CoordinationProtocolInstance

coordinationProtocolPart : CoordinationProtocolPart[1..1] see Section A.3.7 on Page 225

The CoordinationProtocolPart of that instance.

portInstances : PortInstance [1..∗] see Section A.6.13 onPage 257

The port instances that use this coordination protocol instance.

A.6.7. EClass DelegationConnectorInstance

Overview This class represents a delegation connector at instance level.

ESuper Types of DelegationConnectorInstance

PortConnectorInstance see Section A.6.12 on Page 256

EReferences of DelegationConnectorInstance

/delegationConnectorType : DelegationConnector [1..1]see Section A.3.8 on Page 226

The delegation type of this delegation instance.

derivation

s e l f . t y p e . oclAsType ( component : : D e l e g a t i o n C o n n e c t o r )

OCL Constraints of DelegationConnectorInstance

DelegateToEmbeddedCIC

−− D e l e g a t i o n Connec to r I n s t a n c e must d e l e g a t e t o embeddedComponent I n s t a n c e C o n f i g u r a t i o n

s e l f . p o r t I n s t a n c e s −> e x i s t s ( a , b | b . c o m p o n e n t I n s t a n c e . pa ren tCIC .p a r e n t S t r u c t u r e d C o m p o n e n t I n s t a n c e = a . c o m p o n e n t I n s t a n c e )

A.6.8. EClass DiscreteMultiPortInstance

Overview This class represents a multi-port at instance level. For each multi-portof a component, there exists exactly one multi-port instance in the respectivecomponent instance at all times. That instance references an instance of thestatechart of the multi-port as well as an instance of the adaptation behavior. TheDiscreteMultiPortInstance also references all sub-port instances of the multi-portinstance. The DiscreteMultiPortInstance has no visual representation in the concretesyntax. It is represented by its sub-roles.


ESuper Types of DiscreteMultiPortInstance

DiscretePortInstance see Section A.6.9 on Page 253

DiscreteMultiInteractionEndpointInstance see Section A.4.7 onPage 242

EReferences of DiscreteMultiPortInstance

/gmfSubPortInstances :DiscreteSingleInteractionEndpointInstance [0..∗] seeSection A.4.8 on Page 243

This reference just derives the values of "subPortInstances" and specifies acontainment. This containment reference is needed by the GMF tooling.

derivation

s e l f . s u b I n t e r a c t i o n E n d p o i n t I n s t a n c e s

A.6.9. Abstract EClass DiscretePortInstance

Overview This class represents a discrete port at instance level. At instance level,we distinguish between single-port instances and multi-port instances by using twosubclasses of this abstract class.

ESuper Types of DiscretePortInstance



EReferences of DiscretePortInstance

/receiverMessageBuffer : MessageBuffer [0..∗] seeSection A.4.9 on Page 243

The derived properties of the refined role regarding the receiver message buffers.

derivation

i f ( not s e l f . p o r t T y p e . o c l I s U n d e f i n e d ( ) ) and s e l f . p o r t T y p e .o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) thens e l f . p o r t T y p e . oclAsType ( component : : D i s c r e t e P o r t ) .

r e c e i v e r M e s s a g e B u f f e re l s e

O r d e r e d S e t { }e n d i f


/receiverMessageTypes : MessageType [0..∗] see Section A.7.1on Page 259

The receiver message interface defines which messages this port instance receivesIt is derived from the receiver message interface of its port.

derivationi f p o r t T y p e . o c l I s U n d e f i n e d ( ) or not p o r t T y p e . o c l I s K i n d O f (

component : : D i s c r e t e P o r t ) thenO r d e r e d S e t { }

e l s ep o r t T y p e . oclAsType ( component : : D i s c r e t e P o r t ) .

r e c e i v e r M e s s a g e T y p e se n d i f

/refinedRole : Role [0..1] see Section A.8.4 on Page 264

The role of a coordination protocol that the port type of this port instance refines.

derivationi f not s e l f . p o r t T y p e . o c l I s U n d e f i n e d ( ) and s e l f . p o r t T y p e .

o c l I s K i n d O f ( component : : D i s c r e t e P o r t ) thens e l f . p o r t T y p e . oclAsType ( component : : D i s c r e t e P o r t ) .

r e f i n e d R o l ee l s e

n u l le n d i f

/senderMessageTypes : MessageType [0..∗] see Section A.7.1 onPage 259

The sender message interface defines which messages this port instance sends. Itis derived from the sender message interface of its port.

derivationi f p o r t T y p e . o c l I s U n d e f i n e d ( ) or not p o r t T y p e . o c l I s K i n d O f (

component : : D i s c r e t e P o r t ) thenO r d e r e d S e t { }

e l s ep o r t T y p e . oclAsType ( component : : D i s c r e t e P o r t ) .

s enderMessageTypese n d i f

A.6.10. EClass DiscreteSinglePortInstance

Overview This class represents a discrete single port at instance level as well as a sub-portinstance of a multi-port instance. Each single port instance references its behaviorinstance. When used as a sub-port instance, the instance references its role behaviorinstance.

ESuper Types of DiscreteSinglePortInstance

DiscretePortInstance see Section A.6.9 on Page 253

DiscreteSingleInteractionEndpointInstance see Section A.4.8 onPage 243

OCL Constraints of DiscreteSinglePortInstance

PortInstanceNotMultipleAssemblyConnectorInstances

−− P o r t I n s t a n c e must have not have m u l l t i p l e Assembly Connec to rI n s t a n c e s a s s i g n e d .

p o r t C o n n e c t o r I n s t a n c e s −> s e l e c t (c i | c i . o c l I s K i n d O f ( A s s e m b l y C o n n e c t o r I n s t a n c e )

)−> s i z e ( ) <= 1

PortInstanceNotMultipleDelegationConnectorInstances

−− P o r t I n s t a n c e must have not have m u l t i p l e D e l e g a t i o n Connec to rI n s t a n c e s p e r d i r e c t i o n d a s s i g n e d .

l e t d e l e g a t i o n I n s t a n c e s : S e t ( i n s t a n c e : :D e l e g a t i o n C o n n e c t o r I n s t a n c e ) = p o r t C o n n e c t o r I n s t a n c e s −> s e l e c t (o c l I s K i n d O f ( i n s t a n c e : : D e l e g a t i o n C o n n e c t o r I n s t a n c e ) ) . oclAsType (i n s t a n c e : : D e l e g a t i o n C o n n e c t o r I n s t a n c e )−>a s S e t ( ) i n

l e t incoming : S e t ( i n s t a n c e : : D e l e g a t i o n C o n n e c t o r I n s t a n c e ) =d e l e g a t i o n I n s t a n c e s −> s e l e c t ( d i | d i . p o r t I n s t a n c e s −> f o r A l l ( p i |p i = s e l f or p i . c o m p o n e n t I n s t a n c e−> c l o s u r e ( p | i f p .o c l I s K i n d O f ( i n s t a n c e : : S t r u c t u r e d C o m p o n e n t I n s t a n c e ) t h e n p .oclAsType ( i n s t a n c e : : S t r u c t u r e d C o m p o n e n t I n s t a n c e ) . embeddedCIC .c o m p o n e n t I n s t a n c e s e l s e O r d e r e d S e t { p } e n d i f )−> i n c l u d e s ( s e l f. c o m p o n e n t I n s t a n c e ) ) ) i n

l e t o u t g o i n g : S e t ( i n s t a n c e : : D e l e g a t i o n C o n n e c t o r I n s t a n c e ) =d e l e g a t i o n I n s t a n c e s −> s e l e c t ( d i | d i . p o r t I n s t a n c e s −> f o r A l l ( p i |p i = s e l f or s e l f . c o m p o n e n t I n s t a n c e−> c l o s u r e ( p | i f p .o c l I s K i n d O f ( i n s t a n c e : : S t r u c t u r e d C o m p o n e n t I n s t a n c e ) t h e n p .oclAsType ( i n s t a n c e : : S t r u c t u r e d C o m p o n e n t I n s t a n c e ) . embeddedCIC .c o m p o n e n t I n s t a n c e s e l s e O r d e r e d S e t { p } e n d i f )−> i n c l u d e s ( p i .c o m p o n e n t I n s t a n c e ) ) ) i n

incoming−> s i z e ( ) <= 1 and ou tgo ing−> s i z e ( ) <= 1

PortInstanceNeedsDelegationToParentOrAssembly

−− P o r t I n s t a n c e needs a D e l e g a t i o n Connec to r I n s t a n c e t o t h ep a r e n t component ’ s p o r t o r an Assembly Connec to r I n s t a n c e t o a

p o r t w i t h i n t h i s CIC .n o t p o r t C o n n e c t o r I n s t a n c e s −> s e l e c t (

c i | c i . o c l I s K i n d O f ( D e l e g a t i o n C o n n e c t o r I n s t a n c e )and c i . oclAsType ( D e l e g a t i o n C o n n e c t o r I n s t a n c e ) . p o r t I n s t a n c e s −>any ( p i | p i <> s e l f ) . c o m p o n e n t I n s t a n c e . o c l I s K i n d O f (S t r u c t u r e d C o m p o n e n t I n s t a n c e )

and c i . oclAsType ( D e l e g a t i o n C o n n e c t o r I n s t a n c e ) . p o r t I n s t a n c e s −>any ( p i | p i <> s e l f ) . c o m p o n e n t I n s t a n c e . oclAsType (S t r u c t u r e d C o m p o n e n t I n s t a n c e ) . embeddedCIC . c o m p o n e n t I n s t a n c e s−>i n c l u d e s ( c o m p o n e n t I n s t a n c e )

)−>isEmpty ( ) o rn o t p o r t C o n n e c t o r I n s t a n c e s −> s e l e c t (

c i | c i . o c l I s K i n d O f ( A s s e m b l y C o n n e c t o r I n s t a n c e ))−>isEmpty ( )

A.6.11. EClass HybridPortInstance

Overview This class represents a hybrid port at instance level. The port type of a hybrid portinstance must be a hybrid port.

ESuper Types of HybridPortInstance


A.6.12. Abstract EClass PortConnectorInstance

Overview This class is the common super class of delegation instances and assemlyinstances.

ESuper Types of PortConnectorInstance

ConnectorInstance see Section A.4.4 on Page 240

EReferences of PortConnectorInstance

/portConnectorType : PortConnector [0..1] see Section A.3.13on Page 232

The connector type of this connector instance.

derivation

s e l f . t y p e . oclAsType ( component : : P o r t C o n n e c t o r )

/portInstances : PortInstance [2..2] see Section A.6.13 onPage 257

The port instances connected by this connector instance.

derivation

s e l f . c o n n e c t o r E n d p o i n t I n s t a n c e s −> s e l e c t ( c | c . o c l I s K i n d O f (P o r t I n s t a n c e ) ) . oclAsType ( P o r t I n s t a n c e )−>a s O r d e r e d S e t ( )


A.6.13. Abstract EClass PortInstance

Overview A port instance is a port of a component at instance level.

ESuper Types of PortInstance

ConnectorEndpointInstance see Section A.4.3 on Page 239

EReferences of PortInstance

componentInstance : ComponentInstance [0..1] seeSection A.6.3 on Page 250

The component instance this port instance belongs to.

/portConnectorInstances : PortConnectorInstance [0..∗]see Section A.6.12 on Page 256

The port connector instances attached to this port instance.

derivation

s e l f . c o n n e c t o r I n s t a n c e s −> s e l e c t ( i | i . o c l I s K i n d O f (P o r t C o n n e c t o r I n s t a n c e ) ) . oclAsType ( P o r t C o n n e c t o r I n s t a n c e )−>a s O r d e r e d S e t ( )

/portPart : PortPart [0..1] see Section A.3.15 on Page 233

Refers to the first single instance of the corresponding multi discrete interactionendpoint.

derivation

I f t h e e n c l o s i n g component i n s t a n c e c o r r e s p o n d s t o acomponent p a r t o f a s t r u c t u r e d component , r e f e r s t o t h ep o r t p a r t t h a t c o r r e s p o n d s t o t h i s p o r t i n s t a n c e .

/portType : Port [1..1] see Section A.3.12 on Page 232

The port type of which this port instance is built from.

derivation

i f ( s e l f . t y p e . o c l I s K i n d O f ( component : : P o r t ) )thens e l f . t y p e . oclAsType ( component : : P o r t )e l s en u l le n d i f

OCL Constraints of PortInstance

PortInstanceMustReferencePortType

−− The t y p e o f a p o r t i n s t a n c e must be a p o r t t y p ei f ( not s e l f . type−>o c l I s U n d e f i n e d ( ) ) t h e ns e l f . t y p e . o c l I s K i n d O f ( component : : P o r t )e l s ef a l s ee n d i f

PortInstanceMustDelegateToEmbeddedCIC

−− P o r t I n s t a n c e a t S t r u c t u r e d Component must d e l e g a t e t o embeddedCIC

c o m p o n e n t I n s t a n c e . o c l I s K i n d O f ( S t r u c t u r e d C o m p o n e n t I n s t a n c e )i m p l i e s not p o r t C o n n e c t o r I n s t a n c e s −> s e l e c t ( c i | c i . o c l I s K i n d O f( D e l e g a t i o n C o n n e c t o r I n s t a n c e ) and c o m p o n e n t I n s t a n c e . oclAsType (S t r u c t u r e d C o m p o n e n t I n s t a n c e ) . embeddedCIC . c o m p o n e n t I n s t a n c e s−>i n c l u d e s ( c i . oclAsType ( D e l e g a t i o n C o n n e c t o r I n s t a n c e ) .p o r t I n s t a n c e s −>any ( p i | p i <> s e l f ) . c o m p o n e n t I n s t a n c e ) )−>isEmpty ( )

A.6.14. EClass StructuredComponentInstance

Overview A structured component instance is a component instance that has been derivedfrom a structured component type. A structured component instance specifies anembedded component instance configuration defining its inner structure.

ESuper Types of StructuredComponentInstance

ComponentInstance see Section A.6.3 on Page 250

EReferences of StructuredComponentInstance

embeddedCIC :ComponentInstanceConfiguration [1..1] see Section A.6.4 onPage 250

The component instances and connector instances that are embedded in thiscomponent instance are contained by the component instance configuration.

A.7. EPACKAGE MUML::MSGTYPE 259

A.7. EPackage muml::msgtype

Overview This package defines the message types that can be send and received viadiscrete interaction endpoints. Then, the real-time statecharts of the discrete interactionendpoints use the message types to type their asynchronous messages at their transitions.Message types may be grouped in message type repositories.

MessageTypeMessageTypeRepository repository1

messageTypes1..*

Figure A.7.: Meta-Model of the msgtype Package

A.7.1. EClass MessageType

Overview A message type defines the signature of one event. That includes the name of theevent as well as the ordered list of parameters. In addition, a message type is containedin a message type repository.

ESuper Types of MessageType



EReferences of MessageType

parameters : Parameter [0..∗] see Section A.2.4 on Page 215

This reference defines the set of parameters of this message type. A parameterdefines a unique name and a DataType.

repository : MessageTypeRepository [1..1] see Section A.7.2 onPage 260

The message type repository that contains this message type.

OCL Constraints of MessageType

UniqueParameterNames

−− P a r a m e t e r names must be un iq ues e l f . p a r a m e t e r s −>i s U n i q u e ( name )


A.7.2. EClass MessageTypeRepository

Overview A MessageTypeRepository contains a set of message types which are then usedby discrete interaction endpoints and their behavior specifications. Message typerepositories enable to group message types logically, but have no semantics for theMechatronicUML model.

ESuper Types of MessageTypeRepository



EReferences of MessageTypeRepository

messageTypes : MessageType [1..∗] see Section A.7.1 on Page 259

The message types that are contained in this message type repository.

A.8. EPACKAGE MUML::PROTOCOL 261

A.8. EPackage muml::protocol

Overview This package provides modeling support for coordination protocols includingroles, role connectors, and quality of service assumptions.

A.8.1. Abstract EClass AbstractCoordinationSpecification

Overview Abstract base class for coordination protocols.

ESuper Types of AbstractCoordinationSpecificationNamedElement see Section A.13.4 on Page 316



EReferences of AbstractCoordinationSpecificationroleConnector : RoleConnector [1..1] see Section A.8.5 on

Page 265

Each coordination protocol has exactly one role connector. Cardinality is 1because there exists no useful protocol with more than two roles. If a usefulprotocol exists with more than 2 roles, then change cardinality to 1..*

roles : Role [1..2] see Section A.8.4 on Page 264

The roles belonging to this coordination protocol.

OCL Constraints of AbstractCoordinationSpecificationUniqueRoleNames

−− Names of r o l e s must be u n i qu es e l f . r o l e s −>i s U n i q u e ( name )

RoleMessageTypesMustBeCompatible−− Every Role must have t h e senderMessageTypes o f a l l o t h e r Ro les

s e t a s r e c e i v e r M e s s a g e T y p e ss e l f . r o l e s −> f o r A l l ( r o l e 1 : Role , r o l e 2 : Role |

r o l e 1 <> r o l e 2i m p l i e sr o l e 1 . senderMessageTypes−>a s S e t ( ) = r o l e 2 . r e c e i v e r M e s s a g e T y p e s−>a s S e t ( )

)

SingleRoleImpliesMultiRole−− Only one r o l e e x i s t s , so i t must be a M u l t i Role .s e l f . r o l e s −> s i z e ( ) = 1 i m p l i e s s e l f . r o l e s −>any ( t rue ) . m u l t i R o l e


AbstractCoordinationSpecification

Coord

inati

onPro

toco

lR

ole

mult

iRole

: E

Boole

an

Role

Connect

or

Connect

orQ

ualit

yO

fServ

iceA

ssum

pti

ons

mess

ageLo

ssPo

ssib

le :

EB

oole

an

role

s1

..2

role

Connect

or 1

gm

fCoord

inati

onPro

toco

l0

..1

coord

inati

onPro

toco

l1

role

Connect

or

1

coord

inati

onPro

toco

l1

connect

orQ

ualit

yO

fServ

iceA

ssum

pti

ons

1ro

les2

Figure A.8.: Meta-Model of the protocol Package


A.8.2. EClass ConnectorQualityOfServiceAssumptions

Overview The list of quality of service assumptions for this connector. A developer definesthese properties before modeling the role statecharts, because the statecharts depend onthese assumptions. Software layers under the MechatronicUML layer respectively thehardware itself have to ensure that these assumptions are correct.

ESuper Types of ConnectorQualityOfServiceAssumptions


EAttributes of ConnectorQualityOfServiceAssumptions

messageLossPossible : EBoolean [1..1]

Defines if messages that are send using this connector may be lost during transport.

EReferences of ConnectorQualityOfServiceAssumptions

maxMessageDelay : TimeValue [1..1] see Section A.11.5 on Page 300

The maximal time a message needs from the sender to the receiver using thisconnector.

minMessageDelay : TimeValue [1..1] see Section A.11.5 on Page 300

The minimal time a message needs from the sender to the receiver using thisconnector.

A.8.3. EClass CoordinationProtocol

Overview A coordination protocol specifies the coordination between a certain number ofcommunication members. The communication members are represented by roles. Tospecify which roles communicate whith each other they are connected by channels.The communication protocol used by the roles is specified by realtime statecharts.Each role has its own realtime statechart describing the roles communication behavior.Furthermore channels own a realtime statechart which enables specifying properties ofcertain real communication channels e.g. propagation delay or buffering of messages.Furthermore constraints can be assigned to coordination protocols. Constraints specifycertain properties the coordination specified by the protocol has to fullfill.

ESuper Types of CoordinationProtocol

AbstractCoordinationSpecification see Section A.8.1 on Page 261

EReferences of CoordinationProtocol


/gmfCoordinationProtocol : CoordinationProtocol [0..1]see Section A.8.3 on Page 263

This derived reference only exists because GMF needs it to visualize the innerhexagon of a Real-Time Coordination Protocol.

derivation

s e l f

OCL Constraints of CoordinationProtocol

CoordinationProtocolNamesMustBeUnique

−− C o o r d i n a t i o n P r o t o c o l s must have un iq ue namesC o o r d i n a t i o n P r o t o c o l . a l l I n s t a n c e s ( )−>i s U n i q u e ( name )

A.8.4. EClass Role

Overview This class represents a role of a coordination protocol.

ESuper Types of Role

DiscreteInteractionEndpoint see Section A.4.5 on Page 240


EAttributes of Role

/multiRole : EBoolean [1..1]

This derived attribute indicates if the role is a multi role.

derivation

s e l f . m u l t i

EReferences of Role

coordinationProtocol : AbstractCoordinationSpecification[1..1] see Section A.8.1 on Page 261

The coordination protocol this role belongs to.

/roleConnector : RoleConnector [1..1] see Section A.8.5 onPage 265

The role connector that connects this role with another role.

derivation

s e l f . c o n n e c t o r s −>any ( c | c . o c l I s K i n d O f ( Ro leConnec to r ) ) .oclAsType ( Ro leConnec to r )


OCL Constraints of Role

RoleRequiresBehavior

−− Role r e q u i r e s b e h a v i o rnot s e l f . b e h a v i o r . o c l I s U n d e f i n e d ( )

RoleRequiresMessageTypes

−− Role r e q u i r e s message t y p e s t o be s e ts e l f . senderMessageTypes−>notEmpty ( ) or s e l f . r e c e i v e r M e s s a g e T y p e s−>notEmpty ( )

ReceiverMessageTypeMustBeAssignedToExactlyOneBuffer

−− Each r e c e i v e r message t y p e s h o u l d be a s s i g n e d t o e x a c t l y oneb u f f e r

s e l f . r e c e i v e r M e s s a g e T y p e s−> f o r A l l ( t y p e | s e l f .r e c e i v e r M e s s a g e B u f f e r −>one ( messageType−> i n c l u d e s ( t y p e ) ) )

MultiRoleRequiresRoleAndAdaptationBehavior

−− M u l t i r o l e s need a d a p t a t i o n B e h a v i o r andr o l e A n d A d a p t a t i o n B e h a v i o r s e t

s e l f . m u l t i R o l e i m p l i e s( ( not s e l f . a d a p t a t i o n B e h a v i o r . o c l I s U n d e f i n e d ( ) ) and ( not s e l f .

r o l e A n d A d a p t a t i o n B e h a v i o r . o c l I s U n d e f i n e d ( ) ) )

A.8.5. EClass RoleConnector

Overview This class represents a communication channel connecting two roles of acoordination protocol.

ESuper Types of RoleConnector

Connector see Section A.4.1 on Page 238

EReferences of RoleConnector

connectorQualityOfServiceAssumptions :ConnectorQualityOfServiceAssumptions [1..1] seeSection A.8.2 on Page 263

A role connector has exactly one reference for defining its quality of serviceassumptions like message delay and message loss.

coordinationProtocol : AbstractCoordinationSpecification[1..1] see Section A.8.1 on Page 261

The coordination protocol this role connector is part of.


/roles : Role [2..2] see Section A.8.4 on Page 264

The two roles that are connected.

derivation

s e l f . c o n n e c t o r E n d p o i n t s −> s e l e c t ( e | e . o c l I s K i n d O f ( Role ) ) .oclAsType ( Role )−>a s O r d e r e d S e t ( )

OCL Constraints of RoleConnector

OnlyRolesOfSameCoordinationProtocol

−− Role c o n n e c t o r must not c o n n e c t r o l e s a t d i f f e r e n tc o o r d i n a t i o n p r o t o c o l s

i f s e l f . c o o r d i n a t i o n P r o t o c o l . r o l e s −>o c l I s U n d e f i n e d ( ) t h e nt ruee l s es e l f . c o o r d i n a t i o n P r o t o c o l . r o l e s = s e l f . r o l e se n d i f

A.9. EPACKAGE MUML::REALTIMESTATECHART 267

A.9. EPackage muml::realtimestatechart

Overview This package provides modeling support for Real-Time Statecharts as acombination of UML state machines and timed automata.

A.9.1. EClass AbsoluteDeadline

Overview This class represents an absolute deadline. It is always associated with a transitionof the statechart. The deadline depends on the value of a certain clock.

ESuper Types of AbsoluteDeadline

Deadline see Section A.9.6 on Page 270

EReferences of AbsoluteDeadline

clock : Clock [1..1] see Section A.9.4 on Page 269

the references clock of the absolute deadline.

A.9.2. EClass Action

Overview An action is used as a side effect of a transition as well as within a state. Eachtransition can only define one action. A state can define up to three actions (one for stateentry, one for state exit, one while dwelling within the state).

ESuper Types of Action


EReferences of Action

expressions : Expression [1..∗] see Section A.14.1 on Page 318

An action has a defined expression, which can be expressed in different languages.

A.9.3. EClass AsynchronousMessageEvent

Overview An AsynchronousMessageEvent is a TransitionEvent that corresponds toreceiving or sending a message. They are used to model asynchronous communicationbetween realtime statecharts. A trigger events specifies that the corresponding messagehas to be received for the transition to be enabled, a raised event specifies that thecorresponding message will be sent upon execution of the transition.

ESuper Types of AsynchronousMessageEvent

TransitionEvent see Section A.9.27 on Page 292

Deadline

Ab

solu

teD

ead

line

Rela

tiveD

ead

line

Clo

ck

Reg

ion

nam

e :

ES

trin

g

Sta

te

init

ial :

EB

oole

an

fin

al :

EB

oole

an

urg

en

t :

EB

oole

an

sim

ple

: E

Boole

an

getU

niq

ueR

eg

ion

Pri

ori

ty(E

Int)

: E

Int

hasR

eg

ion

OfP

riori

ty(E

Int)

: E

Boole

an

Vertex

isS

up

erV

ert

exO

f(Vert

ex)

: EB

oole

an

getU

niq

ueTr

an

siti

on

Pri

ori

ty(E

Int)

: E

Int

hasO

utg

oin

gTr

an

siti

on

OfP

riori

ty(E

Int)

: E

Boole

an

Tran

siti

on

blo

ckab

le :

EB

oole

an

urg

en

t :

EB

oole

an

Clo

ckC

on

stra

int

op

era

tor

: C

om

pari

ng

Op

era

tor

Act

ion

Asy

nch

ron

ou

sMess

ag

eEven

t

DoEvent

EntryOrExitEvent

Syn

chro

niz

ati

on

Ch

an

nel

Syn

chro

niz

ati

on

kin

d :

Syn

chro

niz

ati

on

Kin

d

PrioritizedElement

pri

ori

ty :

EIn

t

Realt

imeS

tate

chart

flat

: EB

oole

an

em

bed

ded

: E

Boole

an

isS

up

erS

tate

chart

Of(

Realt

imeS

tate

chart

) :

EB

oole

an

getH

igh

est

Pare

ntS

tate

chart

() :

Realt

imeS

tate

chart

getP

ort

OrR

ole

Sta

tech

art

() :

Realt

imeS

tate

chart

<<

en

um

era

tion

>>

Syn

chro

niz

ati

on

Kin

d

SEN

D

REC

EIV

E

Event

kin

d :

Even

tKin

d

TransitionEvent

StateEvent

Mess

ag

e

<<

en

um

era

tion

>>

Even

tKin

d

RA

ISE

TR

IGG

ER

En

tryEven

t

Exit

Even

t

StateConnectionPoint

En

tryPo

int

Exit

Poin

t

clock

1

state

chart

0..

1em

bed

ded

Sta

tech

art

1p

are

ntS

tate

1

em

bed

ded

Reg

ion

s0

..*

doEven

t0

..1

exit

Even

t

0..

1

en

tryEven

t0

..1

invari

an

ts0

..*

chan

nels

0..

*

even

ts0

..*

con

nect

ion

Poin

ts0

..*

pare

ntS

tate

chart

0..

1

allA

vaila

ble

Ch

an

nels

0..

*

outg

oin

gTr

an

siti

on

s0

..*

inco

min

gTr

an

siti

on

s0

..*

allS

up

erV

ert

ices

0..

*

syn

chro

niz

ati

on

0..

1

targ

et

1 sou

rce

1

state

chart

0..

1

clock

Rese

ts0

..*

trig

gerM

ess

ag

eEven

t0

..1

rais

eM

ess

ag

eEven

t0

..1

clock

Con

stra

ints

0..

*

ab

solu

teD

ead

lines

0..

*

rela

tiveD

ead

line

0..

1

even

ts0

..*

act

ion

0..

1

clock1

mess

ag

e1

act

ion

1

clock

Rese

ts0

..*

act

ion

0..

1

state

1

syn

cCh

an

nel

0..

1

pare

ntR

eg

ion

0..

1

tran

siti

on

s0

..*

state

s1

..*

clock

s0

..*

availa

ble

Clo

cks

0..

*

state

1

Figure A.9.: Meta-Model of the realtimestatechart Package


EReferences of AsynchronousMessageEvent

message : Message [1..1] see Section A.9.15 on Page 274

The message associated with this event. The message is either requested to bereceived (trigger event) or it will be sent (raise event).

OCL Constraints of AsynchronousMessageEvent

RaiseMessageEventImpliesParameterBinding

−− A r a i s e message e v e n t must b ind a v a l u e t o e v e r y p a r a m e t e rl e t messageType : msgtype : : MessageType = s e l f . message . i n s t a n c e O f

i n( s e l f . k ind =EventKind : : RAISE and not s e l f . message . o c l I s U n d e f i n e d ( )

) i m p l i e s ( not messageType . o c l I s U n d e f i n e d ( ) i m p l i e s (messageType . p a r a m e t e r s−>asBag ( ) = message . p a r a m e t e r B i n d i n g .p a r a m e t e r−>asBag ( ) ) )

−− a u t h o r : adann

A.9.4. EClass Clock

Overview This class represents clocks of a realtime statechart.

ESuper Types of Clock


EReferences of Clock

statechart : RealtimeStatechart [0..1] see Section A.9.17 onPage 275

The realtime statechart this clock belongs to.

A.9.5. EClass ClockConstraint

Overview This class represents an arbitrary time constraint that can either be used as aninvariant constraint of a state or as a transition guard.

ESuper Types of ClockConstraint


EAttributes of ClockConstraint

operator : ComparingOperator [1..1] see Section A.15.4 onPage 321

The operator that is used in this clock constraint.


EReferences of ClockConstraint

bound : TimeValue [1..1] see Section A.11.5 on Page 300

The bound of a deadline (upper or lower) is a natural number.

clock : Clock [1..1] see Section A.9.4 on Page 269

The clock references in this clock constraint.

A.9.6. Abstract EClass Deadline

Overview This class represents a deadline consisting of an upper and a lower bound.

EReferences of Deadline

lowerBound : TimeValue [1..1] see Section A.11.5 on Page 300

The lower bound of a deadline is a natural number.

upperBound : TimeValue [1..1] see Section A.11.5 on Page 300

The upper bound of a deadline is a natural number.

A.9.7. EClass DoEvent

Overview The action of a state that is executed periodically as long as this state is active.The first period starts after the execution of the entry-action.

ESuper Types of DoEvent

StateEvent see Section A.9.22 on Page 283

EReferences of DoEvent

action : Action [1..1] see Section A.9.2 on Page 267

Each entry or exit action has one or more actions.

period : TimeValue [1..1] see Section A.11.5 on Page 300

the lower bound of the period

A.9.8. EClass EntryEvent

Overview This class represents an entry event. The action associated with this event will beexecuted when the state is entered.

element for different notational elements within the same container.

ESuper Types of EntryEvent

EntryOrExitEvent see Section A.9.9 on Page 271


A.9.9. Abstract EClass EntryOrExitEvent

Overview This class represents an entry or an exit event. The actions associated with thisevent will be executed when the state is entered or left respectively.

ESuper Types of EntryOrExitEvent

StateEvent see Section A.9.22 on Page 283

EReferences of EntryOrExitEvent


Each entry or exit event can have one or more actions.

clockResets : Clock [0..∗] see Section A.9.4 on Page 269

The clock resets of this action

A.9.10. EClass EntryPoint

Overview An EntryPoint is an intermediate pseudostate which makes it possible to chaintransitions between different hierarchy levels. The EntryPoint is assigned to a state. AnEntryPoint is used to activate a dedicated inner state for embedded statecharts.

ESuper Types of EntryPoint

StateConnectionPoint see Section A.9.21 on Page 283

OCL Constraints of EntryPoint

AtLeastOneIncomingTransition

−− E n t r y p o i n t needs a t l e a s t one incoming t r a n s i t i o ns e l f . i n c o m i n g T r a n s i t i o n s −>notEmpty ( )

OneOutgoingTransitionPerRegion

−− a l l r e g i o n s o f t h e p a r e n t s t a t e must have e x a c t l y one v e r t e xt h a t t h e E n t r y P o i n t c o n n e c t s t o

( not s e l f . s t a t e . o c l I s U n d e f i n e d ( ) ) i m p l i e s s e l f . s t a t e .embeddedRegions−> f o r A l l ( r |s e l f . o u t g o i n g T r a n s i t i o n s −>one ( t |

( t . t a r g e t . o c l I s K i n d O f ( S t a t e ) and t . t a r g e t . oclAsType ( S t a t e ) .p a r e n t S t a t e c h a r t . p a r e n t R e g i o n = r )

or( t . t a r g e t . o c l I s K i n d O f ( E n t r y P o i n t ) and t . t a r g e t . oclAsType (

E n t r y P o i n t ) . s t a t e . p a r e n t S t a t e c h a r t . p a r e n t R e g i o n = r ))

)


A.9.11. Abstract EClass Event

Overview This abstract class represents all kinds of events that may occur in a statechart. Aevent can either be a trigger event or a raise event.

EAttributes of Event

kind : EventKind [0..1] see Section A.9.12 on Page 272

Decides the kind: Is this a raise event or a trigger event?

A event may either be a trigger event or a raise event. A trigger event triggers someaction within the statechart, a raise event is generated by the statechart and will beprocessed by another statechart.

A.9.12. EEnumeration EventKind

Overview An event has two kinds: raise and trigger.

ELiterals of EventKind

RAISE = 0

Represents a raise event.

TRIGGER = 1

Represents a trigger event.

A.9.13. EClass ExitEvent

Overview This class represents an exit event. The action associated with this event will beexecuted when the state is left.

Note

We need this subclass, because GMF forbids using the same semantic element fordifferent notational elements within the same container.

ESuper Types of ExitEvent

EntryOrExitEvent see Section A.9.9 on Page 271

A.9.14. EClass ExitPoint

Overview An ExitPoint is an intermediate pseudostate which makes it possible to chaintransitions between different hierarchy levels. The ExitPoint is assigned to a state. AnExitPoint is used to jointly deactivate dedicated inner states of embedded statecharts.

ESuper Types of ExitPoint

StateConnectionPoint see Section A.9.21 on Page 283

OCL Constraints of ExitPoint

AtLeastOneIncomingTransitionPerRegion

−− a l l r e g i o n s o f t h e p a r e n t s t a t e must have a t l e a s t one v e r t e xt h a t c o n n e c t s t o t h e E x i t P o i n t

( not s e l f . s t a t e . o c l I s U n d e f i n e d ( ) ) i m p l i e s s e l f . s t a t e .embeddedRegions−> f o r A l l ( r |s e l f . i n c o m i n g T r a n s i t i o n s −> e x i s t s ( t |

( t . s o u r c e . o c l I s K i n d O f ( S t a t e ) and t . s o u r c e . oclAsType ( S t a t e ) .p a r e n t S t a t e c h a r t . p a r e n t R e g i o n = r )

or( t . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t ) and t . s o u r c e . oclAsType (

E x i t P o i n t ) . s t a t e . p a r e n t S t a t e c h a r t . p a r e n t R e g i o n = r ))

)

OneOutgoingTransition

−− E x i t p o i n t must have e x a c t l y one o u t g o i n g t r a n s i t i o ns e l f . o u t g o i n g T r a n s i t i o n s −> s i z e ( ) = 1

AtMostOneConnectingRegionWithSynchronizations

−− There must be a t most one r e g i o n wi th s y n c h r o n i z i n gt r a n s i t i o n s t h a t c o n n e c t ( d i r e c t l y or i n d i r e c t l y ) t o t h e e x i tp o i n t

l e t e x i t T r a n s i t i o n s : C o l l e c t i o n ( T r a n s i t i o n ) =

s e l f . i n c o m i n g T r a n s i t i o n s −>union (s e l f . i n c o m i n g T r a n s i t i o n s −> c l o s u r e ( t |i f t . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t )t h e n t . s o u r c e . i n c o m i n g T r a n s i t i o n se l s e Sequence {}e n d i f)

)

i n e x i t T r a n s i t i o n s −> f o r A l l ( t 1 : T r a n s i t i o n , t 2 : T r a n s i t i o n | ( t 1<> t 2 and ( not t 1 . s y n c h r o n i z a t i o n . o c l I s U n d e f i n e d ( ) ) and ( nott 2 . s y n c h r o n i z a t i o n . o c l I s U n d e f i n e d ( ) ) ) i m p l i e s ( t 1 . s t a t e c h a r t =

t 2 . s t a t e c h a r t ) )

AtMostOneConnectingRegionWithTriggerMessageEvents

−− There must be a t most one r e g i o n wi th t r a n s i t i o n s t h a t have at r i g g e r message e v e n t and c o n n e c t ( d i r e c t l y or i n d i r e c t l y ) t ot h e e x i t p o i n t

l e t e x i t T r a n s i t i o n s : C o l l e c t i o n ( T r a n s i t i o n ) =

s e l f . i n c o m i n g T r a n s i t i o n s −>union (s e l f . i n c o m i n g T r a n s i t i o n s −> c l o s u r e ( t |i f t . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t )t h e n t . s o u r c e . i n c o m i n g T r a n s i t i o n se l s e Sequence {}e n d i f)

)

i n e x i t T r a n s i t i o n s −> f o r A l l ( t 1 : T r a n s i t i o n , t 2 : T r a n s i t i o n | ( t 1<> t 2 and ( not t 1 . t r i g g e r M e s s a g e E v e n t . o c l I s U n d e f i n e d ( ) ) and (not t 2 . t r i g g e r M e s s a g e E v e n t . o c l I s U n d e f i n e d ( ) ) ) i m p l i e s ( t 1 .s t a t e c h a r t = t 2 . s t a t e c h a r t ) )

A.9.15. EClass Message

Overview The messages are exchanged between components in order to communicateasynchronously. A message is typed over a message type and provides a binding ofall parameters defined by the message type to concrete values.

ESuper Types of Message


EReferences of Message

instanceOf : MessageType [1..1] see Section A.7.1 on Page 259

Retrieves the message type this message is typed over.

parameterBinding : ParameterBinding [0..∗] see Section A.2.5on Page 216

The collection of parameter bindings for this message. All parameters of themessage type must be bound exactly once.

A.9.16. Abstract EClass PrioritizedElement

Overview Enables the priorization of elements. The minimum priority is 1.

EAttributes of PrioritizedElement

priority : EInt [0..1]

The integer value that represents the priority.

OCL Constraints of PrioritizedElement


PriorityGreaterOrEqualOne

−− P r i o r i t y must be >= 1s e l f . p r i o r i t y >= 1

A.9.17. EClass RealtimeStatechart

Overview This class is a concrete statechart implementation of a real-time statechart.

ESuper Types of RealtimeStatechart



Behavior see Section A.2.1 on Page 214

EAttributes of RealtimeStatechart

/embedded : EBoolean [0..1]

This attribute specifies whether this realtime statechart is embedded into a regionor not.

derivation

not s e l f . p a r e n t R e g i o n . o c l I s U n d e f i n e d ( )

/flat : EBoolean [0..1]

This derived attribute allows to checks whether a statechart is flat or not. In aflat statechart, none of the contained states contains a regions with an embeddedsubstatechart.

derivation

−− a s t a t e c h a r t i s f l a t i f i t e x c l u s i v e l y c o n t a i n s s i m p l es t a t e s

s t a t e s −> f o r A l l ( s i m p l e )

EReferences of RealtimeStatechart

/allAvailableOperations : Operation [0..∗] see Section A.2.3on Page 215

All operations accessible within this statechart.

derivation

s e l f −> c l o s u r e ( i f p a r e n t R e g i o n . o c l I s U n d e f i n e d ( ) then s e l fe l s e p a r e n t R e g i o n . p a r e n t S t a t e . p a r e n t S t a t e c h a r t e n d i f ) .o p e r a t i o n s −>a s O r d e r e d S e t ( )


/allAvailableVariables : Variable [0..∗] see Section A.2.7 onPage 216

All variables accessible within this statechart.

derivation

s e l f −> c l o s u r e ( i f p a r e n t R e g i o n . o c l I s U n d e f i n e d ( ) then s e l fe l s e p a r e n t R e g i o n . p a r e n t S t a t e . p a r e n t S t a t e c h a r t e n d i f ) .v a r i a b l e s −>a s O r d e r e d S e t ( )

/availableClocks : Clock [0..∗] see Section A.9.4 on Page 269

Available clocks are all clocks that were defined in this statechart or in ancestorstatecharts.

derivation

s e l f −> c l o s u r e (i f p a r e n t R e g i o n . o c l I s U n d e f i n e d ( ) then

s e l fe l s e

p a r e n t R e g i o n . p a r e n t S t a t e . p a r e n t S t a t e c h a r te n d i f

) . c l o c k s−>a s S e t ( )

clocks : Clock [0..∗] see Section A.9.4 on Page 269

The clocks of this realtime statechart.

parentRegion : Region [0..1] see Section A.9.18 on Page 279

If the real-time statechart is embedded into a region of a composite state, thanthis reference returns the region of this state. If the real-time statechart is notembedded, this reference will be undefined.

states : State [1..∗] see Section A.9.20 on Page 280

The states of this realtime statechart.

transitions : Transition [0..∗] see Section A.9.26 on Page 285

The transitions of the realtime statechart.

EOperations of RealtimeStatechart

getHighestParentStatechart : RealtimeStatechart [1..1]see Section A.9.17 on Page 275

Returns realtime statechart which represents the root of the hierarchy tree.

body (in Java)


R e a l t i m e S t a t e c h a r t r t s c = t h i s ;whi le ( r t s c . isEmbedded ( ) == t rue ){ r t s c = r t s c . g e t P a r e n t R e g i o n ( ) . g e t P a r e n t S t a t e ( ) .

g e t P a r e n t S t a t e c h a r t ( ) ; }re turn r t s c ;

getPortOrRoleStatechart : RealtimeStatechart [1..1] seeSection A.9.17 on Page 275

Returns itself if a Port or a Role is referenced or the next ancestor that referencesa Port or a Role. If no Port or a Role is found, then itself is returned.

body (in Java)/ / check i f t h i s r t s c has a b e h a v i o r a l e l e m e n tR e a l t i m e S t a t e c h a r t r t s c = t h i s ;i f ( r t s c . g e t B e h a v i o r a l E l e m e n t ( ) != n u l l \&\& ( ( r t s c .

g e t B e h a v i o r a l E l e m e n t ( ) i n s t a n c e o f P o r t ) | | ( r t s c .g e t B e h a v i o r a l E l e m e n t ( ) i n s t a n c e o f Role ) ) ) re turn r t s c ;

/ / s e a r c h f o r a n c e s t o r w i t h b e h a v i o r a l e l e m e n twhi le ( r t s c . isEmbedded ( ) == t rue ){r t s c = r t s c . g e t P a r e n t R e g i o n ( ) . g e t P a r e n t S t a t e ( ) .

g e t P a r e n t S t a t e c h a r t ( ) ;i f ( r t s c . g e t B e h a v i o r a l E l e m e n t ( ) != n u l l \&\& ( ( r t s c .

g e t B e h a v i o r a l E l e m e n t ( ) i n s t a n c e o f P o r t ) | | ( r t s c .g e t B e h a v i o r a l E l e m e n t ( ) i n s t a n c e o f Role ) ) ) re turn r t s c ;

}

/ / no r t s c found w i t h b e h a v i o r a l e l e m e n tre turn t h i s ;

isSuperStatechartOf : EBoolean [1..1]

Returns whether this statechart is a super-statechart of the given Real-TimeStatechart.

EParameters

statechart : RealtimeStatechart [1..1]

The statechart to be checked for being a sub-statechart.

body (in Java)/ / TODO: Rep lace by OCL ’ s t r a n s i t i v e c l o s u r e ?

A s s e r t . i s L e g a l ( s t a t e c h a r t != n u l l ) ;

B r e a d t h F i r s t S e a r c h A l g o r i t h m b f s = newB r e a d t h F i r s t S e a r c h A l g o r i t h m ( ) ;

re turn b f s . s e a r c h ( s t a t e c h a r t , new I S e a r c h V i s i t o r ( ) {

@Overridep u b l i c boolean v i s i t ( O b j e c t o b j e c t ) {

re turn ! R e a l t i m e S t a t e c h a r t I m p l . t h i s . e q u a l s ( o b j e c t ) ;}

@Overridep u b l i c L i s t <?> g e t A d j a c e n t N o d e s ( O b j e c t o b j e c t ) {

R e a l t i m e S t a t e c h a r t r t s c = ( R e a l t i m e S t a t e c h a r t ) o b j e c t ;

L i s t < Objec t > p a r e n t S t a t e c h a r t s = new A r r a y L i s t < Objec t> ( ) ;

Region r e g i o n = r t s c . g e t P a r e n t R e g i o n ( ) ;i f ( r e g i o n != n u l l ) {

/ / L i s t <Region > r e g i o n s = r t s c . g e t P a r e n t R e g i o n s ( ) ;/ / f o r ( Region r e g i o n : r e g i o n s ) {S t a t e s t a t e = r e g i o n . g e t P a r e n t S t a t e ( ) ;i f ( s t a t e != n u l l \&\& s t a t e . g e t P a r e n t S t a t e c h a r t ( )

!= n u l l ) {p a r e n t S t a t e c h a r t s . add ( s t a t e . g e t P a r e n t S t a t e c h a r t ( )

) ;}/ / }

}

re turn p a r e n t S t a t e c h a r t s ;}

} ) ;

OCL Constraints of RealtimeStatechart

UniqueNameOfStates

−− S t a t e names must be un iq ues e l f . s t a t e s −>i s U n i q u e ( name )

NoCycles

−− I f we a r e c o n t a i n e d w i t h i n a s t a t e c h a r t . . .( not s e l f . p a r e n t R e g i o n . p a r e n t S t a t e . p a r e n t S t a t e c h a r t .

o c l I s U n d e f i n e d ( ) )

i m p l i e s

−− . . . t h e n we must not be a s u p e r s t a t e c h a r t o f i t .( not s e l f . i s S u p e r S t a t e c h a r t O f ( s e l f . p a r e n t R e g i o n . p a r e n t S t a t e .

p a r e n t S t a t e c h a r t ) )

OneInitialState


−− An i n i t i a l s t a t e i s m i s s i n gs e l f . s t a t e s −> s e l e c t ( s | s . i n i t i a l )−> s i z e ( ) = 1

A.9.18. EClass Region

Overview Regions enables hierarchy and parallelism. Each state can have zero, one or moreregions.

ESuper Types of Region


PrioritizedElement see Section A.9.16 on Page 274

EAttributes of Region

/name : EString [0..1]

The name of a region is derived by its conaining Real-Time Statechart

derivation

i f not s e l f . e m b e d d e d S t a t e c h a r t . o c l I s U n d e f i n e d ( ) thens e l f . e m b e d d e d S t a t e c h a r t . oclAsType ( r e a l t i m e s t a t e c h a r t : :

R e a l t i m e S t a t e c h a r t ) . namee l s e

n u l le n d i f

EReferences of Region

embeddedStatechart : RealtimeStatechart [1..1] seeSection A.9.17 on Page 275

The realtime statechart this region embeds.

parentState : State [1..1] see Section A.9.20 on Page 280

The state this region is embedded.

A.9.19. EClass RelativeDeadline

Overview This class represents a relative deadline. It is always associated with a transitionof the statechart. The deadlin is relative to the point in time when the execution of thetransition starts.

ESuper Types of RelativeDeadline

Deadline see Section A.9.6 on Page 270


A.9.20. EClass State

Overview This class represents a composite state of a realtime statechart. Composite statesmay again contain realtime statecharts hence enabling the creation of hierarchicalstatecharts. Further more composite states have do, entry and exit actions. Alsocomposite states define which synchronization channels are allowed to be used byembedded statecharts.

ESuper Types of State

Vertex see Section A.9.28 on Page 292

EAttributes of State

final : EBoolean [0..1]

a final state is not allowed to have outgoing transitions.

initial : EBoolean [0..1]

An initial state is the first one to active if the statechart is activated. There is onlyone initial state allowed at the top hierarchy of a statechart.

/simple : EBoolean [0..1]

A state is simple if it does not contain a region with an embedded substatechart.

derivation

−− a s t a t e i s s i m p l e i f i t c o n t a i n s no r e g i o n sembeddedRegions−>isEmpty ( )

urgent : EBoolean [0..1]

If a state is active and urgent, no time is allowed to pass until the state is leaved.

EReferences of State

/allAvailableChannels : SynchronizationChannel [0..∗]see Section A.9.24 on Page 284

All synchronization channels accessible within this state.

derivation

s e l f −> c l o s u r e ( i f p a r e n t S t a t e c h a r t . p a r e n t R e g i o n .o c l I s U n d e f i n e d ( ) then s e l f e l s e p a r e n t S t a t e c h a r t .p a r e n t R e g i o n . p a r e n t S t a t e e n d i f ) . c h a n n e l s −>a s O r d e r e d S e t ( )

channels : SynchronizationChannel [0..∗] see Section A.9.24 onPage 284

The synchronization channels provided by this state.


connectionPoints : StateConnectionPoint [0..∗] seeSection A.9.21 on Page 283

A state references its connection points. They can only exist, if a state embeds oneor more statecharts.

doEvent : DoEvent [0..1] see Section A.9.7 on Page 270

The do event. It is executed periodically while the corresponding state is active.

embeddedRegions : Region [0..∗] see Section A.9.18 on Page 279

The regions of this state. Regions are used to model composite states. In caseof one region, we have an xor superstate, in case of multiple regions, we have anAND-superstate.

entryEvent : EntryEvent [0..1] see Section A.9.8 on Page 270

The entry action is exectuted once when the corresponding state is entered.

/events : StateEvent [0..∗] see Section A.9.22 on Page 283

This derived reference returns all StateEvents of this state. The StateEvents of thisstate are all entry-, do- and exit-Events.

derivation

Set { e n t r y E v e n t , e x i t E v e n t , doEvent }−> s e l e c t ( x | not x .o c l I s U n d e f i n e d ( ) )

exitEvent : ExitEvent [0..1] see Section A.9.13 on Page 272

The exit action is exectuted once when the corresponding state is left.

invariants : ClockConstraint [0..∗] see Section A.9.5 on Page 269

The invariant belonging to this complex state. It describes how long it is allowedto reside in this complex state depending on the values of the clocks.

parentStatechart : RealtimeStatechart [0..1] seeSection A.9.17 on Page 275

The realtime statechart this state belongs to.

EOperations of State

getUniqueRegionPriority : EInt [0..1]

Returns the next free higher region priority that is closest to the value provided ashint.

EParameters

hint : EInt [0..1]

The integer value that represents a hint for the priority to be computed.


body (in Java)i n t n e x t H i g h e s t P r i o r i t y = h i n t ;f o r ( ; h a s R e g i o n O f P r i o r i t y ( n e x t H i g h e s t P r i o r i t y ) ;

n e x t H i g h e s t P r i o r i t y ++) ;re turn n e x t H i g h e s t P r i o r i t y ;

hasRegionOfPriority : EBoolean [0..1]

Returns true, if this state contains a region of the given priority.

EParameters


The priority value to be checked.

body (in Java)f o r ( Region r e g i o n : getEmbeddedRegions ( ) ) {

i f ( r e g i o n . g e t P r i o r i t y ( ) == p r i o r i t y ) {re turn true ;

}}re turn f a l s e ;

OCL Constraints of State

NoOutgoingTransitionOfFinalState

−− F i n a l s t a t e s must not have o u t g o i n g t r a n s i t i o n ss e l f . f i n a l i m p l i e s s e l f . o u t g o i n g T r a n s i t i o n s −>isEmpty ( )

NoRegionsOfFinalState

−− F i n a l s t a t e s must not have r e g i o n ss e l f . f i n a l i m p l i e s s e l f . embeddedRegions−>isEmpty ( )

UniquePrioritiesOfOutgoingTransitions

−− Outgoing t r a n s i t i o n s must have a u n iq ue p r i o r i t ys e l f . o u t g o i n g T r a n s i t i o n s −>i s U n i q u e ( p r i o r i t y )

UniquePrioritiesOfRegions

−− Regions must have a u n i qu e p r i o r i t ys e l f . embeddedRegions−>i s U n i q u e ( p r i o r i t y )

UniqueChannelNames

−− S y n c h r o n i z a t i o n c h a n n e l s must have a un iq ue names e l f . c h a n n e l s−>i s U n i q u e ( name )

UniqueRegionNames


−− Regions must have a u n i qu e names e l f . embeddedRegions−>i s U n i q u e ( name )

InvalidClockConstraintOperator

−− Clock C o n s t r a i n t s must on ly use o p e r a t o r s LESS and LESS \ _OR \_EQUAL

s e l f . i n v a r i a n t s −> f o r A l l ( i n v a r i a n t | S e t { c o r e : : e x p r e s s i o n s : : common: : Compar ingOpera to r : : LESS , c o r e : : e x p r e s s i o n s : : common : :Compar ingOpera to r : : LESS \ _OR \_EQUAL }−> i n c l u d e s ( i n v a r i a n t .operator ) )

UniqueStateConnectionPointNames

−− S t a t e C o n n e c t i o n P o i n t s o f a c o m p o s i t e s t a t e must have u n iq uenames .

s e l f . c o n n e c t i o n P o i n t s −>i s U n i q u e ( name )

A.9.21. Abstract EClass StateConnectionPoint

Overview A ConnectionPoint is a pseudostate which makes it possible to chain transitionsbetween different hierarchy levels. The ConnectionPoint is assigned to a state.

ESuper Types of StateConnectionPoint

Vertex see Section A.9.28 on Page 292

EReferences of StateConnectionPoint

state : State [1..1] see Section A.9.20 on Page 280

The StateEntryPoint is assigned to a state.

OCL Constraints of StateConnectionPoint

ConnectionPointsOnlyAtCompositeStates

−− S t a t e c o n n e c t i o n p o i n t s a r e on ly a l l o w e d a t c o m p o s i t e ( non−s i m p l e ) s t a t e s

not s e l f . s t a t e . o c l I s U n d e f i n e d ( ) i m p l i e s not s e l f . s t a t e . s i m p l e

A.9.22. Abstract EClass StateEvent

Overview A StateEvent is an event that occurs within a state of a real-time statechart.StateEvents may only be trigger events.

ESuper Types of StateEvent

Event see Section A.9.11 on Page 272


A.9.23. EClass Synchronization

Overview Two transitions can synchron fire. One transition is the sender, the other thereceiver. This means that both transitions (exactly one sender and one receiver) mustbe activated and has to fire at the same time.

ESuper Types of Synchronization


EAttributes of Synchronization

kind : SynchronizationKind [1..1] see Section A.9.25 on Page 285

Decides the kind: Is this a send or a reveive synchronization?

EReferences of Synchronization

selectorExpression : Expression [0..1] see Section A.14.1 onPage 318

An expression that evaluates to a value which is used to select a particularcounterpart for the synchronization.

syncChannel : SynchronizationChannel [0..1] seeSection A.9.24 on Page 284

the channel that is used by the synchronization

OCL Constraints of Synchronization

SelectorExpressionNecessary

−− S e l e c t e d S y n c h r o n i z a t i o n C h a n n e l r e q u i r e s t h i s S y n c h r o n i z a t i o nt o s p e c i f y a s e l e c t o r e x p r e s s i o n .

not syncChanne l . s e l e c t o r T y p e . o c l I s U n d e f i n e d ( ) i m p l i e s nots e l e c t o r E x p r e s s i o n . o c l I s U n d e f i n e d ( )

SelectorExpressionForbidden

−− S e l e c t e d S y n c h r o n i z a t i o n C h a n n e l f o r b i d s t h i s S y n c h r o n i z a t i o nt o s p e c i f y a s e l e c t o r e x p r e s s i o n .

not syncChanne l . o c l I s U n d e f i n e d ( ) i m p l i e s ( syncChanne l .s e l e c t o r T y p e . o c l I s U n d e f i n e d ( ) i m p l i e s s e l e c t o r E x p r e s s i o n .o c l I s U n d e f i n e d ( ) )

A.9.24. EClass SynchronizationChannel

Overview Defines a type of a synchronization channel that can be used to synchronizebetween statecharts contained as substatecharts in the same state. Serves as a type forSynchronizations.


ESuper Types of SynchronizationChannel



EReferences of SynchronizationChannel

selectorType : DataType [0..1] see Section A.10.2 on Page 294

A data type that provides possible values for the selection of a particularcounterpart when synchronizing over this channel.

state : State [1..1] see Section A.9.20 on Page 280

The state in which this synchronization channel is defined.

A.9.25. EEnumeration SynchronizationKind

Overview A synchronization has two possible kinds: send and receive.

ELiterals of SynchronizationKind

SEND = 0

Represents a send synchronization.

RECEIVE = 1

Represents a receive synchronization.

A.9.26. EClass Transition

Overview A transition connects different vertices. If the vertex is a state a self-transition isalso possible.

ESuper Types of Transition

PrioritizedElement see Section A.9.16 on Page 274


EAttributes of Transition

blockable : EBoolean [0..1]

Needed for failure propagation.

urgent : EBoolean [0..1]

Indicates whether this transition fires immediately when it is enabled.

EReferences of Transition


absoluteDeadlines : AbsoluteDeadline [0..∗] see Section A.9.1on Page 267

a transition can has one or more absolute deadlines


The side effect of this transition. A side effect might be a variable assignment aswell as a method invocation.

clockConstraints : ClockConstraint [0..∗] see Section A.9.5 onPage 269

A clock constraint restricts when the transition can be activeted in dependency ofthe values of the clock.

clockResets : Clock [0..∗] see Section A.9.4 on Page 269

The clock resets of this transition.

events : TransitionEvent [0..∗] see Section A.9.27 on Page 292

All events which belong to this transition.

guard : Expression [0..1] see Section A.14.1 on Page 318

The guard of a transition is defined by an expression which should have return typeboolean. Comparing clock values is not allowed (use clock constraints instead).

/raiseMessageEvent : AsynchronousMessageEvent [0..1] seeSection A.9.3 on Page 267

The event which is raised upon activiation of this transition.

derivation

l e t e v e n t S e t : Sequence ( AsynchronousMessageEvent ) = s e l f .e v e n t s−> s e l e c t ( e | e . o c l I s K i n d O f ( AsynchronousMessageEvent )

and e . k ind =EventKind : : RAISE ) . oclAsType (AsynchronousMessageEvent ) i n

i f e v e n t S e t −> s i z e ( ) = 0 then n u l l e l s e e v e n t S e t −> f i r s t ( )e n d i f

/receiverMessageTypes : MessageType [0..∗] see Section A.7.1on Page 259

All message types accessible by the trigger message event of this transition.

derivation

i f s t a t e c h a r t . o c l I s U n d e f i n e d ( ) thenO r d e r e d S e t { }

e l s ei f s t a t e c h a r t . g e t P o r t O r R o l e S t a t e c h a r t ( ) . o c l I s U n d e f i n e d ( )

thenO r d e r e d S e t { }


e l s el e t b : b e h a v i o r : : B e h a v i o r a l E l e m e n t = s t a t e c h a r t .

g e t P o r t O r R o l e S t a t e c h a r t ( ) . b e h a v i o r a l E l e m e n t i ni f b . o c l I s U n d e f i n e d ( ) then

O r d e r e d S e t { }e l s e

i f b . o c l I s K i n d O f ( c o n n e c t o r : :D i s c r e t e I n t e r a c t i o n E n d p o i n t ) then

b . oclAsType ( c o n n e c t o r : :D i s c r e t e I n t e r a c t i o n E n d p o i n t ) .r e c e i v e r M e s s a g e T y p e s

e l s eO r d e r e d S e t { }

e n d i fe n d i f

e n d i fe n d i f

relativeDeadline : RelativeDeadline [0..1] see Section A.9.19on Page 279

a transition can have one relative deadline

/senderMessageTypes : MessageType [0..∗] see Section A.7.1 onPage 259

All message types accessible by the raise message event of this transition.

derivation

i f s t a t e c h a r t . o c l I s U n d e f i n e d ( ) thenO r d e r e d S e t { }

e l s ei f s t a t e c h a r t . g e t P o r t O r R o l e S t a t e c h a r t ( ) . o c l I s U n d e f i n e d ( )

thenO r d e r e d S e t { }

e l s el e t b : b e h a v i o r : : B e h a v i o r a l E l e m e n t = s t a t e c h a r t .

g e t P o r t O r R o l e S t a t e c h a r t ( ) . b e h a v i o r a l E l e m e n t i ni f b . o c l I s U n d e f i n e d ( ) then

O r d e r e d S e t { }e l s e

i f b . o c l I s K i n d O f ( c o n n e c t o r : :D i s c r e t e I n t e r a c t i o n E n d p o i n t ) then

b . oclAsType ( c o n n e c t o r : :D i s c r e t e I n t e r a c t i o n E n d p o i n t ) .senderMessageTypes

e l s eO r d e r e d S e t { }

e n d i fe n d i f

e n d i f


e n d i f

source : Vertex [1..1] see Section A.9.28 on Page 292

The state which is the source of this transition.

statechart : RealtimeStatechart [1..1] see Section A.9.17 onPage 275

The realtime statechart this transition belongs to.

derivation

i f ( s e l f . s o u r c e . o c l I s K i n d O f ( S t a t e ) )then s e l f . s o u r c e . oclAsType ( S t a t e ) . p a r e n t S t a t e c h a r te l s e

i f ( s e l f . t a r g e t . o c l I s K i n d O f ( S t a t e ) )then s e l f . t a r g e t . oclAsType ( S t a t e ) . p a r e n t S t a t e c h a r te l s e

i f ( s e l f . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t ) )then s e l f . s o u r c e . oclAsType ( E x i t P o i n t ) . s t a t e .

p a r e n t S t a t e c h a r te l s e

i f ( s e l f . t a r g e t . o c l I s K i n d O f ( E n t r y P o i n t ) )then s e l f . t a r g e t . oclAsType ( E n t r y P o i n t ) . s t a t e .

p a r e n t S t a t e c h a r te l s e n u l l −− t h i s t r a n s i t i o n i s i l l e g a l a c c o r d i n g t o our

s y n t a c t i c c o n s t r a i n t s , no e n c l o s i n g s t a t e c h a r t canbe a s s i g n e d

e n d i fe n d i f

e n d i fe n d i f

synchronization : Synchronization [0..1] see Section A.9.23 onPage 284

The synchronisation which is sent upon activation of this transition.

target : Vertex [1..1] see Section A.9.28 on Page 292

The state which is the target of this transition.

/triggerMessageEvent : AsynchronousMessageEvent [0..1]see Section A.9.3 on Page 267

The trigger event of this transition.

derivation

l e t e v e n t S e t : Sequence ( AsynchronousMessageEvent ) = s e l f .e v e n t s−> s e l e c t ( e | e . o c l I s K i n d O f ( AsynchronousMessageEvent )

and e . k ind =EventKind : : TRIGGER) . oclAsType (AsynchronousMessageEvent ) i n


i f e v e n t S e t −> s i z e ( ) = 0 then n u l l e l s e e v e n t S e t −> f i r s t ( )e n d i f

OCL Constraints of Transition

LegalTransitionsOnly

−− I n t e r− l e v e l t r a n s i t i o n s a r e i n v a l i d

i f ( s e l f . s o u r c e . o c l I s U n d e f i n e d ( ) or s e l f . t a r g e t . o c l I s U n d e f i n e d ( ) )t h e n

t ruee l s e−− S t a t e A1 t o E x i t P o i n t o f A2 , where A2 i s t h e d i r e c t p a r e n t

s t a t e o f A1( s e l f . s o u r c e . o c l I s K i n d O f ( S t a t e ) and s e l f . t a r g e t . o c l I s K i n d O f (

E x i t P o i n t ) and s e l f . t a r g e t . oclAsType ( E x i t P o i n t ) . s t a t e .embeddedRegions . e m b e d d e d S t a t e c h a r t . s t a t e s −> i n c l u d e s ( s e l f .s o u r c e . oclAsType ( S t a t e ) ) )

or−− E n t r y P o i n t o f A1 t o S t a t e A2 , where A1 i s t h e d i r e c t p a r e n t

s t a t e o f A2( s e l f . s o u r c e . o c l I s K i n d O f ( E n t r y P o i n t ) and s e l f . t a r g e t . o c l I s K i n d O f (

S t a t e ) and s e l f . s o u r c e . oclAsType ( E n t r y P o i n t ) . s t a t e .embeddedRegions . e m b e d d e d S t a t e c h a r t . s t a t e s −> i n c l u d e s ( s e l f .t a r g e t . oclAsType ( S t a t e ) ) )

or−− E n t r y P o i n t o f A1 t o E n t r y P o i n t o f A2 , where A1 i s t h e d i r e c t

p a r e n t s t a t e o f A2( s e l f . s o u r c e . o c l I s K i n d O f ( E n t r y P o i n t ) and s e l f . t a r g e t . o c l I s K i n d O f (

E n t r y P o i n t ) and s e l f . s o u r c e . oclAsType ( E n t r y P o i n t ) . s t a t e .embeddedRegions . e m b e d d e d S t a t e c h a r t . s t a t e s −> i n c l u d e s ( s e l f .t a r g e t . oclAsType ( E n t r y P o i n t ) . s t a t e ) )

or−− E x i t P o i n t o f A1 t o E x i t P o i n t o f A2 , where A2 i s t h e d i r e c t

p a r e n t s t a t e o f A1( s e l f . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t ) and s e l f . t a r g e t . o c l I s K i n d O f (

E x i t P o i n t ) and s e l f . t a r g e t . oclAsType ( E x i t P o i n t ) . s t a t e .embeddedRegions . e m b e d d e d S t a t e c h a r t . s t a t e s −> i n c l u d e s ( s e l f .s o u r c e . oclAsType ( E x i t P o i n t ) . s t a t e ) )

or−− S t a t e A t o S t a t e B w i t h i n t h e same s t a t e c h a r t( s e l f . s o u r c e . o c l I s K i n d O f ( S t a t e ) and s e l f . t a r g e t . o c l I s K i n d O f ( S t a t e

) and s e l f . s o u r c e . oclAsType ( S t a t e ) . p a r e n t S t a t e c h a r t = s e l f .t a r g e t . oclAsType ( S t a t e ) . p a r e n t S t a t e c h a r t )

or−− S t a t e A t o E n t r y P o i n t o f B , where A and B a r e i n t h e same

s t a t e c h a r t


( s e l f . s o u r c e . o c l I s K i n d O f ( S t a t e ) and s e l f . t a r g e t . o c l I s K i n d O f (E n t r y P o i n t ) and s e l f . s o u r c e . oclAsType ( S t a t e ) . p a r e n t S t a t e c h a r t= s e l f . t a r g e t . oclAsType ( E n t r y P o i n t ) . s t a t e . p a r e n t S t a t e c h a r t )

or−− E x i t P o i n t o f A t o E n t r y P o i n t o f B , where A and B a r e i n t h e

same s t a t e c h a r t( s e l f . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t ) and s e l f . t a r g e t . o c l I s K i n d O f (

E n t r y P o i n t ) and s e l f . s o u r c e . oclAsType ( E x i t P o i n t ) . s t a t e .p a r e n t S t a t e c h a r t = s e l f . t a r g e t . oclAsType ( E n t r y P o i n t ) . s t a t e .p a r e n t S t a t e c h a r t )

or−− E x i t P o i n t o f A t o S t a t e B , where A and B a r e i n t h e same

s t a t e c h a r t( s e l f . s o u r c e . o c l I s K i n d O f ( E x i t P o i n t ) and s e l f . t a r g e t . o c l I s K i n d O f (

S t a t e ) and s e l f . s o u r c e . oclAsType ( E x i t P o i n t ) . s t a t e .p a r e n t S t a t e c h a r t = s e l f . t a r g e t . oclAsType ( S t a t e ) .p a r e n t S t a t e c h a r t )

e n d i f

TriggerMessageEventsMustNotHaveAnOwnedParameterBinding

−− T r i g g e r Message Event must be p a r a m e t e r l e s s ( no p a r a m e t e rb i n d i n g a l l o w e d )

not s e l f . t r i g g e r M e s s a g e E v e n t . message . o c l I s U n d e f i n e d ( ) i m p l i e ss e l f . t r i g g e r M e s s a g e E v e n t . message . p a r a m e t e r B i n d i n g−>isEmpty ( )

ValidTriggerMessageEvents

−− T r i g g e r message t y p e must be added t o r e c e i v e r message t y p e snot t r i g g e r M e s s a g e E v e n t . message . i n s t a n c e O f . o c l I s U n d e f i n e d ( )

i m p l i e s r e c e i v e r M e s s a g e T y p e s−> i n c l u d e s ( t r i g g e r M e s s a g e E v e n t .message . i n s t a n c e O f )

ValidRaiseMessageEvents

−− R a i s e message t y p e must be added t o s e n d e r message t y p e snot r a i s e M e s s a g e E v e n t . message . i n s t a n c e O f . o c l I s U n d e f i n e d ( ) i m p l i e s

senderMessageTypes−> i n c l u d e s ( r a i s e M e s s a g e E v e n t . message .i n s t a n c e O f )

StateConnectionPointIncomingTransitionsNoSideEffectsOrDeadlines

−− T r a n s i t i o n s t o s t a t e c o n n e c t i o n p o i n t s must not d e f i n e s i d ee f f e c t s or d e a d l i n e s

( not s e l f . t a r g e t . o c l I s U n d e f i n e d ( ) and s e l f . t a r g e t . o c l I s K i n d O f (r e a l t i m e s t a t e c h a r t : : S t a t e C o n n e c t i o n P o i n t ) )i m p l i e s (

s e l f . c l o c k R e s e t s −>isEmpty ( )and s e l f . a c t i o n . o c l I s U n d e f i n e d ( )and s e l f . r a i s e M e s s a g e E v e n t . o c l I s U n d e f i n e d ( )and s e l f . a b s o l u t e D e a d l i n e s −>isEmpty ( )


and s e l f . r e l a t i v e D e a d l i n e . o c l I s U n d e f i n e d ( ))

StateConnectionPointOutgoingTransitionsNoConditions−− T r a n s i t i o n s from s t a t e c o n n e c t i o n p o i n t s must not have

c o n d i t i o n s( not s e l f . s o u r c e . o c l I s U n d e f i n e d ( ) and s e l f . s o u r c e . o c l I s K i n d O f (

r e a l t i m e s t a t e c h a r t : : S t a t e C o n n e c t i o n P o i n t ) )i m p l i e s (

s e l f . t r i g g e r M e s s a g e E v e n t . o c l I s U n d e f i n e d ( )and s e l f . c l o c k C o n s t r a i n t s −>isEmpty ( )and s e l f . gua rd . o c l I s U n d e f i n e d ( )and s e l f . s y n c h r o n i z a t i o n . o c l I s U n d e f i n e d ( )

)

StateConnectionPointOutgoingTransitionsMustBeUrgent−− T r a n s i t i o n s from s t a t e c o n n e c t i o n p o i n t s must be u r g e n t( not s e l f . s o u r c e . o c l I s U n d e f i n e d ( ) and s e l f . s o u r c e . o c l I s K i n d O f (

r e a l t i m e s t a t e c h a r t : : S t a t e C o n n e c t i o n P o i n t ) )i m p l i e s (

s e l f . u r g e n t)

NoCombinationOfRelativeAndAbsoluteDeadlines−− D e f i n i n g bo th r e l a t i v e and a b s o l u t e d e a d l i n e s i s f o r b i d d e n( not s e l f . r e l a t i v e D e a d l i n e . o c l I s U n d e f i n e d ( ) ) i m p l i e s ( s e l f .

a b s o l u t e D e a d l i n e s −>isEmpty ( ) )

NoCombinationOfReceivedSynchronizationAndTriggerMessage−− A t r a n s i t i o n must not s p e c i f y a r e c e i v e d s y n c h r o n i z a t i o n and a

t r i g g e r message a t t h e same t ime( ( not s e l f . s y n c h r o n i z a t i o n . o c l I s U n d e f i n e d ( ) ) and ( s e l f .

s y n c h r o n i z a t i o n . k ind = S y n c h r o n i z a t i o n K i n d : : RECEIVE ) )i m p l i e ss e l f . t r i g g e r M e s s a g e E v e n t . o c l I s U n d e f i n e d ( )

TransitionMustBeContainedByCorrectStatechart−− A t r a n s i t i o n must be c o n t a i n e d by i t s l o g i c a l p a r e n t

s t a t e c h a r t( not s e l f . s t a t e c h a r t . o c l I s U n d e f i n e d ( ) ) i m p l i e s ( s e l f . s t a t e c h a r t .

t r a n s i t i o n s −> i n c l u d e s ( s e l f ) )

OutgoingTransitionOfUrgentStateMustBeUrgent−− An o u t g o i n g t r a n s i t i o n o f an u r g e n t s t a t e must be u r g e n t

i t s e l f( s e l f . s o u r c e . o c l I s K i n d O f ( S t a t e ) and s e l f . s o u r c e . oclAsType ( S t a t e ) .

u r g e n t ) i m p l i e s s e l f . u r g e n t


A.9.27. Abstract EClass TransitionEvent

Overview A TransitionEvent is an event that occurs at a transition of a real-time statechart.Trigger Events are part of the precondition for activating the transition, raise events aregenerated as a result of firing the transition.

ESuper Types of TransitionEvent

Event see Section A.9.11 on Page 272

A.9.28. Abstract EClass Vertex

Overview This class represents a node in a realtime statechart that is connected with othernodes via transitions.

ESuper Types of Vertex



EReferences of Vertex

/allSuperVertices : Vertex [0..∗] see Section A.9.28 on Page 292

All super vertices of this vertex.

derivation

i f s e l f . o c l I s K i n d O f ( S t a t e )then s e l f . oclAsType ( S t a t e )−> c l o s u r e ( s | i f s . p a r e n t S t a t e c h a r t

. embedded then s . p a r e n t S t a t e c h a r t . p a r e n t R e g i o n . p a r e n t S t a t ee l s e n u l l e n d i f )−>a s O r d e r e d S e t ( )

e l s ei f s e l f . o c l I s K i n d O f ( S t a t e C o n n e c t i o n P o i n t )then l e t s t a t e : S t a t e = s e l f . oclAsType (

S t a t e C o n n e c t i o n P o i n t ) . s t a t e i n s t a t e −>un ion ( s t a t e −>c l o s u r e ( s | i f s . p a r e n t S t a t e c h a r t . embedded then s .p a r e n t S t a t e c h a r t . p a r e n t R e g i o n . p a r e n t S t a t e e l s e n u l le n d i f ) )−>a s O r d e r e d S e t ( )

e l s e O r d e r e d S e t { }e n d i f

e n d i f

incomingTransitions : Transition [0..∗] see Section A.9.26 onPage 285

The incoming transitions of this vertex

outgoingTransitions : Transition [0..∗] see Section A.9.26 onPage 285

The outgoing transitions of this vertex

EOperations of Vertex

getUniqueTransitionPriority : EInt [0..1]

Returns the next free higher transition priority that is closest to the value providedas hint.

EParameters

hint : EInt [0..1]

The integer value that represents a hint for the priority to be computed.

body (in Java)i n t n e x t H i g h e s t T r a n s i t i o n P r i o r i t y = h i n t ;f o r ( ; h a s O u t g o i n g T r a n s i t i o n O f P r i o r i t y (

n e x t H i g h e s t T r a n s i t i o n P r i o r i t y ) ;n e x t H i g h e s t T r a n s i t i o n P r i o r i t y ++) ;

re turn n e x t H i g h e s t T r a n s i t i o n P r i o r i t y ;

hasOutgoingTransitionOfPriority : EBoolean [0..1]

Returns <code>true</code>, if this Vertex contains an outgoing transition of thegiven priority.

EParameters


The priority value to be checked for.

body (in Java)f o r ( T r a n s i t i o n t r a n s i t i o n : g e t O u t g o i n g T r a n s i t i o n s ( ) ) {

i f ( t r a n s i t i o n . g e t P r i o r i t y ( ) == p r i o r i t y ) {re turn true ;

}}re turn f a l s e ;

isSuperVertexOf : EBoolean [1..1]

Returns if this vertex is a super vertex of another vertex.

EParameters

vertex : Vertex [0..1]

The vertex to be checked as a sub-vertex.

A.10. EPackage muml::types

Overview This package provides modeling support for data types.

ArrayDataType PrimitiveDataType

primitiveType : PrimitiveTypes

DataType<<enumeration>>PrimitiveTypes

VOID

BOOLEAN

BYTE

SHORT

INT

LONG

DOUBLE

RangedPrimitiveDataType

type1

rangedType1

Figure A.10.: Meta-Model of the types Package

A.10.1. EClass ArrayDataType

Overview This data type represents an array data type and specifies the maximum cardinalityof inner data types.

ESuper Types of ArrayDataType


EReferences of ArrayDataType

cardinality : NaturalNumber [1..1] see Section A.11.2 on Page 296

The cardinality that induces the index for this array data type.

type : DataType [1..1] see Section A.10.2 on Page 294

This reference points to the definition of the data type.

A.10.2. Abstract EClass DataType

Overview Abstract super class for all types that may be used for attributes, parameters, andoperations.

ESuper Types of DataType

NamedElement see Section A.13.4 on

A.10. EPACKAGE MUML::TYPES 295

A.10.3. EClass PrimitiveDataType

Overview This data type represents a primitive data type and refers to the PrimitiveDataTypeenumeration for specifying the concrete primitive type.

ESuper Types of PrimitiveDataTypeDataType see Section A.10.2 on Page 294

EAttributes of PrimitiveDataTypeprimitiveType : PrimitiveTypes [1..1] see Section A.10.4 on

Page 295

Refers to the primitive data type as defined by the PrimitiveDataType enumeration.It defines the actual type.

A.10.4. EEnumeration PrimitiveTypes

Overview Defines all primitive types that may be used in MechatronicUML.

ELiterals of PrimitiveTypesVOID = 0

BOOLEAN = 1

BYTE = 2

SHORT = 3

INT = 4

LONG = 5

DOUBLE = 6

A.10.5. EClass RangedPrimitiveDataType

Overview A data type comprising a range of values from another primitive data type.

ESuper Types of RangedPrimitiveDataTypeDataType see Section A.10.2 on Page 294

EReferences of RangedPrimitiveDataTyperange : Range [1..1] see Section A.11.3 on Page 299

The range of values provided by this data type.

rangedType : PrimitiveDataType [1..1] see Section A.10.3 onPage 295

The primitive data type that provides a superset of possible values.

A.11. EPackage muml::valuetype

Overview The classes in this package define different types of values that are used in theMechatronicUML meta-model.

A.11.1. EClass Cardinality

Overview This class represents a two-dimensional range specification of an arbitrary modelobject. It consists of a lower and an upper bound where both need to be greater or equalto zero. Intuitively, the upper bound must be greater or equal to the lower bound.

EReferences of Cardinality

lowerBound : NaturalNumber [1..1] see Section A.11.2 on Page 296

The lower bound of this cardinality.

upperBound : NaturalNumber [1..1] see Section A.11.2 on Page 296

The upper bound of this cardinality.

OCL Constraints of Cardinality

LowerBoundMustBeLessOrEqualThanUpperBound

−− l ower bound of c a r d i n a l i t y must be l e s s or e q u a l t h a n uppe rbound

( not s e l f . lowerBound . o c l I s U n d e f i n e d ( ) and not s e l f . upperBound .o c l I s U n d e f i n e d ( ) ) i m p l i e s

(( ( not s e l f . lowerBound . i n f i n i t y and not s e l f . upperBound .

i n f i n i t y ) i m p l i e s ( s e l f . lowerBound . v a l u e <= s e l f . upperBound. v a l u e ) )

and ( s e l f . lowerBound . i n f i n i t y i m p l i e s s e l f . upperBound . i n f i n i t y)

)

A.11.2. EClass NaturalNumber

Overview This class represents either a natural number or infinity.

EAttributes of NaturalNumber

infinity : EBoolean [0..1]

Determins whether this natural number represents infinity.

value : ELong [0..1]

The value of this natural number.

A.11. EPACKAGE MUML::VALUETYPE 297

Card

inalit

y

Tim

eValu

e

un

it :

Tim

eU

nit

toS

trin

g()

: E

Str

ing

Natu

ralN

um

ber

valu

e :

ELo

ng

infinit

y :

EB

oole

an

setV

alu

e(E

Str

ing)

toStr

ing()

: E

Str

ing

eq

uals

(EO

bje

ct)

: EB

oole

an

less

OrE

qual(

Natu

ralN

um

ber)

: E

Boole

an

gre

ate

rOrE

qual(

Natu

ralN

um

ber)

: E

Boole

an

Range

low

erB

ound

: E

Lon

g

up

perB

ound :

ELo

ng

low

erB

ound 1

upp

erB

ound 1

Figure A.11.: Meta-Model of the valuetype Package


EOperations of NaturalNumber

equals : EBoolean [0..1]

Indicates whether this natural number equals the given object.

EParameters

o : EObject [0..1]

The object to be checked for equivalence.

body (in Java)i f ( o i n s t a n c e o f Natura lNumber ) {

Natura lNumber na tu r a lNumber = ( Natura lNumber ) o ;/ / Value o f i n f i n i t y must be e q u a li f ( i s I n f i n i t y ( ) != na tu r a lNumber . i s I n f i n i t y ( ) ) {

re turn f a l s e ;}/ / I f bo th are n o t i n f i n i t e , make s u r e t h e i r v a l u e i s

i d e n t i c a l .i f ( ! i s I n f i n i t y ( ) \&\& ( na tu r a lNumber . g e t V a l u e ( ) !=

g e t V a l u e ( ) ) ) {re turn f a l s e ;

}re turn true ;

}re turn f a l s e ;

greaterOrEqual : EBoolean [1..1]

Indicates whether this natural number if greater or equal to the given naturalnumber.

EParameters

n : NaturalNumber [1..1]

The given natural number.

lessOrEqual : EBoolean [1..1]

Indicates whether this natural number if less or equal to the given natural number.

EParameters

n : NaturalNumber [1..1]

The given natural number.

setValue : Void [0..1]

Set the value to the value of the given parameter.

EParameters


value : EString [0..1]

The new value to be set.

body (in Java)i f ( v a l u e == n u l l | | v a l u e . e q u a l s ( "∗ " ) ) {

s e t I n f i n i t y ( t rue ) ;re turn ;

}

/ / Conver t t o long , i f s t r i n g ca nn o t be parsed , s e t i n f i n i t y .long l ongVa lue ;t r y {

longVa lue = Long . pa r seLong ( v a l u e ) ;} catch ( NumberFormatExcept ion e ) {

s e t I n f i n i t y ( t rue ) ;re turn ;

}

/ / C a l l s e t V a l u e ( long ) o u t s i t e o f c a t c h b lock , so t h a t t h eNumberFormatExcept ion

/ / i n d i c a t i n g n e g a t i v e numbers i s n o t c a t c h e d .s e t V a l u e ( longVa lue ) ;


This operation yields the value of this natural number in a string representation.

body (in Java)i f ( i s I n f i n i t y ( ) ) {

re turn "∗ " ;}re turn Long . t o S t r i n g ( v a l u e ) ;

OCL Constraints of NaturalNumber

ValueGreaterOrEqualZero

−− N a t u r a l number must not be n e g a t i v es e l f . v a l u e >= 0

A.11.3. EClass Range

Overview This class represents a two-dimensional range specification of an arbitrary modelobject. It consists of a lower and an upper bound. Intuitively, the upper bound must begreater or equal to the lower bound.

EAttributes of Range

lowerBound : ELong [1..1]

Defines the lower bound of the range.

upperBound : ELong [1..1]

Defines the upper bound of the range.

OCL Constraints of Range

LowerBoundMustBeLessOrEqualThanUpperBound

−− l ower bound of r a n g e must be l e s s or e q u a l t h a n uppe r bounds e l f . lowerBound <= s e l f . upperBound

A.11.4. EDataType TimeUnit

Overview A data type for time units.

Instance Type Name java.util.concurrent.TimeUnit

A.11.5. EClass TimeValue

Overview A time value defines a value concerning time and an optional time unit. The valueis an expression and can therefore consist of various elements like variables, operatorsand literals.

ESuper Types of TimeValue


EAttributes of TimeValue

unit : TimeUnit [0..1] see Section A.11.4 on Page 300

The time unit of a time value. Defining the value is optional.

EReferences of TimeValue

value : Expression [1..1] see Section A.14.1 on Page 318

The value concerning time must be an expression. Defining the value is mandatory.

EOperations of TimeValue


body (in Java)


/ / Re tu rn v a l u e c o n c a t e n a t e d w i t h a b b r e v i a t e d u n i t .S t r i n g B u f f e r sb = new S t r i n g B u f f e r ( ) ;i f ( v a l u e == n u l l ) {

sb . append ( " n u l l " ) ;} e l s e {

i f ( v a l u e i n s t a n c e o f L i t e r a l E x p r e s s i o n ) {sb . append ( ( ( L i t e r a l E x p r e s s i o n ) v a l u e ) . g e t V a l u e ( ) ) ;

} e l s e {sb . append ( v a l u e . e C l a s s ( ) . getName ( ) ) ;

}}i f ( u n i t != n u l l ) {

sb . append ( ’ ’ ) ;sb . append ( TimeValueImpl . g e t U n i t R e p r e s e n t a t i o n ( u n i t ) ) ;

}re turn sb . t o S t r i n g ( ) ;

OCL Constraints of TimeValue

LiteralExpressionMustBeANaturalNumber

−− I f a TimeValue has as v a l u e a L i t e r a l E x p r e s s i o n , i t must be an a t u r a l number .

−− 1 . Check i f t h e L i t e r a l E x p r e s s i o n can be c a s t t o an I n t e g e r−− 2 . Check i f t h i s I n t e g e r i s g r e a t e r or e q u a l t o z e r o .

(not s e l f . v a l u e . o c l I s U n d e f i n e d ( )ands e l f . v a l u e . o c l I s K i n d O f ( c o r e : : e x p r e s s i o n s : : common : :

L i t e r a l E x p r e s s i o n ))i m p l i e s(not s e l f . v a l u e . oclAsType ( c o r e : : e x p r e s s i o n s : : common : :

L i t e r a l E x p r e s s i o n ) . v a l u e . t o I n t e g e r ( ) . o c l I s U n d e f i n e d ( )ands e l f . v a l u e . oclAsType ( c o r e : : e x p r e s s i o n s : : common : : L i t e r a l E x p r e s s i o n

) . v a l u e . t o I n t e g e r ( ) >=0)−− a u t h o r : x e l l−− t i c k e t : 770


A.12. EPackage actionlanguage

Overview The base package for the muml action language. It is an extension to thecore.ecore expression package. The action language contains block definition, controlstructures like conditional statements and loops, assignments, and variable and operationcall expressions.

A.12.1. EClass ArrayInitializeExpression

Overview Used to initialize a typed named element of type ArrayDataType (or a subtype).

ESuper Types of ArrayInitializeExpression

Expression see Section A.14.1 on Page 318

EReferences of ArrayInitializeExpression


A collection of expressions, each one used to initialize a particular field of an array.

A.12.2. EEnumeration AssignOperator

Overview Provides operators for the assignment of values to variables.

ELiterals of AssignOperator

UNSET = 0

ASSIGN = 1

PLUS_EQUAL = 2

EQUAL_PLUS = 3

MINUS_EQUAL = 4

EQUAL_MINUS = 5

A.12.3. EClass Assignment

Overview An assignment is used to assign a value to a variable.

ESuper Types of Assignment


EAttributes of Assignment

A.12. EPACKAGE ACTIONLANGUAGE 303

<<enumeration>>

AssignOperator

UNSET

ASSIGN

PLUS_EQUAL

EQUAL_PLUS

MINUS_EQUAL

EQUAL_MINUS

<<enumeration>>

IncrementDecrementOperator

UNSET

INCREMENT

DECREMENT

Block

Loop

WhileLoop

DoWhileLoop

Assignment

assignOperator : AssignOperator

incrementDecrementOperator : IncrementDecrementOperator

ForLoop

IfStatement

AttributeExpression

OperationCall

ReturnStatement

Expression

(from expressions)

Operation

(from core)

ParameterBinding

(from core)

expressions

0..*

block

0..1

ifBlock

0..1

elseIfBlocks

0..*

elseBlock

0..1

loopTest

0..1

lhs_attributeExpression0..1rhs_assignExpression0..1

initalizeExpression

0..1

countingExpression

0..1ifCondition

0..1

elseIfConditions

0..*

indices

0..*

operation1

parameterBinding 0..*

expression

0..1

Figure A.12.: Meta-Model of the actionlanguage Package

assignOperator : AssignOperator [0..1] see Section A.12.2 onPage 302

An assignment is used to assign a value to a variable. A simple assignment isone made using the <ASSIGN> Operator ’:=’. Further, we have four more assignoperators which are used as abbreviated syntax form.

incrementDecrementOperator : IncrementDecrementOperator[0..1] see Section A.12.9 on Page 307

Abbreviated form of x := x+1; or x :=x-1.

EReferences of Assignment

lhs_typedNamedElementExpression: TypedNamedElementExpression [0..1] see Section A.12.18 onPage 311

The left-hand-side of an assignment must be a single variable and must not beanother expression.

rhs_assignExpression : Expression [0..1] see Section A.14.1 onPage 318

The right-hand-side expression evaluates to a value which is assigned to the left-hand-side variable.

OCL Constraints of Assignment

ValidLHS

−− a h y b r i d i n p o r t i s not a l l o w e d as a l h s o f an a s s i g n m e n tl e t l h s : TypedNamedElementExpress ion = l h s \

_ typedNamedElementExpress ioni ni f not l h s . o c l I s U n d e f i n e d ( ) and l h s . typedNamedElement . o c l I s K i n d O f

( component : : H y b r i d P o r t ) t h e nl h s . typedNamedElement . oclAsType ( component : : H y b r i d P o r t ) . o u t P o r t

e l s et rue

e n d i f

A.12.4. EClass Block

Overview A block is used to group expressions.

ESuper Types of Block


EReferences of Block



List of expressions may be attached as a body of a loop or represent a path of aconditional statement.

A.12.5. EClass DiscreteInteractionEndpointReference

Overview A DiscreteInteractionEndpointReference is used for defining SelectorExpressionsin a multi-role or multi-port. There, a SelectorExpression may reference asub-role instance or sub-port instance for selecting the synchronization partner.The DiscreteInteractionEndpointReference always specifies a PositionSelector thatdefines the position of the reference sub-role instance or sub-port instance. Itmay, e.g., be the first or last one in a multi-role or multi-port. The referencetypedNamedElementExpressions allows to reference a variable containing a sub-roleinstance or a sub-port instance. In combination, both references enable to select thenext or previous sub-role (or sub-port) instance, e.g., as var1.next. In this case, next isthe PositionSelector while var1 is the typedNamedElementExpression.

ESuper Types of DiscreteInteractionEndpointReference


EReferences of DiscreteInteractionEndpointReference

position : PositionSelector [1..1] see Section A.12.14 onPage 310

Defines the relative position of the sub-role instance or sub-port instance. Inparticular, it enables to select the first or last sub-role instance (sub-port instance)of a multi-role instance (multi-port instance) using keyword first and last, to selectitself in case of a sub-role instance (sub-port instance) using keyword self, orthe next or previous sub-role given a reference either by self or a variable usingkeywords next and prev.

typedNamedElementExpression : TypedNamedElementExpression[0..1] see Section A.12.18 on Page 311

Allows to reference a variable containing a sub-role instance of sub-port instance.This field is optional.

A.12.6. EClass DoWhileLoop

Overview The do while statement first executes the block and afterwards it evaluates theloop test expression. If the expression evaluates to true it executes the block again.

ESuper Types of DoWhileLoop

Loop see Section A.12.11 on Page 308


A.12.7. EClass ForLoop

Overview The for loop statement firstly initialize a loop variable by the initialize expressionand assigning on each loop run afterwards a loop variable by the counting expression tosuccessive values of a sequence.

ESuper Types of ForLoop


EReferences of ForLoop

countingExpression : Assignment [0..1] see Section A.12.3 onPage 302

Assigning on each loop run afterwards a loop variable by the counting expressionto successive values of a sequence.

initializeExpression : Assignment [0..1] see Section A.12.3 onPage 302

Initialize a loop variable by the initialize expression.

A.12.8. EClass IfStatement

Overview An if statement is used if the referenced block should be executed only when thecondition expression evaluates to true. An if statement always have one if-conditionand one corresponding if-block, any number of else-if-conditions and correspondingelse-if-blocks and at most one else-block.

ESuper Types of IfStatement


EReferences of IfStatement

elseBlock : Block [0..1] see Section A.12.4 on Page 304

Block which is executed if no if or elseif condition evaluates to true.

elseIfBlocks : Block [0..∗] see Section A.12.4 on Page 304

Block which is executed if the corresponding elseif condition evaluates to true.

elseIfConditions : Expression [0..∗] see Section A.14.1 onPage 318

ElseIf condition of the if statement.

ifBlock : Block [0..1] see Section A.12.4 on Page 304

Block which is executed if the if condition evaluates to true.


ifCondition : Expression [0..1] see Section A.14.1 on Page 318

If condition of the if statement.

A.12.9. EEnumeration IncrementDecrementOperator

Overview Provides operators used to increment or decrement integer values.

ELiterals of IncrementDecrementOperator

UNSET = 0

INCREMENT = 2

DECREMENT = 1

A.12.10. EClass LocalVariableDeclarationStatement

Overview Enables to declare a local variable inside a Block. Local variables are declaredaccording to the C-rule and have the scope of the block they are defined in. Localvariables may not have the same name as a variable that is declared in the real-timestatechart.

ESuper Types of LocalVariableDeclarationStatement


EReferences of LocalVariableDeclarationStatement

/allSurroundingBlocks : Block [0..∗] see Section A.12.4 onPage 304

This derived feature returns all blocks that surround this local variable declaration.This is a helper feature for ensuring that the names of local variables are unique.

derivation

−− c o l l e c t a l l b l o c k s which s u r r o u n d t h i sL o c a l V a r i a b l e D e c l a r a t i o n S t a t e m e n t

s e l f . e C o n t a i n e r ( )−> c l o s u r e ( c : e c o r e : : EObjec t |i f c . e C o n t a i n e r ( ) . o c l I s K i n d O f ( c o r e : : e x p r e s s i o n s : :

E x p r e s s i o n ) thenc . e C o n t a i n e r ( )

e l s ec

e n d i f)−>un ion (

Set { e C o n t a i n e r ( ) })−> s e l e c t ( o c l I s K i n d O f ( Block ) )−> c o l l e c t (

oclAsType ( Block ))−>a s O r d e r e d S e t ( )


variable : Variable [1..1] see Section A.2.7 on Page 216

The variable that is declared and optionally initialized by this declarationstatement.

OCL Constraints of LocalVariableDeclarationStatement

UniqueName

−− check i f no v a r i a b l e wi th t h e same name was d e f i n e d b e f o r es e l f . a l l S u r r o u n d i n g B l o c k s −> c o l l e c t (

e x p r e s s i o n s)−> s e l e c t (

o c l I s K i n d O f ( L o c a l V a r i a b l e D e c l a r a t i o n S t a t e m e n t ))−> c o l l e c t (

oclAsType ( L o c a l V a r i a b l e D e c l a r a t i o n S t a t e m e n t ))−>one (

v a r i a b l e . name = s e l f . v a r i a b l e . name)

A.12.11. Abstract EClass Loop

Overview A loop statement executed a block until the Boolean value of loop test expressionis false.

ESuper Types of Loop

Block see Section A.12.4 on Page 304

EReferences of Loop

block : Block [0..1] see Section A.12.4 on Page 304

Body block of the loop.

loopTest : Expression [0..1] see Section A.14.1 on Page 318

If the loop test expression evaluates to true the block is executed.

A.12.12. EClass NondeterministicChoiceExpression

Overview The nondeterministic choice expression selects a value from an interval of integersnondeterministically. It may be used to abstract from computations or interactions thatwill modify a value of a variable, but are not yet implementable, e.g., within a real-time coordination protocol. Nondeterministic choice expressions may only be used asright-hand side of an assignment.

ESuper Types of NondeterministicChoiceExpression



EReferences of NondeterministicChoiceExpression

dataType : PrimitiveDataType [1..1] see Section A.10.3 onPage 295

The base type for the interval defined by the range. We only allow for integertypes.

range : Range [1..1] see Section A.11.3 on Page 299

The range defines the lower bound and the upper bound of the interval from whichvalues will be chosen nondeterministically. Every value in this interval will bechosen with the same probability.

A.12.13. EClass OperationCall

Overview Operation calls are used to call an operation with concrete parameter bindings.

ESuper Types of OperationCall


EReferences of OperationCall

operation : Operation [1..1] see Section A.2.3 on Page 215

Operation which belongs to an operation call.

parameterBinding : ParameterBinding [0..∗] see Section A.2.5on Page 216

Parameter bindings which belongs to an operation call.

OCL Constraints of OperationCall

AllParametersMustBeBound

−− An O p e r a t i o n C a l l must b ind a v a l u e t o e v e r y p a r a m e t e rnot o p e r a t i o n . o c l I s U n d e f i n e d ( ) i m p l i e so p e r a t i o n . p a r a m e t e r s −>a s S e t ( ) = p a r a m e t e r B i n d i n g . p a r a m e t e r−>a s S e t

( )−− a u t h o r : b ingo

UniqueParameterBindings

−− An O p e r a t i o n C a l l must not b ind m u l t i p l e v a l u e s t o anyp a r a m e t e r

p a r a m e t e r B i n d i n g−>i s U n i q u e ( p a r a m e t e r )−− a u t h o r : b ingo


A.12.14. EClass PositionSelector

Overview Defines a relative position of a sub-role instance or sub-port instance. The kinddefines the particular reference using an enum literal where self refers to a sub-roleinstance (sub-port instance) itself, first or last refer to the first or last sub-role instance(sub-port instance) or a multi-role instance (multi-port instance), and next or prev referto the next or previous sub-role instance (sub-port instance). PositionSelectors can beconcatenated using the successor reference. That enables to specify, e.g., self.next,first.next, or self.prev.prev.

ESuper Types of PositionSelector


EAttributes of PositionSelector

kind : PositionSelectorKind [0..1] see Section A.12.15 onPage 310

The enum literal defining the position.

EReferences of PositionSelector

successor : PositionSelector [0..1] see Section A.12.14 onPage 310

Successors of a PositionSelector enable to concatenate PositionSelectors forspecifying more complex expression like self.next or self.prev.prev.

A.12.15. EEnumeration PositionSelectorKind

Overview Defines keywords for referring to sub-role instance (sub-port instances) of a multi-role instance (multi-port instance). Self may be used by a sub-role instance (sub-portinstance) and refers to the corresponding sub-role instance (sub-port instance) itself.First and last may be used by the adaptation behavior and refer to the first or lastsub-role instance (sub-port instance) of the multi-role instance (multi-port instance).Given a reference sub-role instance (sub-port instance), next and prev refer to the nextor previous sub-role instance (sub-port instance). If the reference sub-role instance (sub-port instance) is the last one (first one), then next (first) refers to null.

ELiterals of PositionSelectorKind

SELF = 0

FIRST = 1

LAST = 2

PREV = 3

NEXT = 4


A.12.16. EClass ReturnStatement

Overview The return statement specifies the return expression of an operation call.

ESuper Types of ReturnStatement


EReferences of ReturnStatement

expression : Expression [0..1] see Section A.14.1 on Page 318

Return expression which blongs to a return statement.

A.12.17. EClass TriggerMessageExpression

Overview Represents a parameter of a transition’s trigger message.

ESuper Types of TriggerMessageExpression


EReferences of TriggerMessageExpression

messageType : MessageType [1..1] see Section A.7.1 on Page 259

The message type specified for the trigger message.

parameter : Parameter [1..1] see Section A.2.4 on Page 215

The concrete parameter of the specified message type to be accessed.

A.12.18. EClass TypedNamedElementExpression

Overview To perform an action on a value of a variable of a Real-Time Statechart we usethe typed named element expression, which has a reference to a typed named elementand optional indicies if a concrete array element should be referenced.

ESuper Types of TypedNamedElementExpression


EReferences of TypedNamedElementExpression

indices : Expression [0..∗] see Section A.14.1 on Page 318

Indices which refer to a concrete index of an array.

typedNamedElement : TypedNamedElement [1..1] seeSection A.2.6 on Page 216

The typed named element referenced by this expression.


A.12.19. EClass WhileLoop

Overview The while statement first evaluates the loop test expression and afterwards if theexpression evaluates to true it executes the block.

ESuper Types of WhileLoop


A.13. EPACKAGE CORE 313

A.13. EPackage core

Overview The core package is the root package for the storydriven core meta-model. Itdefines several abstract super classes which implement an extension mechanism as wellas recurring structural features like, e.g., names of elements. The classes in this packageare intended to be sub-classed by any meta-model element.

A.13.1. Abstract EClass CommentableElement

Overview Abstract super class for all meta-model elements that may carry a comment inform of a string.

ESuper Types of CommentableElement


EAttributes of CommentableElement

comment : EString [0..1]

The comment string that can be used to attach arbitrary information toCommentableElements.

A.13.2. Abstract EClass ExtendableElement

Overview Abstract base class for the whole story diagram model. The ExtendableElementspecifies the extension mechanism that can be used to extend an object by an Extensioncontaining additional attributes and references.

ESuper Types of ExtendableElement

EObject

EReferences of ExtendableElement

annotation : EAnnotation [0..∗]

extension : Extension [0..∗] see Section A.13.3 on Page 316

EOperations of ExtendableElement

getAnnotation : EAnnotation [1..1]

EParameters


0..1

extendableBase

*

extension

HasExtension

0..1

annotatedElement

*

annotation

HasAnnotation

1

/eRawType

1

0..1

eClassifier 1

0..1

typedElement

0..1

genericType

HasGenericType

*

typedElement

0..1

/type

HasType

*

extension

0..1

/owningAnnotation

*

extension

1

/base

HasExtendedObject

0..1

/modelBase

*

/extension

HasModelExtension

*

eAnnotations

0..1

eModelElement

*

contents

1

*

references

1

ExtendableElement

getExtension(type:EClass) : Extension

provideExtension(type:EClass) : Extension

getAnnotation(source:String) : EAnnotation

provideAnnotation

(source:String) : EAnnotation

«Metaclass»

EGenericType

«Metaclass»

EClassifier

NamedElement

name:String

TypedElement

Extension

CommentableElement

comment:String="no comment provided"

[0..1]

«Metaclass»

EAnnotation

source:EString[0..1]

details:EStringToStringMapEntry

[0..*]«...»

«Metaclass»

EModelElement

getEAnnotation(source:EString) : EAnnotation

«Metaclass»

EObject

Figure A.13.: Meta-Model of the core Package


source : EString [1..1]

body (in Java)

re turn E x t e n d a b l e E l e m e n t O p e r a t i o n s . g e t A n n o t a t i o n ( t h i s , s o u r c e) ;

getExtension : Extension [1..1] see Section A.13.3 on Page 316

EParameters

type : EClass [1..1]

body (in Java)

re turn E x t e n d a b l e E l e m e n t O p e r a t i o n s . g e t E x t e n s i o n ( t h i s , t y p e ) ;

provideAnnotation : EAnnotation [1..1]

EParameters

source : EString [1..1]

body (in Java)

re turn E x t e n d a b l e E l e m e n t O p e r a t i o n s . p r o v i d e A n n o t a t i o n ( t h i s ,s o u r c e ) ;

provideExtension : Extension [1..1] see Section A.13.3 onPage 316

EParameters

type : EClass [1..1]

body (in Java)

re turn E x t e n d a b l e E l e m e n t O p e r a t i o n s . p r o v i d e E x t e n s i o n ( t h i s ,t y p e ) ;


A.13.3. Abstract EClass Extension

Overview Abstract super class for an Extension that can be defined for an object.

ESuper Types of Extension


EReferences of Extension

/base : EObject [1..1]

extendableBase : ExtendableElement [0..1] see Section A.13.2on Page 313

/modelBase : EModelElement [0..1]

/owningAnnotation : EAnnotation [0..1]

A.13.4. Abstract EClass NamedElement

Overview Abstract super class for all meta-model elements that carry a name.

ESuper Types of NamedElement


EAttributes of NamedElement


The name attribute of a meta-model element.

A.13.5. Abstract EClass TypedElement

Overview Abstract super class for all meta-model elements that are typed by means of anEClassifier or an EGenericType.

ESuper Types of TypedElement


EReferences of TypedElement


genericType : EGenericType [0..1]

/type : EClassifier [0..1]


A.14. EPackage core::expressions

Overview The base package for all expressions which can be used for modeling activitiesand patterns.

CommentableElement

comment : String = "no comment provided" [0..1]

TextualExpression

expressionText : String

language : String

languageVersion : String [0..1]

Expression

Figure A.14.: Meta-Model of the expressions Package

A.14.1. Abstract EClass Expression

Overview Represents any expression in an embedded textual language, e.g. OCL orJava. An expression’s type is dynamically derived by an external mechanism (seeTypedElement).

ESuper Types of Expression


A.14.2. EClass TextualExpression

Overview Represents any expression in a textual language embedded into Story Diagrams,e.g. OCL or Java .

ESuper Types of TextualExpression


EAttributes of TextualExpression

A.14. EPACKAGE CORE::EXPRESSIONS 319

expressionText : EString [1..1]

Holds the expression, e.g. in OCL or Java.

language : EString [1..1]

String representation of the used language which has to be unique. Examples areOCL and Java.

languageVersion : EString [0..1]

String representation of the used language’sversion. The format is <Major>.<Minor>[.<Revision>[.<Build>]] Examples: 1.4or 3.0.1 or 1.0.2.20101208.


A.15. EPackage core::expressions::common

Overview

0..1

revEnclosedExpression

1

enclosedExpression

HasEnclosedExpression

0..1

revLeftExpression

1

leftExpression

HasLeftExpression

0..1

revRightExpression

1

rightExpressionHasRightExpression

Expression

LogicalExpression

operator : LogicOperator

ComparisonExpression

operator : ComparingOperator

ArithmeticExpression

operator : ArithmeticOperator

BinaryExpression

«enumeration»

LogicOperator

AND

OR

XOR

IMPLY

EQUIVALENT

«enumeration»

ComparingOperator

LESS

LESS_OR_EQUAL

EQUAL

GREATER_OR_EQUAL

GREATER

UNEQUAL

REGULAR_EXPRESSION

«enumeration»

ArithmeticOperator

PLUS

MINUS

TIMES

DIVIDE

MODULO

«enumeration»

UnaryOperator

NOT

PLUS

MINUS

LiteralExpression

value : String [0..1]

UnaryExpression

operator : UnaryOperator

TextualExpression

expressionText : String

language : String

languageVersion : String [0..1]

Figure A.15.: Metamodel of the common Package

A.15.1. EClass ArithmeticExpression

Overview Represents arithmetic expressions like a + 5 or a * 7.

ESuper Types of ArithmeticExpression

BinaryExpression see Section A.15.3 on Page 321

EAttributes of ArithmeticExpression

A.15. EPACKAGE CORE::EXPRESSIONS::COMMON 321

operator : ArithmeticOperator [1..1] see Section A.15.2 onPage 321

Specifies the expression’s arithmetic operator, e.g. +, -, *, /, or MODULO.

A.15.2. EEnumeration ArithmeticOperator

Overview Defines the operators for arithmetic expressions.

ELiterals of ArithmeticOperator

PLUS = 0

MINUS = 1

TIMES = 2

DIVIDE = 3

MODULO = 4

A.15.3. Abstract EClass BinaryExpression

Overview Represents any binary expression like v < 5 or x + 7.

ESuper Types of BinaryExpression


EReferences of BinaryExpression

leftExpression : Expression [1..1] see Section A.14.1 on Page 318

Represents the first operand of a binary expression, e.g. x in the expression x < 5.

rightExpression : Expression [1..1] see Section A.14.1 onPage 318

Represents the second operand of a binary expression, e.g. 5 in the expression x <5.

A.15.4. EEnumeration ComparingOperator

Overview Defines the operators for comparing expressions. The operators LESS,LESS_OR_EQUAL, EQUAL, GREATER_OR_EQUAL, GREATER, and UNEQUALhave their usual semantics. The operator REGULAR_EXPRESSION enables tocompare a String contained in the left hand side of a ComparisonExpression with aregular expression contained in the right hand side of the ComparisonExpression.

ELiterals of ComparingOperator

LESS = 0

LESS_OR_EQUAL = 1

EQUAL = 2

GREATER_OR_EQUAL = 3

GREATER = 4

UNEQUAL = 5

REGULAR_EXPRESSION = 6

For comparison of a String with a regular expression.

A.15.5. EClass ComparisonExpression

Overview Represents comparing expressions like a < 5 or a >= 7.

ESuper Types of ComparisonExpression


EAttributes of ComparisonExpression

operator : ComparingOperator [1..1] see Section A.15.4 onPage 321

Specifies the expression’s comparing operator, e.g. <, >=, !=.

A.15.6. EClass LiteralExpression

Overview Represents any literal, i.e. a value whose type is an EDataType. Literals are, forexample, 5, 3.14, ’c’, "text", true.

ESuper Types of LiteralExpression


EAttributes of LiteralExpression

value : EString [1..1]

String representation of the value, e.g. "5", "3.14", "c", "text", or "true".

A.15.7. EEnumeration LogicOperator

Overview Defines the operators for binary logic expressions. The unary logic expressionrepresenting negated expressions is reflected by the NotExpression.

ELiterals of LogicOperator

A.15. EPACKAGE CORE::EXPRESSIONS::COMMON 323

AND = 0

OR = 1

XOR = 2

IMPLY = 3

EQUIVALENT = 4

A.15.8. EClass LogicalExpression

Overview Represents binary, logic expressions like a AND b and a OR b.

ESuper Types of LogicalExpression


EAttributes of LogicalExpression

operator : LogicOperator [1..1] see Section A.15.7 on Page 322

Specifies the expression’s logic operator, e.g. AND, OR, or XOR.

A.15.9. EClass UnaryExpression

Overview Represents an unary expression.

ESuper Types of UnaryExpression


EAttributes of UnaryExpression

operator : UnaryOperator [1..1] see Section A.15.10 on Page 323

Represents the operator of the expression.

EReferences of UnaryExpression

enclosedExpression : Expression [1..1] see Section A.14.1 onPage 318

Represents the operand of a NotExpression, e.g. a < 5 in NOT (a < 5).

A.15.10. EEnumeration UnaryOperator

Overview

ELiterals of UnaryOperator

NOT = 0


MINUS = 2

INCREMENT = 3

DECREMENT = 4

A.16. EPACKAGE STORYDIAGRAMS 325

A.16. EPackage storydiagrams

Overview The storydiagram package is the root package for the story diagram meta-model.It defines the type Variable and otherwise is only used to contain more specific sub-packages.

*

typedElement

0..1

/ type

HasType

Variable

/ variableName : String [0..1] «... »

TypedElement

genericType : EGenericType [0..1] «... »

«Metaclass »

EClassifier

Figure A.16.: Metamodel of the storydiagrams Package

A.16.1. Abstract EClass Variable

Overview Represents a variable which can be, for example, an object variable, an attribute,or any other kind of variable.

ESuper Types of Variable

TypedElement see Section A.13.5 on Page 316

EAttributes of Variable

/variableName : EString [0..1]


A.17. EPackage storydiagrams::activities

Overview

A.17.1. EClass Activity

Overview The diagram that describes the control flow of an operation. It is used to structurea number story patterns into a stroy diagram. Story patterns are contained in activitynodes which are connected by activity edges. In addition, there are special nodes likestart, stop, and juction nodes.

ESuper Types of Activity

Callable see Section A.19.1 on Page 336


EReferences of Activity

ownedActivityEdge : ActivityEdge [0..∗] see Section A.17.3 onPage 328

All ActivityEdges that are contained in this activity.

ownedActivityNode : ActivityNode [0..∗] see Section A.17.5 onPage 329

The activity contains all activity nodes via this reference.

owningOperation : OperationExtension [0..1] seeSection A.17.13 on Page 333

precondition : MatchingStoryNode [0..1] see Section A.17.11 onPage 332

References a story node which represents the precondition for the execution of theactivity. I.e., the activity is executed, iff the object structure in the story node canbe matched. Obviously the referenced story node may only contain black (i.e.,non-create and non-destroy) objects and links.

A.17.2. EClass ActivityCallNode

Overview The ActivityCallNode is a special ActivityNode which represents the calling ofanother story diagram within an activity. To support polymorphic dispatching, multipleactivities can be assigned to it (all of which must have the same call signature, i.e.matching in and out parameters). All assigned activities are then called in the given orderand the first one whose precondition is fulfilled is executed (Chain of Responsibilty).

A.17. EPACKAGE STORYDIAGRAMS::ACTIVITIES 327

0..1

owningActivityN

ode

*

ownedActivityN

ode

ContainsC

hild

Node

*

activity

0..1

preco

ndition

HasP

reco

ndition

1

source

*

outg

oing

HasO

utg

oingEdge

*

ownedActivityN

ode

0..1

owningActivity

ContainsA

ctivityN

ode

*

inco

ming

1

targ

et

HasInco

mingEdge

1

activityE

dge

*

guard

Exc

eption

ContainsG

uard

Exc

eption

1

owningActivity

*

ownedActivityE

dge

ContainsA

ctivityE

dge

*

exc

eptionVariableExp

ression

1

exc

eptionVariable

0..1

owningOperation

0..1

ownedActivity

HasA

ctivity

*

operationExtension

0..1

/operation

0..1

operationExtension

0..1

returnValue

outParameter

*

eParameters

0..1

eOperation

*

activityC

allN

ode

1..*

calle

dActivity H

asC

alle

dActivity

StoryNode

forEach

:Boolean

/storyPattern

:Sto

ryPattern

«...»

StructuredNode

ModifyingStoryNode

ownedRule

:Sto

ryPattern

MatchingStoryNode

ownedPattern

:MatchingPattern

ActivityNode

ActivityEdge

guard

:EdgeGuard

=NONE

guard

Exp

ression

:Exp

ression

[0..1

]

ExceptionVariable

name:S

tring

exc

eptionTyp

e:E

Classifier[0..*]«...»

genericE

xceptionTyp

e:E

GenericT

ype

[0..*]

ExceptionVariableExpression

OperationExtension

«Metaclass

»

EOperation

«Metaclass

»

EParameter

Activity

ActivityCallNode

JunctionNode

ActivityFinalN

ode

/returnValue

:Exp

ression

[0..1

]«...»

returnValues:E

xpression

[0..*]

succ

ess

:Boolean

=true

InitialN

ode

StatementN

ode

statementExp

ression

:Exp

ression

«enumeration»

EdgeGuard

NONE

SUCCESS

FAILURE

EACH_T

IME

END

ELS

E

BOOL

EXCEPTIO

N

FINALL

Y

FlowFinalN

ode

Figure A.17.: Metamodel of the activities Package


ESuper Types of ActivityCallNode

ActivityNode see Section A.17.5 on Page 329

Invocation see Section A.19.2 on Page 336

EReferences of ActivityCallNode

calledActivity : Activity [1..∗] see Section A.17.1 on Page 326

References all activities that are to be considered for the polymorphic dispatchingof the call. All activities must have the same call signature.

A.17.3. EClass ActivityEdge

Overview The ActivityEdge represents the control flow in an activity. It is a derictedconnection from one activity to another one. There exist different kinds of activityedges which are differentiated by the guard attribute.

ESuper Types of ActivityEdge


EAttributes of ActivityEdge

guard : EdgeGuard [1..1] see Section A.17.6 on Page 330

The guard defines the kind of the activity edge. The possible kinds of guards arespecified by the EdgeGuard enum.

EReferences of ActivityEdge

guardException : ExceptionVariable [0..∗] see Section A.17.7on Page 331

Declares variables representing the Exceptions that lead to firing this transition.

guardExpression : Expression [0..1] see Section A.14.1 onPage 318

Points to an expression in case the transition guard is BOOL. The expression hasto evaulate to a boolean value.

owningActivity : Activity [1..1] see Section A.17.1 on Page 326

Points to the activity this ActivityEdge is contained in.

source : ActivityNode [1..1] see Section A.17.5 on Page 329

The source node of this ActivityEdge.

target : ActivityNode [1..1] see Section A.17.5 on Page 329

The target node of this ActivityEdge.


A.17.4. EClass ActivityFinalNode

Overview At a StopNode, the execution of an activity terminates. If the activity specifiesany out-parameters, they have to be bound to a return expression.

ESuper Types of ActivityFinalNode


EAttributes of ActivityFinalNode

success : EBoolean [1..1]

EReferences of ActivityFinalNode

/returnValue : Expression [0..1] see Section A.14.1 on Page 318

Convenience method when dealing with activities that implement an EOperation.In this case, only one out parameter is supported. This attributes then returns thefirst out parameter.

returnValues : Expression [0..∗] see Section A.14.1 on Page 318

Defines the return values of the activity. These return values will be assigned tothe out-parameters.

A.17.5. Abstract EClass ActivityNode

Overview Abstract super class for all kinds of nodes that may be added to an activity. Thisclass provides the basic functionality of connecting the activity nodes in the activity byActivityEdges.

ESuper Types of ActivityNode



EReferences of ActivityNode

incoming : ActivityEdge [0..∗] see Section A.17.3 on Page 328

All ActivityEdges entering this activity node.

outgoing : ActivityEdge [0..∗] see Section A.17.3 on Page 328

All ActivityEdges that leave this activity node. The guards of the outgoing activityedges must be exclusive in order to obtain a well-defined activity.

owningActivity : Activity [0..1] see Section A.17.1 on Page 326

Points to the activity this ActivityNode is contained in.


owningActivityNode : StructuredNode [0..1] seeSection A.17.16 on Page 334

The parent node if this node is contained in a StructuredNode.

A.17.6. EEnumeration EdgeGuard

Overview This enum is used to model different kinds of activity edges.

ELiterals of EdgeGuard

NONE = 0

No guard, only one outgoing activity edge of this kind is supported per activitynode. If an edge with EdgeGuard NONE is used, it must be the only edge leavinga state.

SUCCESS = 1

Edge will be taken if execution of the souce activity node was successful, e.g., astory pattern was matched successfully. There must be another edge leaving thesame node which is of kind FAILURE.

FAILURE = 2

Edge will be taken if execution of the source activity node was not successful, e.g.,a story pattern could not be matched. There must be another edge leaving the samenode which is of kind SUCCESS

EACH_TIME = 3

Edge may only leave a StoryNode whose forEach attribute is true. It will be takenfor each match that can be identified for the story pattern in the foreach StoryNode.There must be another edge leaving the same node which is of kind END

END = 4

Edge may only leave a StoryNode whose forEach attribute is true. It will be takenif no more fresh matches for the story pattern in the foreach node can be found.

ELSE = 5

Complement to the BOOL guard, ELSE may only be used if at least one BOOLactivity edge leaves the same state. The edge will be taken if none of the BOOLguards can be evaluated to true

BOOL = 6

An activity edge specifying a boolean guard using variables that have beenpreviously used in the activity. Edge will be taken if the guardExpression of theactivity edge evaluates to true. More than one BOOL edge is allowed to leave anactivity node.


EXCEPTION = 7

An EXCEPTION edge will be taken if an exception of the type defined by theExceptionVariable connected to the activity edge occured while executing thesource activity node of the edge. More than one edge of kind EXCEPTION isallowed to leave a node.

FINALLY = 8

An activity edge of kind FINALLY may only leave an activity node that has atleast one other outgoing edge of kind EXCEPTION. The finally edge will be takenafter the source node has been executed and after, possibly, the EXCEPTION edgehas been taken.

A.17.7. EClass ExceptionVariable

Overview Declares a variable representing an Exception that leads to firing a transition(ActivityEdge). Can only be applied to ActivityEdge whose guard is set toEXCEPTION.

ESuper Types of ExceptionVariable

Variable see Section A.16.1 on Page 325

EAttributes of ExceptionVariable


Specifies the name of the declared exception variable.

EReferences of ExceptionVariable

activityEdge : ActivityEdge [1..1] see Section A.17.3 on Page 328

Specifies the transition (activity edge) where the exception variable is declared.

exceptionType : EClassifier [0..∗]Specifies the type of the declared exception variable.

genericExceptionType : EGenericType [0..∗]

A.17.8. EClass FlowFinalNode

Overview

ESuper Types of FlowFinalNode

ActivityFinalNode see Section A.17.4 on Page 329


A.17.9. EClass InitialNode

Overview The start node of an activity defines the starting point for the execution of theactivity.

ESuper Types of InitialNode


A.17.10. EClass JunctionNode

Overview A JunctionNode represents a pseudo-activity which is used for branching andmerging the control flow in an activity. It is visualized by a diamond shaped figure.

ESuper Types of JunctionNode


A.17.11. EClass MatchingStoryNode

Overview A MatchingStoryNode may only contain a MatchingPattern which does notchange the graph. I.e., no element contained in this activity carries a create or destroyannotation. Thus, after executing a MatchingStoryNode, the underlying graph isguaranteed to be unchanged.

ESuper Types of MatchingStoryNode

StoryNode see Section A.17.15 on Page 334

EReferences of MatchingStoryNode

ownedPattern : MatchingPattern [1..1] see Section A.21.13 onPage 351

This MatchingPattern contained in this activity.

A.17.12. EClass ModifyingStoryNode

Overview A ModifyingStoryNode contains a story pattern which may change the underlyinggraph upon execution.

ESuper Types of ModifyingStoryNode

StoryNode see Section A.17.15 on Page 334

EReferences of ModifyingStoryNode

ownedRule : StoryPattern [1..1] see Section A.21.18 on Page 353

The story pattern contained in this ModifyingStoryNode.


A.17.13. EClass OperationExtension

Overview An OperationExtension is a stand-in for an EOperation in our model. It isnecessary because we cannot change the type EOperation. Thus, OperationExtensionpoints to an EOperation but adds the reference to an Activity that describes theoperations behavior.

ESuper Types of OperationExtension

Extension see Section A.13.3 on Page 316


EReferences of OperationExtension

/operation : EOperation [0..1]

The EOperation whose behavior is defined by the Activity. The propertyis derived because the actual value is determined by the utility classOperationsExtensionOperation.

ownedActivity : Activity [0..1] see Section A.17.1 on Page 326

returnValue : EParameter [0..1]

The return value of the referenced operation.

EOperations of OperationExtension

NumberOfOutParams : EBoolean [0..1]

EParameters

diagnostics : EDiagnosticChain [0..1]

The chain of diagnostics to which problems are to be appended.

context : EMap [0..1]

The cache of context-specific information.

A.17.14. EClass StatementNode

Overview A statement node is a node that just contains an expression defining its behavior.In combination with a textual expression, arbitrary souce code might be added by usingStatementNodes.

ESuper Types of StatementNode



EReferences of StatementNode

statementExpression : Expression [1..1] see Section A.14.1 onPage 318

The expression which defines the behavior of this StatementNode.

A.17.15. Abstract EClass StoryNode

Overview An activity node containing a story pattern.

ESuper Types of StoryNode


EAttributes of StoryNode

forEach : EBoolean [1..1]

Specifies whether just one match should be found for the contained pattern(forEach = false) or whether all matches should be found (forEach = true).

EReferences of StoryNode

/storyPattern : StoryPattern [1..1] see Section A.21.18 onPage 353

A.17.16. EClass StructuredNode

Overview A structured node is a node that contains several other activities.

ESuper Types of StructuredNode


EReferences of StructuredNode

ownedActivityNode : ActivityNode [0..∗] see Section A.17.5 onPage 329

All subnodes which are contained in this structured node.

A.18. EPACKAGE STORYDIAGRAMS::ACTIVITIES::EXPRESSIONS 335

A.18. EPackagestorydiagrams::activities::expressions

Overview

*

exceptionVariableExpression

1

exceptionVariable

*

exceptionVariable

*

exceptionType

1

activityEdge

*

guardException

ContainsGuardException

ActivityEdge

target : ActivityNode

source : ActivityNode

guard : EdgeGuard = NONE

guardExpression : Expression [0..1]

owningActivity : Activity

ExceptionVariable

name : String

genericExceptionType : EGenericType [0..*]

ExceptionVariableExpression

« Metaclass »

EClassifier

Figure A.18.: Metamodel of the activities::expressions Package

A.18.1. EClass ExceptionVariableExpression

Overview Represents the value of an exception variable declared as a transition guard (theguard of an activity edge).

ESuper Types of ExceptionVariableExpression


EReferences of ExceptionVariableExpression

exceptionVariable : ExceptionVariable [1..1] seeSection A.17.7 on Page 331

Specifies the exception variable that this expression refers to. If you have anactivity edge that catches an exception e, then this expression can represent thereference e.


A.19. EPackage storydiagrams::calls

Overview This package contains all classes for modeling calls to activities and EOperationsfrom within an activity.

A.19.1. Abstract EClass Callable

Overview An entity which can be called by an Invocation. A Callable can have a number of(ordered) parameters which are either in or out parameters. In the case of activities,the number of in and out parameters is unbounded, whereas OperationExtensionsand OpaqueCallables can only have one out parameter (This is enforced by an OCLconstraint).

ESuper Types of Callable


EReferences of Callable

containedParameters : EParameter [0..∗]This reference is used to contain the parameters of a Callable if they are not alreadycontained in another container. If the parameter is contained in another containeras it is the case for parameters of a EOperation, they must not be added to thiscontainer!

inParameter : EParameter [0..∗]The ordered set of in parameters of this Callable. The parameters will not becontained in this reference, if parameters have to be contained in the callable, theyalso have to be added to the containedParameters reference.

outParameter : EParameter [0..∗]The ordered set of out parameters of this Callable. The parameters will not becontained in this reference, if parameters have to be contained in the callable, theyalso have to be added to the containedParameters reference.

A.19.2. Abstract EClass Invocation

Overview Superclass for invocations of behavior which is specified elsewhere, e.g. inmethods (MethodCallExpression) or activities (ActivityCallNode). An invocation hasone parameter binding for each parameter (in or out) of the called method/activity. ForCallables which are contained in the model (i.e. Activities and OperationExtensions)the Invocation directly points to the callee. OpaqueCallables are directly referenced by(and contained in) the MethodCallExpressions.

A.19. EPACKAGE STORYDIAGRAMS::CALLS 337

*

invocation

0..1

callee

HasCallee

1

invocation

*

ownedParameterBindings

ContainsParameterBindings

0..1

parameterBinding

1

valueExpression

ContainsValueExpression

0..1

methodCallExpression

0..1

target

ContainsTarget

*

activityCallNode

1..*

calledActivity

HasCalledActivity

*

revInParameter

*

inParameter

HasInParameter

*

revOutParameter

*

outParameter

HasOutParameter

*

containedParameters

*

revContainedParameters

ContainsParameter

0..1

owningOperation

0..1

ownedActivity

HasActivity

*

parameterBinding

0..1

parameter

HasParameter

*

revInParameter

*

inParameter

OpaqueCallableContainsIn

*

revOutParameter

*

outParameter

OpaqueCallableContainsOut

1

callExpression

0..1

opaqueCallable

ContainsOpaqueCallable

Callable

Activity

Invocation

Expression

ParameterBinding

«Metaclass»

EParameter

OpaqueCallable

OperationExtension

ActivityCallNode

MethodCallExpression

Figure A.19.: Metamodel of the calls Package


ESuper Types of Invocation


EReferences of Invocation

callee : Callable [0..1] see Section A.19.1 on Page 336

ownedParameterBindings : ParameterBinding [0..∗] seeSection A.19.4 on Page 339

A.19.3. EClass OpaqueCallable

Overview An OpaqueCallable represents an external method which is not explicitly modeled(e.g. a method in an external library). Because it is not contained anywhere in the modelit is directly referenced by and contained in the MethodCallExpression.

ESuper Types of OpaqueCallable


EAttributes of OpaqueCallable


EReferences of OpaqueCallable

callExpression : MethodCallExpression [1..1] seeSection A.20.1 on Page 340

EOperations of OpaqueCallable

NumberOfOutParams : EBoolean [0..1]

EParameters





A.19. EPACKAGE STORYDIAGRAMS::CALLS 339

A.19.4. EClass ParameterBinding

Overview Binds a parameter to a certain value for a given invocation. The value of theparameter is represented by an expression.

ESuper Types of ParameterBinding


EReferences of ParameterBinding

invocation : Invocation [1..1] see Section A.19.2 on Page 336

parameter : EParameter [0..1]

valueExpression : Expression [1..1] see Section A.14.1 onPage 318

A.19.5. EClass ParameterExtension

Overview Represents an EParameter and adds functionality to it, especially beiing subtypeof Variable.

ESuper Types of ParameterExtension


Extension see Section A.13.3 on Page 316

EReferences of ParameterExtension

/parameter : EParameter [0..1]


A.20. EPackagestorydiagrams::calls::expressions

Overview

A.20.1. EClass MethodCallExpression

Overview A MethodCallEpression represents the direct invocation of a method. This caneither be a method which is explicitly modeled as an EOperation in a class diagram(referenced by the OperationExtension) or an unmodeled method in an external library(referenced by an OpaqueCallable). Therefore, a MethodCallExpression referenceseither an OperationExtension (indirectly via the callee role between Invocation andCallable) or an OpaqueCallable.

ESuper Types of MethodCallExpression


Invocation see Section A.19.2 on Page 336

EReferences of MethodCallExpression

opaqueCallable : OpaqueCallable [0..1] see Section A.19.3 onPage 338

This containment reference is a helper construct because the OpaqueCallable hasto be contained somewhere. A MethodCallExpression (being an Invocation) couldalso reference an OpaqueCallable (being a Callable) via the callee reference butthen the OpaqueCallable would not be contained anywhere in the model.

target : Expression [0..1] see Section A.14.1 on Page 318

A MethodCallExpression references an expression instead of a target object toallow the determination of the call target by an expression. This can be handy whena method should be called e.g. on the return value of another method (as in a.b().c()). Then the method call of c() would be modeled by a MethodCallExpression withthe callExpression a.b(), which again is a MethodCallExpression itself.

A.20.2. EClass ParameterExpression

Overview An Expressions that represents a parameter value, e.g. the value of an Activity’sparameter.

ESuper Types of ParameterExpression


A.20. EPACKAGE STORYDIAGRAMS::CALLS::EXPRESSIONS 341

*

invocation

0..1

callee

HasC

allee

*

revInParameter

*

inParameter

HasInParameter

*

revOutParameter

*

outParameter

HasO

utParameter

*

containedParameters

*

revContainedParameters

ContainsParameter

*

revInParameter

*

inParameter

OpaqueCallableContainsIn

*

revOutParameter

*

outParameter

OpaqueCallableContainsO

ut

*

parameterExtension

0..1

/parameter

HasParameter

1

callExp

ression

0..1

opaqueCallable

ContainsO

paqueCallable

0..1

methodCallExp

ression

0..1

target

ContainsTarget

*

parameterExp

ression

0..1

parameter

parameter

1

invocation

*

ownedParameterBindings

ContainsParameterBindings

0..1

parameterBinding

1

valueExp

ression

ContainsV

alueExp

ression

*

eParameters

0..1

eOperation

0..1

operationExtension

0..1

returnValue

outParameter

*

parameterBinding

0..1

parameter

HasParameter

*

operationExtension

0..1

/operation

MethodCallExpression

Invocation

Callable

OpaqueCallable

OperationExtension

ownedActivity:A

ctivity[0..1]

Expression

ParameterBinding

«Metaclass»

EParameter

«Metaclass»

EOperation

ParameterExpression

ParameterExtension

Figure A.20.: Metamodel of the calls::expressions Package


EReferences of ParameterExpression

parameter : ParameterExtension [0..1] see Section A.19.5 onPage 339

A.21. EPACKAGE STORYDIAGRAMS::PATTERNS 343

A.21. EPackage storydiagrams::patterns

Overview This package contains all classes for modeling story patterns that may beembedded into StoryActivityNodes of an Activity.

A.21.1. Abstract EClass AbstractLinkVariable

Overview Abstract super class for all kinds of link variables that represent links betweentwo objects in a story pattern.

ESuper Types of AbstractLinkVariable


EAttributes of AbstractLinkVariable

bindingOperator : BindingOperator [1..1] see Section A.21.4 onPage 346

The binding operator defines whether this link will be matched, created ordestroyed by the story pattern. The default value ist "check_only", i.e., the linkwill be matched.

bindingSemantics : BindingSemantics [1..1] see Section A.21.5on Page 346

The binding semantics defines whether the link must be matched for a successfulapplication of the containing story pattern, whether it must not be matched orwhether it is optional, i.e., it will be bound if it can be bound but that does notaffect the success of matching the story pattern. The default value is "mandatory"(i.e., it must be matched).

EReferences of AbstractLinkVariable

firstLinkConstraint : LinkConstraint [0..∗] seeSection A.21.10 on Page 349

pattern : StoryPattern [1..1] see Section A.21.18 on Page 353

secondLinkConstraint : LinkConstraint [0..∗] seeSection A.21.10 on Page 349

source : ObjectVariable [1..1] see Section A.21.15 on Page 351


1

pattern

*

variable

ContainsV

ariables

0..1

parentPattern

*

contained

Pattern

ContainsC

hild

Pattern

1

pattern

*

linkV

ariab

leContainsLinkV

ariab

les

0..1

pattern

*

constraint

ContainsConstraints

*

outgoingLink

1

source

HasSourceO

bject

*

incomingLink

1

target

HasTargetObject

*

firstLinkC

onstraint

1

firstLink

HasFirstLink

*

seco

ndLinkConstraint

0..1

secondLink

HasSecondLink

*

primitiveV

ariab

leExpression

1

primitiveV

ariable

*

objectVariab

leExpression

1

object

ExpressionHasObject

*

attributeValueExp

ression

1

object

HasO

bject

0..1

objectVariable

*

constraint

ContainsConstraints

*

objectSetSizeExpression

1 set

HasSet

1

objectVariable

*

attributeAssignment

ContainsA

ttributeExpression

*

linkO

rderConstraint

1

referencingObject

LinkC

onstraintH

asObjectVariable

StoryPattern

bindingSem

antics

:BindingSem

antics

=MANDATO

RY

templateSignature:TemplateSignature

[0..1]

MatchingPattern

«enumeration»

BindingOperator

CHEC

K_O

NLY

CREA

TE

DESTROY

«enumeration»

BindingState

UNBOUND

BOUND

MAYBE_BOUND

«enumeration»

BindingSemantics

MANDATO

RY

NEG

ATIVE

OPTIONAL

AbstractLinkVariable

bindingSemantics

:BindingSemantics

=MANDATO

RY

bindingOperator:BindingOperator=CHEC

K_O

NLY

bindingState:BindingState=UNBOUND

LinkVariable

/so

urceEnd:EReference

[0..1]«...»

targetEnd:EReference

qualifierExpression:Expression[0..1]

Path

pathExpression:Expression

ContainmentRelation

ContainerVariable

PrimitiveVariableExpression

ObjectVariableExpression

AttributeValueExpression

attribute:EAttribute

Constraint

constraintExp

ression:Exp

ression

ObjectSetVariable

ObjectSetSizeExpression

«enumeration»

LinkConstraintType

FIRST

LAST

DIREC

T_SUCCESSOR

INDIREC

T_SUCCESSOR

INDEX

AttributeAssignment

attribute:EAttribute

valueExp

ression:Expression

AbstractVariable

bindingState:BindingState=UNBOUND

bindingExpression:Expression[0..1]

PrimitiveVariable

classifier

:EDataType«...»

ObjectVariable

bindingSem

antics

:BindingSem

antics

=MANDATO

RY

bindingOperator:BindingOperator=

CHEC

K_O

NLY

classifier:EClass

«...»

LinkConstraint

index

:Integer

constraintTyp

e:LinkC

onstraintTyp

e=DIREC

T_SUCCESSOR

neg

ative

:Boolean

Figure A.21.: Metamodel of the patterns Package


target : AbstractVariable [1..1] see Section A.21.2 on Page 345

A.21.2. Abstract EClass AbstractVariable

Overview Abstract super class for object and primitive variables.

ESuper Types of AbstractVariable



EAttributes of AbstractVariable

bindingState : BindingState [1..1] see Section A.21.6 on Page 347

The binding state defines whether the variable is already bound or whether a matchhas to be obtained for it. The default value is "unbound".

EReferences of AbstractVariable

bindingExpression : Expression [0..1] see Section A.14.1 onPage 318

A binding expression can be used to bind a variable in a different way than just bypattern matching. This way, for example, the return value of a call can be boundto a variable.


All constraints which are defined for this variable. For a successful matching, allconstraints for this variable must evaluate to true.

incomingLink : AbstractLinkVariable [0..∗] see Section A.21.1on Page 343


A.21.3. EClass AttributeAssignment

Overview An AttributeAssignment is used to set the value of a certain attribute of an object.It references the attribute that is to be set and the value. The value can be an expressionto allow for calculations or calls that determine the final value. AttributeAssignmentsare carried out during the final phase of pattern application, i.e. after the matching anddestruction are completed.


EReferences of AttributeAssignment

attribute : EAttribute [1..1]

The attribute whose value is set. It has to be an attribute of the objectVariable thatcontains the AttributeAssignment.

objectVariable : ObjectVariable [1..1] see Section A.21.15 onPage 351

valueExpression : Expression [1..1] see Section A.14.1 onPage 318

The expression that determines the new value that is given to the attribute.

A.21.4. EEnumeration BindingOperator

Overview The BindingOperator enum defines all possible operations for object and linkvariables. An object or link variable may be checked for existence be the story pattern(black object/link variable), it may be created (green object/link variable), or it may bedestroyed (red object/link variable).

ELiterals of BindingOperator

CHECK_ONLY = 0

CHECK_ONLY is the default value of this enum. It requires an object or linkvariable just to be matched by the story pattern.

CREATE = 1

An object or link variable marked as CREATE will be created by the story pattern.

DESTROY = 2

An object or link variable marked as DESTROY will be destroyed be the storypattern.

A.21.5. EEnumeration BindingSemantics

Overview The binding semantics defines which kind of match will be obtained for the objector link variable.

ELiterals of BindingSemantics

MANDATORY = 0

For a mandatory object or link variable, a match has to be found for a pattern to besuccessfully applied.


NEGATIVE = 1

If an object or link variable is marked as NEGATIVE, no match may be found forthat object or link variable. If a match can be found, the execution of the storypattern fails.

OPTIONAL = 2

For an OPTIONAL object or link variable, the matching tries to find a match. Ifno match can be found, this does not affect the success of the pattern application.If a match can be found, the respective object or link is bound to the variable.

A.21.6. EEnumeration BindingState

Overview The BindingState defines whether an object or link variable is already bound to aconcrete value or not.

ELiterals of BindingState

UNBOUND = 0

UNBOUND is the default value for this enum. If an object or link variable in astory pattern is unbound, a new match has to be obtained for that variable.

BOUND = 1

A bound variable has already been bound to a concrete value. The concrete valuehas to be passed either as a parameter or it has to be bound in a previous activity. If,during the execution of a story pattern, a bound variable has no value, the executionof the story pattern fails.

MAYBE_BOUND = 2

A variable marked with maybe_bound indicates that it is unknown (orunimportant) at design time whether the variable is bound or not. If, during theexecution of the pattern, the variable is not bound, an object is matched and boundto the variable. If it is already bound, it is not altered. If the variable is stillunbound after this process, the matching fails (except for OPTIONAL variables).

A.21.7. EClass CollectionVariable

Overview Represents a set of objects of the same type that are represented by a single node.The context for contained Constraints and AttributeAssignments is every single objectin the set. E.g., if the constraint is "name = ’abc’", only objects with that name arematched and added to the set. The use of the binding operator "CREATE" is not definedfor ObjectSetVariables, i.e., the sets can only be matched and deleted.

ESuper Types of CollectionVariable


ObjectVariable see Section A.21.15 on Page 351

EAttributes of CollectionVariable

atLeastOne : EBoolean [1..1]

unique : EBoolean [1..1]

A.21.8. EClass Constraint

Overview A constraint represents a condition which must be fulfilled for a successful patternmatching. It can either be contained in the story pattern or in a variable. In the formercase, the constraint is evaluated after the matching of the object structure is complete. Itstill has to be true for the pattern application to be sucessful (and therefore for creationsand destructions to be carried out). If the constraint is contained in a variable, itconstrains the matching of that variable, i.e., it is evaluated during the matching of thecontaining variable and has to be true for a successful matching. If the variable is anObjectSetVariable, the constraint has to be true for every object in the set.

EReferences of Constraint

constraintExpression : Expression [1..1] see Section A.14.1 onPage 318

The constraintExpression defines the concrete condition of this constraint.

objectVariable : AbstractVariable [0..1] see Section A.21.2 onPage 345

The object variable this constraint applies to.


The story pattern this constraint applies to.

A.21.9. EClass InclusionLink

Overview Specifies the containment of an object in a set (represented by aContainerVariable). Will be displayed by a line having a circle with a plus inside atthe end of the container (the source end of the link). A create modifier specifies that theobject will be added to the container, delete that it will be removed, and none that it willbe checked to be contained.

ESuper Types of InclusionLink

AbstractLinkVariable see Section A.21.1 on Page 343


A.21.10. EClass LinkConstraint

Overview Link constraints (formerly known as MultiLinks in old meta-model) constrainthe ordering of links of the referencingObject is a collection. This way objects can berequired to have a certain position in the collection (FIRST, LAST, INDEX) or a certainordering relative to each other (DIRECT_SUCCESSOR, INDIRECT_SUCCESSOR).While the first kind of LinkConstraint can be imposed upon a single link, the second kindrequires two links that are related to each other (e.g., have the same referencingObject).

ESuper Types of LinkConstraint


EAttributes of LinkConstraint

constraintType : LinkConstraintType [1..1] seeSection A.21.11 on Page 349

The constraint type of the LinkConstraint.

index : EInt [1..1]

The index of the linked object in the collection. The semantics of this attribute isonly defined if the constraintType of the LinkConstraint is INDEX.

negative : EBoolean [1..1]

If the negative attribute is true, the link constraint may not be fulfilled for thecomplete pattern application to be successful.

EReferences of LinkConstraint

firstLink : AbstractLinkVariable [1..1] see Section A.21.1 onPage 343

referencingObject : ObjectVariable [1..1] see Section A.21.15on Page 351

secondLink : AbstractLinkVariable [0..1] see Section A.21.1 onPage 343

A.21.11. EEnumeration LinkConstraintType

Overview The LinkConstraintType represents the different uses of LinkConstraints. Objectscan be required to have a certain position in their containing collection (FIRST,


LAST, INDEX) or a certain ordering relative to each other (DIRECT_SUCCESSOR,INDIRECT_SUCCESSOR).

ELiterals of LinkConstraintType

FIRST = 0

LAST = 1

NEXT = 2

INDIRECT_SUCCESSOR = 3

INDEX = 4

A.21.12. EClass LinkVariable

Overview A link variable represents one link between two object variables. It is typedover one of the associations between the classes of those objects. Because EMF onlydirectly supports references, the two link ends are typed over these references. In caseof a uni-directional association, only the targetEnd is typed. In case of a bi-directionalassociation, the reference that types the source end is automatically determined.

ESuper Types of LinkVariable


EReferences of LinkVariable

qualifierExpression : Expression [0..1] see Section A.14.1 onPage 318

If a link is typed over a qualified reference, a qualifier determines the key underwhich the object reachable via the link is stored. Because the qualifier can be setby an expression, it can either be a simple string or something more complex, e.g.,a call like "object.getName()".

/sourceEnd : EReference [0..1]

The source end of a link variable can only be determined when the link is typedover a bi-directional association. In this case, it points to the "reverse" direction ofthe association. If the reference is only uni-directional, the source end is null. Thevalue of this attribute is derived automatically.

targetEnd : EReference [1..1]

The target end points to the reference that types this direction of the link (the"normal" direction). This link end must be set always.


A.21.13. EClass MatchingPattern

Overview A MatchingPattern is a special kind of story pattern that does not change theunderlying graph. Thus, no contained object or link may carry an create or destroyBindingOperator.

ESuper Types of MatchingPattern

StoryPattern see Section A.21.18 on Page 353

EOperations of MatchingPattern

NoModifierInMatchingPattern : EBoolean [0..1]

EParameters





A.21.14. EClass MaybeLink

Overview

ESuper Types of MaybeLink


A.21.15. EClass ObjectVariable

Overview An ObjectVariable holds a value of a complex type which is defined by an EClass.

ESuper Types of ObjectVariable

AbstractVariable see Section A.21.2 on Page 345

EAttributes of ObjectVariable

bindingOperator : BindingOperator [1..1] see Section A.21.4 onPage 346

The binding operator defines whether this object will be matched, created ordestroyed by the story pattern.



The binding semantics defines whether the object must be matched for a successfulapplication of the containing story pattern, whether it must not be matched orwhether it is optional, i.e., it will be bound if it can be bound but that does notaffect the success of matching the story pattern.

EReferences of ObjectVariable

attributeAssignment : AttributeAssignment [0..∗] seeSection A.21.3 on Page 345

classifier : EClass [1..1]

The type of this ObjectVariable, given as an EClass.

linkOrderConstraint : LinkConstraint [0..∗] seeSection A.21.10 on Page 349

outgoingLink : AbstractLinkVariable [0..∗] see Section A.21.1on Page 343

A.21.16. EClass Path

Overview A path is a special link variable that specifies an indirect connection betweentwo objects. That means, the connected objects have other links and objects "betweenthem". Exactly which types of links may be traversed during the matching of a path canbe constrained by a path expression.

ESuper Types of Path


EReferences of Path

pathExpression : Expression [1..1] see Section A.14.1 on Page 318

The path expression constrains the matching of the path variable during patternapplication. It can determine which links may be matched when and how manytimes to reach the target object of the path from the source object.


A.21.17. EClass PrimitiveVariable

Overview Represents a variable that holds a value of a primitive type, e.g. integer, boolean,String.

ESuper Types of PrimitiveVariable

AbstractVariable see Section A.21.2 on Page 345

EReferences of PrimitiveVariable

classifier : EDataType [1..1]

The type of the primitive variable which must be an EDataType.

A.21.18. EClass StoryPattern

Overview A Story Pattern is a graph rewrite rule that may be embedded into aStoryActivityNode of an Activity.

ESuper Types of StoryPattern


EAttributes of StoryPattern


EReferences of StoryPattern


All constraints which are defined for this story pattern. For a successful matching,all constraints for this story pattern must evaluate to true.

containedPattern : StoryPattern [0..∗] see Section A.21.18 onPage 353

linkVariable : AbstractLinkVariable [0..∗] see Section A.21.1on Page 343

parentPattern : StoryPattern [0..1] see Section A.21.18 onPage 353


templateSignature : TemplateSignature [0..1] seeSection A.23.3 on Page 359

variable : AbstractVariable [0..∗] see Section A.21.2 on Page 345

A.22. EPACKAGE STORYDIAGRAMS::PATTERNS::EXPRESSIONS 355

A.22. EPackagestorydiagrams::patterns::expressions

Overview

A.22.1. EClass AttributeValueExpression

Overview Represents the value of an object’s attribute, e.g. obj.attr for an object obj and anattribute attr.

ESuper Types of AttributeValueExpression


EReferences of AttributeValueExpression

attribute : EAttribute [1..1]

Specifies the object’s attribute whose attribute value is represented by thisexpression.

object : ObjectVariable [1..1] see Section A.21.15 on Page 351

Specifies the object variable whose attribute value is represented by thisexpression.

A.22.2. EClass CollectionSizeExpression

Overview Represents the number of elements in the set of objects that is represented by anobject set variable. For example, if you have an object set variable mySet, then thisexpression would represent something like mySet.size(). The expression can be usedto constrain the pattern application, e.g., to only a apply the pattern when at least twoobjects can be matched for the set.

ESuper Types of CollectionSizeExpression


EReferences of CollectionSizeExpression

set : CollectionVariable [1..1] see Section A.21.7 on Page 347

Specifies the object set variable whose number of set elements is to be representedby this expression.


*

objectVariableExpression

1

object

ExpressionHasObject

0..1

owningObject

0..1

bindingExpression

HasBindingExpression

0..1

attributeExpression

1

valueExpression

HasValue

0..1

owningConstraint

1

constraintExpression

ContainsConstraintExpression

*

objectSetSizeExpression

1 set

HasSet

*

primitiveVariableExpression

1

primitiveVariable

*

attributeValueExpression

1

object

HasObject

*

attributeValueExpression

1

attribute

HasAttribute

0..1

objectVariable

*

constraint

ContainsConstraints

1

objectVariable

*

attributeAssignment

ContainsAttributeExpression

*

attributeExpression

1

attribute

BindsProperty

ObjectVariableExpression

Expression

ObjectSetVariable

ObjectSetSizeExpression

PrimitiveVariable

PrimitiveVariableExpression

AttributeValueExpression

AbstractVariable

ObjectVariable AttributeAssignment

«Metaclass»

EAttribute

id:EBoolean[0..1]«...»

/eAttributeType:EDataType«...»

Constraint

Figure A.22.: Metamodel of the patterns::expressions Package

A.22. EPACKAGE STORYDIAGRAMS::PATTERNS::EXPRESSIONS 357

A.22.3. EClass ObjectVariableExpression

Overview Represents the reference to an object in an expression, i.e. the value of an objectvariable.

ESuper Types of ObjectVariableExpression


EReferences of ObjectVariableExpression

object : ObjectVariable [1..1] see Section A.21.15 on Page 351

Specifies the object variable that holds the reference to be represented by thisexpression.

A.22.4. EClass PrimitiveVariableExpression

Overview Represents the value of a primitive variable, e.g., 5 or "MyName".

ESuper Types of PrimitiveVariableExpression


EReferences of PrimitiveVariableExpression

primitiveVariable : PrimitiveVariable [1..1] seeSection A.21.17 on Page 353


A.23. EPackage storydiagrams::templates

Overview

0..1

templateBinding

1

bindingExpression

0..1

propertyBinding

1

bindingExpression

1

pattern

0..1

templateSignatureContainsTemplateSignature

*

propertyBinding

1

boundProperty

HasBoundProperty

1

owningTemplate

*

typeParameter

ContainsTypeParameter

*

templateBinding

1

boundParameter

HasBoundParameter

1

template*

templateBinding

ContainsBinding

1

templateBinding

*

propertyBinding

StoryPattern

TemplateBinding

TemplateSignature

PropertyBinding

«Metaclass»

EStructuralFeature Expression

«Metaclass»

EClassifier

Figure A.23.: Metamodel of the templates Package

A.23.1. EClass PropertyBinding

Overview

ESuper Types of PropertyBinding


EReferences of PropertyBinding


boundProperty : EStructuralFeature [1..1]

templateBinding : TemplateBinding [1..1] see Section A.23.2 onPage 359

A.23. EPACKAGE STORYDIAGRAMS::TEMPLATES 359

A.23.2. EClass TemplateBinding

Overview

ESuper Types of TemplateBinding


EReferences of TemplateBinding


boundParameter : EClassifier [1..1]

propertyBinding : PropertyBinding [0..∗] see Section A.23.1 onPage 358

template : TemplateSignature [1..1] see Section A.23.3 onPage 359

A.23.3. EClass TemplateSignature

Overview

EReferences of TemplateSignature


templateBinding : TemplateBinding [0..∗] see Section A.23.2 onPage 359

typeParameter : EClassifier [0..∗]

Appendix B.

Action Language XText Grammar

1 / / a u t o m a t i c a l l y g e n e r a t e d by X t e x t2 grammar de . u n i _ p a d e r b o r n . f u j a b a . muml . Ac t ionLanguage wi th org . e c l i p s e . x t e x t

. common . T e r m i n a l s3

4 i m p o r t " p l a t f o r m : / r e s o u r c e / de . u n i _ p a d e r b o r n . f u j a b a . muml . a c t i o n l a n g u a g e /model / a c t i o n l a n g u a g e . e c o r e " a s a c t i o n l a n g u a g e

5

6 i m p o r t " h t t p : / / www. e c l i p s e . o rg / emf / 2 0 0 2 / Ecore " a s e c o r e7

8 i m p o r t " p l a t f o r m : / r e s o u r c e / o rg . s t o r y d r i v e n . c o r e / model / c o r e . e c o r e " asmodel ing

9

10 i m p o r t " p l a t f o r m : / r e s o u r c e / de . u n i _ p a d e r b o r n . f u j a b a . muml / model / muml . e c o r e# / / r e a l t i m e s t a t e c h a r t " a s r t s c

11

12 i m p o r t " p l a t f o r m : / r e s o u r c e / de . u n i _ p a d e r b o r n . f u j a b a . muml / model / muml . e c o r e# / / b e h a v i o r " a s b e h a v i o r

13

14 i m p o r t " p l a t f o r m : / r e s o u r c e / de . u n i _ p a d e r b o r n . f u j a b a . muml / model / muml . e c o r e# / / t y p e s " a s t y p e s

15

16 i m p o r t " p l a t f o r m : / r e s o u r c e / de . u n i _ p a d e r b o r n . f u j a b a . muml / model / muml . e c o r e# / / msgtype " as msgtype

17

18 i m p o r t " p l a t f o r m : / r e s o u r c e / de . u n i _ p a d e r b o r n . f u j a b a . muml / model / muml . e c o r e# / / v a l u e t y p e " as v a l u e t y p e

19

20 i m p o r t " p l a t f o r m : / r e s o u r c e / o rg . s t o r y d r i v e n . c o r e / model / c o r e . e c o r e # / /e x p r e s s i o n s " a s e x p r e s s i o n s

21

22 i m p o r t " p l a t f o r m : / r e s o u r c e / o rg . s t o r y d r i v e n . c o r e / model / c o r e . e c o r e # / /e x p r e s s i o n s / common" as commonExpress ions

23

24 E n t r y r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :25 Block | E x p r e s s i o n | A r r a y I n i t i a l i z e E x p r e s s i o n26 ;27

28 Block r e t u r n s a c t i o n l a n g u a g e : : Block h i dd en (WS, ML_COMMENT, SL_COMMENT) :

361

362 APPENDIX B. ACTION LANGUAGE XTEXT GRAMMAR

29 { a c t i o n l a n g u a g e : : Block }30 ’ { ’31 ( e x p r e s s i o n s += E x p r e s s i o n S t a r t R u l e ∗ )32 ’ } ’33 ;34

35 / / TODO: c l a r i f y i f i t makes s e n s e t o a l l o w a r b i t r a r y e x p r e s s i o n s f o r36 / / t h e i n i t i a l i z e E x p r e s s i o n and c o u n t i n g E x p r e s s i o n37 ForLoop r e t u r n s a c t i o n l a n g u a g e : : ForLoop :38 ’ f o r ’ ’ ( ’ i n i t i a l i z e E x p r e s s i o n = Ass ignment l o o p T e s t = E x p r e s s i o n ’ ; ’

c o u n t i n g E x p r e s s i o n = F o r L o o p C o u n t i n g E x p r e s s i o n ’ ) ’39 b l o c k =Block40 ;41

42 F o r L o o p C o u n t i n g E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : : Ass ignment :43 l h s _ t y p e d N a m e d E l e m e n t E x p r e s s i o n =TypedNamedElementExpress ion44 (45 i n c r e m e n t D e c r e m e n t O p e r a t o r = U n a r y P o s t I n c r e m e n t D e c r e m e n t O p e r a t o r46 | ( a s s i g n O p e r a t o r = A s s i g n O p e r a t o r r h s _ a s s i g n E x p r e s s i o n = E x p r e s s i o n )47 )48 ;49

50 WhileLoop r e t u r n s a c t i o n l a n g u a g e : : WhileLoop :51 ’ w h i l e ’ ’ ( ’ l o o p T e s t = E x p r e s s i o n ’ ) ’52 b l o c k =Block53 ;54

55 DoWhileLoop r e t u r n s a c t i o n l a n g u a g e : : DoWhileLoop :56 ’ do ’57 b l o c k =Block58 ’ w h i l e ’ ’ ( ’ l o o p T e s t = E x p r e s s i o n ’ ) ; ’59 ;60

61 I f S t a t e m e n t r e t u r n s a c t i o n l a n g u a g e : : I f S t a t e m e n t :62 ’ i f ’ ’ ( ’ i f C o n d i t i o n = E x p r e s s i o n ’ ) ’63 i f B l o c k =Block64 ( ’ e l s e i f ’ ’ ( ’ e l s e I f C o n d i t i o n s += E x p r e s s i o n ’ ) ’65 e l s e I f B l o c k s += Block66 ) ∗67 ( ’ e l s e ’ e l s e B l o c k =Block ) ?68 ;69

70 R e t u r n S t a t e m e n t r e t u r n s a c t i o n l a n g u a g e : : R e t u r n S t a t e m e n t :71 { a c t i o n l a n g u a g e : : R e t u r n S t a t e m e n t }72 ’ r e t u r n ’ e x p r e s s i o n = E x p r e s s i o n ’ ; ’73 ;74

75 O p e r a t i o n C a l l S t a t e m e n t r e t u r n s a c t i o n l a n g u a g e : : O p e r a t i o n C a l l :76 O p e r a t i o n C a l l ’ ; ’77 ;

363

78

79 E x p r e s s i o n S t a r t R u l e r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :80 Assignment | ForLoop |81 WhileLoop | DoWhileLoop |82 I f S t a t e m e n t | R e t u r n S t a t e m e n t |

L o c a l V a r i a b l e O r C o n s t a n t D e c l a r a t i o n S t a t e m e n t |83 O p e r a t i o n C a l l S t a t e m e n t84 ;85

86 enum U n a r y P o s t I n c r e m e n t D e c r e m e n t O p e r a t o r r e t u r n s a c t i o n l a n g u a g e : :I n c r e m e n t D e c r e m e n t O p e r a t o r :

87 INCREMENT= ’++ ’ | DECREMENT= ’−− ’88 ;89

90 / / A s s i g n m e n t91

92 Assignment r e t u r n s a c t i o n l a n g u a g e : : Ass ignment :93 l h s _ t y p e d N a m e d E l e m e n t E x p r e s s i o n =TypedNamedElementExpress ion94 (95 (96 a s s i g n O p e r a t o r = A s s i g n O p e r a t o r r h s _ a s s i g n E x p r e s s i o n =

I n i t i a l i z e E x p r e s s i o n97 ) |98 (99 i n c r e m e n t D e c r e m e n t O p e r a t o r = U n a r y P o s t I n c r e m e n t D e c r e m e n t O p e r a t o r

100 )101

102 ) ’ ; ’103 ;104

105 enum I n c r e m e n t D e c r e m e n t O p e r a t o r E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : :I n c r e m e n t D e c r e m e n t O p e r a t o r :

106 INCREMENT= ’++ ’ | DECREMENT= ’−− ’107 ;108

109 enum A s s i g n O p e r a t o r r e t u r n s a c t i o n l a n g u a g e : : A s s i g n O p e r a t o r :110 ASSIGN= ’ := ’ | PLUS_EQUAL= ’+= ’ | MINUS_EQUAL= ’−= ’111 ;112

113 / / end o f a s s i g n m e n t114

115 / / i n i t i a l i z e e x p r e s s i o n116

117 I n i t i a l i z e E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :118 A r r a y I n i t i a l i z e E x p r e s s i o n | N o n d e t e r m i n i s t i c C h o i c e E x p r e s s i o n |

E x p r e s s i o n119 ;120

121 / / end o f i n i t i a l i z e e x p r e s s i o n122

123 / / a r r a y i n i t i a l i z a t i o n124

125 A r r a y I n i t i a l i z e E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : :A r r a y I n i t i a l i z e E x p r e s s i o n :

126 ’ [ ’ e x p r e s s i o n s += I n i t i a l i z e E x p r e s s i o n127 ( ’ , ’ e x p r e s s i o n s += I n i t i a l i z e E x p r e s s i o n ) ∗128 ’ ] ’129 ;130

131 / / end o f a r r a y i n i t i a l i z a t i o n132

133 / / l o c a l v a r i a b l e d e c l a r a t i o n134

135 L o c a l V a r i a b l e O r C o n s t a n t D e c l a r a t i o n S t a t e m e n t r e t u r n s a c t i o n l a n g u a g e : :L o c a l V a r i a b l e D e c l a r a t i o n S t a t e m e n t :

136 v a r i a b l e =( L o c a l V a r i a b l e D e c l a r a t i o n | L o c a l C o n s t a n t D e c l a r a t i o n )137 ;138

139 L o c a l V a r i a b l e D e c l a r a t i o n r e t u r n s b e h a v i o r : : V a r i a b l e :140 da taType =[ t y p e s : : DataType | DATATYPE] name=ID ( ’ := ’ i n i t i a l i z e E x p r e s s i o n =

I n i t i a l i z e E x p r e s s i o n ) ? ’ ; ’141 ;142

143 L o c a l C o n s t a n t D e c l a r a t i o n r e t u r n s b e h a v i o r : : V a r i a b l e :144 c o n s t a n t ?= ’ c o n s t ’ da t aType =[ t y p e s : : DataType | DATATYPE] name=ID ’ := ’

i n i t i a l i z e E x p r e s s i o n = I n i t i a l i z e E x p r e s s i o n ’ ; ’145 ;146

147 / / end o f l o c a l v a r i a b l e d e c l a r a t i o n148

149 / / n o n d e t e r m i n i s t i c c h o i c e e x p r e s s i o n150

151 N o n d e t e r m i n i s t i c C h o i c e E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : :N o n d e t e r m i n i s t i c C h o i c e E x p r e s s i o n :

152 da taType =[ t y p e s : : P r i m i t i v e D a t a T y p e ] r a n g e =Range153 ;154

155 Range r e t u r n s v a l u e t y p e : : Range :156 ’< ’ lowerBound=LONG ’ , ’ upperBound=LONG ’> ’157 ;158

159 LONG r e t u r n s e c o r e : : ELong :160 INT161 ;162

163 / / end o f n o n d e t e r m i n i s t i c c h o i c e e x p r e s s i o n164

165 E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :166 L o g i c a l E x p r e s s i o n167 ;

365

168

169 / / L o g i c a l E x p r e s s i o n170

171 L o g i c a l E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :172 L o g i c a l O r E x p r e s s i o n173 ;174

175 L o g i c a l O r E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :176 L o g i c a l A n d E x p r e s s i o n177 (178 { commonExpress ions : : L o g i c a l E x p r e s s i o n . l e f t E x p r e s s i o n = c u r r e n t }179 o p e r a t o r = L o g i c a l O r O p e r a t o r180 r i g h t E x p r e s s i o n = L o g i c a l A n d E x p r e s s i o n181 ) ∗182 ;183

184 enum L o g i c a l O r O p e r a t o r r e t u r n s commonExpress ions : : L o g i c O p e r a t o r :185 OR= ’ | | ’186 ;187

188 L o g i c a l A n d E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :189 C o m p a r i s o n E x p r e s s i o n190 (191 { commonExpress ions : : L o g i c a l E x p r e s s i o n . l e f t E x p r e s s i o n = c u r r e n t }192 o p e r a t o r = L o g i c a l A n d O p e r a t o r193 r i g h t E x p r e s s i o n = C o m p a r i s o n E x p r e s s i o n194 ) ∗195 ;196

197 enum L o g i c a l A n d O p e r a t o r r e t u r n s commonExpress ions : : L o g i c O p e r a t o r :198 AND= ’&&’199 ;200

201 / / end o f L o g i c a l E x p r e s s i o n202

203 / / Compar i sonExpre s s ion204

205 C o m p a r i s o n E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :206 Compar i sonHighe rOpExpress ion207 (208 { commonExpress ions : : C o m p a r i s o n E x p r e s s i o n . l e f t E x p r e s s i o n = c u r r e n t }209 o p e r a t o r =ComparingEQNEQOperator210 r i g h t E x p r e s s i o n = Compar i sonHighe rOpExpress ion211 ) ?212 ;213

214 Compar i sonHighe rOpExpress ion r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :215 A r i t h m e t i c E x p r e s s i o n216 ( { commonExpress ions : : C o m p a r i s o n E x p r e s s i o n . l e f t E x p r e s s i o n = c u r r e n t }217 o p e r a t o r = Compar ingRe lOpera to r

218 r i g h t E x p r e s s i o n = A r i t h m e t i c E x p r e s s i o n219 ) ?220 ;221

222 enum ComparingEQNEQOperator r e t u r n s commonExpress ions : : Compar ingOpera to r :223 EQUAL= ’== ’ | UNEQUAL= ’<> ’224 ;225

226 enum Compar ingRe lOpera to r r e t u r n s commonExpress ions : : Compar ingOpera to r :227 LESS= ’< ’ | LESS_OR_EQUAL= ’<= ’ | GREATER_OR_EQUAL= ’>= ’ | GREATER= ’> ’228 ;229

230 / / end o f Compar i sonExpre s s ion231

232 / / A r i t h m e t i c E x p r e s s i o n233

234 A r i t h m e t i c E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :235 A d d i t i o n E x p r e s s i o n236 ;237

238 A d d i t i o n E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :239 M u l t i p l i c a t i o n E x p r e s s i o n240 (241 { commonExpress ions : : A r i t h m e t i c E x p r e s s i o n . l e f t E x p r e s s i o n = c u r r e n t }242 o p e r a t o r = A d d i t i o n O p e r a t o r r i g h t E x p r e s s i o n = M u l t i p l i c a t i o n E x p r e s s i o n243 ) ∗244 ;245

246 enum A d d i t i o n O p e r a t o r r e t u r n s commonExpress ions : : A r i t h m e t i c O p e r a t o r :247 PLUS= ’+ ’ | MINUS= ’− ’248 ;249

250 M u l t i p l i c a t i o n E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :251 U n a r y P r e E x p r e s s i o n | Operand252 ( { commonExpress ions : : A r i t h m e t i c E x p r e s s i o n . l e f t E x p r e s s i o n = c u r r e n t }253 o p e r a t o r = M u l t i p l i c a t i o n O p e r a t o r r i g h t E x p r e s s i o n =( U n a r y P r e E x p r e s s i o n

| Operand )254 ) ∗255 ;256

257 enum M u l t i p l i c a t i o n O p e r a t o r r e t u r n s commonExpress ions : : A r i t h m e t i c O p e r a t o r :258 TIMES= ’∗ ’ | DIVIDE= ’ / ’259 ;260

261 / / end o f A r i t h m e t i c E x p r e s s i o n262

263 / / UnaryPreExpres s ion264

265 U n a r y P r e E x p r e s s i o n r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :266 { commonExpress ions : : U n a r y E x p r e s s i o n }

367

267 o p e r a t o r = U n a r y P r e O p e r a t o r e n c l o s e d E x p r e s s i o n =Operand268 ;269

270 enum U n a r y P r e O p e r a t o r r e t u r n s commonExpress ions : : Una ryOpe ra to r :271 NOT= ’ n o t ’ | MINUS= ’− ’272 ;273

274 / / end o f UnaryPreExpres s ion275

276 / / Operand277

278 Operand r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :279 ’ ( ’ E x p r e s s i o n ’ ) ’ | L i t e r a l E x p r e s s i o n |

ExtendedTypedNamedElementExpress ion280 | O p e r a t i o n C a l l | T r i g g e r M e s s a g e E x p r e s s i o n |

N o A t t r i b u t e S e l e c t o r E x p r e s s i o n281 ;282

283 / / end o f Operand284

285 L i t e r a l E x p r e s s i o n r e t u r n s commonExpress ions : : L i t e r a l E x p r e s s i o n :286 { commonExpress ions : : L i t e r a l E x p r e s s i o n } v a l u e = L i t e r a l287 ;288

289 L i t e r a l r e t u r n s e c o r e : : E S t r i n g :290 NUMBER | BOOLEAN | INT | ’ n u l l ’291 ;292

293 ExtendedTypedNamedElementExpress ion r e t u r n s e x p r e s s i o n s : : E x p r e s s i o n :294 TypedNamedElementExpress ion295 (296 (297 { a c t i o n l a n g u a g e : : D i s c r e t e I n t e r a c t i o n E n d p o i n t R e f e r e n c e .

typedNamedElementExpress ion = c u r r e n t }298 ’ . ’ p o s i t i o n = P o s i t i o n S e l e c t o r E x p r e s s i o n299 ) |300 (301 / / unary p o s t i n c r e m e n t / dec remen t302 { a c t i o n l a n g u a g e : : Ass ignment . l h s _ t y p e d N a m e d E l e m e n t E x p r e s s i o n =

c u r r e n t }303 i n c r e m e n t D e c r e m e n t O p e r a t o r = I n c r e m e n t D e c r e m e n t O p e r a t o r E x p r e s s i o n304 )305 ) ?306 ;307

308 TypedNamedElementExpress ion r e t u r n s a c t i o n l a n g u a g e : :TypedNamedElementExpress ion :

309 typedNamedElement =[ b e h a v i o r : : TypedNamedElement ] ( ’ [ ’ i n d i c e s +=A r i t h m e t i c E x p r e s s i o n ’ ] ’ ) ∗

310 ;


311

312 N o A t t r i b u t e S e l e c t o r E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : :D i s c r e t e I n t e r a c t i o n E n d p o i n t R e f e r e n c e :

313 p o s i t i o n = P o s i t i o n S e l e c t o r E x p r e s s i o n314 ;315

316 P o s i t i o n S e l e c t o r E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : : P o s i t i o n S e l e c t o r :317 k ind = P o s i t i o n S e l e c t o r K i n d ( ’ . ’ s u c c e s s o r = P o s i t i o n S e l e c t o r E x p r e s s i o n ) ?318 ;319

320 enum P o s i t i o n S e l e c t o r K i n d r e t u r n s a c t i o n l a n g u a g e : : P o s i t i o n S e l e c t o r K i n d :321 SELF= ’ s e l f ’ | FIRST= ’ f i r s t ’ | LAST= ’ l a s t ’ | PREV= ’ p rev ’ | NEXT= ’ n e x t ’322 ;323

324 O p e r a t i o n C a l l r e t u r n s a c t i o n l a n g u a g e : : O p e r a t i o n C a l l :325 o p e r a t i o n =[ b e h a v i o r : : O p e r a t i o n ] ’ ( ’326 ( p a r a m e t e r B i n d i n g += P a r a m a t e r B i n d i n g ( ’ , ’ p a r a m e t e r B i n d i n g +=

P a r a m a t e r B i n d i n g ) ∗ ) ?327 ’ ) ’328 ;329

330 P a r a m a t e r B i n d i n g r e t u r n s b e h a v i o r : : P a r a m e t e r B i n d i n g :331 { b e h a v i o r : : P a r a m e t e r B i n d i n g } p a r a m e t e r =[ b e h a v i o r : : P a r a m e t e r ] ’ := ’ v a l u e =

E x p r e s s i o n332 ;333

334 / / T r i g g e r M e s s a g e E x p r e s s i o n335

336 T r i g g e r M e s s a g e E x p r e s s i o n r e t u r n s a c t i o n l a n g u a g e : : T r i g g e r M e s s a g e E x p r e s s i o n :337 messageType =[ msgtype : : MessageType ] ’ . ’ p a r a m e t e r =[ b e h a v i o r : : P a r a m e t e r ]338 ;339

340 / / end o f T r i g g e r M e s s a g e E x p r e s s i o n341

342 t e r m i n a l NUMBER r e t u r n s e c o r e : : EBigDecimal :343 INT ’ . ’ INT344 ;345

346 t e r m i n a l BOOLEAN r e t u r n s e c o r e : : EBoolean :347 ’ t r u e ’ | ’ f a l s e ’348 ;349

350 t e r m i n a l ID :351 ’ ^ ’ ? ( ’ a ’ . . ’ z ’ | ’A’ . . ’Z ’ | ’ _ ’ ) ( ’ a ’ . . ’ z ’ | ’A’ . . ’Z ’ | ’ _ ’ | ’ 0 ’ . . ’ 9 ’ ) ∗352 ;353

354 DATATYPE r e t u r n s e c o r e : : E S t r i n g :355 ID ( ’ [ ’ INT ’ ] ’ ) ∗356 ;

the mechatronicuml design method process and language … · the mechatronicuml design method –...

Documents