A UML Based Modeling Language With Operational ...

A UML Based Modeling Language With Operational Semantics Defined By Modelica by

Uwe Pohlmann

Fakultät für Elektrotechnik, Informatik und Mathematik Heinz Nixdorf Institut und Institut für Informatik Fachgebiet Softwaretechnik Warburger Straße 100 33098 Paderborn

A UML Based Modeling Language With Operational Semantics Defined By Modelica Master Thesis Submitted to the Software Engineering Research Group in Partial Fulfillment of the Requirements for the Degree of

Master of Science by

Uwe Pohlmann Dahlienweg 4 59609 Anröchte

Thesis Supervisors:

Prof. Dr. Wilhelm Schäfer and

Prof. Dr. Gregor Engels Paderborn, July 8, 2010

Declaration (Translation from German) I hereby declare that I prepared this thesis entirely on my own and have not used outside sources without declaration in the text. Any concepts or quotations applicable to these sources are clearly attributed to them. This thesis has not been submitted in the same or substantially similar version, not even in part, to any other authority for grading and has not been published elsewhere.

Original Declaration Text in German: Erkl¨ arung Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder a¨hnlicher Form noch keiner anderen Pr¨ ufungsbehörde vorgelegen hat und von dieser als Teil einer Pr¨ ufungsleistung angenommen worden ist. Alle Ausf¨ uhrungen, die wörtlich oder sinngemäß u ¨bernommen worden sind, sind als solche gekennzeichnet.

City, Date

Signature

v

Abstract ModelicaML is a UML profile for the creation of executable models. ModelicaML combines the UML standardized graphical notation for systems and software modeling, and the simulation capabilities of Modelica. However, ModelicaML lacks a definition of its syntax and its state machine semantics. Such a formal basis of the language is required in order to fully specify the structure and behavior of complex technical systems and to simulate them. Therefore, this thesis addresses the concrete language definition (syntax, constraints) of ModelicaML, the semantics of UML/ModelicaML state machines and the mapping to Modelica code. This thesis focuses on the requirements for integrated modeling of physical mechatronic systems containing discrete and continuous behavior. Further, this thesis demonstrates that using ModelicaML enables the integrated modeling and simulation of continuous and discrete physical system dynamics. Additionally, this thesis presents a prototypical implementation of a ModelicaML modeling environment, a validation mechanism for ModelicaML models, and a code-generator. The code-generator transfers ModelicaML models to Modelica code. This code can be simulated to analyze mechatronic systems.

Keywords: UML, Modelica, ModelicaML, Modeling, Semantics, Simulation, State Machine, StateChart, Syntax.

Acknowledgement I am thankful to many people for their help and support during my work on this thesis. First of all I would like to thank my promoter Wladimir Schamai who has helped me to acclimatise in ModelicaML and the world of system engineering. I also wish to thank my adviser Matthias Tichy for guiding me through the not always serene waters of research and my Professor Wilhelm Schäfer who made this thesis possible. I would like to thank my former advisers Stefan Henkler and Martin Hirsch and the whole Software Engineering Group of Paderborn for introducing me to the methods of model-based engineering and academia. I had the pleasure to do a lot of work for this master thesis at EADS Innovation Works in Hamburg Finkenwerder, where I have met many kind people and discovered the world of Airbus aircraft. Thanks to Axel Hillebrand, Alexander Gahn and others for being kind colleagues and sharing office space. I thank my fellow students Oleg Travkin and Thomas Böker for assessing my manuscript and giving valuable comments. I also received useful comments from Thomas Gewering, Anna Hansen, Christopher Gerking, Tobias Eckardt, and Stefan Dziwok. I want to thank my friends, who made my life pleasant and for accommodating me at anytime. This thesis would not have been possible without the support of family.

ix

Contents 1 Introduction 1.1 Motivation . . . . . . . . . . . . 1.1.1 Example of Application 1.2 Objectives . . . . . . . . . . . . 1.3 Structure of this Thesis . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Fundamentals 2.1 Modeling and Simulation . . . . . . . . . . . . . . . 2.1.1 Systems and Experiments . . . . . . . . . . 2.1.2 Modeling . . . . . . . . . . . . . . . . . . . 2.1.3 Simulation . . . . . . . . . . . . . . . . . . . 2.1.4 Validation . . . . . . . . . . . . . . . . . . . 2.2 Modelica . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Types of Equations . . . . . . . . . . . . . . 2.2.2 Restricted/Enhanced Classes . . . . . . . . 2.2.3 Variability of Variables . . . . . . . . . . . . 2.2.4 Components . . . . . . . . . . . . . . . . . . 2.2.5 Ports/Connectors . . . . . . . . . . . . . . . 2.2.6 Connections . . . . . . . . . . . . . . . . . . 2.2.7 Connection Diagram . . . . . . . . . . . . . 2.2.8 Synchronous Data Flow Principle and Single 2.2.9 Equations vs. Algorithm Sections . . . . . . 2.2.10 Notion of Events . . . . . . . . . . . . . . . 2.2.11 Integration and Event Iteration . . . . . . . 2.2.12 Conditional Expressions . . . . . . . . . . . 2.2.13 Simulation Environments . . . . . . . . . . . 2.3 UML . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Structure . . . . . . . . . . . . . . . . . . . 2.3.2 Behavior . . . . . . . . . . . . . . . . . . . . 2.3.3 Customizing UML . . . . . . . . . . . . . . 2.4 ModelicaML . . . . . . . . . . . . . . . . . . . . . . 2.5 Constraints . . . . . . . . . . . . . . . . . . . . . . 2.5.1 OCL . . . . . . . . . . . . . . . . . . . . . . 2.6 Transformation . . . . . . . . . . . . . . . . . . . . 3 Methodology and Concrete Language Definition

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

1 2 3 3 4

. . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5 5 6 7 7 8 9 10 10 11 12 12 12 12 14 15 16 16 16 16 17 20 24 26 27 27 28 29

xi

Contents 3.1 3.2

. . . . . . . . . . . . . . . . . . . . . . . . . .

30 30 31 34 35 35 37 37 39 39 39 40 40 41 41 42 44 44 54 58 60 62 63 63 63 65

4 State Machine Semantics 4.1 Semantics Definition of ModelicaML State Machines . . . . . . . . 4.1.1 Events and Triggers . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Event Processing . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Instantaneous States and Delayed Transitions . . . . . . . 4.1.4 Self Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.5 Concurrent Regions Execution . . . . . . . . . . . . . . . . 4.1.6 Conflicting Transitions . . . . . . . . . . . . . . . . . . . . 4.1.7 Conflicting Transitions at Different State Hierarchy Levels 4.1.8 Entry-/ Do-/ Exit-Actions, Effects and Activities . . . . . 4.1.9 Interlevel Transitions and Concurrency . . . . . . . . . . . 4.1.10 Terminate . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.11 FinalState . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.12 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.13 OR-Compound Transitions . . . . . . . . . . . . . . . . . . 4.1.14 AND-Compound Transitions . . . . . . . . . . . . . . . . . 4.1.15 Submachine . . . . . . . . . . . . . . . . . . . . . . . . . .

67 68 68 69 71 72 72 73 74 75 76 78 78 78 80 81 83

3.3

3.4

3.5

xii

Language Architecture . . . . . . . . . . Class Structure . . . . . . . . . . . . . . 3.2.1 Class . . . . . . . . . . . . . . . . 3.2.2 Property . . . . . . . . . . . . . . 3.2.3 Package . . . . . . . . . . . . . . 3.2.4 Generalization . . . . . . . . . . . 3.2.5 Primitive Types . . . . . . . . . . 3.2.6 Class Structure Example . . . . . Composite Structure . . . . . . . . . . . 3.3.1 Class from Composite Structures 3.3.2 Property . . . . . . . . . . . . . . 3.3.3 Interface Class . . . . . . . . . . 3.3.4 Port . . . . . . . . . . . . . . . . 3.3.5 Connector . . . . . . . . . . . . . 3.3.6 Composite Structure Example . . Behavior . . . . . . . . . . . . . . . . . . 3.4.1 Opaque Behavior . . . . . . . . . 3.4.2 State Machine . . . . . . . . . . . 3.4.3 Activity . . . . . . . . . . . . . . 3.4.4 Behavior Example . . . . . . . . Diagram . . . . . . . . . . . . . . . . . . 3.5.1 Class Diagram . . . . . . . . . . 3.5.2 Composite structure diagram . . 3.5.3 State Machine Diagram . . . . . 3.5.4 Algorithm Diagram . . . . . . . . 3.5.5 Conditional Equation Diagram .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

Contents 4.1.16 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Implementation 5.1 Modeling Tool Support . . . . . . . . . 5.1.1 Papyrus UML . . . . . . . . . . 5.1.2 Modeling Support . . . . . . . . 5.1.3 Property View Support . . . . . 5.1.4 Composite Diagram Extension . 5.1.5 Conclusion . . . . . . . . . . . . 5.2 From Model to Modelica Code . . . . . 5.2.1 Acceleo . . . . . . . . . . . . . 5.2.2 Validation . . . . . . . . . . . . 5.2.3 Code Generation . . . . . . . . 5.2.4 State Machine Structure Code . 5.2.5 Simple State Machine Example 5.2.6 State Machine Behavior Code .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

6 Related Work 6.1 Modelica Modeling and Simulation Environments 6.1.1 Dymola / MathModelica / OpenModelica 6.1.2 StateGraph2 . . . . . . . . . . . . . . . . . 6.1.3 SimulationX . . . . . . . . . . . . . . . . . 6.1.4 Mosilab . . . . . . . . . . . . . . . . . . . 6.2 Hybrid Automata . . . . . . . . . . . . . . . . . . 6.3 MATLAB/ Simulink/ Stateflow . . . . . . . . . . 6.4 MECHATRONIC UML . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

84

. . . . . . . . . . . . .

87 88 88 89 89 92 92 92 93 94 95 95 98 103

. . . . . . . .

119 119 119 120 121 122 123 124 125

7 Summary and Future Work 127 7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Appendix A ModelicaML Constraints A.1 Class Structure . . . A.2 Composite Structure A.3 Activity . . . . . . . A.4 State Machine . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

131 131 134 136 137

B Constraint Operations

143

C ModelicaML

145

D CD-ROM

157

xiii

Contents Bibliography

xiv

159

List of Figures 1.1

Two Tank System . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

Continuously vs. Discrete Dynamic Models . . . . . . Restrictions on the Kind of Base Class . . . . . . . . Modelica Variable Types . . . . . . . . . . . . . . . . Connection Diagram Schema . . . . . . . . . . . . . . Multidomain Connection Diagram . . . . . . . . . . . History of object-oriented methods and notations . . Class notion . . . . . . . . . . . . . . . . . . . . . . . Connected Composite Structure of Two Tank System MetaModel of UML Behavior . . . . . . . . . . . . . Notion of activity nodes . . . . . . . . . . . . . . . . State Machine Metamodel . . . . . . . . . . . . . . . UML 2 state machines . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

8 11 11 13 13 18 19 21 21 22 25 26

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22

Overview of ModelicaML/UML interrelationship . . . Model Tree . . . . . . . . . . . . . . . . . . . . . . . Package . . . . . . . . . . . . . . . . . . . . . . . . . Tank Class . . . . . . . . . . . . . . . . . . . . . . . . Controller . . . . . . . . . . . . . . . . . . . . . . . . Composite Class Notion . . . . . . . . . . . . . . . . Port Notion . . . . . . . . . . . . . . . . . . . . . . . Two Tank System Class . . . . . . . . . . . . . . . . Interface Class . . . . . . . . . . . . . . . . . . . . . . Connected Composite Structure of Two Tank System StateMachine Notion . . . . . . . . . . . . . . . . . . SimpleState Notion . . . . . . . . . . . . . . . . . . . Transition Notion . . . . . . . . . . . . . . . . . . . . Transition Label Notion . . . . . . . . . . . . . . . . Region Notion . . . . . . . . . . . . . . . . . . . . . . CompositeState Notion . . . . . . . . . . . . . . . . . Submachine-State Notion . . . . . . . . . . . . . . . . FinalState Notion . . . . . . . . . . . . . . . . . . . . Initial-Pseudostate Notion . . . . . . . . . . . . . . . ShallowHistory-Pseudostate Notion . . . . . . . . . . Junction-Pseudostate Notion . . . . . . . . . . . . . . Choice-Pseudostate Notion . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

31 32 36 38 38 39 41 42 42 43 44 45 45 47 47 48 48 48 49 49 50 51

xv

List of Figures 3.23 3.24 3.25 3.26 3.27 3.28 3.29 3.30 3.31 3.32 3.33 3.34 3.35 3.36 3.37 3.38 3.39 3.40 3.41 3.42 3.43 3.44 3.45

Transition Label Notion . . . . . . . . . Fork-Pseudostate Notion . . . . . . . . . ConnectionPointReference Label Notion EntryPoint-Pseudostate Notion . . . . . ExitPoint-Pseudostate Notion . . . . . . Terminate-Pseudostate Notion . . . . . . Conditional Algorithm Notion . . . . . . Conditional Equations Notion . . . . . . Initial Notion . . . . . . . . . . . . . . . Statement Notion . . . . . . . . . . . . . Equation Notion . . . . . . . . . . . . . ControlFlow Notion . . . . . . . . . . . . Merge Notion . . . . . . . . . . . . . . . If- decision Notion . . . . . . . . . . . . When-decision Notion . . . . . . . . . . State Machine . . . . . . . . . . . . . . . Actuator Signal Activation . . . . . . . . Diagram Frame . . . . . . . . . . . . . . Diagram Taxonomy . . . . . . . . . . . . Class diagram . . . . . . . . . . . . . . . Composite Diagram . . . . . . . . . . . . State Machine Diagram Example with all Conditional Algorithm Diagram Example

. . . . . . . . . . . . . . . . . . . . . . .

51 52 52 53 53 54 55 55 55 56 56 56 57 58 58 59 60 61 62 62 63 64 64

4.1 4.2

69

4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

State Machine Example with SignalEvent and ChangeEvent . . . Simulation Result of State Machine Example with SignalEvent and ChangeEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Machine Example with a Loop . . . . . . . . . . . . . . . . Priority Order List . . . . . . . . . . . . . . . . . . . . . . . . . . Conflicting Transitions Example . . . . . . . . . . . . . . . . . . . Conflicting High-Level Transitions . . . . . . . . . . . . . . . . . . Do-Action Example . . . . . . . . . . . . . . . . . . . . . . . . . . Do-Action Simulation Result . . . . . . . . . . . . . . . . . . . . . Interlevel Transitions and Concurrency . . . . . . . . . . . . . . . ShallowHistory Example . . . . . . . . . . . . . . . . . . . . . . . DeepHistory Example . . . . . . . . . . . . . . . . . . . . . . . . . Junction Example . . . . . . . . . . . . . . . . . . . . . . . . . . . Choice Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fork and Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Submachine Example . . . . . . . . . . . . . . . . . . . . . . . . .

70 72 73 74 74 76 76 77 79 80 81 81 82 84

5.1 5.2 5.3

Plug-in Architecture . . . . . . . . . . . . . . . . . . . . . . . . . Architecture of GEF . . . . . . . . . . . . . . . . . . . . . . . . . ModelicaML Papyrus UML Palette . . . . . . . . . . . . . . . . .

88 89 90

xvi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elements . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

List of Figures 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18

Context Menu of the Outline . . . . . . . . . . . . Tabbed Property of ModelicaML Model Element . Stereotype Documentation View . . . . . . . . . . ModelicaML Validation View . . . . . . . . . . . Validation Template Scripts . . . . . . . . . . . . Modelica State Machine Structure . . . . . . . . . State Machine Structure . . . . . . . . . . . . . . Simple State Machine Example in Modelica . . . State 0 Behavior . . . . . . . . . . . . . . . . . . State 1 Behavior . . . . . . . . . . . . . . . . . . Behavior of Variable x and t . . . . . . . . . . . . State Machine Behavior Scripts . . . . . . . . . . Junction Chain . . . . . . . . . . . . . . . . . . . Choice Chain . . . . . . . . . . . . . . . . . . . . State Machine with Composite State . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

90 91 91 93 94 96 98 98 100 100 100 108 113 113 114

6.1 6.2 6.3

StateGraph2 Example . . . . . . . . . . . . . . . . . . . . . . . . Graphical Representation of Hybrid Automata . . . . . . . . . . . A Tank with Three Valves Modeled in Simulink/Stateflow . . . .

122 124 125

7.1

Modeling and Simulation . . . . . . . . . . . . . . . . . . . . . . .

128

D.1 CD-ROM Structure . . . . . . . . . . . . . . . . . . . . . . . . . .

158

xvii

Listings 2.1

”Simple Event Example” . . . . . . . . . . . . . . . . . . . . . . .

15

3.1 3.2 3.3

”Equations(code) BaseController” . . . . . . . . . . . . . . . . . . ”Equations(code) PIcontinuousController” . . . . . . . . . . . . . ”Equation power on” . . . . . . . . . . . . . . . . . . . . . . . . .

58 58 59

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28 5.29 5.30 5.31

”Modelica class structure” . . . . . . . . . . . . . ”Simple State Definition ” . . . . . . . . . . . . . ”State Machine Defintiion ” . . . . . . . . . . . . ”ShallowHistory Record” . . . . . . . . . . . . . . ”Signal Record” . . . . . . . . . . . . . . . . . . . ”Simple State Machine” . . . . . . . . . . . . . . ”Change Event Statement” . . . . . . . . . . . . . ”Change Trigger” . . . . . . . . . . . . . . . . . . ”Signal Event Statement” . . . . . . . . . . . . . ”Signal Trigger” . . . . . . . . . . . . . . . . . . . ”Time Event Statements” . . . . . . . . . . . . . ”Time Trigger” . . . . . . . . . . . . . . . . . . . ”State Machine Initialization” . . . . . . . . . . . ”Local Time Behavior of States” . . . . . . . . . ”Set ShallowHistory to Most Recent Active State” ”Initial-Pseudostate Behavior” . . . . . . . . . . . ”Shallow History Pseudostate Behavior” . . . . . ”Simple Transition Behavior” . . . . . . . . . . . ”Junction Behavior” . . . . . . . . . . . . . . . . ”Choice Behavior” . . . . . . . . . . . . . . . . . ”Highlevel Transition Behavior” . . . . . . . . . . ”Interlevel Transition Activation Behavior” . . . . ”Interlevel Transition Deactivation Behavior” . . ”Fork Behavior” . . . . . . . . . . . . . . . . . . . ”Join Behavior” . . . . . . . . . . . . . . . . . . . ”EntryPoint Behavior” . . . . . . . . . . . . . . . ”ExitPoint Behavior” . . . . . . . . . . . . . . . . ”Sampled State Machine Behavior” . . . . . . . . ”Terminate Transition Behavior” . . . . . . . . . ”Terminate Behavior” . . . . . . . . . . . . . . . ”Hybrid Behavior” . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95 96 96 97 97 99 108 108 109 109 109 109 110 111 111 112 112 112 113 113 114 115 115 116 116 117 117 117 118 118 118

xix

Listings A.1 A ModelicaML package may only contain the following elements: Class ,Property, PrimitiveType, Enumeration, FunctionBehavior . 131 A.2 Classifier must have a name. . . . . . . . . . . . . . . . . . . . . . 131 A.3 UML Classifier, which is no Behavior, must have stereotype applied indicating that this is a ModelicaML restricted class (e.g. model, block, record, connector, etc.). . . . . . . . . . . . . . . . . . . . . 131 A.4 A ModelicaML class may only contain: Class, Enumeration, PrimitiveType, Property, Parameter, StateMachine, Activity, OpaqueBehavior, Port, FunctionBehavior, Comment, Connector, Constraint, Generalization, Dependency . . . . . . . . . . . . . . . . . . . . . 131 A.5 A UML Property of a ModelicaML classifier must have a stereotype applied which indicates that this is a ModelicaML Property (i.e. instance of a class). . . . . . . . . . . . . . . . . . . . . . . . . . . 132 A.6 A UML Generalization must have a ModelicaML stereotype indicating that this is a Modelica ”extends” or ”type extends” relation. 132 A.7 A ModelicaML model or class can only extend a model, block or record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 A.8 A ModelicaML block can only extend a block or record. . . . . . . 133 A.9 A ModelicaML connector can only extend a type, record or connector.133 A.10 A ModelicaML record can only extend a record. . . . . . . . . . . 133 A.11 A ModelicaML type can only extend a type. . . . . . . . . . . . . 133 A.12 A ModelicaML function can only extend a function. . . . . . . . . 133 A.13 A ModelicaML class may have only one redeclare relation. . . . . 134 A.14 A ModelicaML class may have only one partial derivative relation. 134 A.15 A ModelicaML class may have only one ”constrainedby” relation. 134 A.16 A ModelicaML function can only have a partial derivative relation to another function. . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.17 A Modelica components must have a type. . . . . . . . . . . . . . 134 A.18 A component of a ModelicaML block must have causality (input/output) defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.19 Ports must have ModelicaML stereotype . . . . . . . . . . . . . . 135 A.20 A UML connector must have a ModelicaML stereotype. . . . . . . 135 A.21 All UML connector ends must be set. . . . . . . . . . . . . . . . . 135 A.22 A ModelicaML connection can only connect ports. . . . . . . . . . 135 A.23 UML Behavior must have a stereotype applied which indicates that this is a part of the ModelicaML class behavior (i.e. equation or algorithm sections). . . . . . . . . . . . . . . . . . . . . . . . . . . 135 A.24 A Modelica package, record, connector or type cannot have behavior.135 A.25 Action: Only ’OpaqueAction’ and ’CallBehaviorAction’ are supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 A.26 ActivityEdge: Only ’ControlFlow’ is supported. . . . . . . . . . . 136 A.27 ControlNode: Only ’InitialNode’ and ’DecisionNode’ are supported. 136 A.28 A ModelicaML Activity must have exactly one initial node. . . . . 136

xx

Listings A.29 A ModelicaML Activity must have exactly one outgoing transition of an initial node. . . . . . . . . . . . . . . . . . . . . . . . . . . . A.30 A ModelicaML MergeNode must have exactly one outgoing ControlFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.31 A ModelicaML outgoing ControlFlow of MergeNodes is not allowed to have a guard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.32 A ModelicaML DecisionNode can only have one incoming ControlFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.33 DecisionNode must have stereotype ’If’ or ’When’ . . . . . . . . . A.34 Each Region must have exactly one initial or shallowHistory pseudostate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.35 The initial or shallowHistory pseudostate of each region must have exactly one outgoing transition. . . . . . . . . . . . . . . . . . . . A.36 The initial pseudostate or shallowHistory pseudostate of each region may not have a guard on its outgoing transition. . . . . . . . . . . A.37 The outgoing transition from the initial or shallowHistory pseudostate may not be an interlevel transition. . . . . . . . . . . . . . A.38 All transitions from an entryPoint must lead to the targets that are contained in the same region. . . . . . . . . . . . . . . . . . . . . A.39 ExitPoints can have one incoming transition at most. . . . . . . . A.40 EntryPoints cannot have incoming transitions. . . . . . . . . . . . A.41 ExitPoints cannot have outgoing transitions. . . . . . . . . . . . . A.42 Pseudostates of kind ’deepHistory’ are not supported. . . . . . . . A.43 A choice/junction Pseudostate must have incoming and outgoing transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.44 Transitions to forks must have state node as a source. . . . . . . . A.45 Transitions to forks may not be interlevel. . . . . . . . . . . . . . A.46 In a complete state machine, a fork pseudostate must have at least two outgoing transitions and exactly one incoming transition. . . A.47 Transitions from join-pseudostates must have State or FinalState as their target. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.48 Transitions from join-pseudostates may not be interlevel. . . . . . A.49 In a complete state machine, a join vertex must have at least two incoming transitions and exactly one outgoing transition. . . . . . A.50 Source and target must be set for a transition. . . . . . . . . . . . A.51 Transitions cannot cross region borders. . . . . . . . . . . . . . . . A.52 ConnectionPointReference may only reference one entryPoint/exitPoits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.53 ConnectionPoint referencing an entryPoint may not have outgoing transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.54 ConnectionPoint referencing an exitPoint may not have incoming transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.55 ConnectionPoint referencing an exitPoint must have an outgoing transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

136 137 137 137 137 137 138 138 138 138 138 139 139 139 139 139 139 139 140 140 140 140 140 140 140 140 141

xxi

Listings A.56 Final state may not have outgoing transitions. . . . . . . . . . . . A.57 Terminate state may not have outgoing transitions. . . . . . . . .

xxii

141 141

1 Introduction “All models are wrong; some models are useful.” George Box

Today’s technical systems such as aircrafts, spacecrafts, automobiles, or satellite systems are large and very complex. They can be designed virtually before any physical prototypes are built by using digital computers. The development of virtual models of complex systems requires a close collaboration between engineers from different disciplines. To describe the integration of mechanical and electronic components in consumer products the word mechatronics originated in Japan around 1970. Mechatronics has come to mean multidisciplinary systems engineering and is the synergistic integration of physical systems, electronics, controls, and computers through the design process [Cra09]. As all the elements of a technical system interact with each other, they cannot be engineered independently and then assembled to produce a working system. Instead, a tight integration in mechatronic design is the key element as complexity has been transferred from mechanical domain to the electronic and computer software domains. Mechatronics is the best practice for synthesis by engineers driven by the needs of industry and human beings [Cra09]. The design of mechatronic systems under the requirements of a tight integration between the different disciplines and their engineers lead to an overall objectoriented, component- and model-based design approach. Such modeling and simulation languages for mechatronic system have been introduced some years ago [HPI99, MEB97, CBIB99]. A modeling language for system engineering should make it possible to model system structure and its components, to model system requirements, and to model system behavior.

Further, a formal mathematical representation is important for the simulation of virtual prototypes. Physical parts of a system are described typically as continuoustime models through differential algebraic equations (DAEs). Differential algebraic equations which have discontinuities or may have variable structures or may change at certain points in time are called hybrid DAEs. The changes of physical system parts and the control logic can be evaluated simultaneously as a whole system. Modelica is a modeling language which can be used to model and simulate hybrid systems.

1

1. Introduction

1.1 Motivation Modelica uses the hybrid DAE formalism as mathematical representation. It is an object-oriented, declarative, multi-domain modeling language for describing and simulating hybrid models. Such models can represent physical behavior, the exchange of energy, signals or other continuous-time interactions between system components as well as reactive, time-discrete behavior. Modelica consists of compositions of sub-models connected by ports that represent interaction points for energy flow (undirected) or signal flow (directed). The models are equation-based, declarative, and have not necessarily predefined causality. Furthermore, mature compilation and simulation environments for Modelica exist. Modelica is defined as a textual language and has only one graphical diagram, the connection diagram. The connection diagram can handle domain specific libraries and has a specific icon for each element. However, Modelica does not have a standardised graphical notation and there is also no standardised policy to specify and include system requirements. In contrast, UML/SysML provides the modeler with standardised graphical notation that enables different views on the system definition. For example, UML 2 has six structure diagrams and seven behavior diagrams. SysML defines another two diagram types with well defined visual formalisms, the requirement and parametric diagrams respectively. However, the UML has no formal standardised operational semantics. The MECHATRONIC UML [GBSO04, BGT04, BGH+ 07] as a refinement of the UML, has formal defined syntax and semantics. It targets the structural and behavioral specification of hybrid embedded software. However, MECHATRONIC UML cannot be used to specify physical parts of mechatronic systems. Integration of UML-based languages and Modelica simulation capabilities into one language, enables integrated modeling and simulation of system requirements and design. It closes the gap between documentation and programming language, as the models are a graphical and executable specification of the problem space. Further advantages are a higher level of abstraction than pure Modelica and an easy exchange and reuse of knowledge by using the industry standard UML. It facilitates creation of executable system-specification and -analysis models that can simulate both the time-discrete and the time-continuous behavior of a system [Sch09]. ModelicaML [Sch09] is an approach that attempts the specification of the structure and the behavior of systems based on a subset of the OMG Unified Modeling Language and reuses concepts from the OMG Systems Modeling Language. It is defined as a profile to the UML using UML’s profile mechanism [Hus06, BH08]. ModelicaML supports the Modelica language constructs for the specification of continuous behavior and it reuses e.g. UML state machines or activity diagrams for behavior specification. The ModelicaML profile, a prototype of the Modelica code generator and a ModelicaML example model are available on the OpenMod-

2

1.2 Objectives elica Project site1 . However, the concrete syntax and the operational semantics of the ModelicaML is not defined in a sound formal way yet. A formal basis of the language (including concrete syntax and semantics) is required in order to fully specify the structure and behavior of complex technical systems and to simulate them. The specification of the ModelicaML syntax and the ModelicaML state machine semantics are objectives of this thesis.

1.1.1 Example of Application An example for a hybrid mechatronic system is a two tank system as shown in figure 1.1. A requirement for the system is that the liquid level in the tanks must levelSensor

source maxLevel level

tank

valve

tank

pipe valveActor

controller

controller

Figure 1.1: Two Tank System (cf. [Fri04, p. 391])

be kept closely at a fixed level. From the source liquid flows through a pipe into the left tank. Every tank has a sensor which measures the current level of liquid in the tank. Each tank has one controller. The controller gets the current value of the level in its tank. The controller can regulate the level of liquid by adjusting the valve of the discharge unit. The liquid flows from the left tank through a pipe into the right tank.

1.2 Objectives The objective of this master thesis is to show an approach to model mechatronic systems with UML/ModelicaML in order to transform these models into Modelica code and to simulate them by a Modelica simulation environment. Therefore, the ModelicaML profile is revised. This includes the specification of a language definition based on the requirements for modeling the two tank systems. The language definition consists of a description of all model elements to be used by system engineers. Parts of this are the definition of the concrete graphical syntax/notation 1

http://www.openmodelica.org/index.php/developer/tools/134

3

1. Introduction for the model elements and the formalisation of modeling constraints implied by the target language Modelica. Further, an aim is the definition of the execution semantics for state machines used in ModelicaML. The objective is to show a transition from this execution semantics to Modelica code. The translation will be performed by Acceleo[Acc09], an appropriate model-to-text template based approach [OMG08] approach. As a proof-of-concept a prototypical implementation in an appropriate eclipse-based open source UML 2 tool will be implemented. This prototype will support the specification of mechatronic models with ModelicaML, the validation of in this thesis defined constraints and the generation of Modelica code for simulation purposes. It will be possible to simulate the resulting Modelica code with Dymola from Dassault Systèmes AB, or MathModelica System Designer from MathCore.

1.3 Structure of this Thesis This thesis is structured into seven chapters. After this introduction follows chapter 2 which describes the fundamentals on which this thesis is based on. Accordingly, chapter 3 describes a methodology and language definition for modeling mechatronic systems based on UML and ModelicaML. Afterwards, chapter 4 discusses and describes state machine semantics for state machines used in ModelicaML. In chapter 5 the implementation of the prototype of a modeling environment and the Modelica code generation of state machines with the previous defined semantics is described. Chapter 6 gives an overview of related work. The last chapter, chapter 7 gives a summary of this thesis and an outlook on possible future work.

4

2 Fundamentals “Every large system that works started as a small system that worked.” Anonymous

This chapter addresses the fundamentals which this thesis is based on. Firstly, modeling and simulation is described. Secondly, Modelica, an object-oriented language for modeling of complex systems, is presented. Thirdly, UML is introduced. Fourthly, the UML profile ModelicaML [Sch09] is introduced. Fifthly, the object-constraint-language (OCL) is described. In the last section of this chapter, transformation approaches for model-to-model and model-to-text transformations are discussed.

2.1 Modeling and Simulation This section addresses the issue of modeling and simulation of mechatronic systems. It is mainly based on the books “Principles of Object-Oriented Modeling and Simulation with Modelica”[Fri04] and “Engineering Complex Systems with Models and Objects” [OKK97].

2.1.1 Systems and Experiments What is a system? As mentioned in the introduction, systems are for example aircrafts, spacecrafts, automobiles, or satellite systems. A system can be almost anything. A possible definition of a system is: “A system is a complex unity formed of many often diverse parts subject to a common plan or serving a common purpose.” [Gov81]. From the engineering point of view it is important to know the properties of a system in order to understand and build it. From the point of view of natural science one has to study a system to understand more about nature. The properties of a system can be studied by experiments. “An experiment is the process of extracting data from a system by exerting it through its inputs.”[CEO96]. While performing an experiment some problems may occur.

5

2. Fundamentals 1. A system might not be controllable. 2. A system might not be observable. 3. The experiment might be too dangerous. 4. The experiment might be too expensive. The drawbacks of experiments lead to the model concept. If a model of a system exists, this model can be investigated and may answer many questions regarding the real system.

2.1.2 Modeling Modeling is known as the process of building a model of a system. This process consists of the following steps: Identification of the system boundary. Decomposition of the system into sub-systems and their relations. Identification of behavior.

Models will represent a real system. It is not required that a model can be exactly mapped on a real system. A model may only represent a part or an abstraction of a real system. “A model of a system is anything an “experiment” can be applied to in order to answer questions about that system.” [Fri04, p. 6]. A model can describe a system in different ways. [Fri04, p. 6]. 1. Mental Model: A statement like “a system is secure or reliable” 2. Physical Model: A physical mock-up which mimics the real system. 3. Verbal Model: A natural language description of a real system. 4. Mathematical model: The behavior of a system is expressed in mathematical form. Artifacts represented by mathematical models in a computer are often called virtual prototypes. Actually, one of the main purpose of models is to perform experiments on models.

6

2.1 Modeling and Simulation

2.1.3 Simulation “A simulation is an experiment performed on a model.” [KW78]. The advantage of a simulation is that the time scale can be varied. It is possible to simulate just a few seconds up to millions of years. Modeling and simulation aim at managing the complexity of mechatronic systems. Mechatronic systems are too complex to be understood and built without any prototypes. The simulation of these systems and their behavior helps to assess the safety and to measure the performance of complex systems. Further, the systems can be optimized before they are constructed. Virtual prototypes, i.e. a model of a system, enables engineers to analyze what-if scenarios. A complex system may consist of a collection of objects, which build the system parts. The properties of these systems are the parts an engineer wants to study to understand the interaction of different system parts. Therefore, it is possible to understand the whole system behavior in a bottom up process. Simulations are processed over a specific simulation time. It is possible to study the behavior of objects of a system. A dynamical system can be considered to be a model describing the temporal evolution of a system. The term dynamic system is originated from the mathematician Birkhoff [Bir27]. Time is either directly addressed as a variable in the model or indirectly through the time derivative of a variable. It is not always required to model all variables as time dependence variables. It may be useful to make an approximation and define some parts or even the whole model static. Static models can be defined without involving time and are used to describe system structure. Continuous models evolve their variables continuously over time. For example, physical processes and many laws of nature follow such patterns. Such processes can be formulated as differential equations with time derivatives of some model variables. Discrete models change their values only at certain points in time. The state of the model depends on the last input and the last state of the model. They map the state of the model at one point in time to the state at the next point in time. The behavior of such systems can be modeled as a finite state machine [Gil62]. Figure 2.1 shows the continuous model A, which represent a differential equation with time derivatives of some model variables. Further, it shows a discrete model B which changes values only at certain points in time. Model A and model B are independent from each other. Systems which have both, continuous and discrete dynamic behavior, that interact with each other are called hybrid systems.

2.1.4 Validation Simulation helps to test if a system satisfies a certain criterion. The drawback of simulation is that it cannot prove the absence of failures. It can only find failures.

7

2. Fundamentals

Figure 2.1: Continuously vs. Discrete Dynamic Models [Fri04, p.13]

Validation of system properties can also be done in other ways than simulations. Analytical techniques like verification [Hir08] are better than simulations, but they can often only be applied under a set of simplifying assumptions, which cannot always be justified. Therefore, it is possible to combine simulations and analytic approaches to reach a system of high quality [GP06].

2.2 Modelica This section gives an overview over the concepts and some essential language constructs of Modelica, which are important for this thesis. For a detailed description of Modelica please refer to the Modelica book of Peter Fritzson [Fri04] and the Modelica language specification [Mod10]. Modelica is a free object oriented modeling and simulation language and has been developed and is being developed by the non-profit Modelica Association (http://www.modelica.org/association) since 1996. The current milestone of Modelica is version 3.2. It was released in 2010. The Modelica association has about 80 individual and twelve organizational members. Besides the specification the association publishes a free Modelica Library, a free simulation environment (Open Modelica) and about 300 papers about Modelica. They can be found under www.modelica.org. Modelica targets not only mechatronic systems. It is suitable for multi-domain modeling involving but not limited to, mechanical, electrical, hydraulic and control systems, process oriented applications and system dynamics. In Modelica it is possible to model systems acausal. Therefore, it is possible to build systems in a similar way as an engineer builds a real system. The model behavior is based on ordinary and differential algebraic equation (ODE and DAE) systems combined with discrete events, so called hybrid DAEs. Such models are ideally suited for representing physical behavior and the exchange of energy, signals, or other continuous-time or discrete-time interactions between

8

2.2 Modelica system components. Modelica models are object-oriented. Modelica models consist of compositions of sub-models connected by connections that represent energy flow (undirected) or signal flow (directed). The object-orientation concept is different to other programming languages like Simula, C++, Java or Smalltalk. In these languages the number of objects often changes dynamically. The Modelica view on object-orientation is different. Modelica focuses on structured mathematical modeling. Object-orientation is just used as a static structuring concept to handle the complexity of large system descriptions. It is for example not possible to invoke class methods. Modelica is inspired by mathematics and uses the concept of declarative programming by using equations. The declarative Modelica view of object-orientation, from the point of view of object-oriented mathematical modeling is summarized in the book [Fri04, p.25] as follows: Object-orientation is primarily used as a structuring concept, emphasizing the declarative structure and reuse of mathematical models. Our three ways of structuring are hierarchies, componentconnections, and inheritance. Dynamic model properties are expressed in a declarative way through equations. An object is a collection of instance variables and equations that share a set of data.

However, it is also possible to write sequential algorithmic code in Modelica. Equation- and algorithm-sections are introduced in section 2.2.9 of this chapter. Before Modelica code can be simulated it is compiled to some intermediate code, usually C code. This in turn will be compiled to machine code and executed together with a numerical ordinary differential equation (ODE) solver or differential algebraic equation (DAE) solver to produce a solution for variables as a function of time.

2.2.1 Types of Equations This section addresses the different types of equations used in mathematical models. The mathematical description of Modelica is represented by hybrid DAEs. This section is based on [Fri04, p.399]. For a more detailed description also refer to [Fri04, p.399]. Ordinary Differential Equations: Mathematical models of continuous dynamic systems consist of ODEs because the time dependency in those models is shown by the presence of time derivatives of state variables. Algebraic Equations: Relations between variables not involving derivatives of any variables.

9

2. Fundamentals Differential Algebraic Equations: A system of a DAE, include both ordinary differential and algebraic equations. Difference equations: Occur in discrete-time models and typically relate values of quantities to different discrete points in time, e.g. between the times tk and tk+1 . Conditional equations: Include equations that become active only at certain points in time, or during certain time periods. This kind of equation is used to define the notion of events. Hybrid DAEs: DAEs which also may include some conditional equations. The hybrid DAE equation form is the basic equation representation behind Modelica.

A concrete representation of Modelica as hybrid DAE is described in [Mod10, p.225 Appendix C].

2.2.2 Restricted/Enhanced Classes In Modelica almost everything is a class. Therefore, it is important for the modeler to develop a well structured class concept. Special restricted classes help the modeler to make the code easier to read and maintain it. Restricted classes differ between connector, record, block, model and type. They can be used instead of simple Modelica classes and have special constraints. A record, for example, has no behavior of its own and a block is a class with fixed causality input or output of all its interfaces. Besides restricted classes Modelica has a concept of enhanced classes. Package and function classes carry additional special semantics of their own. The package and function concepts in Modelica and the class concept have much in common but are not really restricted classes since these concepts carry additional special semantics of their own. Section [Fri04, p.81, section 3.8] gives a more detailed description and typical usage examples of the Modelica class concept. Further, in Modelica restrictions exist based on the kind of super class when one class inherits from another. Which kind of super class is allowed is shown in figure 2.2.

2.2.3 Variability of Variables In Modelica a variable can have the time-variability prefix continuous, discrete, parameter, or constant. The prefix defines when the value of a variable may change or if it is kept constant. Figure 2.3 shows the different kinds of variability. Constants and parameter have the same semantics during running simulations. The difference is that constants never change value once they have been defined. Parameters can be changed when a simulation is paused. The simulation can be

10

2.2 Modelica

Figure 2.2: Restrictions on the Kind of Super Class (source [Mod10, p.67])

restarted with a new parameter value. The time derivative of parameters is always equal to zero.

Figure 2.3: Variability of Variables (source [Fri04, p.90])

2.2.4 Components Modelica uses a component model which is similar to the UML component model. It is possible to reuse components. Components are instances of Modelica classes which are modular and encapsulated. Modelica provides a connection mechanism. Therefore, it is possible to connect components with each other. A component framework in Modelica ensures that communication between components works over connections. Each component requires a well-defined interface for communication. The interface consists of ports. In Modelica ports are called connectors. They enable a component to be independent of its environment and the modeler,

11

2. Fundamentals to realize a modular design concept. In modular design each component is independent. All expressions of a model can only use local variables and connector variables. Communication with other model elements is only allowed via a connector. Further, a component may internally consist of other connected components. This makes it possible to model hierarchically.

2.2.5 Ports/Connectors Ports/Connectors are instances of restricted connector classes. A connector class may have variables which take part in the communication between connectors. It builds the interface of a component defined by the connectors of that component.

2.2.6 Connections Explicit connections between a pair of ports/connectors can be modeled by connect equations as follows: connect ( connector1 , connector2 )

Connections are only valid between ports of the same type. Two ports have the same type when the following condition from [Fri04, p.148] holds: “The names must be identical and corresponding types of declared variable members in the classes of the connected connectors must be equivalent, but the ordering between the member declarations in the connector classes need not be the same.” Besides explicit connections implicit connections exists [Fri04, p.148]. These are not required for this thesis and are out of scope. Connection always means explicit connection in this thesis.

2.2.7 Connection Diagram Modelica offers a visual representation of components and connections. This will help to grasp the structure of a complex system. It is quite similar to the UML composite diagram. A schema of the connection diagram is shown in figure 2.4, a concrete multidomain connection diagram is shown in figure 2.5.

2.2.8 Synchronous Data Flow Principle and Single Assignment Modelica is based on the synchronous data flow principle and the single assignment rule. The synchronous data flow principle and the single assignment rule is essential for each model. It is defined in the Modelica specification in the following way:

12

2.2 Modelica

Figure 2.4: Connection Diagram Schema (source [Fri04, p.146])

Figure 2.5: Multidomain Connection Diagram of DCMotorCircuit model with mechanical, electrical, and signal block components. (source [Fri04, p.162])

“ All variables keep their actual values until these values are explicitly changed. Variable values can be accessed at any time instant during continuous integration and at event instants. At every time instant, during continuous integration and at event instants, the active equations express relations between variables which have to be fulfilled concurrently (equations are not active if the corresponding if-branch, when-clause or block in which the equation is present is not active). Computation and communication at an event instant does not take time. [If computation or communication time has to be simulated, this property has to be explicitly modeled]. The total number of equations is identical to the total number of unknown variables (= single assignment rule). ” [Mod10, p. 86].

“The rules for the synchronous data flow principle guarantee that vari-

13

2. Fundamentals ables are always defined by a unique set of equations. It is not possible that a variable is e.g. defined by two equations, which would give rise to conflicts or non-deterministic behavior. Furthermore, the continuous and the discrete parts of a model are always automatically “synchronized”.” [Mod10, p. 87]. “The single assignment rule . . . allow[s] a certain degree of model verification already at compile time.” [Mod10, p. 87]. The single assignment rule does not guarantee that the equations are well defined and can always be solved during executing the simulation. The single assignment rule is a necessary condition for execution of the simulation. It is not a sufficient condition.

2.2.9 Equations vs. Algorithm Sections Equations Equations represent relations between expressions in a declarative way. It is not required to handle the control- or data flow as in conventional procedural languages. Equations are used for different tasks in Modelica. It is possible to declare the value of variables, parameters or constants. Further, they are used to modify commonly used attributes of classes or specify initialisation problems. Equations allow to program in a more abstract way than with procedural statements. For example Ohm’s law which states that the resistance R multiplied by the current i is equal to the voltage V can be expressed by the equation R ∗i = V . To express this by statements one of the following three different statements have to be used: i := V /R, V := R ∗i and R := V /i, depending on the known variables. Simple Equality Equations Simple equality equations are used to model equations from mathematics which express equality relations between the left-hand expression and the right-hand expression of a ’=’. expression1 = expression2 Declaration Equations Declaration Equations are used to set the value of variables with constant or parameter variability . Declaration Equations are required for constants. parameter ModelicaReal tank height = 1 constant ModelicaReal pi = u/d Modification Equations Modification Equations are used when there is a need to modify the default value of a variable. A modification equation replaces the declaration equation. continuous h(start = 0.0, unit = “m”)

14

2.2 Modelica Algorithms In contrast to declarative equations algorithms are processed sequentially as sequences of instructions. These instructions are called statements. Algorithmic statements are in Modelica only allowed in algorithm sections. An algorithm section starts with the keyword algorithm. Externally it is treated as a group of equations involving one or more variables. Within the same algorithm section multiple assignments to the same variable are allowed. They are counted as a single assignment and transgress not the single assignment rule (see section 2.2.8). At the end of an event iteration a variable has the value of the last assignment. Algorithmic assignments are denoted through the operator ’:=’. The operator is different to the operator ’=’ which is used in equation sections and the equality operator ’==’ used for comparisons in Boolean expressions. In statements the right-hand side is assigned to the left-hand side of the operator ’:=’. As Modelica is strongly typed [EMO98], the type of the right-hand side must be a subtype of the left-hand side.

2.2.10 Notion of Events Events occur whenever a Real elementary relation, e.g. “x > 3”, changes its value. Therefore, the integration is halted. The value of such relations can be changed in Modelica only at event instants. The relation, which triggered an event, changes its value when evaluated literally before the model is processed at the event instant. Modelica simulators have a root finding mechanism which determines a small time interval in which the relation changes its value. The event occurs at the right side of this interval. Events represent changes of variable status that are involved in expressions and can enforce event iterations. During continuous integration a Real elementary relation has the constant value of the relation from the last event instant. Listing 2.1 shows an example for an event which occurs when the level of liquid in a tank becomes greater than or equal to the height of the tank. This event causes a halt of the integration and as an effect the variable overflow is set. A complexer example is described in section 5.2.5. Listing 2.1: ”Simple Event Example” within T w o T a n k s S y s t e m E x a m p l e . R e q u i r e m e n t s model TankOverflow Real parameter tank_height ; Real input level ; Boolean overflow ; equation if level >= tank_height then overflow : = true ; else overflow : = false ;

15

2. Fundamentals end if ; end TankOverflow ;

2.2.11 Integration and Event Iteration Event iteration means re-evaluation/execution of an equation or algorithm system after events have occurred. The re-evaluation is performed until for all variables “pre(v) == v” is true, i.e. no change of variable value is caused by reaction to the last events. Event iterations do not consume any simulated time.

2.2.12 Conditional Expressions Conditional expressions provide a single expression that computes one out of two expressions dependent on the value of the condition. Conditional expressions may be used to describe hybrid behavior. The syntax is: ( if | when ) condition then expression1 [ else ( if | when ) condition [ else expression3 ] end if ;

expression2 ]

Modelica provides two kinds of constructs (if/when) for expressing hybrid behavior. If is used to describe discontinuous and conditional models, for example an equation which is only valid if a discrete state is active. When is used to express equations that are valid only at discontinuities, for example when an event is raised. When-equations contain only variables with discrete-time variability. The single assignment rule forces each conditional-equation to have both, the then-part and the else-part of the conditional expression. Conditional expressions can be nested with some restriction. A when-expression is not allowed within an if-expression.

2.2.13 Simulation Environments To simulate Modelica a couple of compiler and simulation environments exist. The best known are Dymola, MathModelica, SimulationX, MOSILAB, OpenModelica, and SCICOS. Some of them are described in chapter 6 as they make up a part of the related work.

2.3 UML This section addresses the Unified Modeling Language (UML). Today, the UML is the standard modeling language for devolving software. It is independent of any programming language.

16

2.3 UML “The UML is the standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system.” [Qua01]. UML notion set is a language without any methodology. Therefore, it is very flexible and can fit into different development processes and methodologies without any changes. The UML provides a wide range of different diagrams. The usage of several types of diagrams with a given methodology increases the ease of understanding an application under development. From a historic point of view UML is not one notion. It consist of a synthesis of several notions by Grady Booch (Object-oriented Analysis & Design (OOAD)) [Boo86, Boo93], Jim Rumbaugh (Object Modeling Technique (OMT))[RBL+ 90], Ivar Jacobson (Object-oriented Software Engineering method (OOSE)[Jac92]), and many others. Jim Rumbaugh OMT methodology was strong in analysis but not good in design. The Booch methodology was strong in design but not good for analysis. Ivar Jacobson’s Objectory took the user experience into account. In 1993 all of them published articles and books which combined their approaches. In 1996 Rumbaugh, Booch and Jacobson published the unified modeling language [BRJ96] together. In 1997 they submitted the UML to the Object Management Group (OMG) as standardization. The UML contains, additionally as an important part, the state charts from Harel [Har87]. Figure 2.6 shows an extensive history of object-oriented methods and notions of the UML-environment. UML 2 distinguishes between two kinds of diagram categories, structure diagrams and behavior diagrams. Each diagram belongs to one category. Structure diagrams show the static structure of a system and behavior diagrams show the dynamic behavior between the objects of a system. This master thesis focuses especially on state machine diagrams. Thus, concrete specification of state machine [UML09, p.525] is presented in more detail in section 2.3.2. Further, class diagrams, composite structure diagrams and activity diagrams are addressed. Class and composite diagrams are used to model the structure and properties of a system and activity diagrams are used to model procedural processes and conditional/hybrid behavior. In addition, some common UML elements like OpaqueBehavior or different types of UML events are introduced.

2.3.1 Structure Structure diagrams show the elements of a system as a static structure. The structure is irrespective of time. Structure diagrams show the types and their instances in the system. Structure diagrams may also show the composite of a system. UML offers no diagram which is called structure diagram. The class diagram is the central diagram to model and show the types and instances of system parts and it offers elements to model inheritance. Further, it has elements to model aggregations, associations, compositions, and dependencies, which are out of scope of this thesis. The following paragraphs give an overview of the basic

17

2. Fundamentals

Figure 2.6: History of Object-oriented Methods and Notations (from Axel Scheithauer, OOSE)

structure elements of UML. Class “A class describes a set of objects that share the same specifications of features, constraints, and semantics.” [UML09, p.49]. A class specifies a classification of objects with same structural attributes and behavior. Attributes are associated by instances of Property that are owned by a class. Instances of a class must contain values for each attribute that is a member of that class, in accordance with the characteristics of the attribute. Property “A property represents a set of instances that are owned by a containing classifier instance.” [UML09, p.184]. A property is either an instance of a data type or an instance of another class. When an instance of a class exists a set of instances corresponding to the class properties exists as well. These instances are instances of the class typing the property.

18

2.3 UML Data type A data type is a type which instances are identified only by their value. A typical use of data types is the presentation of programming languages’ primitive types. For example, Integer, Real and String types are often treated as data types. Further, a data type can be an enumeration. Enumeration An enumeration data type consists of user-defined enumeration literals which values are enumerated in the model. Class Diagram The main element of a class diagram is a class. A class is shown as a classifier symbol [UML09, p.51] with three compartments. The upper compartment shows the class name, the middle compartment holds a list of attributes, and the bottom compartment holds a list of operations. Not all compartments have to be shown and a class can have additional compartments, for example for the containing behavior of a class. There are some additional style guides for the presentation of classes which can be found at [UML09, p.51]. Figure 2.7 shows different examples of class notions within a class diagram.

Figure 2.7: Class Notation (source [UML09, p.51])

Component A component is a modular part of a system that encapsulates its contents from its environment. A complex system may be assembled by reusing components as parts in an hierarchical encompassing component or assembly of components. A class is a generalization of a component. A component can be represented as a structured class.

19

2. Fundamentals StructuredClasses A structured class is a class that has ports and an internal structure. It is defined in UML specification at [UML09, p.166] and can be modeled within a composite diagram. Internal Structures The internal structure of a class is represented by the InternalStructure-subpackage [UML09, p.186]. It provides mechanisms for specifying structures of interconnected elements that are created within an instance of a containing class. A structure of this type represents a decomposition of that class and is referred to as its “internal structure”. Interface Class Interface classes declare variables that are part of the communication interface of a component. Port A Port is an instance of an interface class which “provides mechanisms for isolating a classifier from its environment” [UML09, p. 161]. They provide a point of conducting interactions between the internals of its owner classifier and its environment. A class can contain multiple ports. This enables to distinguish between interactions “based on the port through which they occur ” [UML09, p. 161]. Ports are used to make a class encapsulated from its environment. The class can be specified independently and “is reusable in any environment that conforms to the interaction constraints imposed by its ports” [UML09]. Ports can be connected through connectors. Connector A connector is a link between two ports. It enables the connected classes to share information with each other or communicate via the link. Composite structure diagram A composite structure diagram shows the internal structure of a classifier. A property of a class is displayed as a part. The ports of these properties are displayed as rectangles. When two ports are linked through a connector this is displayed as a line. Figure 2.8 shows a composite structure diagram. Source, tank1, tank2, piContinuous1, piContinuous2 are parts of the class TanksConnectedPI.

2.3.2 Behavior Behavior in UML can be modeled in different ways. In this thesis activity, state machine and opaque behavior are used (see figure 2.9). Activities are modeled graphically as activity diagrams. An activity diagram shows the overall flow of control as a step-by-step procedure. State Machines are an object-based variant of Harel statechart [Har87]. They use hierarchically nested states and orthogonal regions, and can invoke actions depending on a state, trigger or guard. State machine diagrams represent the elements of a state machine. Not

20

2.3 UML

Figure 2.8: Connected Composite Structure of Two Tank System with Ports

Figure 2.9: MetaModel of UML Behavior (cf. [UML09])

every behavior in UML has a graphical notion. For example, OpaqueBehavior is specified textually as a surface action language. The language can be any language with well defined semantics. Activity UML specifies activities as follows: “An activity specifies the coordination of executions of subordinate behaviors, using a control and data flow model.” [UML09, p. 316]. In this master thesis only the control flow is used. Data flow is out of scope. An activity may be initiated by other behaviors of the model. The flow of execution is modeled as activity nodes connected by control flow. An activity may also loop. An activity node may be either a ControlNode or an OpaqueAction. A ControlNode is a FinalNode, ForkNode, JoinNode, MergeNode, or a DecisionNode. An OpaqueAction represents a single step within an activity. It is not further decomposed within the activity. An OpaqueAction has, like an OpaqueBehavior, a body which is specified as a language with well defined semantics. The semantics of activities is defined by taking and offering of tokens. The execution algorithm is defined in the UML specification in the following way:

21

2. Fundamentals “The action begins execution by taking tokens from its incoming control edges and input pins. When the execution of an action is complete, it offers tokens in its outgoing control edges and output pins, where they are accessible to other actions. . . . ” [UML09, p. 312, p. 318]. Activity Diagram An activity can be visualized as an activity diagram. An activity can also be presented textually. Figure 2.10 shows the notion of activity nodes.

Figure 2.10: Notion of Activity Nodes (source [UML09, p. 335])

State Machine A state machine[Har87, HN96, HK04] is an extended automaton with high-levelconstructs. Many variants of finite state machine exists. A comparison of some state machine variants is described in [Bee94]. UML standardization of state machines is defined [UML09, p.525]. The semantics of state machines is discussed in section 4.1. A formal semantics of UML state machines can be found in [Boe]. UML definition of state machines is summarized in the following paragraph. This definition builds the foundation of state machine in this thesis. UML defines two types of state machines. Behavior state machines and protocol state machines. Behavior state machines are used to model parts of class behavior. Protocol state machines are limited in terms of expressiveness and are tailored to the need of expressing protocols or defining a life-cycle of objects. Since that is not the main intended area of this thesis the protocol state machines are not taken into account. The following elements from UML are discussed in this thesis in the context of state machines. The number in the brackets is the section number in the UML specification [UML09]: ConnectionPointReference (15.3.1); FinalState (15.3.2); Pseudostate (15.3.8); PseudostateKind (15.3.9): initial, deepHistory, shallowHistory, join, fork, junction, choice, entryPoint, exitPoint, terminate; Region (15.3.10 ); State , Simple-, Composite, Submachine-, Orthogonal-State (15.3.11); StateMachine (15.3.1); TimeEvent (15.3.13); Transition (15.3.14); TransitionKind (15.3.15); Vertex (15.3.16); ChangeEvent (13.3.7); SignalEvent (13.3.25); TimeEvent (13.3.27); TimeExpression (13.3.28); Trigger (13.3.31).

22

2.3 UML Informal Description of UML 2 State Machines State machines mainly consist of states and transitions between states. States can contain regions which are called subregions. A state without regions is called simple state, whereas a state with regions is called composite state. If a state has more than one subregion it is also called orthogonal state. Each (sub-)region must contain at least one state, called substate, and an initial or history pseudostate. A state can contain the insertion of the specification of a submachine state machine instead of regions. Then the state is called submachine state. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. The hierarchy of states and regions builds a tree structure. A configuration of a state machine describes all active states at a point in time. If a state is not active no substate of its subregions is allowed to be active. If a state is active exactly one direct substate of all direct subregions must be active. A state is entered and activated when an incoming transition fires and a state is exited and deactivated when an outgoing transition fires. A state can have an entry-action, which is executed when the state is entered, an exit-action, which is executed when a state is exited and do-actions which are executed as long as a state is active. The execution and semantics of state machines are discussed in section 4.1.2. In this section the different types of events are addressed as well. A transition has references to its source, a target, a trigger (optional), a Boolean expression guard (optional), and has an effect (optional) which may start an action. The source and target of a transition may be the same. This is called self transition. A transition which crosses multiple hierarchies is called interlevel transition. A transition which source is a composite state is called highlevel transition. Transitions which are connected by pseudostates are called compound transitions. A transition is enabled when the Boolean guard expression is true and if the transition has a trigger and the related event occurs. If more than one transition is enabled the transitions are in conflict with each other. It is only allowed that one transition of transitions which are in conflict with each other fires. When transitions are in conflict and which transition fires is discussed in sections 4.1.6 and 4.1.7. The firing of an interlevel transition t leads, in this order, to (i) exiting the source state and the corresponding states together with the execution of their exit-actions, (ii) the execution of the effect of t, and (iii) entering the corresponding and target states together with the execution of their entry-actions. UML calls states which do not represent a state of a system, but rather are part of connected transitions, pseudostates. The semantics of a pseudostate are defined by its kind. UML defines the PseudostateKinds initial, deepHistory, shallowHistory, join, fork, junction, choice, entryPoint, exitPoint, and terminate. Initial has one outgoing transition which points to default state which is activated when its superstate becomes active. DeepHistory activates the most recent configuration of the composite state it is contained in. ShallowHistory activates the most recent

23

2. Fundamentals substate of the composite state it is contained in. In case history was not active before, the outgoing transition fires. Join-, fork -pseudostates are used to collect different transitions into a compound transition having a set of sources and a set of targets. Junctions are used to bundle several incoming transitions into one transition or to make a static choice of the target. Therefore, during run-time a decision of the state, which will be activated, is taken based on the different guards of the outgoing transitions of junction. Their guards must be mutually exclusive. All effects of the transitions combined are executed after the guards have been evaluated. A choice-pseudostate is similar to a junction besides that each transition effect is directly executed after its guard has been evaluated. A choice makes a dynamic decision. Entry-, exit-Points are used to enter/exit submachines. Terminate ends up the whole state machine. ConnectionPointReference belongs to submachine states and refer to entry/exit points of the containing submachine. A connectionPointReference can be used to enter/exit a submachine state. For a more formal explanation of state machines refer to [UML09, p.525]. The metamodel of UML state machine is presented in the next paragraph. Metamodel of UML state machines Figure 2.11 shows the meta model of UML state machines. State Machine Diagram State machine can typically draw within a state machine diagram. For example, figure 2.12 shows a UML 2 state machine diagram.

2.3.3 Customizing UML UML has the feature to be extended or tailored for a specific domain. Customization allows to use existing modeling tools. It is also possible to re-use existing models and adapt them by making small changes. As the superstructure specification points out, there are several reasons to customize the UML: “Give a terminology that is adapted to a particular platform or domain.” “Give a syntax for constructs that do not have a notation.” “Give a different notation for already existing symbols.” “Add semantics that is left unspecified in the metamodel.” “Add semantics that does not exist in the metamodel.” “Add constraints that restrict the way you may use the metamodel and its constructs.” “Add information that can be used when transforming a model to another model or code.”

[UML09, p.654].

24

2.3 UML

Figure 2.11: State Machine Metamodel cf. [UML09, p.527]

It is possible to customize the UML in different ways. It depends on the nature of domains and how the customized model will be used. Firstly, new properties or constraints can be added by the UML profile. The UML specification defines this possibility in [UML09, p. 653]. UML profiles allow to add new constraints that are specific to the profile. It is not possible to take away any of the constraints that apply to a metamodel or change the reference metamodel. It is forbidden to insert new metaclasses to the UML metaclass hierarchy or to modify the standard UML metaclass definitions. A profile specializes the semantics of standard UML metamodel elements. Notational convention for graphical stereotype definitions as part of a profile can be provided. It is possible to add or retract a profile to/from an existing model dynamically and to combine several profiles.

25

2. Fundamentals

Figure 2.12: UML 2 State Machine (source [Boe])

Secondly, if the behavior, restrictions on certain collections, complex features, or, elements will be added or altered, a heavy weight extension of UML is required. This can be handled through MOF[MOF06], where no restrictions about changes of a metamodel exists. It is possible to add and remove metaclasses and relationships as required. MOF makes it possible to design such a domain specific language (DSL). MOF is the metamodel of the UML and therefore it is a meta-metamodel. However, the cost of designing, implementing, and maintaining an own language is higher than the development of a UML profile. In this master thesis no change of the UML metamodel is required and therefore the UML lightweight extension is sufficient.

2.4 ModelicaML ModelicaML is a UML profile which extends the UML with concepts of Modelica and enables the modeler to specify advanced constructs like requirements for Modelica. The Motivation of ModelicaML is to integrate Modelica and UML. UML’s strength in graphical and descriptive high-level modeling is combined with Modelica’s formal executable modeling for analyses and trade studies. Therefore, Modelica is also used as an action language for UML models. ModelicaML does not only target modelers who are familiar with UML. Modelica modelers will also benefit from using ModelicaML/UML for editing and maintaining Modelica models, because graphical modeling promises to be more effective and efficient than textual representation. The strength and efficiency of UML for system modeling and simulation has been proved in the last years. Common understanding of models for parties involved in development of systems results in high-quality models. Further, the combination of time-discrete and time-continuous simulation gives modelers a great benefit. ModelicaML provides the modeler with powerful executable constructs and execution semantics that are based on Modelica and UML. ModelicaML uses a limited set of UML and extends the UML as profile with new constructs in order to introduce missing Modelica concepts. ModelicaML models are translated into Modelica code by a code generator. Hence, the execution semantics is defined by the Modelica language and ultimately by a Modelica compiler.

26

2.5 Constraints The concrete ModelicaML profile documentation can be found in Appendix C. This thesis uses and extends this profile. The changes which result from this work become part of the ModelicaML profile. When the work for this master thesis was started the profile was in the version which is described in the technical report [Sch09]. Earlier versions of ModelicaML are described in [PAF07a, PAF07b]. Chapter 3 describes the language as it is used in this thesis.

2.5 Constraints A constraint is a property which a model of a system must fulfill. A metamodel such as the ModelicaML profile is not refined enough to provide all the relevant aspects of a specification. Therefore, it allows the modeler to specify models which are not well formed to generate simulation code. There is a need to describe additional constraints which must hold before a model may be simulated. Such constraints are often described in natural language. This results in ambiguities and modelers cannot automatically check their models against the rules. Formal languages make it possible to describe rules which are not ambiguous and can be checked automatically. The object constraint language (OCL) is such a formal language.

2.5.1 OCL The OCL is a declarative language for describing rules, i.e. constraints to UML (meta-)models or stereotyped [OCL10]. It is possible to embed these rules into a UML profile. These constraints must hold for each model which applies to the profile. OCL expressions have no side effects, i.e. they do not change the state of the model, when they are evaluated. OCL expressions can be used to specify helping operations. Further, OCL can be used to specify applicationspecific constraints in models. The context keyword introduces the context of the expression. The keywords inv (invariant), pre (precondition), and post(postcondition) denote the stereotype of the constraints. The actual OCL expression comes after the colon. The result of the expression is false or true. context TypeName inv : self . attribute > number

OCL is used in this master thesis to define constraints on the ModelicaML profile. All defined constraints for ModelicaML are specified in appendix A. For more information about OCL refer to the Bibliography of [OCL10, Annex B, p. 219].

27

2. Fundamentals

2.6 Transformation Transformations are required to transform a model into another form of model or into software artifacts such as code. Additionally, specifications, reports, and documents can be generated automatically. At the top level, model-to-text and model-to-model transformation approaches have to be distinguished. In [CH03, Kön08] detailed overviews and classifications of transformation approaches are described. General, a model-to-text transformation is a model-to-model transformation when a metamodel for the target languages is provided. Therefore, the concrete syntax of a textual language has to be distinguished from the abstract syntax. Model-to-model transformations translate between source and target models, which can be instances of the same or different metamodels. When bridging large abstraction gaps between models it is easier to generate intermediate models than generating directly into code. Model-to-model approaches can be distinguished between relational approaches and graph-transformation-based approaches [GK07]. Relational approaches like QVT-Relations (Query/View/Transformation) are declarative approaches where the main concept is mathematical relations. The basic idea is to state the source and target element type of a relation and specify its using constraints. Graph-transformation-based approaches are based on the theoretical work of graph transformations. They operate on typed, attributed, labeled graphs. These graphs allow to represent UML-like models. Each graph rule has a right-hand-site (RHS) and a left-hand-side (LHS). The LHS specifies the state of the model before the transformation and the RHS after the transformation. The change from the LHS to the RHS is the transformation. The advantage of graph rules is that it is more familiar to developers than QVT. Modelica is a language which is specified only as a concrete syntax in EBNFgrammar. It is up to the tool vendor to specify and implement a metamodel and a compiler which defines the semantics of the models. For practical reasons it is therefore easier to generate text directly, which is then fed into a compiler. Model-to-text approaches can be distinguished between visitor-based and templatebased approaches. Visitor-based approaches provide a visitor-mechanism and write code to a text stream. A template-based approach consists of a template of a target code with placeholders for data to be extracted from the source model. These placeholders are attributes of the metamodel. The values are selected and converted into text by queries. They can be augmented by macros which manipulate the values. In contrast to visitor-based transformation, the structure of a template is more closely to the generated code. Template based approaches make an iterative development possible. Templates can be easily derived from examples. The OMG publishes a standard for model-to-text transformations [OMG08]. In this thesis the template-based model-to-text approach of Acceleo is used to transform ModelicaML models into Modelica code.

28

3 Methodology and Concrete Language Definition “Two things are necessary for our work: inexhaustible stamina, and the readiness to throw away something in which one has invested a lot of time and work.” Albert Einstein

The basic question at the beginning of the development of complex technical systems is how to reach high quality systems. Modeling is a facility to describe characteristics of a system and to simulate concrete features. A systematic approach for the development helps to arrive at reasonable models. Reasonably well structured models are necessary to handle the complexity of large systems. This is particularly important in the context of hybrid systems, because the complexity is much harder to handle than pure discrete or continuous systems. The interaction between discrete model behavior and continuous model behavior has to be well defined. This thesis uses an object-oriented component-based modeling approach. This approach uses, just like object-oriented software programming languages, the four basic principles abstraction, encapsulation, modularity, and hierarchy to describe deductive systems. Further, the specification of the system structure and the specification of the behavior are distinguished. The structure contains the “how it is built” part and the behavior contains the “what it does” part. Visual notions, especially UML, are used pervasively for software engineering. The first visual notion for software engineering was the program flow-charts of Goldstine and von Neumann developed in the 1940s [GVN47]. It is the ancestor of all software engineering visual notations [MG06]. Graphic representation has the advantage that it uses the capabilities of the highly parallel human visual system. Information is encoded spatially and can be processed parallel by the human brain. The power of UML has proved through many projects in the last years. Visual notion makes it possible to express model information easily as well as concisely and precisely. Though, visual notion has many advantages it is not useful to display everything as a shape on a diagram. In some cases it is more effective to capture model parts still as text. As an example a complex mathematical formula cannot be easily displayed graphically on a diagram. The diagram would become overloaded and unreadable. To present complex models, visual notions offer mechanisms for structuring hierarchically and modularise model elements

29

3. Methodology and Concrete Language Definition within a diagram and overall diagrams. Therefore a syntactic solution has to be defined. This chapter gives an informal description of the language elements of this thesis and describes the methodology of modeling mechatronic systems by examples for modeling the two tank system, which is described in section 1.1.1. The language uses a subset of UML elements which are defined in this chapter. The elements are enhanced by stereotypes of a profile. All stereotypes which are introduced in this chapter are incorporated into the ModelicaML profile. The profile itself has some more stereotypes which are not required in this master thesis. Therefore, not all stereotypes and elements are addressed here. The language described in this chapter is a part of ModelicaML, which is described in more detail in appendix C. When ModelicaML is directly addressed it is equivalent with the language which is introduced in this chapter. Besides the description of the language elements, a notion of these elements is presented, modeling constraints are specified, and some diagram types are introduced, which show how these elements can be composed within a diagram.

3.1 Language Architecture The following UML elements from [UML09] are part of the language and are translated into Modelica code. Some of them are extended by stereotypes of the ModelicaML profile in order to add new features and to facilitate the capturing of required Modelica constructs. All elements which are used in this thesis are presented in this chapter. Further, all elements which belong to state machines are converted to Modelica code by the code generation which is described in section 5.2. As a language is nothing static it can be enhanced with further elements and stereotypes in the future. Figure 3.1 shows an overview of interrelationship between the involved languages.

3.2 Class Structure The class structure describes the elements of a system as a static structure. The structure is irrespective of time. The class diagram is the central diagram to model and show the types and instances of system parts and it offers generalization to model inheritance. This section describes the elements which are required for modeling the class structure. The used UML elements are described in the UML specification [UML09, p. 23] in chapter 7. These language elements make it possible to specify the properties of the model elements.

30

3.2 Class Structure

Figure 3.1: Overview of ModelicaML/UML Interrelationship

3.2.1 Class Based on what kind of system should be built and what it should do the system has to be broken down into its most important components. For the components classes are sketched or existing classes from appropriate libraries can be used. As described in section 2.3.1 a class is a set of objects that shares the same attributes and operations. A class specifies a classification of objects with the same structural attributes and behavior. Attributes are associated by instances of Property that are owned by a class. To map the restricted class concept (see section 2.2.2) of Modelica to UML the stereotypes Connector, Record, Block, Model, CalculationModel, ModelicaPackage, Function, ModelicaClass can be applied to UML class. These stereotypes have all the properties encapsulated, partial, final, replaceable, which are equivalent with Modelica properties of a class. They are mapped to Modelica class prefixes. Further, the modeler can define a icon for a class. Therefore, it is possible to define class icons like in the Modelica connection diagram. The graphical notion of a class is a possibility to display the elements which belong to a class within a diagram. The elements which belong to a class can also be shown in a tree structure (see figure 3.2). The strength of a diagram is to show relations of objects, whereas the strength of a tree is to show a hierarchical structure of elements. A class is shown in a diagram as a rectangle. Further, the class is shown with several compartments. All compartments, besides the main compartment, are optional. The following paragraphs define the different types of compartments. Nested classes can alternatively be shown as a containment relation (see last row

31

3. Methodology and Concrete Language Definition

Figure 3.2: Model Tree

of table 3.1). Table 3.1 gives an example for class and compartment notion. Main Compartment The main compartment is the topmost compartment. It contains the class name in boldface in the middle of the compartment. If the property partial of the applied stereotype is true, the class name is shown in italics. Above the class name the applied stereotype name is shown bordered by ’’, or alternatively, the stereotype icon is shown. Attribute Compartment The attribute compartment shows variables and components(class instances) that belong to the class. Attributes may be presented grouped by stereotype. A stereotype name or symbol can then be given once for multiple features with the same stereotype. The concrete syntax of the attributes is described in the following section. Nested Compartment The nested compartment shows classes which are nested in the class. Behavior Compartment The behavior compartment shows behavior which belongs to the class. The type of behavior can be Activity, State Machine, or Opaque Behavior.

32

3.2 Class Structure Icon Compartment The icon compartment shows the user defined icon, if present, which is referenced as iconImagePath String in the applied stereotype. Containment Relation A containment relation represents a decomposition of a class and shows the nested classes. The notion as cross-hair relation is used from SysML notion [Sys08, p. 24].

Element Name

Concrete Syntax Example

Main Compartment

Attribute Compartment Nested Compartment Behavior Compartment Icon Compartment

Containment Relation Table 3.1: Class notion

Constraints A Classifier must have a name (refer to listing A.2). UML Classifier which is no Behavior must have stereotype applied indicating that this is a ModelicaML restricted class (e.g. model, block, record, connector, etc.) (refer to listing A.3). A ModelicaML class may only contain: Class, Enumeration, PrimitiveType, Property, Parameter, StateMachine, Activity, OpaqueBehavior, Port, FunctionBehavior, Comment, Connector, Constraint, Generalization, Dependency (refer to listing A.4).

33


3.2.2 Property A property is a structural feature which is related to a class by ownedAttribute. Property represents an attribute and is an instance of a class or an instance of a primitive type. If a property is an instance of a class the stereotype Component has to be applied. If it is an instance of a primitive type the stereotype Variable has to be applied. These stereotypes have several attributes which specify the Modelica prefixes, or the concrete value. For a component the user can define an icon which represents the component in the composite diagram. Refer to appendix C for a detailed description of the properties. The following general notation for properties is defined: < property > : : = < visibility > [ ,< flowFlag > ] [ ,< scope > ] [ , causality ] [ ,< variability > ] [ < derived > ] < name > [ ' : ' < prop - type > ] [ ' [ ' < multiplicity > ' ] ' ] [ ' = ' < declarationEquationOrAssignment > ] ] < visibility > : : = < public > | < protected > < flowFlag > : : = < flow > | < stream > < causality > : = < input > | < output > < variability > : = < continuous > | < discrete > | < parameter > | < constant >

hpublici ::= +, hprotectedi := # hf lowi :=', hstreami :=6' hinputi := ~i, houtputi := ~o hcontinuousi := ⊕, hdiscretei := hparameteri := , hconstanti := ⊗ hderivedi := /

where: hnamei is the name of the property. hprop-typei is the name of the Class that is the type of the property. hmultiplicityi is the multiplicity of the property. If this term is omitted, it implies a multiplicity of 1 (exactly one). hdeclarationEquationOrAssignmenti is the right-hand side of the operator ’=’ or ’:=’.

34

3.2 Class Structure Constraints A UML Property of a ModelicaML classifier must have a stereotype applied which indicates that this is a ModelicaML Property (i.e. instance of a class) (refer to listing A.5).

3.2.3 Package Name conflicts are a major problem when developing modular systems. Name collisions can be avoided by grouping related elements into a package. A package is a container or namespace for its members, i.e. names of classes, functions, constants, and other allowed definitions, and may contain other packages. Additionally, definitions from other packages can be imported into the namespace of a package. Modelica has defined the package concept as a restriction and enhancement of the class concept. Thus, inheritance could be used for importing definitions into the name space of another package. This is not possible in the UML, therefore, besides a UML package, also UML class with stereotype ModelicaPackage can be used to model a package. The notion of package and class with stereotype ModelicaPackage is the same as defined in the UML [UML09, p. 109]. “A package is shown as a large rectangle with a small rectangle (a “tab”) attached to the left side of the top of the large rectangle. The members of the package may be shown within the large rectangle.” “If the members of the package are not shown within the large rectangle, then the name of the package should be placed within the large rectangle.” “If the members of the package are shown within the large rectangle, then the name of the package should be placed within the tab.”

Figure 3.3 shows a package with two nested packages. Constraints A ModelicaML package may only contain the elements Class, Property, PrimitiveType, Enumeration, FunctionBehavior (refer to listing A.1).

3.2.4 Generalization One of the major benefits of object-orientation is the ability to group and to generalize common aspects of classes to one superclass. Classes which have these behaviors and properties can inherit them from the superclass. To specify inheritance from a superclass into a subclass, Generalization (7.3.20) from UML

35


Figure 3.3: Package

[UML09, p. 71] is used. Since, the UML classes are translated to Modelica code, the semantics of the generalization concept of Modelica [Mod10, p. 65, chapter 7] is applied. The superclass is extended to create a more specialized version of that class. In this process, the data and behavior of the superclass in the form of variable declarations, equations, and certain other contents are copied from the superclass into the subclass. Before copying certain operations, such as type expansion, checking, and modification are performed on the inherited contents when appropriate. The elements of the superclass become elements of the subclass, including equation sections and algorithm sections. Equations of superclass that are syntactically equivalent to equations in the subclass are discarded. Equations that are mathematically equivalent but not syntactically equivalent are not discarded, hence yield an overdetermined system of equations. A generalization has the stereotype ExtendsRelation. This stereotype has the modification property, which makes it possible to modify existing values of an attribute. A Generalization is shown as a line with a hollow triangle as an arrowhead between the symbols representing the involved classes. The arrowhead points to the superclass and the arrow tail to the subclass. If modification is not empty, it can be displayed in a callout box, also called callout notation in the SysML specification [Sys08]. The callout box is displayed as a rectangle with the upper right corner bent, called comment symbol. The rectangle contains the modification strings. If the string is too long it can be abbreviated by ’. . . ’. The connection to the rectangle is shown by a dashed line. Table 3.2 shows the symbols for a generalization and the callout notion of modification. Constraints A UML Generalization must have a ModelicaML stereotype indicating that this is a Modelica extends or type extends relation (refer to listing A.6).

36

3.2 Class Structure Element Name

Concrete Syntax Example

Generalization

Generalization modification

with

instance Table 3.2: Generalization notion

A ModelicaML model or class can only extend a model, block, or record (refer to listing A.7). A ModelicaML block can only extend a block or record (refer to listing A.8). A ModelicaML connector can only extend a type, record, or connector (refer to listing A.9). A ModelicaML record can only extend a record (refer to listing A.10). A ModelicaML type can only extend a type (refer to listing A.11). A ModelicaML function can only extend a function (refer to listing A.12).

3.2.5 Primitive Types The UML defines a primitive type as a predefined data type, without any relevant substructure. ModelicaML has the primitive types ModelicaBoolean, ModelicaInteger, ModelicaReal, and ModelicaString. They are instantiated as UML property with the stereotype Variable.

3.2.6 Class Structure Example Figure 3.4 shows the class Tank of the Two Tank System which is described in section 1.1.1. The Tank class has for example the variables minV and maxV, which define the limits for the output valve flow. The value of these variables is defined through equations or statements. An instance of the class can also change these values. Figure 3.5 shows a base controller and a PI continuous controller. The PI continuous controller contains all variables and behaviors of the base controller. Further, it is extended by the variables x, powered and some behavior is added. The variables K, T are modified, they are assigned with new values.

37


Figure 3.4: Tank Class

Figure 3.5: Controller

38

3.3 Composite Structure

3.3 Composite Structure In the previous section system elements have been described as self-contained classes. Modeling a whole system as a flat model creates confusing and very complex models. These models are more error-prone than hierarchical, well structured models. Complex systems can be naturally described as hierarchical structures of components. This allows new structuring and grouping mechanisms, which are not available in flat modeling. Hierarchical structures consist of components that are not bound to one hierarchy level; they can become many levels deep. To model the internal structure of components, which consist of other components, ModelicaML uses composite structure diagrams. These describe how things are composed.

3.3.1 Class from Composite Structures A class, which represents a modular part of a system, is also called component. It can be shown and modeled within the composite structure diagram. As a structured class it can have ports and an internal structure. The internal structure consists of properties with the stereotype Component (see section 3.3.2) as assembled parts in the encompassing class. Assembling of parts is done by wiring ports together by using Connectors. A component is described in more detail in section 2.3.1. A class is shown as a rectangle with two compartments. The upper compartment is called name compartment and shows the name and optionally the stereotype of the class. The lower compartment is called composite compartment and shows the internal structure of the class as nested parts and connections. An example is shown in figure 3.6.

Figure 3.6: Composite Class Notion

3.3.2 Property A property of a class with the stereotype Component, which is an element of a composition is also called part. The type of the property defines the connection points, i.e. the ports of the property.

39

3. Methodology and Concrete Language Definition A part is shown by graphical nesting of a rectangle within the composition compartment of the containing class. The rectangle has two compartments. The upper compartment is called name compartment and shows the stereotype of the property, the property name and the type of the property with the following syntax: > name : Type

The stereotype and the type can be obtained. The lower compartment shows the icon, which is referenced in the iconImagePath of the stereotype Component. If no icon is referenced, the icon which is reference in class of the type, is shown. Otherwise the empty compartment is shown. An example is shown as the internal structure within the composite class in figure 3.6. Constraints A Modelica component must have a type (refer to listing A.17). A component of a ModelicaML block must have causality (input/output) defined (refer to listing A.18).

3.3.3 Interface Class Interface classes declare variables that are part of the communication interface of a component. Interface classes have no internal structure or port and cannot be shown within a composite structure. Instances of interface classes are shown as ports.

3.3.4 Port Ports are instances of interface classes which “provide mechanisms for isolating a classifier from its environment”[UML09, p. 161]. They provide a point of conducting interactions between the internals of its owner classifier and its environment (see also section 2.3.1). Ports can be connected through Connectors. “A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. The port symbol may be placed either overlapping the boundary of the rectangle symbol denoting that classifier or it may be shown inside the rectangle symbol.” [UML09, p. 181]. Figure 3.7 shows the port symbol.

40

3.3 Composite Structure

Figure 3.7: Port Notion (source [UML09, p. 181])

Constraints Ports must have ModelicaML stereotype (refer to listing A.19).

3.3.5 Connector A connector is a link between two ports. It enables the connected classes to share information with each other or communicate via the link. It has the stereotype Connection with the property explicitConnectionEnds. The string can be used to explicitly connect attributes with different names of the interface classes of the involved ports at the connection ends. A connector is drawn as a solid line connecting two ports. The optional name string of the connector obeys the following syntax: ( [ name ] ' : ' < classname > ) | < name >

where < name > is the name of the connector, and < classname > is the name of the association that is its type. A stereotype keyword within guillemets may be placed above or in front of the connector name. The property strings of explicitConnectionEnds may be placed after or below the connector name. Alternatively they can be displayed in the callout notation. Constraints A UML connector must have a ModelicaML stereotype (refer to listing A.20). All UML connector ends must be set (refer to listing A.21). A ModelicaML connection can only connect ports (refer to listing A.21).

3.3.6 Composite Structure Example The composite structure describes the internal structure of a class. This class contains the components that should be composed together. The two tank system contains an instance of the class LiquidSource, two instances of the class Tank, and two instances of the class PIcontinuousController. Figure 3.8 shows the external class structure view of the two tank system class TanksConnectedPI, which connects all containing elements.

41


Figure 3.8: Two Tank System Class

After specifying, which elements should be connected, the interactions and communication paths between these components have to be defined. However, before components can interact with each other they need interfaces. These interfaces are defined as ports. Each port has an interface class as type. Figure 3.9 shows the interface class LiquidFlow of the ports which represents the inlets and outlets of a tank . It has the variable lflow, which describes the liquid flow. This interface class is instantiated twice as port in the class tank. One instance of LiquidFlow qIn represents the inlet of a tank, the other instance of LiquidFlow qOut represents the outlet of a tank.

Figure 3.9: Interface Class LiquidFlow

Figure 3.10 shows the composite structure of the class TanksConnectedPI with all components, ports, and connectors. The ports of components are connected by connectors.

3.4 Behavior Hybrid systems have continuous behavior and discrete behavior. Physical parts of a system evolve continuously, whereas artificial system parts evolve discretely. Since hybrid systems contain both, hybrid and discrete parts, these parts are not separated from each other; they interact with each other. The discrete part of a hybrid system can change its state as a result of a change of its environment. A continuous part also changes its behavior when an attribute of the equation is changed. This can be a result of a state change. As system elements are defined

42

3.4 Behavior

Figure 3.10: Connected Composite Structure of Two Tank System with Ports

by classes, each class can have continuous and discrete behavior. Simple classes, which are driven by data, do not have a certain behavior. During simulation several objects of the same class can exist, such objects are called instances. Each instance has an active configuration. The active configuration is determined by a set of attributes at a certain point in time. The behavior of a class can access the attributes of the class it belongs to. For each new instance of a class new behavior is created which is independent of the other behaviors. Interaction between class instances is only enabled via connected ports. Continuous behavior is specified as differential equations. These can either be directly specified as formula or as an activity diagram. Discrete behavior is specified as state machines. Further, algorithms, which are finite sequences of instructions, can be defined by activity diagrams. A typical system with hybrid behavior is a computer system which interacts with a real physical system.

Constraints UML Behavior must have a stereotype applied which indicates that this is a part of the ModelicaML class behavior (i.e. equation or algorithm sections) (refer to listing A.23). A Modelica package, record, connector, or type cannot have behavior (refer to listing A.24).

43


3.4.1 Opaque Behavior Opaque Behavior is used to specify Modelica code directly within a class. This could be for example a continuous differential equation. Modelica is used as UML action language. Therefore, the Modelica code is specified textually in the body of a UML Opaque Behavior. The code has no graphical syntax. It is mentioned for the future to display mathematical equations rendered as mathematical notation as follows: dy + y 2 x = 2x dx

3.4.2 State Machine ModelicaML StateMachine State machines are used to express the behavior of discrete parts of a system. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs. A state machine must have the Stereotype modelicaMLStateMachine. This stereotype has the attribute samplingExpression. If this expression is set, for example, with the string sample(0,0.1), the state machine is evaluated periodically every 0.1 seconds. State Machine is drawn as a rectangle with rounded corners. It has the name compartment and the internal compartment separated from each other by a horizontal line. The name compartment contains the stereotype name above the state machine name. The internal compartment contains a graph that represents the state machine. States and pseudostates in the state machine graph are drawn as their symbols, while transitions are drawn as directed arcs. Figure 3.11 shows a state machine with an empty region. The association between a state machine and its context class or behavioral feature does not have a special notation. It is up to a tool to show such relations. The StateMachine defines a set of concepts that can be used for modeling dis-

Figure 3.11: StateMachine Notion

crete behavior through finite state transition systems. The activities and opaque behavior that are invoked during the transition, entry, and exit of the states are specified along with the associated event and guard conditions. A composite state has nested states that can be sequential or concurrent.

44

3.4 Behavior The UML concept of protocol state machines is excluded from this thesis to reduce the complexity of the language. The standard UML state machine concept (called behavior state machines in UML) is considered to be sufficient for expressing protocols. StateMachines are described in detail in section 2.3.2. The following subsections give an overview of supported elements, the stereotypes which can be applied, and the notion of these elements. SimpleState A state represents a discrete state of a system. In general a state is shown as a rectangle with rounded corners, with the state name shown inside the rectangle. Further, if entry-, exit- or do-action is set, it has an internal activities compartment which displays the set activities. Figure 3.12 shows a simple state with an entry, exit-, and do-action.

Figure 3.12: SimpleState Notion

Transition A transition is a directed arc and specifies the connection of states. A transition has references to triggers, a guard, effect, source, target, and container. Each transition has the stereotype ExecutionOrderPriority with a unique priority Integer value related to other outgoing transitions with the same source state. Additionally, a transition can have the stereotype StateDependency with a reference to another state. A StateDependency-guard of a transition only becomes true if an orthogonal region is in the dependent state. A transition is drawn as a line with an arrowhead. A transition leaves the border of a state or pseudostate and end at either a state or pseudostate. The priority value can be shown in a small circle at the source of the transition. A transition can cross borders of composite states. Figure 3.13 shows a simple transition.

Figure 3.13: Transition Notion

45

3. Methodology and Concrete Language Definition Constraints Source and target must be set for a transition (refer to listing A.50). Transitions cannot cross region borders (refer to listing A.51).

Trigger,Guard, Effect A transition can have a trigger which activates the transition if the associated event is true. An event is a time-event, change-event, or a signal-event. A time-event occurs when a time-expression evaluates to true. An example for a time-expression is time > 3. A change event occurs when a referenced expression evaluates to true. For example the change event with the expression x occurs each time when the value of x changes. A signal-event has just a name and is something which a state machine can generate and another part of the state machine can react to. A signal can be generated by the ModelicaML GEN SIGNAL()-macro which can be invoked by an effect or entry-, exit-, do-action. The syntax of the macro is: GEN_SIGNAL ( n ame _o f_ th e_ si gn al )

For example GEN SIGNAL(ev open door) generates the ev open door signal. A guard is, in contrast to an event, true as long as its corresponding expression is true. A transition can only fire if its guard is true. A time-guard relative to a local state time can be modeled through the AFTER()-macro. It is dedicated to state transitions. The meaning is that after a state is entered and the local state time exceeds the given seconds this part of the transition-guard evaluates to true. The syntax of the macro is: AFTER ( expression )

An effect is a behavior-expression which is invoked when the corresponding transition fires. The default notation for a transition is defined by the following BNF expression:

< transition > : : = [ < trigger > [ ' , ' < trigger > ] * [ ' [ ' < guard > ' ] ' ] [ ' / ' < effect > ] ] < trigger > : : = < time - event > | < signal - event > | < change - event > < time - event > : : = ' when ' < time - expression > < change - event > : : = ' when ' < expression > < signal - event > : : = < name > < guard > : : = < expression > < effect > : : = < opaqueBehavior > | < activity > < opaqueBehavior > : : = < expression >

46

3.4 Behavior Figure 3.14 shows a simple transition with a label for an event, a guard, and an effect.

Figure 3.14: Transition Label Notion

Orthogonal-State/-StateMachine A composite state with more than one region is called orthogonal state. A state machine can also have multiple orthogonal regions. If the surrounding state or state machine of a region is active it is implied that exactly one state of this region is active. Each region can be given an Integer value which must be unique in relation to the orthogonal regions. The value specifies the region execution priority. Each region must have a name. Further, it contains the nested disjoint states and the transitions between those transitions. Transitions between different orthogonal regions are not allowed. A composite state or state machine with regions is shown by tiling the graph region of the state/state machine using dashed lines to divide it into regions. The priority value can be shown in a small circle near the dash line. The text compartment of the surrounding state is separated from the orthogonal regions by a solid line. Figure 3.15 shows a composite state with two regions.

Figure 3.15: Region Notion

Constraints Each Region must have exactly one initial or shallowHistory pseudostate (refer to listing A.34).

47

3. Methodology and Concrete Language Definition CompositeState A composite state is a simple state with hierarchy. Besides name and activity compartment it has the decomposition compartment. This compartment shows the composition structure of the state. The composition structure consists of regions, states, pseudostates, and transition. Figure 3.16 shows a composite state with an empty region.

Figure 3.16: CompositeState Notion

Submachine-State Submachine states provide encapsulation of state machines. They make it possible to reuse state machines and enable state machines with submachines to scale. The submachine state is drawn as a simple state with a name compartment where the string in the name compartment has the following syntax: < state name > ' : ' < name of referenced state machine >

Figure 3.17 shows a submachine state.

Figure 3.17: Submachine-State Notion

FinalState A FinalState is a state which abandons the execution of a region. It is drawn as a circle with a smaller black dot inside, as shown in figure 3.18.

Figure 3.18: FinalState Notion

48

3.4 Behavior Constraints A FinalState may not have outgoing transitions (refer to listing A.56).

Initial-Pseudostate An initial-pseudostate is the default node of a region. It is the source for a single transition to the default state of a region. A transition can have a behavior but no trigger or guard. It is drawn as a solid filled circle, as shown in figure 3.19.

Figure 3.19: Initial-Pseudostate Notion

Constraints The initial pseudostate of each region may not have a guard on its outgoing transition. (refer to listing A.36). The initial of each region must have exactly one outgoing transition (refer to listing A.35). The outgoing transition from the initial pseudostate may not be an interlevel transition (refer to listing A.37).

ShallowHistory-Pseudostate ShallowHistory references the most recent active state of a region. It has exactly one outgoing transition to a default state. It is drawn as a circle which encloses the letter H (see figure 3.20).

Figure 3.20: ShallowHistory-Pseudostate Notion

49

3. Methodology and Concrete Language Definition Constraints The shallowHistory pseudostate of each region may not have a guard on its outgoing transition. (refer to listing A.36). The shallowHistory pseudostate of each region must have exactly one outgoing transition (refer to listing A.35). The outgoing transition from shallowHistory pseudostate may not be an interlevel transition (refer to listing A.37). Pseudostates of kind deepHistory are not supported (refer to listing A.42).

Junction-Pseudostate Junction is used to chain together multiple transitions. All guards are evaluated before one chain of transition fires and behavior is executed. An “else”-guard may be defined for at most one outgoing transition. A junction-pseudostate is drawn as a small black circle (see figure 3.21).

Figure 3.21: Junction-Pseudostate Notion

Constraints A junction-Pseudostate must have incoming and outgoing transitions (refer to listing A.43).

Choice-Pseudostate Choice is used like a junction to chain together multiple transitions. The guards and triggers are dynamically evaluated. After each evaluation the behavior of the corresponding transition is executed. A choice is drawn as a diamond-shaped symbol (see figure 3.22). Constraints A choice-Pseudostate must have incoming and outgoing transitions (refer to listing A.43).

50

3.4 Behavior

Figure 3.22: Choice-Pseudostate Notion

Join-Pseudostate A join-pseudostate is used to synchronize several transitions with their source in different regions from the same composite state. It is drawn as a filled, short heavy bar (see figure 3.23).

Figure 3.23: Transition Label Notion

Constraints Transitions from join must have State or FinalState as target (refer to listing A.47). Transitions from join may not be interlevel (refer to listing A.48). In a complete state machine, a join vertex must have at least two incoming transitions and exactly one outgoing transition (refer to listing A.49).

Fork-Pseudostate A fork-pseudostate is used to split an incoming transition into two or more transitions, which targets are located in orthogonal regions. It is drawn as a filled, short heavy bar (see figure 3.24). Constraints Transitions to forks must have state node as source (refer to listing A.44). Transitions to forks may not be interlevel (refer to listing A.45).

51


Figure 3.24: Fork-Pseudostate Notion

In a complete state machine, a fork pseudostate must have at least two outgoing transitions and exactly one incoming transition (refer to listing A.46).

ConnectionPointReference ConnectionPointReference is used to realize interlevel transition to and from a submachine. It is drawn as a circle. It is placed on the border of the state symbol of a submachine state. If a ConnectionPointReference has a reference to an EntryPoint the circle is empty (right circle). If a ConnectionPointReference has a reference to an ExitPoint the circle contains a cross (see figure 3.25).

Figure 3.25: ConnectionPointReference Label Notion

Constraints ConnectionPointReference may only reference one entryPoint/exitPoits (refer to listing A.52). ConnectionPointReference referencing an entryPoint may not have outgoing transitions (refer to listing A.53). ConnectionPointReference referencing an exitPoint may not have incoming transitions (refer to listing A.54). ConnectionPointReference referencing an exitPoint must have an outgoing transition (refer to listing A.55).

52

3.4 Behavior EntryPoint-Pseudostate An EntryPoint pseudostate is an EntryPoint of a submachine. It has the same function as a junction. Only one trigger or guard of the outgoing transitions can become true in an instance. An EntryPoint-pseudostate is drawn as a small circle on the border of a submachine, as shown in figure 3.26.

Figure 3.26: EntryPoint-Pseudostate Notion

Constraints EntryPoints cannot have incoming transitions (refer to listing A.40). All transitions from an entryPoint must lead to the targets that are contained in the same region (refer to listing A.38).

ExitPoint-Pseudostate An ExitPoint pseudostate is an ExitPoint of a submachine. Entering an exit point of a submachine implies the exit of the referenced submachine state and the triggering of the transition that has the ConnectionPointReference as source in the state machine enclosing the submachine. An ExitPoint-pseudostate is drawn as a small circle with a cross on the border of a submachine, as shown in figure 3.27.

Figure 3.27: ExitPoint-Pseudostate Notion

Constraints ExitPoints can have at most one incoming transition (refer to listing A.39). ExitPoints cannot have outgoing transitions (refer to listing A.41).

53

3. Methodology and Concrete Language Definition Terminate-Pseudostate Entering a terminate pseudostate implies that the execution of this state machine stops. A terminate pseudostate is drawn as a cross (see figure 3.28).

Figure 3.28: Terminate-Pseudostate Notion

Constraints A Terminate pseudostate may not have outgoing transitions (refer to listing A.57).

3.4.3 Activity UML specifies an activity as follows: “The specification of parametrized behavior as the coordinated sequencing of subordinate units which individual elements are actions.” [UML09]. An activity can be modeled graphically within an Activity-Diagram [UML09, p. 315]. ModelicaML Activity In ModelicaML an activity is divided into algorithmic activity, i.e. activity with stereotype ConditionalAlgorithm(Diagram) (see figure 3.29), and equation activity, i.e. activity with stereotype ConditionalEquations(Diagram) (see figure 3.30). The main difference between algorithmic and equation activity is the way they are executed when they are translated to Modelica. The execution of the algorithmic actions is defined though the control flow, whereas equations are executed all at the same time in one simulation step. Thus, an activity diagram is just used to model the particular equations and the decision tree of conditional equations. Therefore, equation activities have no control-flow enforcing a procedural execution. Algorithmic activities can be invoked by another action. This can be, for example, an entry- or exit-action of a state, or an effect of a transition. An activity is drawn as a round-cornered border rectangle. The rectangle contains only one compartment for modeling activity nodes and edges. The applied stereotype is displayed centered at the top of the compartment.

54

3.4 Behavior

Figure 3.29: Conditional Notion

Algorithm

Figure 3.30: Conditional Notion

Equations

Constraints ControlNode: Only ’InitialNode’ and ’DecisionNode’ are supported (refer to listing A.27).

Initial Node An initial node is a control node at which flow starts when the activity is invoked. Initial nodes are notated as a solid circle, as shown in the figure 3.31.

Figure 3.31: Initial Notion

Constraints A ModelicaML Activity must have exactly one initial node (refer to listing A.28). A ModelicaML Activity must have exactly one outgoing transition of an initial node (refer to listing A.29).

Actions (statements/ equations) An action is a named element that stores Modelica code. The execution of an action represents the execution of the stored Modelica code. An action is modeled in activity diagram as a UML OpaqueAction, which is just the placeholder for the Modelica code. If the action is within an algorithmic activity it represents a Modelica statement and must have the stereotype AlgorithmStatements(CodeInDiagram) (see figure 3.32). A statement is executed when

55

3. Methodology and Concrete Language Definition the control flow invokes the statement. If the action is within an equation activity, it represents a Modelica equation and must have the stereotype Equations(CodeInDiagram) (see figure 3.33). All equations are active simultaneously, unless an equation is in an inactive conditional branch. Actions are notated as round-cornered rectangles. The name of the action or the Modelica statement/ equation appears in the symbol. As an alternative to the name the defined Modelica code can be displayed.

Figure 3.32: Statement Notion

Figure 3.33: Equation Notion

Constraints Action: Only ’OpaqueAction’ and ’CallBehaviorAction’ are supported (refer to listing A.25).

Activity Edge An activity edge specifies in algorithmic-activities the control flow of the algorithm. In equation-activities it specifies the different branches of the decision tree. To model an edge UML ControlFlow is used. The stereotype ExecutionOrderPriority can be used to give a priority to an edge. Further, the stereotype StateDependency can be used to specify the guard of the edge. The guard is only true if the referenced state is active. This can be used to model hybrid behavior in conditional equation diagrams (see section 3.5.5). An activity edge is notated by an open arrowhead line connecting two activity nodes. If the edge has a name, it is notated near the arrow (see figure 3.34).

Figure 3.34: ControlFlow Notion

Constraints ActivityEdge: Only ’ControlFlow’ is supported (refer to listing A.25).

56

3.4 Behavior Merge Node Merge nodes are introduced to bring multiple flows together in activities. The functionality of merge node and decision node can be combined by using the same node symbol. The notation for a merge node is a diamond-shaped as shown in figure 3.35.

Figure 3.35: Merge Notion

Constraints A ModelicaML MergeNode must have exactly one outgoing ControlFlow (refer to listing A.30). A ModelicaML outgoing ControlFlow of MergeNodes is not allowed to have a guard (refer to listing A.31).

Conditional Statement A conditional node is a node which is used to choose between outgoing flows. UML DecisionNodes [UML09, p. 360] are introduced to support conditionals in activities. In Modelica an if -decision is distinguished from a when-decision. An if-decision is a decision node with the stereotype If (see figure 3.36). A whendecision is a decision node with the stereotype when (see figure 3.37). The if-branch of a decision node is taken at each evaluation as long as its condition is true. Otherwise, the else branch is taken. The when-branch is only taken when the Boolean conditions switch their value from false to true. Otherwise, the else branch is taken. The notation for a decision node is a diamond-shaped symbol. In the middle of the decision node the stereotype if or when is shown. A decision node must have one non-decision input activity edge entering it and one or more edges leaving it. The functionality of a decision node and a merge node can be combined by using the same node symbol. Constraints A ModelicaML DecisionNode can only have one incoming ControlFlow (refer to listing A.32). DecisionNode must have stereotype ’If’ or ’When’ (refer to listing A.33).

57


Figure 3.36: If- decision Notion

Figure 3.37: When-decision Notion

Conditional Equation A conditional equation is used to model hybrid behavior. The decision node is used to decide which equation is active. Hereby, it is assured that the single assignment rule is not violated and always one of the equations is active. Therefore, the equations must contain all the same variables. The notion of conditional statements is used to model the decision nodes.

3.4.4 Behavior Example Continuous Behavior The class PIcontinuousController has the opaque behavior equations(code) (see listing 3.1) which specifies that the deviation from the reference level (error) is equal to the difference of the reference level (ref) and the value of the connected sensor(cIn.val). Listing 3.1: ”Equations(code) BaseController” equation error = ref - cIn.val ;

The continuous behavior of PIcontinuousController is defined through the sys= error , outCtr = K ∗ (error + x) which is implemented as tem of equations dx dy T equations(code) in Modelica syntax (see listing 3.2) within an opaque behavior. This system of equations has two equations and the two unknown variables x and outCtr. Listing 3.2: ”Equations(code) PIcontinuousController” equation der ( x ) = error / T ; outCtr = K * ( error + x ) ;

Discrete Behavior The algorithm power on(see listing 3.3) sets the variable powered to true in the moment when the simulation time becomes greater than zero.

58

3.4 Behavior Listing 3.3: ”Equation power on” algorithm when time > 0 then powered : = true ; end when ;

Figure 3.38 shows the discrete behavior of the continuous controller as the state machine sm. Initially the pi continuous controller states in the simple state off. If the variable powered gets the value true, the guard becomes true and sm changes it state instantaneously to the composite state on.

Figure 3.38: State Machine

The composite state on is at activation in the state monitoring the level. If the sensors measures a liquid amount in the tank which is greater than 0.2 (cIn.val > 0.2) the controller changes its state to controlling the level. If it is less than 0.08 (cIn.val < 0.08) it changes back to the state monitoring the level. In the state monitoring the level the controller will only monitor and not control the level of liquid in the tank. The value of the port cOut must be zero. In the state controlling the level the actuator of the valve will be controlled. Therefore, the value of cOut must be set to the value of outCtr, which is calculated through listing 3.2. Hybrid Behavior Figure 3.39 shows the signal activation of the valve actuator. As long as the state controlling the level is active the equation cOut.act = outCtr is active and the level of liquid is controlled by the continuous controller. Otherwise the equation cOut.act = 0; is active and the valve of the tank is closed. Conditional equations must always have one active equation.

59


Figure 3.39: Actuator Signal Activation

3.5 Diagram When building models all information is stored in the model repository. The notion of diagrams is defined in UML specification as follows: “Each diagram has a contents area. As an option, it may have a frame and a heading. . . The diagram contents area contains the graphical symbols; the primary graphical symbols define the type of the diagram (e.g., a class diagram is a diagram where the primary symbols in the contents area are class symbols).”[UML09, p. 683]. Diagrams are only a view on a selected part of the model data. The diagram must have an indication when only a part of an element is shown. Not indicating that a diagram shows only a part of information (that is defined in the model and may appear on this diagram) can lead to miss-interpretations when reading the diagrams. Further, each diagram will define which model data can appear on it. The usage of a graphical notation to represent model data by means of diagrams is a trade-off between multiple aspects: Size of diagrams and the willingness to accept a split into multiple diagrams. For example, if diagrams become too big for a screen or to be printed on paper it may be a convenient way to split the contents into multiple diagrams. However, this makes the reading and understanding of interrelations between elements more difficult. Readability of content presented and an overload of information to be receipted by the reader, intuitive and simple notation (boxes, edges, etc.) and the level of expressiveness. Tool support. There are many model parts and features which a diagram cannot display in a sufficient manner. A modeling tool or an automatic process can make modeling much easier and help to understand a model in a better way. For example, when building models, using a modeling tool, the user should not spend much time on arranging diagrams elements. The

60

3.5 Diagram modeler should concentrate on the contents to be modeled. The tool can support the user by providing capabilities for automated diagram layouts. Taking into account the aspects listed above a diagram should only display all necessary information and should be kept simple and clearly structured. The modeler has to define style guidelines for their diagrams and has to follow these guidelines consistently. Further, the modeling tool has to inform the modeler if only a part of the model is displayed or if other diagrams exist which give another view on the model part. This cannot be reached by a diagram notion. A heading on the diagram can help the modeler to classify it and to get to know what is displayed on the diagram. The heading is a string within a rectangle with cutoff corners, in the upper leftmost corner of the rectangle, with the following syntax:

[ < diagram kind } >] [ ' [ ' [ < stereotype > ] [ < element kind > ] ' ] ' ] < element name >

The diagram kind can be class, state machine, or activity diagram. The stereotype is the applied stereotype of the main diagram element, for example, the state machine with the stereotype modelicaMLStateMachine within a state machine diagram. In cases where not needed, the heading may be omitted. Figure 3.40 shows a heading of a diagram. Optionally, the diagram heading can have a comment with some more information about the diagram.

Figure 3.40: Diagram heading with frame from [Sys08, p. 173]

The taxonomy of diagrams which are used in this master thesis are shown in figure 3.41. The diagrams are similar to UML diagrams, but they are altered, tailored and enhanced. Only elements which are described in this chapter are allowed. As ModelicaML uses a subset of UML not all UML diagram-types are used at the moment. The requirement diagram is part of the ModelicaML specification but is out of scope of this thesis. Therefore, it will not be described in this chapter.

61


Figure 3.41: Diagram Taxonomy

3.5.1 Class Diagram The class diagram only displays classes, packages, generalizations, and nested classes as containment (crosshair) relation. Class diagrams represent a structural part of the model. The class diagram can contain the elements which are defined in section 3.2.1. It captures the definition of classes in terms of properties and behavior. Figure 3.42 shows an example class diagram.

Figure 3.42: Class diagram

62

3.5 Diagram

3.5.2 Composite structure diagram Composite diagrams show the internal structure of a class. They contain elements from section 3.3. Figure 3.43 shows an example for a composite structure diagram.

Figure 3.43: Composite Diagram

3.5.3 State Machine Diagram State Machine diagrams specify state machines. A state machine diagram only contains a state machine symbol with its compartments which show the internal structure of the state machine. Therefore, only elements which are described in section 3.4.2 are allowed. UML allows for a diagram to display only a part of a model. In this thesis this should be explicitly forbidden for state machines, because this leads to behavior which cannot be understood and traced by the modeler. If a state machine gets too complex submachines can be used to subdivide the behavior. As an exception the internal structure of a composite state can be hidden and displayed by the ). A state machine example with all allowed elements is shown hidden symbol ( in figure 3.44.

3.5.4 Algorithm Diagram The focus of algorithm diagrams is the modeling of sequences and conditions for coordinating Modelica statements. Therefore, an activity with stereotype Con-

63


Figure 3.44: State Machine Diagram Example with all Elements

ditionalAlgorithm(Diagram) can be displayed within an algorithm diagram. An algorithm diagram is a subset of UML activity diagram. The following constructs are allowed in algorithm diagram: Activity with stereotype ConditionalAlgorithm(Diagram) OpaqueAction with stereotype AlgorithmStatements(CodeInDiagram) Merge node Decision Node with stereotype if Decision Node with stereotype when ControlFlow with and without stereotypes ExecutionOrderPriority, StateDependency

An example is shown in figure 3.45

Figure 3.45: Conditional Algorithm Diagram Example

64

3.5 Diagram

3.5.5 Conditional Equation Diagram The focus of conditional equation diagrams is the modeling of conditional equations or hybrid behavior. Therefore, an activity with stereotype ConditionalEquations(Diagram) can be displayed within a conditional equation diagram. The following constructs are allowed in equation diagrams: Activity with stereotype ConditionalEquations(Diagram) OpaqueAction with stereotype Equations(CodeInDiagram) Merge node Decision Node with stereotype if Decision Node with stereotype when ActivityEdge with and without stereotypes ExecutionOrderPriority, StateDependency

An example is already shown in figure 3.39.

65

4 State Machine Semantics “Computer programs are complex by nature.” Steve C. McConnell

This chapter addresses the semantics of ModelicaML state machines with the target to map this semantics to Modelica language constructs. The state machines semantics in this thesis is just as the language definition closely linked to the UML semantics definition. However, there are some issues in which the state machine semantics of this master thesis differ from UML. This is based on the target language Modelica and the domain of physical systems which are described by the state machines in this thesis. The next sections address and highlight the issues which are identified, the resulting differences and provide the rational for design decisions. The main objective of the state machine semantics in these thesis is to describe discrete behavior of real physical systems with UML state machines and to map this state machines to Modelica. Physical systems have the characteristic that they react immediately and have normally no discrete memory. The memory of a physical system can be mostly described by a differential equation dependent on the past and present model values [Wel79]. The state machine semantics of this thesis will not change the synchronous data flow principle of Modelica. Anyway, it is possible to model clocked/sampled discrete behavior. Therefore, the state machine behavior can be executed with a constant sample period if required. It is planned for the future to extend the modeling capabilities for hard realtime systems. An example for modeling features like deadlines or invariants for real-time state machines is described in [GB03]. In this thesis clocked real-time systems are not the main focus. The two tank system works without any clocked control element. The control mechanisms of the two tank system is modeled with control engineering techniques. A ModelicaML class can have multiple parts of different behavior. Behavior in this thesis is described by a state machine, an activity, or an opaque behavior (see figure 2.9, refer to section 3.4). In this thesis state machines are translated into Modelica algorithmic codes. The reasons for this decision are described in section 5.2.6. Activities and opaque behavior are translated into Modelica equations or algorithmic codes depending on their stereotype. For an example refer to the next chapter, where the mapping is shown (see figure 5.11 and listing 5.6).

67

4. State Machine Semantics

4.1 Semantics Definition of ModelicaML State Machines This section addresses the definition of ModelicaML state machine semantics. The semantics of the different state machine elements is discussed with regard to the description of discrete physical behavior and the possibility to map this behavior to Modelica. Since ModelicaML state machines are a subset of UML state machines, the semantics described in the UML is taken into account. The UML defines the behavior of state machines as follows: “Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of (event) occurrences.” [UML09, p.564]. In this thesis state machines can react immediately to each model change because they are evaluated continuously, namely, after having finished continuous time integration steps and at Modelica event iterations. For a description of the discrete/ continuous modeling/simulation in Modelica based on the synchronous data-flow principle refer to [OEM]. Modelica event iterations are defined by the Modelica specification as follows: “A new event is triggered if at least for one variable v 0 pre(v) v 0 after the active model equations are evaluated at an event instant. In this case the model is at once reevaluated. This evaluation sequence is called ’event iteration’. The integration is restarted, if for all v used in pre-operators the following condition holds: 0 pre(v) == v 0 .” [Mod10, p.27]. If the state machine should not react immediately it is possible to evaluate the state machines only at sample events. A sample event has to be defined by the modeler and allocated to the state machine. As an example the sample duration can be the clock cycle of an electronic control unit.

4.1.1 Events and Triggers This section addresses the execution of events in ModelicaML and Modelica. An event is something that happens, for example a change in the model or a message internally of a state machine. A message is also called signal or signal event. It is always asyncron. This means, that the sender of a message does not wait to the answer of the receiver of a message. ModelicaML uses the UML events CallEvent, ChangeEvent, SignalEvent, and TimeEvent. The event construct in UML is pretty similar to the event construct in Modelica. The difference is that a signal event does not exist in Modelica. Therefore, signal events are mapped to variables and Boolean conditions in Modelica.

68

4.1 Semantics Definition of ModelicaML State Machines In Modelica an event is triggered, when the condition of a Boolean condition becomes true, the integration is halted, and the discrete evaluation is processed [OEM]. The challenge to map the abstract event construct to concrete Modelica variables and expressions is a task which is handled by the code generator. The code generation for events is described on page 107 in the section “Events and Trigger ” of the next chapter. A trigger is an abstract construct which reacts to the occurrence of an event. It is specified at transitions and is a conjunction with the guard. A trigger becomes true when an event occurs. That means when the expression which is associated with an event gets true. In this thesis a trigger is only true in the next Modelica event iteration after the event has been generated. This is addressed in the next section. Figure 4.1 shows an example of a state machine with the signal event Signal A and the change event ChangeEvent A. The change event has as condition the expression pre(x) > 2. After one second the guard of the transition from State 0 to State 0 gets true, the transition fires and the effect GEN SIGNAL(Signal A) is executed. The effect causes the signal event SIGNAL A. This has as result that the trigger of the transition from State 1 to State 2 gets true. Therefore, this transition fires and State 2 is entered. When State 2 is entered the entry-action x := 4 is executed. When x gets the value four the change event ChangeEvent A is raised. Therefore, the trigger of the transition from State 3 to State 4 gets true and this transition fires. Note, that a change event is true only in the moment when its condition changes from false to true. In contrast a guard with the same condition is true as long as the condition is true. Figure 4.2 shows a part of the simulation results of this state machine.

Figure 4.1: State Machine Example with SignalEvent and ChangeEvent

4.1.2 Event Processing This section addresses the event processing of ModelicaML events by Modelica.

69


Figure 4.2: Simulation Result of State Machine Example with SignalEvent and ChangeEvent

The UML defines the run-to-completion semantics for event processing as follows: “Event occurrences are detected, dispatched, and then processed by the state machine, one at a time.” [UML09, p.565]. The lifetime of an event, the order of event processing, and if multiple triggers can react to the same event is left to the developer. The following semantic variation points out. “It is a semantic variation whether one or more behaviors are triggered when an event satisfies multiple outstanding triggers. If an event in the pool satisfies no triggers at a wait point, it is a semantic variation point what to do with it. The ordering of the events in the input pool is a semantic variation.” [UML09, p.435]. The definition of the run-to-completion semantics is also applicable to the state machines in this master thesis. Whenever an event occurs a state machine first finishes its behavior before events, which are generated during this processing, are processed. Based on the semantic variation points above, a decision for event processing must be taken. Clocked systems like embedded hard or software often have to queue information and process them stepwise. Physical systems otherwise react immediately and simultaneously to events and usually have no memory of events from the past. All events of the event pool are processed and dispatched in parallel in the next evaluation of the state machine. Clocked systems are not of any focus in this thesis. Thus, the state machines’ semantics of this thesis is not concerned with the order in which events occur. Events are processed simultaneously and live only for one event iteration (see figure 4.1 and figure 4.2). Therefore, state machines do not require a queue for

70

4.1 Semantics Definition of ModelicaML State Machines the event pool. Clocked systems have another focus. If code for clocked systems should be generated a queue has to be implemented (see page 107, section 5.2.6).

4.1.3 Instantaneous States and Delayed Transitions This section addresses the possibility of state machines to change its state more than once in the same time instance. Simulation time can be accessed in Modelica by the global variable time. Computation takes in Modelica no simulation time, because it is a synchronous language. Therefore, also event iterations take no time in Modelica. The outcome of this is that a state can be entered and exited at the same simulated time instant. State changes result in a new event iteration of Modelica. As a result the simulation can be stated in a livelock caused by the event loop. Another problem, which must be avoided in Modelica, is that multiple state changes happen at the same evaluation of an algorithmic section. Note, the semantics of Modelica algorithmic sections is quite similar to a function. All variables’ values, which are assigned before a algorithm starts, are the inputs and the variables assigned values by the algorithm define the outputs of the algorithm. So, if multiple state changes are performed during the same evaluation of an algorithm, this cannot be seen by other model parts. Avoiding multiple state changes in the same event iteration is simple in Modelica. This can be ensured by the pre-Function [Mod10, p.27] of Modelica. Before a transition can fire its source state must be already active before the evaluation of the algorithmic section starts. Therefore, the code generation generates corresponding Modelica code (see section 5.2.5). This enforces the entire behavior to react first on events which are generated before the current algorithm evaluation. Instantaneous states are not practicable for real-time systems because the zerotime execution assumption for side-effects is not realistic [BG03]. Therefore, to simulate a clocked system it has to be either sampled [OEM+ 99] or every transition must be a delayed transition (transition with time-guard). This means that when a transition will be enabled it must stay enabled for a delayed time which is greater than zero before it fires [MEM+ 08]. On the other side instantaneous states are useful to describe the discrete behavior of a physical system. For example, the discrete state change of a tank from empty to filled takes no time, because the physical process takes to time. Therefore, it is useful to allow instantaneous state changes. Modeling with instantaneous state changes makes it possible to model livelocks. This happens if a loop exists within a state machine (see upper state machine, figure 4.3), where all guards can be true at the same time. As a consequence each loop in the graph requires at least one transition with a time-guard (see lower state machine, figure 4.3), which is greater than zero. Otherwise the model is not well formed. In large models it is not obvious if a non-delayed loop exists. To prevent a livelock other techniques like model checking have to be used to detect such failures in the model.

71


Figure 4.3: StateMachine Example with a Loop

4.1.4 Self Transition This section addresses self transitions. A self transition is a transition which has the same state as source and target. When a self transition fires it executes all exit-actions of the source state and its sub-states. Further, it deactivates the active state and all containing sub-states. Then it executes the transition effect and activates the target state. It is the same behavior as for a normal transition. A clock which starts when a state is entered, has to be restarted when a self transition fires. In this master thesis an interlevel1 -self transition will not be allowed.

4.1.5 Concurrent Regions Execution This section addresses the execution order of different regions of the same composite state or state machine. Regions, which have the same composite state or state machine as a parent, are executed in parallel, i.e. at the same event iteration. In Modelica it is not possible to specify threats which run parallel and independent of each other. The algorithmic code of a state machine is still sequential. This means, that a statement which is “higher” in a section is processed before a statement which stands at a “lower” position. To ensure a determinism execution and an explicit execution order of parallel regions clear priorities have to be given to each region. They can be represented due to unique Integer values. A lower value implies a higher priority. Integer values are easy to process by a computer but allocating Integer 1

For a description of interlevel transitions refer to section 4.1.9.

72

4.1 Semantics Definition of ModelicaML State Machines values to transitions has a bad usability. It is better to give the user an ability to sort an ordered list like in figure 4.4.

Figure 4.4: Priority Order List

4.1.6 Conflicting Transitions This section addresses what happens if two transitions with the same source state can fire at the same time. Transitions are in conflict with each other if they have the same source and overlapping guard conditions. In one event iteration only one transition is allowed to fire (compare [UML09, p.566]). If events are processed simultaneously transitions can also be in conflict with each other if more than one trigger event of outgoing transitions is dispatched out of the event pool. This is not possible in the UML because no simultaneous event dispatching exists. Resolving a determinism priority order of transitions with the same source and a target, which is no join-pseudostate, is possible by giving a unique Integer value to each transition. All priorities of transitions, which have the same state as source, have to be mutually exclusive. The transition with the lowest value has the highest priority. Such a transition is preferred over transitions which can fire but have a higher Integer value. The priority of transitions which have a join-pseudostate as target is discussed in section 4.1.14. Consider the state machine in figure 4.5. When State 0 is entered the entryaction is executed and sets x := 5. The three outgoing transitions of State 0 are in conflict now because all guards are true. The specified priority affects which transition fires. The transition from State 0 to State 3 should have the highest priority. Therefore, it has the lowermost Integer value. As a result of the given priorities the transition from State 0 to State 3 fires. Further, transitions can be in conflict with each other if they are at different state hierarchies. The source of one transition is the composite state which contains the other transition. The transition which source is the composite state is called high-level transition.

73


Figure 4.5: Conflicting Transitions Example

4.1.7 Conflicting Transitions at Different State Hierarchy Levels This section addresses the execution order of transitions which are in conflict and which source states are at different hierarchy levels. In UML transitions, which are originated from a sub-state, have higher priority than a conflict transition from one of the parent states of the sub-state (compare [UML09, p.567]). This priority schema is not factually justified as pointed out in [CD07]. Figure 4.6 shows two conflicting transitions at different state hierarchies. The state machine activates state a in the first step. A post condition of an active composite state is that exactly one state of each region is active after an event iteration . Therefore, state b must be activated. At this point, the transition from state b to state c is in conflict with the transitions from state a to state d. In this thesis a transition which source is at the highest level has the highest priority.

Figure 4.6: Conflicting High-Level Transitions

74

4.1 Semantics Definition of ModelicaML State Machines The advantage of this behavior is that the semantics is more obvious to the modeler because a lower level can be grained finer than a higher level. Each composite state can have multiple regions and these can have multiple composite states. The modeler must investigate each of these to figure out if a high-level transition can fire. With the semantics of this thesis the modeler just has to check at the highest level if a guard or trigger is true. This is particularly the case when submachines are used. These are not displayed in the same diagram and are not directly visible to the modeler. Another point is that it is very difficult to implement the UML priority schema with Modelica because then the behavior of a higher state depends on the state of a lower level. It is very difficult to implement this dynamic behavior with the static structure of Modelica. The size and the complexity of the generator and the generated code would increase.

4.1.8 Entry-/ Do-/ Exit-Actions, Effects and Activities This section addresses the possibility of states to execute actions or activities when they are entered, exited, or during dwell in a state. Further, this section addresses the possibility of transitions to perform an effect when it fires. Actions and activities are assumed to take no time. If the execution of an entryaction should take some time this has to be explicitly modeled by a separate state which cannot be left before an explicit time has elapsed. Entry-actions have to be performed immediately after a state is activated. Exit-actions have to be performed immediately before a state is being deactivated. Do-actions are performed as long as a state is active. That means, that it is executed in each evaluation of the algorithmic section, as long as the state is active. Consider the state machine in figure 4.7. State 0 is active the whole time. The do-action of State 0 is x := y + 1;. State 2 is entered every second. Each time when it is entered the action y := y + 1; is executed. Figure 4.8 shows the simulation results, when the state machine is simulated for 4 seconds. Every time when y changes its value, also x changes its value. Note, it is not allowed that within a do-action a variable depends on its own value. For example the action x := x + 1; is not allowed. This would lead to a Modelica event iteration cycle, because the continuous integration in Modelica starts only if all variables are in a stable configuration. Therefore, a do-action which depends on its own value breaks the simulation. Effects are associated with transitions and are performed when their transition fires. Actions are either pure Modelica code, which may set a variable, or even a whole activity. The order in which actions are executed is very important if data dependency exists between different actions. Data dependency between actions exists if two different actions are read or set the same variable. The execution order of actions during a state change is defined in this thesis as follows: 1. Exit-Action

75


Figure 4.7: Do-Action Example

Figure 4.8: Do-Action Simulation Result

2. Deactivate Source State 3. Transition Effect 4. Activate Target State 5. Entry-Action 6. While Target State is Active: Do-Action

4.1.9 Interlevel Transitions and Concurrency This section discusses the execution order of actions as a result of interlevel transitions and concurrency. As mentioned in the last section the execution order is particularly important if data dependency exists. Consider the state machine shown in figure 4.9. Assume that every state has an entry- and exit-action. Further, (Region x,Region y) implies Region x has a higher priority than Region y, when x < y and x! = y. The state machine starts in state a and cond1 becomes true. The question is now in which execution order

76

4.1 Semantics Definition of ModelicaML State Machines the states are activated, deactivated and in which order the related actions have to be performed. This issue is not clearly addressed in the UML specification [UML09, p. 574]. From the general state machine semantics a state cannot be activated as long as its composite state is not activated. Vice versa a composite state is not allowed to be deactivated as long as one of its sub-states is active. For the example in figure 4.9 this means that state c cannot become active before state b is active.

Figure 4.9: Interlevel Transitions and Concurrency

Further, the question is what happens with parallel regions of the target state and also of parallel states of the composite state of the target state. Some possible activation orders are: b→c→d, and then e2→g→h→i or g→e2→h→i or g→h→e2→i org→h→i→e2 . . . . In this thesis the execution order is defined as follows: 1. It activates the target of the transition because the target state is directly addressed by the modeler. Then the execution order is b→c→d→e2→. . . . 2. The states {g,h,i} are activated in order of the region execution priority. The modeler can define it exactly and the execution order is always consistent. In this example and the priority definition from above the execution order is b →c →d →e2 →g →h →i. The question of the execution order also exists for the transition from state e2 to state a. When the state machine is in state e2 and cond2 becomes true e2,f,g,h,c,i,b have to be deactivated. A composite state is not allowed to be

77

4. State Machine Semantics deactivated as long as one of its sub-states is active. Considering the region execution order and the preemption of the source state, the deactivation order in this thesis is e2 →f →d →g→h→c→i →b.

4.1.10 Terminate This section addresses the semantics of a terminate-pseudostate, which is used to end up a simulation. The semantics of a terminate-pseudostate predicts that the execution of the state machine stops. No exit behavior of any active state is executed. Further, the UML specifies that entering a terminate-pseudostate is equivalent to invoking a DestroyObjectAction. As objects cannot be destroyed in Modelica the question is whether the whole simulation or just the state machine should stop. In this thesis the execution of the state machine stops and all active states are deactivated by entering a terminate-pseudostate. This is based on the aspect that a state machine is just one part of the behavior and may be independent of the continuous behavior. If the simulation is ought to stop the modeler can invoke the Modelica terminate()-function by an effect. This stops the whole simulation.

4.1.11 FinalState This section addresses the semantics of FinalStates, which are used to describe that a region is in a stable configuration. The semantics of the FinalState predicts that when a FinalState is entered, its containing region is completed. The region is in a stable state configuration. A final-pseudostate is not allowed to have outgoing transitions. In this master thesis the containing state or state machine for this region does not terminate when all its regions are in a final state, because destroying objects is not possible in Modelica.

4.1.12 History This section addresses the semantics of ShallowHistory-pseudostates. A ShallowHistory-pseudostate stores the most recent active sub-state of a composite state. Consider figure 4.10. It shows a state machine with a simple state and a composite state. The composite state has instead of an initial-pseudostate a historypseudostate. After two seconds the composite state is entered for the first time. Because it is entered for the first time the history is empty and the default transition from the history-pseudostate fires. The state Initial entering is activated and the entry-action j := j + 1; is executed. The value of j is zero at the beginning and now as a result of the entry-action 1. The history now stores the state Initial entering as recent active state. In the next step the outgoing transition of the state Initial entering fires and the state Re-entering Composite State is activated

78

4.1 Semantics Definition of ModelicaML State Machines and the action i := i+1; is executed. The value of variable i is now 1. The history stores the state Re-entering Composite State as recent active state now. After one second the state Composite State is deactivated and SimpleState is active again. After another two seconds the state Composite State is activated again. As the history points out the state Re-entering Composite State as recent active state, this state has to be activated and i = 2.

Figure 4.10: ShallowHistory Example

UML distinguishes between shallow and deep history. Deep history represents the most recent active configuration of the composite state in which it is located. The most recent active configuration are all active sub-states (spanning all levels of hierarchy) when the composite state was recent exited. Shallow history represents only the recent active direct sub-state, but not the sub-states of that sub-state. This master thesis only considers the shallow history because it is very difficult to manage deep history behavior with pure Modelica code. The severity to manage deep history is that at run-time the state has to decide if the initial state or the most recent active state will be activated. Consider the activation of state a in figure 4.11. It makes a difference if state a will be activated as a result of the activation of the state Composite State and its deep history behavior or as a result of firing of the outgoing transition of state b. Assuming that the most recent active state of a is state DeepHistory, this has to be activated when a is activated through the state Composite State. In the case when the transition from b fires the state Initial has to be activated. To achieve such a behavior the whole activation of all sub-states must be explicitly generated instead of just activating the initial state of the first sub-level of the composite state. This increases the code generation effort. The implementation in Modelica of shallow history behavior is described on page 111 in section 5.2.6.

79


Figure 4.11: Deep History Example

4.1.13 OR-Compound Transitions This section addresses the semantics of OR-compound transitions. OR-compound transitions are a chain of transitions joined via junction or choice. OR-compound transitions enable the modeler to merge multiple paths into a single path. This decreases the visual complexity of a state machine and avoids that a transition with the same effect has to be modeled multiple times. Further, OR-compound transitions can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. The guards have to be mutually exclusive or at most one transition must have the guard else. ORcompound transitions contain a junction or a choice-pseudostate. A junction realizes a static conditional branch. All guards are evaluated before any effect associated with the transitions is executed. Consider the state machine in figure 4.12. Assuming in state a i=0. The state changes from state a to state b because the effect i := 4; is executed after the guards are evaluated. Conversely, a choice realizes a dynamic conditional branch. In this case first the guard of the incoming transition is evaluated before the effect of this transition is executed. Afterwards, the guards of the outgoing transitions are evaluated and one transition is enabled. Then the effect of the enabled transition is executed. Consider the state machine in figure 4.13. The effect i := 4; is executed before the guards are evaluated. Therefore state c will be activated.

80

4.1 Semantics Definition of ModelicaML State Machines

Figure 4.12: Junction Example (cf. [UML09, p.545])

Figure 4.13: Choice Example (cf.[UML09, p.545])

4.1.14 AND-Compound Transitions This section addresses the semantics of AND-compound transitions. AND-compound transitions are a chain of transitions joined via join or fork. While OR-compound transitions just activate or deactivate a single state ANDcompound transitions activate/deactivate several states of different regions. ANDcompound transitions have a fork-pseudostate as source or a join-pseudostate as target. This section describes the activation order of states which are reached from a fork-pseudostate and the deactivation of states which outgoing transition has a join-pseudostate as a target. Further, this section addresses conflicting transitions between transitions, which target is a normal state, and which target is a join-pseudostate. Consider the example in figure 4.14. The black initial-pseudostate activates at the beginning the state a. The outgoing transition of state a has a fork-pseudostate as target. A fork-pseudostate has only the constraint that it must have at least two outgoing transitions and that the target of all outgoing transitions of the fork-pseudostate has the same composite state as superstate. The state machine in figure 4.14 fulfills these conditions and is well formed. At this point the question is in which sequence states b,c,d,f,i are activated. State b has to be activated before any of its sub-states can be activated. The regions of state b have a priority order (as displayed in the grey box on the lower right side) and the outgoing transitions from the fork-pseudostate have the priority order (as display in the black box on

81

4. State Machine Semantics the upper right side). Consider only the region priorities. A possible activation order is b→c→d→f→i. On the other hand the modeler has the ability to give a special activation order by prioritizing the outgoing transitions of the fork-pseudostate. Then the transition priority has a higher priority than the region priority. This results in the execution order b→d→f→c→i.

Figure 4.14: Fork and Join

When b,c,d,f,i are activated the state machine can change in the next event iteration its state to the active configuration set {b,c,e,g,i} or to the active state {j}. At this point two questions occur. First, will the state machine change in the next event iteration from state f to state g. Second, a join-pseudostate will have a higher priority than a normal transition? A join-pseudostate is always located on a higher level than the source of its incoming transitions. This is evidence for the modeler that this transition has a higher priority than a normal transition. In the semantics of this thesis a join-pseudostate has a higher priority. Therefore, the deactivation order of the states depends on the join-incoming transitions

82

4.1 Semantics Definition of ModelicaML State Machines priority value and the region priority value of the remaining regions Region 0, Region 3. With this solution the modeler can define the execution order explicitly. The resulting deactivation order for the state machine in figure 4.14 is: e→g→c→i→b.

4.1.15 Submachine This section addresses the semantics of submachines. A submachine is a state machine that is referenced by a simple state. This becomes a submachine state. The state machine that contains the submachine state is called the contained state machine. The same state machine may be referenced more than once in different submachine states. In this master thesis a submachine state is semantically equivalent to a composite state. The regions of a submachine are nested into the submachine state like the regions of a normal composite state. A submachine may have its own state machine diagram. Therefore, it is not allowed to draw interlevel transitions to states contained in the submachine. A semantically equivalent transition can be modeled by using entry/exit points as targets/sources of transitions. Entry-, Exit- and Connection Reference-Point Entry-/exit-points belong to the submachine. They are referenced by connection reference-points of the submachine state. An entry point has different semantic meanings. If all outgoing transitions have their target, in the same region it is equivalent with a junction. If all transitions have their targets in different regions of the same orthogonal composite state it is a fork. The fork semantics is not supported by the code generator at the moment. The following in the UML specification defined semantics for entry points is also valid for this thesis. “Entering via an entry point implies that the entry behavior of the composite state is executed, followed by the (partial) transition(s) from the entry point to the target state(s) within the composite state.” [UML09, p.556]. An exit point has the same semantics as a junction if only one incoming transition exists. If it has more than one incoming transition and the source of all incoming transitions is from the same orthogonal state, it has the join semantics. Otherwise the state machine is not well formed. The join semantics is not supported by the code generator at the moment .The following in the UML specification defined semantics for exit points is also valid for this thesis. “Exiting via an exit point implies that first behavior of the transition with the exit point as target is executed, followed by the exit behavior of the composite state.” [UML09, p.556].

83

4. State Machine Semantics The UML specification allows multiple references of entry/exit points of the same connection reference-point [UML09, p.530]. This is also not restricted by its constraints [UML09, p.530,p.553]. This master thesis allows only one reference to either an entry or an exit point by a connection reference-point, because otherwise the state machine behavior is not traceable. Consider the state machines in figure 4.15. StateMachine 0 is the main state machine. StateMachine 1 is a submachine because it is referenced by state S 2. S 2 has two connection reference-points. One reference-point ( ) has a reference to the entry point of StateMachine 1 and the other reference-point (⊗) has a reference to the exit point of StateMachine 1.

Figure 4.15: Submachine Example

When the outgoing transition of state S 1 fires state S 2 is activated and state a is also activated because it is the target of the outgoing transition of the entry point. When the outgoing transition of state a fires, state a will be deactivated and the outgoing transition of the connection point-reference fires. This deactivates state S 2. If StateMachine 0 would be also a submachine it will be possible that the outgoing transition of the connection reference-point targets another exit point. In this case the outgoing transition of the connection reference-point of this exit point would fire and deactivate the submachine state. State b would be activated if S 2 would be directly activated as a target of a simple transition.

4.1.16 Conclusion In this section the semantics for ModelicaML state machine has been discussed and defined. The UML state machine semantics has been analyzed with the target to map this semantics to state machines described by Modelica language constructs. For the description and comparison of other state machine semantics refer to the

84

4.1 Semantics Definition of ModelicaML State Machines following papers [Har87, HN96, HK04, Bee94, CD07, And03, GB03, HR07]. The next chapter addresses the implementation of a ModelicaML modeling suite and the concrete mapping of ModelicaML state machines to Modelica code.

85

5 Implementation “In theory, there’s no difference between theory and practice. In practice, there is! ” attributed to Jan L. A. van de Snepscheut

This chapter addresses the implementation of a modeling and validation tool for ModelicaML models and the transformation of a ModelicaML state machine into Modelica code. Additionally, the interaction between state machines and continuous behavior is described. The implementation of the modeling tool builds up on Eclipse and Papyrus UML. Eclipse is based on a component-based architecture. A small kernel (OSGi) is extended by components, also called plug-ins. Papyrus UML uses the Eclipse framework and the Eclipse provided modeling tools1 . This includes the Eclipse UML2 EMF-based-metamodel2 . The ModelicaML modeling tools are implemented as Eclipse plug-ins. They use Eclipse and the Papyrus UML3 modeling environment. The implementation of the code generator builds up on the prototypic implementation of code generation templates for Acceleo4 by Wladimir Schamai5 . With this existing implementation it was possible to produce Modelica code for the static structure of a ModelicaML models and for equations, algorithms, and activities. The static structure of the implementation of state machines was partly available. Figure 5.1 shows an overview of the architecture of the developed tool-suite. The rectangles with the solid border represent the plug-ins developed within this master thesis. These plug-ins are described within the following sections. The rectangles with the dashed border represent the used and extended plug-ins. This chapter splits up into the description of the developed plug-ins for the modeling tools, the plug-ins for validation of ModelicaML models, and the Modelica code generation for ModelicaML state machines. 1

http://www.eclipse.org/modeling/ http://www.eclipse.org/modeling/mdt/?project=uml2 3 http://www.papyrusuml.org 4 http://www.acceleo.org 5 EADS Innovation Works, Germany, http://www.eads.com, http://www.openmodelica.org/index.php/developer/tools/134 2

87

5. Implementation

Figure 5.1: Plug-in Architecture

5.1 Modeling Tool Support The developed modeling plug-ins com.eads.modelicaml, com.eads.modelicaml.tabbedproperties, com.eads.modelicaml.diagram.composite use and extend Eclipse and Papyrus UML.

5.1.1 Papyrus UML The Papyrus UML modeling tool is a dedicated tool for modeling within UML2. This open source tool is based on the Eclipse environment and is implemented as a plug-in editor using the Eclipse Graphical Editing Framework (GEF)6 and with a Model View Controller architecture. Figure 5.2 shows the architecture of GEF. Some of the key features of Papyrus UML are Eclipse UML2 compliance, respect of the UML2 standard as defined by the OMG, respect of the DI2 (Diagram Interchange) standard, profile development support, nested profiles support, and OCL constraints in profile descriptions. Papyrus supports editors for the UML diagrams Class, Composite, Use Case, Deployment, Component, Profile, Sequence, State Machine, and Activity. Papyrus UML provides some extension points which facilitate the extension of the editors. At the moment Papyrus UML is being redeveloped and supposed to become the standard Eclipse modeling tool for UML 6

http://www.eclipse.org/gef/

88

5.1 Modeling Tool Support

Figure 5.2: Model View Controller Architecture of GEF (cf. [Pil09])

[Pap09] within Eclipse.

5.1.2 Modeling Support The plug-in com.eadsiw.modelicaml extends Papyrus UML with modeling features. Firstly, it extends Papyrus UML with the ModelicaML profile. This enables modelers to apply the profile to their models. Secondly, the plug-in extends the Papyrus UML editor palettes of the class, composite, activity, and state machine diagrams with ModelicaML elements. Additionally, each element is provided with the target filter which allows the creation of an element only when the ModelicaML profile is applied to the model. Otherwise, the element would be created, but the application of the stereotype cannot be done. Figure 5.3 shows the four different pallets of the ModelicaML diagram editors with ModelicaML elements. Thirdly, the plug-in extends the Eclipse outline context menu with popupactions which allow to create ModelicaML elements and diagrams. Figure 5.4 shows the available context menus and the corresponding items. Further, it is possible to start the model validation, or the Modelica code generation by popupactions.

5.1.3 Property View Support Besides the improvement of the modeling capabilities, the facility of model inspection should be improved. Therefore, another plug-in has been developed which shows model properties in the tabbed property view of Eclipse. Additionally, it

89

5. Implementation

Figure 5.3: Class, Composite, Activity, State Machine Diagram Editor Palettes with ModelicaML elements

Figure 5.4: Context Menu of the Outline

enables the modeler to change the properties of the model easily in the property view.

90

5.1 Modeling Tool Support The plug-in com.eads.modelicaml.tabbedproperties extends the property view of Papyrus UML with ModelicaML property tabs and property sections. A tab presents defined categories and a section presents special properties like the name of an element. The ModelicaML tab shows the main properties of a UML element and its applied ModelicaML stereotype. Other properties of a stereotype are shown in addition sub-tabs. The property view is context sensitive. When the selection of an element or the applied stereotype of an element changes the appearance of the property view changes. Therefore, each property section has its own filter, which determines if an element is visible or enabled. Figure 5.5 shows an example property view of a class property with stereotype Component. The developed plug-in contains property tabs and sections for nearly each ModelicaML stereotype and property. Additionally, it improves the accessibility, clearness, and usability of ModelicaML model elements. A detailed description of each property view element is not given as this is beyond the scope of this thesis.

Figure 5.5: Tabbed Property of ModelicaML Model Element Besides the property view elements, the developed plug-in provides the stereotype documentation view. This view gives a context sensitive description of the applied ModelicaML stereotype of an element. Figure 5.6 shows this view with the description of the ModelicaMLStateMachine stereotype.

Figure 5.6: Stereotype Documentation View

91

5. Implementation

5.1.4 Composite Diagram Extension The notion of the ModelicaML profile specifies that internal structure elements show a user defined icon (see section 3.3.2 and figure 3.43). In Papyrus UML it is not possible to alter or extend the figures which display the UML elements by extension points. Further, the original papyrus plug-ins shall not be altered. This would have the effect that with each new version of Papyrus UML a new custom Papyrus UML version had to be produced. Therefore, it is required to develop a new editor which extends the existing composite structure diagram editor. The plug-in com.eadsiw.modelicaml.diagram.composite implements a new composite structure diagram editor which inherits all features from the existing papyrus composite editor and changes the figure of the UML element Property. The new editor is integrated into Papyrus like the other existing editors. To create the new diagram type the plug-in also provides a new pop-up action which creates this diagram. The new CompositeModelicaML diagram with the new Property figure makes it possible to draw diagrams, which can be compared to the Modelica connection diagram and mainly improves the clarity of the diagram.

5.1.5 Conclusion The three plug-ins which are described in this section make modeling easier, faster, and clearer for the modeler. They improve the handling of the ModelicaML profile within papyrus. During modeling the model has to be validated against the constraints which are specified in appendix A. For this purpose a validation algorithm and a validation view have been developed. The algorithm uses the Acceleo framework. The next section describes the process from a model to Modelica and the resulting code.

5.2 From Model to Modelica Code The translation from ModelicaML models to Modelica is done in two steps. Firstly, the ModelicaML constraints have to be validated for the model. Therefore, the modeler can start the validation process at each time by the pop-up action “Validate ModelicaML model ” of the context menu (see figure 5.4). The result of the validation is shown in the new view ModelicaML Validation. This view only shows ModelicaML warnings and errors. An example for a validation result within the view is shown in figure 5.7. Besides the description of the error or warning the view shows the location of the defective element. It is possible to locate this element in the papyrus editor by the pop-up action “Locate in Papyrus Editor ” or to open it in the standard UML Eclipse editor by a double-click on the element item in the view. Secondly, if the model is error free the modeler can start the code generation process by the pop-up action “Generate Modelica code from this ModelicaML model ” (see figure 5.4). The validation and generation process uses Acceleo. Acceleo is

92

5.2 From Model to Modelica Code

Figure 5.7: ModelicaML Validation View

described in the next section. Accordingly, the validation and generation processes are described.

5.2.1 Acceleo Acceleo is a code generator, which works on the meta-level of a model. It transforms an input model to code in a defined target language. Acceleo is based on EMF, and is thus directly compatible with tools created around this framework. UML2 models are compatible with Acceleo. Acceleo allows to provide new code generators for a given technological platform as a module by using an Acceleo extension point. A module consists of several templates and each template consists of several scripts. The structure of the generated code can be determined in the different templates. Besides the templates Java services can be used to permit complex operations on primitive types and elements of the meta-model. Every script starts with the declaration tag which defines the metamodel element to which the script will be applied to and the name of the script. The content is the text that starts after the declaration of the script, and ends at the beginning of the next script or the end of the file. In Acceleo execution chains are used to execute the generation for a target application. Chains are equivalent with “Makefiles”. They allow the chaining of several generations and operations on models. In this thesis templates were developed to transform ModelicaML state machines to Modelica. The following sections describe the resulting validation and code generation algorithms, which are specified through several templates and the resulting Modelica code for state machines.

93

5. Implementation

5.2.2 Validation The pop-up action “Validate ModelicaML model ”starts the validation by invoking the Acceleo validation chain. The chain gets as an argument the path of the UML model-file. It is important that the model is always saved before the validation process starts, because only the stored file is analyzed. The validation chain calls the template file which contains the validation scripts. Each script checks certain properties and then calls further scripts for additional checks. If an error is detected a script is called which creates error messages in the validation view. Besides the creation of the error messages, a xml-file is created within the project folder with the validation results. Figure 5.8 shows the different scripts of the validation process and the objects on which the scripts are invoked.

Figure 5.8: Validation Scripts

The script uml.Model : ModelicaML standalone validator is the starting point of the validation. It calls the script validation for the model element of the ModelicaML model. The script validation recursively calls itself for all owned packages and classifier. Additionally, it calls different scripts for several types of owned elements, like Activity or StateMachine. Each script calls the script uml.Element : alert to report errors or warnings. To get a better overview, the different scripts have been distributed over different template files. Due to practical reasons, validation rules were implemented as Acceleo scripts instead of embedding them directly into the profile as constraints specified in OCL. It was easier to implement, to test and to display the constraints. The validation features of papyrus are not sufficient at the moment.

94

5.2 From Model to Modelica Code

5.2.3 Code Generation The code generation is invoked by the pop-up action “Generate Modelica code from this ModelicaML model ”. This action starts the Acceleo chain code generation.chain from the plug-in com.eadsiw.modelicaml.gen.modelica. The chain gets as an argument the path of the UML model-file. The code generation of the class and package structure of the model is oriented towards the grammar of Modelica [Mod10, Appendix B.2,p.220]. Each class-file begins with the Modelica keyword within followed by the full package name. The stereotype name of a class is mapped to the corresponding Modelica class prefix. Each class instantiates all owned variables and components. The composite structure connections between the ports are mapped to Modelica connections represented by the Modelica keyword connect. Listing 5.1 shows for example the UML class SimpleStateMachine with Stereotype Model. It is located in the package simpleexample. After the definition of the variables and components the behavior code is located. The concrete generation of all stereotypes and its properties is beyond the scope of this master thesis. The following sections describe the Modelica code generation of the structure and behavior of UML state machines. The class is the context of state machines. Listing 5.1: ”Modelica class structure” within simpleexample ; model Si mp le St at eM ac hi ne Integer x ; Real t ; ... end Si mp le St at eMa ch in e ;

5.2.4 State Machine Structure Code The code generation generates a Modelica record structure for the state machine and its regions and states. A record is a class for specifying data without behavior. The behavior is in an algorithm section of the context class of the state machine. The behavior of each state is not nested in its own record because of the single assignment rule. For example, a state has to activate a state at a different hierarchy level. Therefore, it is required that this state can access the variables of the other record. If each state record has its own algorithm section only one of the algorithm section can write a variable. The architecture of the record structure is based on the GoF composite and state pattern [GHJV95], [Z¨ un01, p. 77]. That means that a variant of the composite pattern is used to form the hierarchy. A state machine is nested within its context class. Each record of a region is nested in the record of a state machine or composite/ submachine state (see figure 5.9). At run-time each state machine,

95

5. Implementation region, and state is an object like in the state pattern. Simple, initial, or final states share in each case a common record. The state handler of the state pattern is the algorithm section of the context class.

Figure 5.9: Modelica State Machine Structure The state machine and each state have the variables active, timeAtActivation, stime, and selfTransitionActivated. Active indicates whether a state is active (active = 1 ) or inactive (active = 0 ). TimeAtActivation is set to simulation time when the state is activated. Stime is a local timer. The value is calculated by the statement time - timeAtActivation. SelfTransitionActivated is an auxiliary variable, which will be true when a self transition fires. Listing 5.2 shows the Modelica definition of SimpleState. InitialState and FinalState have the same structure as SimpleState, but have a different annotation for the Modelica icon. Listing 5.2: ”Simple State Definition ” record SimpleState Boolean active ; Real timeAtActivation ; Real stime ; Boolean s e l f T r a n s i t i o n A c t i v a t e d ; end SimpleState ;

Additionally, the state machine has the variable startBehavior. It is used to initialize the state machine behavior. Each region has the variable numberOfActiveStates. This variable is used to assert that in a region there is never more than one state active. Listing 5.3 shows the Modelica structure code for the state machine shown in figure 5.11. Listing 5.3: ”State Machine Defintiion ” record S i m p l e S t a t e M a c h i n e _ S t a t e M a c h i n e _ S t a t e M a c h i n e _ 0 // lib properties STATE MACHINE

96

5.2 From Model to Modelica Code Boolean active ; // indicates if the state is active. Real timeAtActivation ; // time when the state is entered. Real stime ; // local timer. Boolean s e l f T r a n s i t i o n A c t i v a t e d ; Boolean startBehavior ; S t a t e M a c h i n e _ 0 _ R e g i o n _ 0 Region_0 ; // instantiation // REGION records record S t a t e M a c h i n e _ 0 _ R e g i o n _ 0 // SIMPLE STATES instantiation SimpleState State_0 ; SimpleState State_1 ; InitialState Initial_0 ; Integer n u m b e r O f A c t i v e S t a t e s ; // debug end S t a t e M a c h i n e _ 0 _ R e g i o n _ 0 ; ... end S i m p l e S t a t e M a c h i n e _ S t a t e M a c h i n e _ S t a t e M a c h i n e _ 0 ;

A special record is required if, instead of an initial-pseudostate, a shallowHistory-pseudostate is used. This record must have a type with an enumeration of all states of the region. Further, the variable lastActive is an instance of this type. Listing 5.4 shows an example for such a record. Listing 5.4: ”ShallowHistory Record” record R e g i o n _ 0 _ H i s t o r y S t a t e Boolean active ; Real timeAtActivation ; Real stime ; Boolean s e l f T r a n s i t i o n A c t i v a t e d ; type HistoryStateT = enumeration ( State_0 , State_1 ) ; HistoryStateT lastActive ; end R e g i o n _ 0 _ H i s t o r y S t a t e ;

Besides the generation of the state machine structure, the structure for signals has to be generated. A signal is generated as a record. This record has at least the Boolean variable occurrence. Occurrence becomes true when a signal event is raised. A signal can have further user defined attributes. Listing 5.5 shows an example for a simple signal record. Change events and time events have no structure. The are instantiated as Boolean variables. Listing 5.5: ”Signal Record” // SignalEvent : ev_request definition record e v _ r e q u e s t _ D e f i n i t i o n Boolean occurrence ; end e v _ r e q u e s t _ D e f i n i t i o n ;

Figure 5.10 shows the different scripts and the elements which they process. The links show on which elements the next script is invoked. The script add inc structure is the starting point for this chain. The main structure of the code is built up by

97

5. Implementation the script uml.Region : RegionModelicaClasses. This script recursively calls itself for the regions of the owned composite states and submachine states. This forms the hierarchical structure of the code.

Figure 5.10: State Machine Structure Scripts

Before the behavior code generation is shown, a simple state machine example is described as it is generated by this code generation.

5.2.5 Simple State Machine Example Assume, the behavior defined by the state machines depicted in Figure 5.11 shall be simulated by using Modelica. The state machine sets and reacts to the discrete Integer variable x and to the continuous Real variable t. The variable x is by default zero at the start of the simulation. The variable t is calculated by the equation der(t) = time, where time is the simulation time.

Figure 5.11: Simple State Machine Example in Modelica

This state machine defines a part of the behavior of class SimpleStateMachine. The expected execution behavior is as follows:

98

5.2 From Model to Modelica Code When the state machine is initialized it is in the initial-pseudostate, Initial 0. When the execution is started the state machine changes its state to State 0. As soon as the guard condition, [t > 1 and x < 2], is true, State 0 is exited, the transition effect, x := 1, is executed and State 1 is entered. The state machine is again in a stable configuration that is referred to as an active configuration. As soon as the guard condition, [t > 1.5 and x > 0], becomes true, State 1 is exited, the effect, x := 2, is executed and State 0 is entered again.

Listing 5.6 shows Modelica code that performs the behavior described above. Figure 5.12, 5.13, and 5.14 present the simulation results. Listing 5.6: ”Simple State Machine” model S imp le St at eM ac hi ne Integer x ; Real t ; ... SimpleState State_0 ; SimpleState State_1 ; InitialState Initial_0 ; ... equation der ( t ) = time ; algorithm // behavior of StateMachine_0 S t a t e M a c h i n e _ 0 . s t a r t B e h a v i o r : = true ; // start behavior when S t a t e M a c h i n e _ 0 . s t a r t B e h a v i o r then // initial S t a t e M a c h i n e _ 0 . a c t i v e : = true ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = true ; end when ; ... // local time behavior // start transition code if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e ) then // initial - pseudostate behavior S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ; end if ; if ( S t a t e M a c h i n e _ 0 . a c t i v e ) then // start state_0 behavior if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e ) then if t > 1 and x < 2 then // guard S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = false ; x : = 1; // effect S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = true ; end if ; // start state_1 behavior elseif pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e ) then if t > 1 .5 and x > 0 then // guard

99

5. Implementation S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = false ; x : = 2; // effect S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ; end if ; end if ; end Si mp le Sta te Ma ch in e ;

Figure 5.12: State 0 Behavior

Figure 5.13: State 1 Behavior

Figure 5.14: Behavior of Variable x and t

The execution of this Modelica code has to be investigated in detail. When the model SimpleStateMachine is instantiated and the initial conditions are solved the class variables have the following values: Initial_0 = true , pre ( Initial_0 ) = true , State_0 = false , pre ( State_0 ) = false , State_1 = false , pre ( State_1 ) = false , x = 0 , pre ( x ) = 0 , t = 0 , pre ( t ) = 0 .

Note, the pre() function returns the “left limit” y(tpre ) of variable y(t) at a time instant t. At an event instant, y(tpre ) is the value of y after the last event iteration at time instant t. The solver does not start the integration until the variable configuration is stable. The Modelica specification [Mod10, p.84] defines that as follows:

100

5.2 From Model to Modelica Code “The integration is halted and an event occurs whenever a Real elementary relation, e.g. ’x > 2’, changes its value. The value of such a relation can only be changed at event instants [in other words, Real elementary relations induce state or time events]. The relation which triggered an event changes its value when evaluated literally before the model is processed at the event instant [in other words, a root finding mechanism is needed which determines a small time interval in which the relation changes its value; the event occurs at the right side of this interval]. Relations in the body of a when-clause are always taken literally. During continuous integration a Real elementary relation has the constant value of the relation from the last event instant.” Moreover, Modelica specification [Mod10, p. 25] defines that “A new event is triggered if at least for one variable v “pre(v)! = v” after the active model equations are evaluated at an event instant. In this case the model is at once reevaluated. This evaluation sequence is called “event iteration”. The integration is restarted, if for all v used in pre-operators the following condition holds: “pre(v) == v”.” The first event is generated by the condition: if (StateMachine 0.Region 0.Initial 0.active) Then the following code is executed. S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ;

When this event is generated the values are: Initial_0 = false , pre ( Initial_0 ) = false , State_0 = true , pre ( State_0 ) = false , State_1 = false , pre ( State_1 ) = false , x = 0 , pre ( x ) = 0 , t = 0 , pre ( t ) = 0 .

At this point the condition “pre(v)! = v” is true for State 0. Now the first event generation takes place. This means that the equation system is re-evaluated once again. This re-evaluation changes the values as follows. Initial_0 = false , pre ( Initial_0 ) = false , State_0 = true , pre ( State_0 ) = true , State_1 = false , pre ( State_1 ) = false , x = 0 , pre ( x ) = 0 , t = 0 , pre ( t ) = 0 .

If no further expression (i.e. conditions for the transitions), based on the new values, becomes true, no variables (that are involved in expressions) change their

101

5. Implementation value. Thus, no event is generated, the solver starts the continuous integration and advances the time by the required integration time steps. After the integration in the first time step all variables’ values are still the same except the value of the variable t that is increased based on the result of evaluation of the equation der(t) = time. At this point the entire equation system is evaluated (i.e. the equation section as well as the algorithm section). The solver continues the integration step by step until the expression “pre(State 0) and t > 1 and x < 2” becomes true and the code for the transition is executed: // start state_0 behavior if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e ) then if t > 1 and x < 2 then // guard S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = false ; x : = 1; // effect S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = true ; end if ;

When this event is generated the values are: Initial_0 = false , pre ( Initial_0 ) = false , State_0 = false , pre ( State_0 ) = true , State_1 = true , pre ( State_1 ) = false , x = 1 , pre ( x ) = 0 , t = ( ca. ) 1 .0001 , pre ( t ) = ( ca. ) 1 .

At this point the condition “pre(v)! = v” is true for the following variables: State 0, State 1, x and t. Now the event generation takes place. This re-evaluation changes the values as follows. Values after 1st event iteration: Initial_0 = false , pre ( Initial_0 ) = false , State_0 = false , pre ( State_0 ) = false , State_1 = true , pre ( State_1 ) = true , x = 1 , pre ( x ) = 1 , t = 1 .0001 , pre ( t ) = ( ca. ) 1 .0001.

Since no further expression becomes true based on the new values the solver resumes the continuous integration and advances the time by the required integration time steps. The continuous integration is stopped once again when t becomes greater than 1.5 (see condition for the second transition: “pre(State 1) and t > 1.5 and x > 0”) and the following code is executed: // Transition from State_1 to State_0 elseif pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e ) then if t > 1 .5 and x > 0 then // guard

102

5.2 From Model to Modelica Code S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = false ; x : = 2; // effect S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ; end if ; end if ;

When this event is generated the values are: Initial_0 = false , pre ( Initial_0 ) = false , State_0 = true , pre ( State_0 ) = false , State_1 = false , pre ( State_1 ) = true , x = 2 , pre ( x ) = 1 , t = ( ca. ) 1 .5001 , pre ( t ) = ( ca. ) 1 .5.

Again an event iteration (re-evaluation of the equation systems) takes place that changes the values as follows. Values after 2nd event iteration: Initial_0 = false , pre ( Initial_0 ) = false , State_0 = true , pre ( State_0 ) = true , State_1 = false , pre ( State_1 ) = false , x = 2 , pre ( x ) = 2 , t = ( ca. ) 1 .5001 , pre ( t ) = ( ca. ) 1 .5001

If no further expression becomes true after the re-evaluation (2nd event iteration), and thus, no variables’ values are changed (i.e. pre(v) == v) and, subsequently, no events were generated, the solver resumes the continuous integration. In fact, no further events are generated in this model any more because the state machine is now in the State 0 again and x = 2, hence, the if-condition for the transition to State 1 will never become true. Thus, continuous integration will continue until the stopTime. The change of the states is depicted on the plot in Figure 5.12 and 5.13. Note, the Pseudostate Initial 0 is activated and deactivated at the same time instance, i.e. no simulated time has elapsed. In conclusion, it can be said that Modelica code for a ModelicaML state machine is evaluated continuously, namely, after each finished continuous integration step and, if there are event iterations, at each event iteration. The next section describes the Modelica code for ModelicaML state machine behavior.

5.2.6 State Machine Behavior Code The behavior of state machines consists of the change between states, effects, entry-, do-, exit- actions, and the occurrence of events. It is important that the change between states and the associated activities is handled in the right order. Further, the handling and generation of events have to be considered. Time- and change-events occur when their conditional expressions become true. Signal events

103

5. Implementation occur when they are raised by a transition effect or an entry-, do- ,exit-action. The semantics of the state machine defined by Modelica has to be the same as defined in chapter 4. Implementation Variants of State Machine Behavior in Modelica The implementation of state machines in Modelica can be done in different ways. One possibility in Modelica is to define a library which use equations. “Model libraries are collections of reusable model parts and subsystems in a modeling and simulation tool.” [Tum02]. An existing state chart library for Modelica is StateGraph2 [OME+ 09]. The advantage of using a library is that the execution semantics of the state machine is understandable just by inspecting the library classes. Another possibility is to generate algorithmic code, which represent the state machine behavior. [DHBN08]. In order to understand the execution semantics of generated code one has to understand the code generation algorithm. The advantage of a code generator is that it is more flexible than a library. The semantics of a state machine is independent from the model. If another semantics of a model is required a new code generation algorithm has to be implemented or the existing code generation has to be changed. The model itself is still the same and does not have to be altered. Another advantage is, neither Modelica language enhancements nor special libraries are necessary. The state machine model is automatically mapped onto standard Modelica constructs (if-when-clauses) and can be simulated with any common Modelica standard simulator. Further, the model is independent of the target simulation language. It can be translated into several languages like Modelica, VHDL-AMS, Java, or even C. Another question which must be considered is, whether the state machine is expressed by the Modelica algorithmic code or by the Modelica equation code. The StateGraph2 library [OME+ 09] uses equations to express state machines in Modelica. Algorithmic codes are always causal. It is executed exactly in the same way it is defined. In contrast, equation codes are acausal. The execution order depends on the data dependency of the involved variables. This makes it easy to implement many tasks. Otherwise it is difficult to describe causal procedures by equations. The behavior of state machines is always causal. The next action of a state machine depends only on the current state of the system. Further, an action itself consists of a number of sub tasks which have to be executed in the right order. To express this execution order only by data dependency is very complex and it is not understandable by inspecting the code. As a result of the reasons above in this master thesis a code generator is used to transform the state machines into Modelica algorithmic code. The following sections and paragraphs describe the concrete state machine elements as they are defined by Modelica. Besides the generated Modelica code,

104

5.2 From Model to Modelica Code the position in the algorithm section is essential. As an algorithm section is processed sequentially, statements, which are “higher” in the algorithm section are processed earlier and have therefore a higher priority than statements, which are at a lower position. For example, the priority of the different regions is mapped to the position in the Modelica algorithm code. The priority of transitions, which are in conflict with each other at different hierarchy levels (see section 4.1.7), is also solved by this mapping. The behavior of high-level transition is above the code for the behavior of transitions at a lower level. Therefore, they are processed with a higher priority. At the beginning, the code of the region with the highest priority of the state machine is stated. After this code the code from the nested composite- and submachine-states is stated. When all nested behavior is stated the behavior from the concurrent region with lower priority is stated. The mapping of the transition behavior results in a nested code structure for the state machine hierarchy and the concurrent regions. The transition behavior of states from the same region is mutually exclusive. Therefore, it is mapped to an if-elsif-else then control structure and it is ensured that always only one state from the same region can have transition behavior. State Machine Behavior Modelica Code Structure As already mentioned the order of the generated code is very important for the semantics of the state machines. Therefore, the algorithm 5.2.1 shows the order of the resulting Modelica algorithm code. At the beginning, change-, time-, and signal-events are generated if required. When an event is generated the value of the event variable changes. A transition can react to it in the same event iteration because the current value is different to the pre-value of the event variable. Afterwards, the initialization of the state machine is stated in the code. Accordingly, the region code is generated in the order of their priority. After that code the termination code is stated. This will only be processed if the state machine reaches a terminate-pseudostate. At the end debug code is generated. Algorithm 5.2.1: stateMachineBehaviorCode(StateM achine) changeEventsStatements absoluteTimeEventsTimeStatements relativeTimeEventsStatements signalEventsStatements initializeStateMachine for each Region.sortRegion() do regionBehaviorCode(Region) terminateCode regionDebugCode Algorithm 5.2.2 shows the structure of the region behavior code. The region behavior code starts with the local time management. This sets and calculates the

105

5. Implementation variables timeAtActivation and sTime. Afterwards, the history nodes, if present, are set to the current active states. It doesn’t matter if the history code is located before the transition code or after the transition code. Now the transition code is generated for the region. It is nested within an if-condition if the state machine has a sampling expression. In this case the transition code is executed each time when the sampling expression becomes true. Accordingly, the code for the do-actions and the code of join-pseudostates follow. At the end of the region behavior code the region behavior code of composite states and submachine states are stated. The code generation invokes the script regionBehaviorCode recursively at this point. Algorithm 5.2.2: regionBehaviorCode(Region) set local Time Behavior set History Node to Current Active State comment: Start Transition Code if SamplingExpression  transitionBehaviorCode(Region) then do code  join code for each CompositeState for each Region.sortRegions() do do regionBehaviorCode(Region) for each SubM achineState for each Region.sortRegions() do do regionBehaviorCode(Region) Algorithm 5.2.3 shows the structure of the transition behavior code. The code starts with the behavior code for the initial- and shallowHistory-pseudostates. These states are auxiliary states and are directly processed in favour. The behavior code for each state is nested within an if-clause. This clause will only be processed if the parent state is still active. Therefore, it is ensured that a transition can never fire if the parent is not active. Algorithm 5.2.3: transitionBehaviorCode(Region) initialBehaviorCode shallowHistoryBehaviorCode if (parent  is still active) for each State if (stateis pre active) then  do then TransitonCode(State) Algorithm 5.2.4 shows the structure of a simple transition code. The concrete execution of a compound transition depends on the pseudostates which are involved in the chain of transitions from one state to another. This example directly

106

5.2 From Model to Modelica Code connects two states. The transition with the highest priority is in the if-clause. Then the other transitions follow in the order of their priority in the else-if-clauses. If the guard is empty the condition is set to true. A trigger is optional. Entry-, and exit-actions are only generated if available. Algorithm 5.2.4: transitionCode(State) comment: First Transition (Highest Priority) if guard [and trigger] execute exit-action     deactivate active state then execute effect   activate transition target state    execute entry-action comment: Second Transition (Lower Priority) else ifguard [and trigger] execute exit-action     deactivate active state then execute effect   activate transition target state    execute entry-action

State Machine Code Generation Scripts As already mentioned in Acceleo the order of the generated code is the same as the order in which the scripts are invoked. Figure 5.15 shows the main scripts and the interrelations of the behavior code generation algorithm. The code generation for behavior starts with the script uml.Classifier : add inc behavior. This script calls the script uml.StateMachine : stateMachineBehaviorCode which is the starting point for state machine behavior generation. The following sections describe the Modelica code for particular elements. Events and Trigger ModelicaML supports change, time, and signal events and trigger. A change trigger is the reaction on a change event. A change event specifies an event that is raised when a boolean-valued expression becomes true as a result of a change in value of one or more variables. The lifetime of an event is a UML semantic variation point as already mentioned in section 4.1.2. The Boolean variable which represents the change event is true as long as the expression is true. A transition, which reacts on the occurrence of a change event reacts only to the switch from false to true of the change event variable. Therefore, the change trigger at a transition remains true in ModelicaML for one event iteration. If a

107

5. Implementation

Figure 5.15: State Machine Behavior Scripts

transition will react to a Boolean-valued expression as long as this expression is true this has to be specified in the guard of the transition. The Modelica representation of the change event generation is given by the listing 5.7. The transition which has the change event as trigger is shown in listing 5.8. The condition is only true when the Boolean event variable changes its value from false to true. Listing 5.7: ”Change Event Statement” Boolean eventName : = pre ( x > 3 ) ; // ChangeEvent statement

Listing 5.8: ”Change Trigger” if pre ( state_0.active ) then if ( edge ( eventName ) ) and true then // trigger and empty guard ... // transition behavior end if ; end if ;

A signal event is the dispatch of an asynchronous signal instance. A signal trigger represents the receipt of this instance. As described in the structure section a signal is a record typed message. Every new signal is notified by toggling the occur-

108

5.2 From Model to Modelica Code rence flag. Signals are produced by the GEN SIGNAL(name of the signal)-Macro. This is expanded inside the state machine instance to name of the signal.occurence := true;. This signal is detected by an if-clause at the position of the signalEventsStatements (see algorithm 5.2.1) and reset to false. This reset causes a falling edge of the variable and extents the lifetime of the event up to one event iteration. Listing 5.9 shows this construct as it is stated in Modelica. Listing 5.9: ”Signal Event Statement” if s i g n a l E v e n t N a m e . o c c u r r e n c e then s i g n a l E v e n t N a m e . o c c u r r e n c e : = false ; end if ;

Listing 5.10: ”Signal Trigger” if pre ( State.active ) then if ( not s i g n a l E v e n t N a m e . o c c u r e n c e and pre ( s i g n a l E v e n t N a m e . o c c u r e n c e ) ) then ... // transition behavior end if ; end if ;

// signal trigger

At the moment signals can just be used to communicate internally within a state machine, for example to communicate between transitions from different regions. It cannot be used to communicate between different state machines. This communication must be explicitly modeled by connected ports. Another state machine can than react to changes of port-variables. Time events are distinguished into relative time events and absolute time events. Absolute time events are related to the global simulation time. Relative time events are related to a local state time. A trigger reacts when the time expression becomes true. A relative time trigger at a transition can be dangerous because it is only active for one event iteration. If a state has just one outgoing transition with a relative time trigger and a guard it could happen that the event is raised but the guard is not true. In this case the state machine is in a deadlock. Listing 5.11 shows the generation of an absolute and a relative time event. Listing 5.12 shows the time trigger at a transition. Listing 5.11: ”Time Event Statements” absTimeEvent : = time > 5; // Absolute Time Event statement relTimeEvent : = state_0.stime > 5; // Relative Time Event statement

Listing 5.12: ”Time Trigger” if pre ( state_0.active ) then if ( edge ( absTimeEvent ) or // absolute time trigger

109

5. Implementation edge ( relTimeEvent ) ) then // relative time trigger ... // transition behavior end if ; end if ;

If code for a clocked system, which uses a queue, should be generated, this can be implemented in several ways. It is possible to write a dynamic queue in C-code and use this queue by the external function interface of Modelica[Mod10, p.146]. Another solution is to use a ring-array. A ring-array is a static array which has an index-pointer for the current read position and an index-pointer for the current write position. In each event iteration the array is read at the read index-pointerposition. If an event exists the event is dispatched to the state machine. When a trigger gets true the event is destroyed immediately or after the event iteration by deleting the read-index-position of the array. At the end of the event iteration the read position must be iterated. If an event occurs during the event iteration it must be written to the array at the write-index-position of the array and the index-position has to be iterated. If the array is full a failure must occur. If no trigger of the state machine gets true or the array is empty the integration of the model continues. The implementation of a queue with Modelica is not tested yet. State Machine Initialization State machines are initialized when the simulation is started. Therefore, the variable startBehavior is set to true. This activates the when-clause which has the variable startBehavior as condition. Within this clause initial- or historypseudostates of all regions are set to true. Listing 5.13 shows an example of this initialization in Modelica. Listing 5.13: ”State Machine Initialization” S t a t e _ M a c h i n e _ 0 . s t a r t B e h a v i o r : = true when S t a t e _ M a c h i n e _ 0 . s t a r t B e h a v i o r then M a i n _ B e h a v i o r . a c t i v e : = true ; S t a t e _ M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = true ; S t a t e _ M a c h i n e _ 0 . R e g i o n _ 1 . I n i t i a l _ 0 . a c t i v e : = true ; end when ;

Local Time Behavior Each state has the time variables timeAtActivation and stime. Additionally, they have the auxiliary variable selfTransitionActivated. The variable timeAtActivation is set to the current time when a state is entered. The time has also to be reset if it is entered by a self transition. Therefore, the variable selfTransitionActivated is used. The variable stime is set in each integration step to the difference of the current simulation time and the timeAtActivation. If a state is not active the local

110

5.2 From Model to Modelica Code timer stime is set to zero. The Modelica code for this purpose is shown in listing 5.14. Listing 5.14: ”Local Time Behavior of States” when { St a t eM a c hi n e _0 . R e gi o n _0 . S ta t e _0 . a ct i v e , S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . s e l f T r a n s i t i o n A c t i v a t e d } then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . t i m e A t A c t i v a t i o n : = time ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . s e l f T r a n s i t i o n A c t i v a t e d : = false ; end when ; if S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . s t i m e : = time StateMachine_0.Region_0.State_0.timeAtActivation ; end if ; if not S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . s t i m e : = 0; end if ;

ShallowHistory If a region has a shallowHistory-pseudostate the variable lastActive has to be set to the currently active state. This ensures that the variable always stores the most recent active state. Listing 5.15 shows an example how the variable is set. Listing 5.15: ”Set ShallowHistory to Most Recent Active State” if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e ) then StateMachine_0.Region_0.ShallowHistory_0.lastActive := ( StateMachine_0.Region_0.ShallowHistory_0.HistoryStateT.State_0 ); end if ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e ) then StateMachine_0.Region_0.ShallowHistory_0.lastActive := ( StateMachine_0.Region_0.ShallowHistory_0.HistoryStateT.State_1 ); end if ;

In the case when a composite state with shallowHistory state is being re-entered the state, which is referenced by the variable lastActive, is activated. This is shown in the next section. Initial/ShallowHistory-Pseudostate Behavior If the initial -pseudostate is active it will be deactivated and the target of the outgoing transition is activated. If the shallowHistory-pseudostate is active the most recent active state is activated. If no most recent active state exists the target of the outgoing transition is activated. Listing 5.16 shows the behavior of the initial-pseudostate, listing 5.17 the behavior of a shallowHistory-pseudostate.

111

5. Implementation Listing 5.16: ”Initial-Pseudostate Behavior” if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ; end if ;

Listing 5.17: ”Shallow History Pseudostate Behavior” if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S h a l l o w H i s t o r y _ 0 . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S h a l l o w H i s t o r y _ 0 . a c t i v e : = false ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S h a l l o w H i s t o r y _ 0 . l a s t A c t i v e = = StateMachine_0.Region_0.ShallowHistory_0.HistoryStateT.State_0 ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ; elseif ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S h a l l o w H i s t o r y _ 0 . l a s t A c t i v e = = StateMachine_0.Region_0.ShallowHistory_0.HistoryStateT.State_1 ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = true ; else S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = true ; end if ; end if ;

Simple Transition Behavior A simple transition is a transition which directly connects two states. It is activated if the source state is pre-active. The Modelica pre-function is used to ensure that a state is active at the beginning of the event iteration. Therefore, it is not possible that a state becomes active and not active during the same iteration of an algorithm section. For example if the State 0 from StateMachine 0 (see figure 5.11) has as exitaction the statement y := 1;, as outgoing transition effect the statement y :=y* 2; and as entry-action of State 1 the statement y := y+1; then listing 5.18 shows the resulting Modelica code. When simulating that behavior y starts with the value y=0 and ends with the value y=3. Listing 5.18: ”Simple Transition Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e ) then if t > 1 and x < 2 then // guard y : = 1; // exit behavior S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = false ; y : = y * 2; // effect behavior S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = true ; y : = y + 1; // entry behavior end if ; end if ;

112

5.2 From Model to Modelica Code OR-Compound Transition Behavior OR-compound transitions are transitions which are chained by a junction or choice-pseudostate. At a junction chain a static decision is taken. This means that, firstly, all guards are evaluated, and secondly, the transition effect is executed. At a choice chain a dynamic decision is taken. Firstly, the first guards are evaluated, secondly the transition effect is executed, and thirdly the second guards are evaluated. Figure 5.16 shows a state machine with a junction-pseudostate and figure 5.17 with a choice-pseudostate. The corresponding transition behavior in Modelica is described in listing 5.19, and 5.20. The simulation of the junction state machine results in the state b, and the simulation of the choice state machine results in state c.

Figure 5.16: Junction Chain

Figure 5.17: Choice Chain

Listing 5.19: ”Junction Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e ) then if true then // empty guard if i < 3 then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e : = false ; i : = 4; // effect behavior S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . a c t i v e : = true ; elseif i > 3 then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e : = false ; i : = 4; // effect behavior S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . c . a c t i v e : = true ; else S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e : = false ; i : = 4; // effect behavior S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . d . a c t i v e : = true ; end if ; end if ; end if ;

Listing 5.20: ”Choice Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e ) then

113

5. Implementation if true then // empty guard S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e : = false ; i : = 4; // effect behavior if i < 3 then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . a c t i v e : = true ; elseif i > 3 then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . c . a c t i v e : = true ; else S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . d . a c t i v e : = true ; end if ; end if ; end if ;

Highlevel Transition Behavior Highlevel transitions are outgoing transitions of composite or submachine states. When a highlevel transition deactivates these hierarchical states it has to be ensured that all active nested substates are de-activated before the composite-/ submachine is deactivated. Consider the state machine in figure 5.18. At the beginning State 0 is activated. Afterwards, State 0 0 is activated. Accordingly, the highlevel transition to State 1 is taken. Therefore, State 0 0 and State 0 are deactivated and then State 1 is activated. Listing 5.21 shows the corresponding Modelica code.

Figure 5.18: State Machine with Composite State

Listing 5.21: ”Highlevel Transition Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e ) then if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . R e g i o n _ 0 . S t a t e _ 0 _ 0 . a c t i v e ) then StateMachine_0.Region_0.State_0.Region_0 .St ate_0_ 0.acti ve : = false ; end if ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . R e g i o n _ 0 . S t a t e _ 0 _ 1 . a c t i v e ) then StateMachine_0.Region_0.State_0.Region_0

114

5.2 From Model to Modelica Code .St ate_0_ 1.acti ve : = false ; end if ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = true ; end if ;

Interlevel Transition Behavior Interlevel transitions are transitions which cross the border of a composite state. As already described in section 4.1.9 the order in which states are activated and de-activated is very important. Consider the example shown in figure 4.9. The resulting Modelica code for the interlevel transition from state a to state e2 is shown in listing 5.22. Firstly, the source state is deactivated. Secondly, all states which are crossed by the interlevel transition are activated. Afterwards, the initialpseudostates of the concurrent regions are activated.

Listing 5.22: ”Interlevel Transition Activation Behavior” // ... : = S t a t e M a c h i n e _ 0 . R e g i o n _ 0 if pre ( ... .a.active ) then if cond1 then ... .a.active : = false ; ... .b.active : = true ; ... . b . R e g i o n _ 0 . c . a c t i v e : = true ; ... . b . R e g i o n _ 0 . c . R e g i o n _ 0 . d . a c t i v e : = true ; ... . b . R e g i o n _ 0 . c . R e g i o n _ 0 . d . R e g i o n _ 0 . e 2 . a c t i v e : = true ; ... . b . R e g i o n _ 0 . c . R e g i o n _ 0 . d . R e g i o n _ 1 . I n i t i a l _ 0 . a c t i v e : = true ; ... . b . R e g i o n _ 0 . c . R e g i o n _ 1 . I n i t i a l _ 0 . a c t i v e : = true ; ... . b . R e g i o n _ 0 . c . R e g i o n _ 2 . I n i t i a l _ 0 . a c t i v e : = true ; ... . b . R e g i o n _ 1 . I n i t i a l _ 0 . a c t i v e : = true ; end if ; end if ;

The Modelica code for the interlevel transition from state e2 to state a is shown in listing 5.23. Each time before a composite state is deactivated the active internal state has to be deactivated. This is ensured by the if-clauses.

Listing 5.23: ”Interlevel Transition Deactivation Behavior” if pre ( ... . b . R e g i o n _ 0 . c . R e g i o n _ 0 . d . R e g i o n _ 0 . e 2 . a c t i v e ) then if cond2 then ... // de - activate all substates of b if they are active ... .b.active : = false ; ... .a.active : = true ; end if ; end if ;

115

5. Implementation And-Compound Transition Behavior And-compound transitions are transitions which are chained by a fork or join pseudostate. Fork-pseudostates are used to directly activate explicit states of orthogonal regions. Join-pseudostates are used to synchronize the deactivation of explicit states of orthogonal regions. Consider the discussed example in figure 4.14. The corresponding Modelica code for the behavior of the and-compound transition from state a to the states d,f is shown in listing 5.24. Listing 5.24: ”Fork Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . a . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . a c t i v e : = true ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 1 . d . a c t i v e : = true ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 2 . f . a c t i v e : = true ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = true ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 3 . I n i t i a l _ 0 . a c t i v e : = true ; end if ;

The corresponding Modelica code for the behavior of the and-compound transition from the states e,g to state j is shown in listing 5.25. Listing 5.25: ”Join Behavior” if ( pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 1 . e . a c t i v e ) and pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 2 . g . a c t i v e ) ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 1 . e . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 2 . g . a c t i v e : = false ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = false ; end if ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 0 . c . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 0 . c . a c t i v e : = false ; end if ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 3 . I n i t i a l _ 0 . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 3 . I n i t i a l _ 0 . a c t i v e : = false ; end if ; if ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 3 . i . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . R e g i o n _ 3 . i . a c t i v e : = false ; end if ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . b . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . j . a c t i v e : = true ; end if ;

Entry-, ExitPoint-Transition Behavior Entry- and ExitPoints are used to specify interlevel transitions to/from submachines. Additionally, they have the same behavior as junction compound transi-

116

5.2 From Model to Modelica Code tions. Listing 5.26 shows the transition behavior of the transition from state S 1 to the entryPoint of submachine state S 2 from the example shown in figure 4.15. Listing 5.26: ”EntryPoint Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 1 . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 1 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 2 . a c t i v e : = true ; if true then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 2 . R e g i o n _ 0 . a . a c t i v e : = true ; end if ; end if ;

Listing 5.27 shows the behavior of the transition from state a to state S 3 via the exitPoint. Listing 5.27: ”ExitPoint Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 2 . R e g i o n _ 0 . a . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 2 . R e g i o n _ 0 . a . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 2 . a c t i v e : = false ; if true then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S _ 3 . a c t i v e : = true ; end if ; end if ;

Sampled State Machine A sampled state machine is a state machine which behavior is only executed when the sample expression becomes true. Therefore, a clocked platform can be simulated. The example in listing 5.28 shows a state machine which transition behavior starts at time 0 and is evaluated every 0.1 seconds. Listing 5.28: ”Sampled State Machine Behavior” when sample ( 0 ,0 .1 ) then // sample expression ... // transition behavior end when ;

Terminate A terminate-pseudostate stops the execution of the state machine. Therefore, a transition which target is a terminate-pseudostate, sets the variable active of the state machine to false. The terminate behavior at the end of the algorithm section sets the active variable of every existing state to false. Listing 5.29 shows a transition to a terminate-pseudostate, listing 5.29 shows the de-activation of every existing state.

117

5. Implementation Listing 5.29: ”Terminate Transition Behavior” if pre ( S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e ) then S t a t e M a c h i n e _ 0 . a c t i v e : = false ; end if ;

Listing 5.30: ”Terminate Behavior” if ( not S t a t e M a c h i n e _ 0 . a c t i v e ) then S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . I n i t i a l _ 0 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 0 . a c t i v e : = false ; S t a t e M a c h i n e _ 0 . R e g i o n _ 0 . S t a t e _ 1 . a c t i v e : = false ; end if ;

Final Final States are handled like normal states. The only difference of a final state is, that it has no outgoing transition and therefore, no own transition behavior. Hybrid Behavior It is possible to combine conditional equation diagrams with state machine diagrams. The active equation depends on the currently active state. It is required that one clause is always true. Listing 5.31 shows an equation which values depend on an active state. Therefore, the if-clause has the active variable of a state as condition. The else-clause is active if the variable active of the state is false. The resulting behavior is hybrid, as it depends on a continuous differential equation and a discrete state. Listing 5.31: ”Hybrid Behavior” equation if s m . R e g i o n _ 0 . o v e r f l o w . a c t i v e then v o l u m e _ o f _ l i q u i d _ l o s t = ( h - tank_height ) * areaCal.area ; else v o l u m e _ o f _ l i q u i d _ l o s t = 0; end if ;

118

6 Related Work “Publishing a theory should not be the end of one’s conversation with the universe, but the beginning.” Eric Raymond

This chapter addresses related work and the state of the art of hybrid modeling and simulation. Therefore, the next section describes some Modelica modeling environments Dymola, MathModelica, and OpenModelica. Afterwards, the Modelica StateGraph2 library is described. Further, the Modelica tool SimulationX and Mosilab are addressed, which have in contrast to the other Modelica tools their own state machine implementation. Accordingly, the theoretical approach hybrid automata for describing hybrid behavior is addressed. In addition, the tool MATLAB with its Simulink and Stateflow module is portrayed. In the last section the approach MECHATRONIC UML is described.

6.1 Modelica Modeling and Simulation Environments This section addresses some of the Modelica simulators and modeling environments. The only possibility to model state machines in these modeling environments are libraries. And up to now, Modelica does not directly define state charts. A state chart library in basic Modelica notation is available for these environments. This library allows to model complex conditions which are internally translated into IF - THEN - ELSE or WHEN constructs. The library is called StateGraph2 and is addressed in the section 6.1.2.

6.1.1 Dymola / MathModelica / OpenModelica Dymola is the most popular Modelica tool and can be considered as the mother of Modelica. Dymola was introduced by F. E. Cellier [Cel79] as acausal modeling language, and developed to a simulator by H. Elmquist [Elm78]. Dymola handles any hybrid DAE system. For DAE solving, modified DASSL [Pet82] algorithms are used. In software structure, Dymola is similar to Advanced continuous simulation language (ACSL) [MG76], using an extended SCi continuous system simulation language (CSSL) [SAF+ 67] structure. Dymola comes with a graphical modeling and basic simulation environment, and provides a simple script language as extended environment. [Bre08].

119

6. Related Work MathModelica is developed by MathCoreAB. The MathModelica translator is very similar to Dymola’s model translator. Most related features are available1 . OpenModelica is a Modelica modeling, compilation, and simulation environment based on free software. Open Modelica is a generic Modelica simulator, so all basic features are met2 . For DAE solving, variants of DASSL solver are used. Open Modelica has no further abilities to model state machines than to use libraries. [Bre08]. The presented Modelica environments can be distinguished from ModelicaML by their graphical modeling capabilities. The connection diagram can handle domain specific libraries and has a specific icon for each element. However, Modelica does not have a standardised graphical notation In contrast, UML/ModelicaML provides the modeler with standardised graphical notation that enables different views on the system definition.

6.1.2 StateGraph2 StateGraph2 is a free Modelica library providing components to model discrete event, reactive and hybrid systems with deterministic hierarchical state diagrams. The Modelica StateGraph2 library [OME+ 09] is based on StateGraph [O˚ AD05] + and the ModeGraph library [MEM 08]. The library is inspired by Grafcet/Sequential Function Charts (SFC) [Dav95], Statecharts [Har87], Safe State Machines (SSM)[And03] and Mode Automata [MR98], and utilizes Modelica as action language. Via special blocks actions can be defined in a graphical way depending on the active step. An experimental module for Dymola exists, which exports StateGraph models to SMV (Symbolic Model Verification) [CCG+ 02] models. This makes it possible to verify StateGraph models [OME+ 09]. The main difference between ModelicaML state machines and StateGraph is that StateGraph uses an equation based block-oriented modeling approach. StateGraph state machines are represented by Modelica equation code. In contrast ModelicaML state machines use UML based state machine modeling approach. These state machines are transferred to a Modelica algorithmic code. The basic elements of StateGraphs are steps and transitions which are connected by the Modelica connect(x,y) function. Steps represent discrete states of a system. Transitions are used to define a possible change of a system state. A transition is connected to the output connector of the preceding step (step out[i]) and to the input connector of the succeeding step (step in[i]). If outgoing transitions of a step are in conflict with each other the priority is defined as follows: “The transition 1

Note that the currently available version 2.1 of MathModelica is not able to simulate shallowHistory pseudostates as they are mapped to Modelica in this thesis, because some problems with enumerations exists. The implementation is tested with an alpha version of the upcoming version 2.2 of MathModelica. 2 Note that complex ModelicaML state machines with concurrency, hierarchy, and history behavior not always simulate with Open Modelica. The reason therefore is unknown at the moment.

120

6.1 Modelica Modeling and Simulation Environments that is connected to the lowest index of the step out connector vector is defined to have highest priority.” [OME+ 09]. Transitions can be delayed in StateGraph by adding a time guard. This time guard is relative to the source step of a transition and semantically equivalent to the AFTER(x) transition time guard of ModelicaML. It is possible to model hierarchical and orthogonal steps with StateGraph. Steps which can have parallel processing are called Parallel component. This component functions also as composite state. Highlevel transitions are not allowed in StateGraph. Transitions between different state levels are modeled as interlevel transitions which use the step out/step in connectors as exit/entry points. It is also possible to process do-actions, if a step is active. So called MultiSwitches are used to activate an expression. “A MultiSwitch block selects one of n expressions depending on an array of Boolean inputs. The index of the first input in the Boolean array that is true defines the index of the expression in the expression array to be used as the scalar output y.” [OME+ 09]. The first input of a MultiSwitch which becomes true, sets the value of the output. Due to this fact, it is not possible that a variable changes its value more than once during the same time instance. This is different to ModelicaML state machines where the value of a variable can change in each event iteration. Further, it is possible to model entry-, exit- actions by the RisingEdge, FallingEdge block. History can be represented in StateGraph by the suspend and resume connector. A Parallel component may be suspended and subsequently resumed. When it is resumed it is re-activated in the same state as when it was suspended. Submachines can be modeled in StateGraph by so called PartialParallel component. This component adds another hierarchy. StateGraph represents a domain specific language for Modelica state machines. Compared to UML/ModelicaML state machines, StateGraph has another graphical representation. Steps are shown as boxes and transitions are shown as short heavy bars. StateGraph does not implement a comprehensive set of state machines concepts as defined in the UML specification. Larger StateGraphs models are not easy to grasp as they are graphical more complex than UML state machines. A small example model constructed with StateGraph2 is shown in figure 6.1. It will be the target of further research to compare ModelicaML state machine semantics in more detail with the semantics of StateGraph models. Further, it is very interesting if it is possible to map ModelicaML state machines to semantic equivalent StateGraph models.

6.1.3 SimulationX SimulationX is a new Modelica simulator developed by ITI simulation, Dresden. The simulation engine from ITI-SIM uses an implicit integration scheme with state event handling [Bre08]. The state machines which can be modeled with SimulationX are alike to the state machines from this thesis. SimulationX supports a subset of UML state machine [DHBN08]. The following items can be used for modeling state machines.

121

6. Related Work

Figure 6.1: StateGraph2 Example

States: Simple States, Non-Concurrent Composite States, Pseudo States. Transitions: Signal Triggers, Change Triggers, Time Triggers, Guards.

In SimulationX priorities of transitions can be defined by the user. Further, state machines are visualized as so called assertion charts, derived from [Dru]. The visualisation is implemented as a mapping to Modelica graphical annotations. The main difference to ModelicaML state machine is that SimulationX provides no possibility to model orthogonal states. Regions as they are defined in the UML do not exist within SimulationX. SimulationX also provides no mechanism like submachines to group a state machine into multiple parts and to reduce the visual complexity. SimulationX has its own metamodel for state machines which is not conform with the UML meta model for state machines. As a result existing UML models cannot be used within SimulationX. Further, SimulationX provides, besides the state machine diagram, only the connection diagram like the other Modelica modeling environments.

6.1.4 Mosilab Fraunhofer Gesellschaft Dresden has developed the generic Modelica simulator Mosilab (MOdeling and SImulation LABoratory), since 2004. “The main innovation from point of simulation techniques view in this simulator is the illustration

122

6.2 Hybrid Automata of condition-based changes in the model structure (model structure dynamics).” [ZLB07]. Mosilab includes an extended state chart modeling, which is translated into Modelica IF - THEN - ELSE constructs. In Mosilab it is possible at state chart level, that state events cause a switch between structural different models. Mosilab translates each model separately, and generates a main simulation program out of state charts, controlling the call of the precompiled models, and passing data between the models. The textual and graphical constructs for the state charts are modifications of state chart modeling in AnyLogic [BKK02, Bre08]. Mosilab uses, like ModelicaML, a subset of UML to specify models. Therefore the language U M LH as a subset of UML was developed. The U M LH editor provides three different views (class diagrams, statechart diagrams, collaboration diagrams) which are implemented as a part of the Modelica simulation tool Mosilab [NG07, NGEN+ 06, NGEN+ 05]. In contrast to ModelicaML state machines Mosilab models cannot be simulated with Dymola or MathModelica. Mosilab has defined an own textual description for state machines [NG07]. Mosilab supports four different kinds of states: “ Initial states, symbolized with a black filled circle, Final states, symbolized with a point in an unfilled circle, Atomic states, with a flat internal structure, Normal states, which can contain additional entry or exit actions and can be substructured in further statechart diagrams.

The transitions between the states are specified with an optional label, an event, an optional guard and the action part.” [NG07]. Mosilab does not support orthogonal states. At the moment Mosilab is not available anymore for the public. Therefore, it could not be tested while working on this thesis.

6.2 Hybrid Automata Hybrid automata is another approach for modeling continuous/discrete systems [Hen96, ACHH93]. In hybrid automata a state represents the value of a continuous variable within a determined interval. The variables can change continuously within a state. Variables are used for guard conditions at transitions. Therefore, variables will be compared with each other or with absolute values. The discrete transitions of the automata are specified by a change of the program counter, which ranges over a finite set of control locations. There are only finitely many discontinuous state changes possible. Hybrid automata can be defined by graphs whose edges represent discrete transitions and whose vertices represent continuous activities. The calculation rule for continuous variables can change as a result of

123

6. Related Work a state change. The calculation rules are specified as invariants by differential equations. The invariants are displayed textually within the notion of a state, which is displayed as a node. Figure 6.2 shows the graphical representation of a hybrid automata. It has the data variable x. It consists of two locations l1 and l2 . The value of the variable x decreases by 1 at a constant rate. The location l1 can be left at any time as soon as the value of the variable is below the value 6. The location l1 must be left before the value is below the value 5. As an effect of the location change the variable x is decreased by 1. Further, the invariant and the calculation rule for the variable x change.

Figure 6.2: Graphical Representation of Hybrid Automata (source [ACHH93])

Hybrid Automata provides an efficient way to describe hybrid behavior. Contrary to ModelicaML it is not possible to model the whole system with hybrid automata. Hybrid Automata is only useful to describe hybrid behavior. Hybrid Automata has many similarities with ModelicaML state machines. A guard for example can depend in both cases on continuous variables. It is difficult to describe Modelica state machines with hybrid automata because of the single assignment rule of Modelica. The Modelica language must be extended when expressions should be directly defined in states. This is also expressed by the following statement: “. . . , compared to the alternative where the expressions are defined directly in the respective Steps. This latter approach would, however, require non-trivial extensions to the Modelica language.” [OME+ 09].

6.3 MATLAB/ Simulink/ Stateflow MATLAB is a very powerful environment with various modules. It is developed by the company MathWorks. For industry MATLAB is the most important modeling and simulation environments. The simulation module for block-oriented dynamic models is called Simulink. It can be combined with Stateflow. Stateflow is MATLAB’s module for event-driven state changes described by state charts. For control, in MATLAB only IF - THEN constructs are available. At Simulink level, Stateflow may control different submodels. A submodel is for example a dynamic model based on ordinary differential equation, or a static

124

6.4 MECHATRONIC UML model describing discrete actions. [Bre08]. Stateflow operational semantics is described in [HR07]. Figure 6.3 shows for example a tank with three valves modeled in Simulink/Stateflow. An approach how well defined Simulink/Stateflow models can be transformed to hybrid automata is described in [ASK04].

Figure 6.3: A Tank with Three Valves Modeled in Simulink/Stateflow (source [ASK04])

In contrast to ModelicaML it is not possible to model a-causal in MATLAB or Simulink. In MATLAB the signal flow must be always described. The semantics of Stateflow models depends in contrast to ModelicaML state machine on the relative position of model elements in the diagram. The arrangement of states and transitions can change the order of execution in a way which is not easy to understand by the modeler. Further, Simulink/Stateflow is not based on an open standard, as it is Modelica. MATLAB has the drawback that it is a proprietary software and therefore the modeler is heavily dependent on the future development of the owner company MathWorks. Modelica modeling or simulation is not supported by MATLAB.

6.4 MECHATRONIC UML MECHATRONIC UML is an approach for model-driven development and verification of mechatronic real-time systems. It is developed by the Software Engineering Group, Department of Computer Science at the University of Paderborn, Germany. The modeling of the structure is using component diagrams based on UML [GBSO04]. MECHATRONIC UML distinguishes between discrete and continuous components.

125

6. Related Work For the modeling of behavior between different components MECHATRONIC UML uses real-time coordination patterns [GT05]. Discrete real-time behavior can be defined by real-time statecharts [BGS03]. Real-time statecharts have special ability for modeling real-time properties of a system. The semantics of real-time statecharts is based on timed automata [AD94]. Further, MECHATRONIC UML offers an approach for modeling dynamic reconfiguration of structural model parts [BGT05]. Therefore, the configurations of the continuous components are embedded within hybrid states [GBSO04, BGT05, BGT04]. This is modeled by hybrid reconfiguration charts. A modeling environment for MECHATRONIC UML is provided by the FUJABA Real Time Tool-Suite3 . Further, a code generation mechanism is provided, which generates code for the real-time Java target platform and C++. The generated code can be simulated in combination with the tool CAMeL-View [HH08, BGH+ 07]. In contrast to ModelicaML, MECHATRONIC UML cannot be used to specify physical parts of mechatronic systems. This has to be done in the external modeling environment CAMeL-view. Integration of UML-based languages and Modelica simulation capabilities into one language, enables an integrated modeling and simulation of system requirements and design.

3

http://www2.cs.uni-paderborn.de/cs/ag-schaefer/Lehre/PG/FUJABA/projects/ realtime/index.html

126

7 Summary and Future Work “We can only see a short distance ahead, but we can see plenty there that needs to be done.” Alan Turing

In this chapter the overall results of this thesis are concluded. Additionally, those concepts of the approach, where additional work is suggested for the future are described.

7.1 Summary Mechatronics has come to mean multidisciplinary systems engineering and is the synergistic integration of physical systems, electronics, controls, and computers through the design process. The design of mechatronic systems under the requirements of a tight integration between the different disciplines and their engineers lead to an overall object-oriented, component- and model-based design approach [MEB97, BGH+ 07]. Mechatronics is the best practise for synthesis by engineers driven by the needs of industry and human beings [Cra09]. UML has great graphical modeling features but it lacks a concrete execution semantics and formal mathematical representation. These features are important for simulation of virtual prototypes. The combination of continuous-time and discrete-time models are described through hybrid DAEs. Modelica uses hybrid DAEs as mathematical description. The changes of physical system parts and the control logic can be described as a whole system by Modelica. Simulation environments, like Dymola or MathModelica, evaluate the Modelica model and the containing hybrid behavior simultaneously. ModelicaML builds the link between UML and Modelica. Integration of UML-based language and Modelica simulation capabilities into one language enables an integrated modeling and simulation of system requirements and design (including hardware and software) [Sch09]. It closes the gap between documentation and programming language, as the models are a graphical and executable specification of the problem space. Further advantages are a higher level of abstraction than pure Modelica and an easy exchange and reuse of knowledge by using the industry standard UML. It facilitates the creation of executable system-specification and -analysis models that can simulate both the time-discrete and the time-continuous behavior of a system.

127

7. Summary and Future Work In this thesis an approach for modeling and simulating mechatronic systems has been presented. The approach is based on UML, the ModelicaML profile, and Modelica. The approach enables the modeler to specify mechatronic systems with the language defined in this thesis. A specified model is transferred to Modelica code and can be simulated by Modelica simulators. Figure 7.1 shows the process from modeling to simulation. The state machine described in this thesis enables the modeler to model discrete behavior with nearly all capabilities of UML 2 state machines. Particularly, the combination of hierarchical and orthogonal modeling of states is a powerful notion construct which can be used by the modeler. The ModelicaML state machines have been transferred into Modelica and therefore every other continuous Modelica model part, for example differential, algebraic and discrete equations, as well as functions, can be conveniently and naturally combined with these state machines and used to model and simulate hybrid behavior. As a result of this thesis a complete modeling environment based on the UML Papyrus editor has been developed. This modeling environment is used as a proof of concept to develop mechatronic systems. The modeling environment has the ability to generate Modelica code out of ModelicaML models. The resulting Modelica models can be simulated with Dymola or MathModelica. The developed plug-ins can be found on the CD-ROM (refer to appendix D). The simulation makes it possible to test and to study the execution of modeled systems. The plug-ins are published also as part of the Open Modelica project at http://www.openmodelica.org/index.php/developer/tools/134.

Figure 7.1: Modeling and Simulation

128

7.2 Future Work Further, some validation examples have been modeled. For example, the discussed Two-Tank-System, the Bouncing Ball example, a watchdog system example, and a small traffic light system. These examples are also stored on the attached CD-ROM (refer to appendix D).

7.2 Future Work Although the described approach already defines a procedure for modeling and simulation of mechatronic system, several aspects are suggested for future work. Unfinished solutions and open questions are highlighted in this section and an outlook for possible future work is given. The state machines defined in this thesis are developed for the needs and requirements of system engineers. The aspect of hard real-time requirements of software is beyond the focus. Therefore, ModelicaML state machines have to be revised for hard real-time requirements of software. This includes for example the realisation of event queues for state machines, communication capabilities of distributed systems, including time-consuming transitions, and deadlines. Related work is described in [BGS05, Bur02, GB03]. Another topic in which research has to be investigated is the verification of hybrid mechatronic systems. Simulation of models helps to find failures but cannot prove the absence of failures. An approach for model-based verification of distributed mechatronic systems is described in [Hir08]. The approach presented in this thesis may be also used for integration and model-based-testing of Modelica legacy models. Therefore, these models have to be imported as black-box models into ModelicaML. This could be done by creating a ModelicaML class that works as a dummy to the Modelica. This dummy class must have a reference to the existing Modelica legacy model and must know the model path to the top level package of the Modelica model. Further, the interfaces of that model must be known, and therefore ports have to be created. The blackbox class can be instantiated as components and connected to other model parts. Test cases can be specified model-based for the black-box components. The test cases have to be transferred into Modelica code and simulated together with the legacy Modelica system. A component-based integration of legacy systems is described in [HMS+ 10]. The simulation and the results of a ModelicaML model should be visualized. Therefore, UML sequence diagrams can display the occurrence of events. The execution of state machines can be visualized by Modelica graphical annotations. These annotations for graphical objects are specified in Modelica specification [Mod10, p. 189]. The appearance of the graphical objects can depend on the value of a variable. For the parts which have to be specified textually a meta-model and a special editor are required. This editor will for example offer code completion features, which dynamically propose a list of available variables for instances of composite

129

7. Summary and Future Work type and their variables that can be accessed. Therefore, it is necessary to provide the editor with the context (i.e., class variables, including inherited variables, that can be used) in order to enable parsing and initial code completion. The context is to be deduced from the ModelicaML model. The code generation for activity diagrams has to be reworked. Therefore, a grammar for activity diagrams has to be specified, for example with graph grammars. [Kle99]. Graph grammars could help to generate the control flow. Based on the graph grammar the code for the control structure of activity diagram can be generated. A well formed activity diagram is required for the code generation. It has to be investigated if not well formed activity diagrams can be automatically transferred into well formed activity diagrams, which can be mapped to Modelica code. Alternatively, the code generation algorithm could apply the graphgrammar-rules backwards and generate simultaneously the appendant code. If at the end the start graph is left over the activity diagram was well formed and the code is generated. [EKR+ 10]. The approach described in this thesis is validated only for small examples. It will be up to future work to validate the approach for bigger and more complex application examples.

130

Appendix A ModelicaML Constraints A.1 Class Structure

Listing A.1: A ModelicaML package may only contain the following elements: Class ,Property, PrimitiveType, Enumeration, FunctionBehavior context Classifier inv : self . hasStereoType ( ' ModelicaPackage ' ) implies self . ownedElements - > forAll ( o | o . oclIsTypeOf ( Class ) or o . oclIsTypeOf ( Class ) or o . oclIsTypeOf ( Property ) or o . oclIsTypeOf ( PrimitiveType ) or o . oclIsTypeOf ( Enumeration ) or o . oclIsTypeOf ( FunctionBehavior ) )

Listing A.2: Classifier must have a name. context Classifier inv : self . name ""

Listing A.3: UML Classifier, which is no Behavior, must have stereotype applied indicating that this is a ModelicaML restricted class (e.g. model, block, record, connector, etc.). context Classifier inv : self - > forAll ( c | c . oclIsKindOf ( Behavior ) or c. isModelicaRestrictedClass ())

131

A. ModelicaML Constraints Listing A.4: A ModelicaML class may only contain: Class, Enumeration, PrimitiveType, Property, Parameter, StateMachine, Activity, OpaqueBehavior, Port, FunctionBehavior, Comment, Connector, Constraint, Generalization, Dependency context Class inv : self . ownedElement - > forAll ( c | c . oclIsTypeOf ( Class ) or c . oclIsTypeOf ( Enumeration ) or c . oclIsTypeOf ( PrimitiveType ) or c . oclIsTypeOf ( Property ) or c . oclIsTypeOf ( Parameter ) or c . oclIsTypeOf ( StateMachine ) or c . oclIsTypeOf ( Activity ) or c . oclIsTypeOf ( OpaqueBehavior ) or c . oclIsTypeOf ( Port ) or c . oclIsTypeOf ( FunctionBehavior ) or c . oclIsTypeOf ( Comment ) or c . oclIsTypeOf ( Connector ) or c . oclIsTypeOf ( Constraint ) or c . oclIsTypeOf ( Generalization ) or c . oclIsTypeOf ( Dependency ) )

Listing A.5: A UML Property of a ModelicaML classifier must have a stereotype applied which indicates that this is a ModelicaML Property (i.e. instance of a class). context Classifier inv : self . ownedElement - > select ( c | c . oclIsTypeOf ( Property ) ) - > forAll ( p | p . i sM o d el i c aC o m po n e nt ( ) )

Listing A.6: A UML Generalization must have a ModelicaML stereotype indicating that this is a Modelica ”extends” or ”type extends” relation. context Classifier inv : self . ownedElement - > select ( c | c . oclIsTypeOf ( Generalization ) ) - > forAll ( g | g . i s M o d e l i c a G e n e r a l i z a t i o n ( ) )

Listing A.7: A ModelicaML model or class can only extend a model, block or record. context Classifier inv : ( self . hasStereotype ( ' Model ' ) or self . hasStereotype ( ' ModelicaClass ' ) ) implies self . general - > forAll ( g | g . hasStereotype ( ' Model ' )

132

A.1 Class Structure or g . hasStereotype ( ' Block ' ) or g . hasStereotype ( ' Record ' ) )

Listing A.8: A ModelicaML block can only extend a block or record. context Classifier inv : self . hasStereotype ( ' Block ' ) implies self . general - > forAll ( g | g . hasStereotype ( ' Block ' ) or g . hasStereotype ( ' Record ' ) )

Listing A.9: A ModelicaML connector can only extend a type, record or connector. context Classifier inv : self . hasStereotype ( ' Connector ' ) implies self . general - > forAll ( g | g . hasStereotype ( ' Type ' ) or g . hasStereotype ( ' Record ' ) or g . hasStereotype ( ' Connector ' ) )

Listing A.10: A ModelicaML record can only extend a record. context Classifier inv : self . hasStereotype ( ' Record ' ) implies self . general - > forAll ( g | g . hasStereotype ( ' Record ' ) )

Listing A.11: A ModelicaML type can only extend a type. context Classifier inv : self . hasStereotype ( ' Type ' ) implies self . general - > forAll ( g | g . hasStereotype ( ' Type ' ) or g . oclIsTypeOf ( PrimitiveType ) )

Listing A.12: A ModelicaML function can only extend a function. context Classifier inv : self . hasStereotype ( ' Function ' ) implies self . general - > forAll ( g | g . hasStereotype ( ' Function ' ) )

133

A. ModelicaML Constraints Dependency is not described in this thesis as it is beyond the scope of this master thesis. Nevertheless, dependency is part of the ModelicaML profile. The constraints are specified here formal in OCL for the completeness of the constraints. Listing A.13: A ModelicaML class may have only one redeclare relation. context Classifier inv : self . clientDependency - > select ( c | c . hasStereotype ( ' Red eclare Relati on ' ) ) - > not size ( ) >1

Listing A.14: A ModelicaML class may have only one partial derivative relation. context Classifier inv : self . clientDependency - > select ( c | c . hasStereotype ( ' P a r t i a l D e r i v a t i v e O f F u n c t i o n R e l a t i o n ' ) ) - > not size ( ) >1

Listing A.15: A ModelicaML class may have only one ”constrainedby” relation. context Classifier inv : self . clientDependency - > select ( c | c . hasStereotype ( ' C o n s t r a i n e d B y R e l a t i o n ' ) ) - > not size ( ) >1

Listing A.16: A ModelicaML function can only have a partial derivative relation to another function. context Classifier inv : self . hasStereotype ( ' Function ' ) implies self . clientDependency - > select ( c | c . hasStereotype ( ' C o n s t r a i n e d B y R e l a t i o n ' ) ) - > forAll ( t | t . target . hasStereotype ( ' Function ' ) )

A.2 Composite Structure Listing A.17: A Modelica components must have a type. context TypedElement inv : self . type - > notEmpty ( )

134

A.2 Composite Structure Listing A.18: A component of a ModelicaML block must have causality (input/output) defined. context TypedElement inv : self . owner . oclIsKindOf ( Classifier ) and self . owner . hasStereotype ( ' Block ' ) implies self . causality < >""

Listing A.19: Ports must have ModelicaML stereotype context Port inv : self . hasStereotype ( ' ConnectionPort ' ) )

Listing A.20: A UML connector must have a ModelicaML stereotype. context Connector inv : self . hasStereotype ( ' Connection ' )

Listing A.21: All UML connector ends must be set. context Connector inv : self . end - > not isEmpty ( ) and forAll ( e | e . role null )

Listing A.22: A ModelicaML connection can only connect ports. context Connector inv : self . end - > forAll ( e | e . role . oclIsTypeOf ( Port ) )

Listing A.23: UML Behavior must have a stereotype applied which indicates that this is a part of the ModelicaML class behavior (i.e. equation or algorithm sections). context Behavior inv : self - > forAll ( s | s . hasStereotype ( ' Algorithm ( Code ) ' ) or hasStereotype ( ' Equations ( Code ) ' ) or hasStereotype ( ' C o n d i t i o n a l A l g o r i t h m ( Diagram ) ' ) or hasStereotype ( ' C o n d i t i o n a l E q u a t i o n s ( Diagram ) ' ) or hasStereotype ( ' M o d e l i c a M L S t a t e M a c h i n e ' ) ) )

Listing A.24: A Modelica package, record, connector or type cannot have behavior. context Classifier

135

A. ModelicaML Constraints inv : self . hasStereotype ( ' Package ' ) or self . hasStereotype ( ' Record ' ) or self . hasStereotype ( ' Connector ' ) or self . hasStereotype ( ' Type ' ) implies self . ownedElements - > forAll ( o | not ( o . oclIsKindOf ( Behavior ) ) )

A.3 Activity Listing A.25: Action: Only ’OpaqueAction’ and ’CallBehaviorAction’ are supported. context Activity inv : self . ownedElement - > select ( o | o . oclIsKindOf ( Action ) ) - > forAll ( a | a . oclIsTypeOf ( OpaqueAction ) or a . oclIsTypeOf ( Ca ll Be ha vi or Ac ti on ) )

Listing A.26: ActivityEdge: Only ’ControlFlow’ is supported. context Activity inv : self . ownedElement - > select ( o | o . oclIsKindOf ( ActivityEdge ) ) - > forAll ( a | a . oclIsTypeOf ( ControlFlow ) )

Listing A.27: ControlNode: Only ’InitialNode’ and ’DecisionNode’ are supported. context Activity inv : self . ownedElement - > select ( o | o . oclIsKindOf ( ControlNode ) ) - > forAll ( a | a . oclIsTypeOf ( InitialNode ) or a . oclIsTypeOf ( DecisionNode ) )

Listing A.28: A ModelicaML Activity must have exactly one initial node. context Activity inv : self . ownedElement - > select ( o | o . oclIsTypeOf ( InitialNode ) ) - > size ( ) = 1

Listing A.29: A ModelicaML Activity must have exactly one outgoing transition of an initial node. context Activity inv : self . ownedElement - >

136

A.4 State Machine select ( o | o . oclIsTypeOf ( InitialNode ) ) - > forAll ( i | i . outgoing . size ( ) = 1 )

Listing A.30: A ModelicaML MergeNode must have exactly one outgoing ControlFlow. context Activity inv : self . ownedElement - > select ( o | o . oclIsTypeOf ( MergeNode ) ) - > forAll ( m | ( select ( m . outgoing . oclIsTypeOf ( ControlFlow ) ) - > size ( ) = 1 ) )

Listing A.31: A ModelicaML outgoing ControlFlow of MergeNodes is not allowed to have a guard. context Activity inv : self . ownedElement - > select ( o | o . oclIsTypeOf ( MergeNode ) ) - > select ( f | f . oclAsType ( ActivityNode ) . outgoing . guard . oclAsType ( V al ue Sp eci fi ca ti on ) . stringValue ( ) = = ""

Listing A.32: A ModelicaML DecisionNode can only have one incoming ControlFlow. context Activity inv : self . ownedElement - > select ( o | o . oclIsTypeOf ( DecisionNode ) ) - > forAll ( f | not f . oclAsType ( ActivityNode ) . incoming . size ( ) >1 )

Listing A.33: DecisionNode must have stereotype ’If’ or ’When’ context Activity inv : self . ownedElement - > select ( o | o . oclIsTypeOf ( DecisionNode ) ) - > forAll ( d | d . hasStereotype ( If ) or d . hasStereotype ( When ) )

A.4 State Machine Listing A.34: Each Region must have exactly one initial or shallowHistory pseudostate. context Region

137

A. ModelicaML Constraints inv : self . ownedElement - > select ( e | e . oclIsKindOf ( Pseudostate ) ) - > select ( f | f . kind = # initial or # shallowHistory ) - > size ( ) = 1

Listing A.35: The initial or shallowHistory pseudostate of each region must have exactly one outgoing transition. context Region inv : self . ownedElement - > select ( e | e . oclIsKindOf ( Pseudostate ) ) - > select ( f | f . kind = # initial or # shallowHistory ) - > forAll ( i | i . outgoing - > size ( ) = 1 )

Listing A.36: The initial pseudostate or shallowHistory pseudostate of each region may not have a guard on its outgoing transition. context Region inv : self . ownedElement - > select ( e | e . oclIsKindOf ( Transition ) ) - > select ( t | t . source . oclIsKindOf ( Pseudostate ) ) - > select ( f | f . source . kind = # initial or # shallowHistory ) - > select ( l | l . guard . specification . oclIsKindOf ( LiteralString ) - > forAll ( i | i . guard . specification . value "" )

Listing A.37: The outgoing transition from the initial or shallowHistory pseudostate may not be an interlevel transition. context Region inv : self . ownedElement - > select ( e | e . oclIsKindOf ( Transition ) ) - > select ( t | t . source . oclIsKindOf ( Pseudostate ) ) - > select ( f | f . source . kind = # initial or # shallowHistory ) - > forAll ( l | l . source . container = l . target . container )

Listing A.38: All transitions from an entryPoint must lead to the targets that are contained in the same region. context Pseudostate inv : self . kind = # entryPoint implies self . outgoing - > forAll ( o1 , o2 | o1 o2 implies o1 . container = o2 . container )

Listing A.39: ExitPoints can have one incoming transition at most. context Pseudostate

138

A.4 State Machine inv : self . kind = # exitPoint implies self . incoming - > size ( ) size ( ) = 0

Listing A.41: ExitPoints cannot have outgoing transitions. context Pseudostate inv : self . kind = # exitPoint implies self . outgoing - > size ( ) = 0

Listing A.42: Pseudostates of kind ’deepHistory’ are not supported. context Pseudostate inv : self . kind = # deepHistory implies self . size ( ) = 0

Listing A.43: A choice/junction Pseudostate must have incoming and outgoing transitions. context Pseudostate inv : self . kind = # choice or # junction implies incoming . size ( ) > 0 and outgoing . size ( ) > 0

Listing A.44: Transitions to forks must have state node as a source. context Pseudostate inv : self . kind = # fork implies source . oclIsKindOf ( State )

Listing A.45: Transitions to forks may not be interlevel. context Pseudostate inv : self . kind = # fork implies forAll ( self . incoming . source . container = self . container )

Listing A.46: In a complete state machine, a fork pseudostate must have at least two outgoing transitions and exactly one incoming transition. context Pseudostate inv : self . kind = # fork implies self . outgoing . size ( ) >= 2 and self . incoming . size ( ) = 1

139

A. ModelicaML Constraints Listing A.47: Transitions from join-pseudostates must have State or FinalState as their target. context Pseudostate inv : self . kind = # join implies forAll ( self . outgoing . target . oclIsKindOf ( State ) )

Listing A.48: Transitions from join-pseudostates may not be interlevel. context Pseudostate inv : self . kind = # join implies forAll ( self . outgoing . target = self . container )

Listing A.49: In a complete state machine, a join vertex must have at least two incoming transitions and exactly one outgoing transition. context Pseudostate inv : self . kind = # join implies self . incoming . size ( ) >= 2 and self . outgoing . size ( ) = 1

Listing A.50: Source and target must be set for a transition. context Transition inv : self . source . notEmpty ( ) and self . target . notEmpty ( )

Listing A.51: Transitions cannot cross region borders. context Transition inv : self - > forAll ( t | self . stateMachine . LCA ( t . target , t . source ) . notEmpty ( ) )

Listing A.52: ConnectionPointReference entryPoint/exitPoits.

may

only

reference

one

context C o n n e c t i o n P o i n t R e f e r e n c e inv : self . entry . size ( ) = 1 xor self . exit . size ( ) = 1

Listing A.53: ConnectionPoint referencing an entryPoint may not have outgoing transitions. context C o n n e c t i o n P o i n t R e f e r e n c e inv : self . entry . notEmpty ( ) implies self . outgoing . size ( ) = 0

140

A.4 State Machine Listing A.54: ConnectionPoint referencing an exitPoint may not have incoming transitions. context C o n n e c t i o n P o i n t R e f e r e n c e inv : self . exit . notEmpty ( ) implies self . incoming . size ( ) = 0

Listing A.55: ConnectionPoint referencing an exitPoint must have an outgoing transition. context C o n n e c t i o n P o i n t R e f e r e n c e inv : self . exit . notEmpty ( ) implies self . outgoing . size ( ) > 0

Listing A.56: Final state may not have outgoing transitions. context FinalState inv : self . outgoing . size ( ) = 0

Listing A.57: Terminate state may not have outgoing transitions. context Pseudostate inv : self . kind = # terminate implies self . outgoing . size ( ) = 0

141

Appendix B Constraint Operations hasStereotype ( stereotype : String ) : Boolean post : result = ( self . g e t A p p l i e d S t e r e o t y p e s ( ) - > select ( f | f . name = stereotype ) - > notEmpty ( ) )

i s Mo d e li c a Co m p on e n t ( ) : Boolean post : result = ( self . hasStereotype ( ' Component ' ) or self . hasStereotype ( ' Variable ' ) or self . hasStereotype ( ' ConnectionPort ' ) or self . hasStereotype ( ' FunctionArgument ' ) or self . hasStereotype ( ' R eq u i re m e nt I n s ta n c e ' ) or self . hasStereotype ( ' Ca lc ul at ed Pr op er ty ' ) )

i s M o d e l i c a R e s t r i c t e d C l a s s ( ) : Boolean post : result = ( self . hasStereotype ( ' ModelicaPackage ' ) or self . hasStereotype ( ' Operator ' ) or self . hasStereotype ( ' ModelicaClass ' ) or self . hasStereotype ( ' Model ' ) or self . hasStereotype ( ' Block ' ) or self . hasStereotype ( ' Record ' ) or self . hasStereotype ( ' Connector ' ) or self . hasStereotype ( ' Type ' ) or self . hasStereotype ( ' Function ' ) or self . hasStereotype ( ' M od e l ic a E nu m e r at i o n ' ) or self . hasStereotype ( ' CalculationModel ' ) or self . hasStereotype ( ' Requirement ' ) or self . hasStereotype ( ' R e q u i r e m e n t R e p r e s e n t a t i v e ' ) or self . hasStereotype ( ' M e a s u r e O f E f f e c t i v e n e s s ' ) )

is Mo de li ca Be ha vi or ( ) : Boolean post : result = ( hasStereotype ( ' Equations ( Code ) ' )

143

B. Constraint Operations or or or or

hasStereotype ( ' Algorithm ( Code ) ' ) hasStereotype ( ' M o d e l i c a S t a t e M a c h i n e ' ) hasStereotype ( ' C o n d i t i o n a l E q u a t i o n s ( Diagram ) ' ) hasStereotype ( ' C o n d i t i o n a l A l g o r i t h m ( Diagram ) ' ) )

i s M o d e l i c a G e n e r a l i z a t i o n ( ) : Boolean post : result = hasStereotype ( ' ExtendsRelation ' ) or hasStereotype ( ' TypeRelation ' ) )

144

When instantiated, it calculates values that are used by other components.

Appendix C ModelicaML

Inherits from the Stereotype: «Model» the properties: encapsulated, partial, final, replaceable, iconImagePath

Stereotype: «Connector» Description: This stereotype is used to represent the Modelica restricted class "connector". A "connector" cannot contain equation or algorithm sections, it can have causality and flow specification. All ports must be typed by a "connector".

Profile Version: 0.0.102 Note: In each section the stereotypes are sorted alphabetically.

Extends the UML meta-class: Class Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath Property: expandable (multiplicity of entries: 1..1), type: Boolean.

ModelicaClassConstructs

Stereotype: «Function»

Full List Of Stereotypes

Description: Modelica "function" resembles the Modelica "block" but it: Stereotype: «Block» - can only have inputs and outputs; no connectors Description: This stereotype is used to represent the - does not have a connectable interface but instead Modelica "block". Modelica "block" is the same as needs to be called Modelica "model", but the ports (instances of - can be called recursively "connector" classes) must have fixed causality (i.e. - is more dynamic; the arguments are computed at "input" or "output"). run-time - does not have internal states Extends the UML meta-class: Class - can have only one algorithm section and no Inherits from the Stereotype: equation section; is always imperative «ModelicaClassDefinition» the properties: - becomes part of the equation system as black boxes encapsulated, partial, final, replaceable, only; the internals are not manipulated symbolically iconImagePath by the solver Extends the UML meta-class: FunctionBehavior Stereotype: «CalculationModel» (is not a Inherits from the Stereotype: «ModelicaClassDefinition» the properties: Modelica concept) encapsulated, partial, final, replaceable, Description: A CalculationModel is a sub-type of iconImagePath Modelica "model". It is defined in order to enable reusing of equations. It does not represent a physical Property: externalLanguageSpecification system part and cannot have external connectors. 145

C. ModelicaML

(multiplicity of entries: 0..1), type: String. Property: externalFunctionCall (multiplicity of entries: 0..1), type: String. Property: externalAnnotation (multiplicity of entries: 0..1), type: String. Property: scope (multiplicity of entries: 0..1), type: ModelicaScope (inner, outer).

type: Boolean. Property: iconImagePath (multiplicity of entries: 0..1), type: String. Property description: This is the path to the icon image relative to the location of the model file.

Stereotype: «ModelicaEnumeration» Stereotype: «Model»

Description:

Description: This stereotype is used to represent the Modelica restricted class "model". All the following Modelica class elements are allowed in models: Both equation and algorithm sections; connectors, inputs, outputs; states;

Extends the UML meta-class: Enumeration Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Extends the UML meta-class: Class Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Stereotype: «ModelicaModelReference» (is not a Modelica concept) Description: This stereotype represents an existing Modelica model that is included as black-box into ModelicaML model.

Stereotype: «ModelicaClass»

Extends the UML meta-class: Class Description: This stereotype is used to represent the Modelica "class". Property: modelPath (multiplicity of entries: 1..1), type: String. Property description: This string is the Extends the UML meta-class: Class absolute model path (dot-notation, starting with the Inherits from the Stereotype: top-level package) to the referenced model. «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Stereotype: «ModelicaPackage»

Description: This stereotype is used to represent the Stereotype: «ModelicaClassDefinition» (is Modelica restricted class "package".

abstract) Description: This stereotype has attributes that are common to all Modelica restricted classes.

Extends the UML meta-class: Class Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Property: encapsulated (multiplicity of entries: 1..1), type: Boolean. Property: partial (multiplicity of entries: 1..1), type: Boolean. Stereotype: «Operator» Property: final (multiplicity of entries: 1..1), type: Description: This stereotype is used to represent the Boolean. Property: replaceable (multiplicity of entries: 1..1), Modelica restricted class "operator". 146

Modelica component of a composite type. Extends the UML meta-class: Class Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Stereotype: «Record»

Extends the UML meta-class: Property Inherits from the Stereotype: «InstanceOfAClass» the properties: final, modification, arraySize, replaceable, conditionalExpression, iconImagePath

Stereotype: «Connection»

Description: This stereotype is used to represent the Description: This stereotype is used to represent the Modelica "connection" clause and implies its Modelica "record". A Modelica "record" cannot associated semantics (Kirchhoff's laws). contain equation or algorithm sections and does not contain causality and flow specification. Extends the UML meta-class: Connector Extends the UML meta-class: Class Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Stereotype: «Type» Description: This stereotype is used to represent the Modelica restricted class "type". Extends the UML meta-class: PrimitiveType Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

ModelicaCompositeConstructs

Property: explicitConnectionEnds (multiplicity of entries: 0..1), type: String. Property description: This property can be used to define the content of a Modelica connect clause. The keyword "connect" and the parenthesizes are omitted. The string must contain paths to both ports (using the dot-notation) separated by comma. Example: component1.port1.variable1 , component2.port2.variable2

Stereotype: «ConnectionPort» Description: This stereotype is used to represent a Modelica class instance of the type "connector". Extends the UML meta-class: Port Inherits from the Stereotype: «InstanceOfAClass» the properties: final, modification, arraySize, replaceable, conditionalExpression, iconImagePath

Property: causality (multiplicity of entries: 0..1), Stereotype: «CalculatedProperty» (is not a type: ModelicaCausality (input, output).

Modelica concept) Description: Does not represent a physical system part. This component supplies other components with calculated values.

Stereotype: «FunctionArgument» Description: This stereotype is used to represent variables of functions.

Inherits from the Stereotype: «Component» the Extends the UML meta-class: Parameter properties: final, modification, arraySize, Inherits from the Stereotype: «InstanceOfAClass» replaceable, conditionalExpression, iconImagePath the properties: final, modification, arraySize, replaceable, conditionalExpression, iconImagePath

Stereotype: «Component» Description: This stereotype is used to represent a

Property: flowFlag (multiplicity of entries: 0..1), 147

C. ModelicaML

type: ModelicaFlowFlag (flow, stream). else no icon is displayed). Property: scope (multiplicity of entries: 0..1), type: ModelicaScope (inner, outer). Stereotype: «Variable» Property: causality (multiplicity of entries: 1..1), Description: This stereotype is used to represent a type: ModelicaCausality (input, output). Property: variability (multiplicity of entries: 1..1), Modelica class instance of a primitive type (Real, String, Boolean, Integer) or a sub-type of Modelica type: ModelicaVariability (continuous, discrete, restricted class "type". parameter, constant). Property: declarationEquationOrAssignment (multiplicity of entries: 0..1), type: String. Property Extends the UML meta-class: Property description: This refers to the shorthand notation in Inherits from the Stereotype: «InstanceOfAClass» Modelica. The result must be of the same type as the the properties: final, modification, arraySize, Modelica component itself. In this case the value is replaceable, conditionalExpression, iconImagePath the right-hand-expression of the equation or assigment. The "=" or ":=" sign must be included. Property: flowFlag (multiplicity of entries: 0..1), type: ModelicaFlowFlag (flow, stream). Property: scope (multiplicity of entries: 0..1), type: ModelicaScope (inner, outer). Stereotype: «InstanceOfAClass» (is Property: causality (multiplicity of entries: 0..1), abstract) type: ModelicaCausality (input, output). Description: This stereotype has attributes that are Property: variability (multiplicity of entries: 1..1), type: ModelicaVariability (continuous, discrete, common to all Modelica class instances. parameter, constant). Property: final (multiplicity of entries: 1..1), type: Property: declarationEquationOrAssignment (multiplicity of entries: 0..1), type: String. Property Boolean. Property: modification (multiplicity of entries: 0..*), description: This refers to the shorthand notation in Modelica. The result must be of the same type as the type: String. Property description: Each entry Modelica component itself. In this case the value is represents one instance modification of type the right-hand-expression of the equation or "instance name = modification expression". The parenthesis "(" and ")" and the commas are omitted. assigment. The "=" or ":=" sign must be included. Property: arraySize (multiplicity of entries: 0..*), type: String. Property description: Each entry string ModelicaBehaviorConstructs contains the full specification of the array. For example, "[1,3,:]". Property: replaceable (multiplicity of entries: 1..1), Stereotype: «AdditionalIncludes» type: Boolean. Description: Property: conditionalExpression (multiplicity of entries: 0..1), type: String. Property description: Extends the UML meta-class: StateMachine Only if the condition is true then the Modelica Property: additionalActionCode (multiplicity of component is created; the condition is only entries: 0..1), type: String. evaluated at compilation time and is often used for configuration changes. The result of expression must Stereotype: «Algorithm(Code)» be of type Boolean. This string contains the expression. The keyword "if" is omitted. Description: This stereotype is used to represent a Property: iconImagePath (multiplicity of entries: set of statements in an algorithm section. 0..1), type: String. Property description: This is the path to the icon image relative to the location of the Extends the UML meta-class: OpaqueBehavior model file. If no icon is defined for a property then Inherits from the Stereotype: the icon of the property type is displayed (if defined, «AlgorithmLoopProperties» the properties: 148

loopKind, forIndices, whileExpression

Any OpaqueActions, in such an Activity Diagram, must contain Modelica statements in the "body" Property: initial (multiplicity of entries: 1..1), type: attribute. Boolean. Extends the UML meta-class: Activity Stereotype: «AlgorithmLoopProperties» Inherits from the Stereotype: «AlgorithmLoopProperties» the properties: (is abstract) loopKind, forIndices, whileExpression Description: This stereotype has properties that are inherited by other stereotypes in order to be able to Property: isSubActivity (multiplicity of entries: 1..1), type: Boolean. Property description: This capture the "for" or a "while" loop with the "forattribute indicates that this activity is a sub-activity. indices" or "while expression" respectively. It is invoked by another activity using Property: loopKind (multiplicity of entries: 0..1), CallBehaviorAction. type: ModelicaAlgorithmLoopKind (for, while). Property: forIndices (multiplicity of entries: 0..1), Property: initial (multiplicity of entries: 1..1), type: Boolean. type: String. Property: whileExpression (multiplicity of entries: 0..1), type: String. Stereotype:

«ConditionalEquations(Diagram)» Stereotype: Description: This stereotype is used to represent an «AlgorithmStatements(CodeInDiagram)» equation section. An Activity Diagram is used to Description: This stereotype is used to represent a set of algorithm statements in a diagram. Extends the UML meta-class: OpaqueAction Inherits from the Stereotype: «AlgorithmLoopProperties» the properties: loopKind, forIndices, whileExpression

Stereotype: «Assert»

model the conditional constructs (loop, if, when). Any OpaqueActions, in such an Activity Diagram, must contain Modelica equations in the "body" attribute. Extends the UML meta-class: Activity Inherits from the Stereotype: «EquationsLoopProperties» the properties: loopKind, forIndices

Description: This stereotype represents the Modelica assert() function. Property: isSubActivity (multiplicity of entries: Extends the UML meta-class: Constraint 1..1), type: Boolean. Property description: This attribute indicates that this activity is a sub-activity. Property: condition (multiplicity of entries: 1..1), It is invoked by another activity using type: String. CallBehaviorAction. Property: message (multiplicity of entries: 1..1), type: String. Property: initial (multiplicity of entries: 1..1), type: Property: level (multiplicity of entries: 1..1), type: Boolean. ModelicaAssertionLevel (warning, error).

Stereotype: «ConditionalAlgorithm(Diagram)»

Stereotype: «Equations(Code)» Description: This stereotype is used to represent a set of equations in an equation section.

Description: This stereotype is used to represent an algorithm section. An Activity Diagram is used to Extends the UML meta-class: OpaqueBehavior Inherits from the Stereotype: model the conditional constructs (loop, if, when). 149

C. ModelicaML

«EquationsLoopProperties» the properties: Stereotype: «ModelicaMLStateMachine» loopKind, forIndices (is not a Modelica concept) Property: initial (multiplicity of entries: 1..1), type: Description: This stereotypes indicates that this a Boolean. special case of the UML StateMachine. It uses a limited set of the UML StateMachine meta-model Stereotype: «Equations(CodeInDiagram)» classes. It is capable to be translated into executable Description: This stereotype is used to represent a Modelica code. set of equations in a diagram. Extends the UML meta-class: StateMachine Extends the UML meta-class: OpaqueAction Property: samplingExpression (multiplicity of Inherits from the Stereotype: entries: 0..1), type: String. «EquationsLoopProperties» the properties: loopKind, forIndices

Stereotype: «EquationsLoopProperties» (is abstract)

Stereotype: «StateDependency» (is not a Modelica concept)

Description: Description: This stereotype has properties that are inherited by other stereotypes in order to be able to Extends the UML meta-class: ControlFlow, Transition capture the "for" loop with the "for-indices". Property: loopKind (multiplicity of entries: 0..1), type: ModelicaEquationsLoopKind (for). Property: forIndices (multiplicity of entries: 0..1), type: String.

Stereotype: «ExecutionOrderPriority» Description: Extends the UML meta-class: Transition, ControlFlow, Region

Property: isInState (multiplicity of entries: 1..*), type: State. Property description: Reference to a state in one of the state machines of the class. Property: logicalOperator (multiplicity of entries: 1..1), type: LogicalOperators (and, or, not). Property description: The logical operator to be used between the multiple state references.

Stereotype: «StateSpecification» (is not a Modelica concept)

Property: priority (multiplicity of entries: 1..1), Description: type: Integer. Property description: Execution priority in code. A lower number implies a higher execution priority. Elements with higher priority are Extends the UML meta-class: State, StateMachine executed first. Property: freezeExpression (multiplicity of entries: 0..1), type: String. Property description: The state Stereotype: «If» machine or the composite state is fozen, i.e., the Description: This stereotype is used to represent the state is active but no reactions and no actions will be executed inside the state, as long as this expression Modelica "if" keyword. evaluates to true. Extends the UML meta-class: DecisionNode

Stereotype: «StateTransitionSpecification» (is not a Modelica concept) Description: 150

Extends the UML meta-class: Dependency Extends the UML meta-class: Transition Property: arguments (multiplicity of entries: 1..*), type: String.

Property: suppressExitActions (multiplicity of entries: 1..1), type: Boolean. Property description: If set to true then exit actions of the transition sourceStereotype: «RedeclareRelation» state and its sub-states are not executed. Description: Property: suppressEntryActions (multiplicity of entries: 1..1), type: Boolean. Property description: If Extends the UML meta-class: Dependency set to true then entry actions of the transition targetProperty: modification (multiplicity of entries: 0..*), state (not its sub-states) are not executed. type: String.

Stereotype: «When»

Stereotype: «TypeRelation»

Description: This stereotype is used to represent the Description: This stereotype has attributes which Modelica "when" keyword. allow the capturing of type modifications. It can only be used between classes of primitive type. Extends the UML meta-class: DecisionNode

ModelicaRelationsConstructs Stereotype: «ConstrainedByRelation» Description:

Extends the UML meta-class: Generalization Property: modification (multiplicity of entries: 0..*), type: String. Property description: Each entry represents a Modelica type modification. Commas and the parenthesis "(" and ")" are omitted.

Extends the UML meta-class: Dependency

Property: arraySize (multiplicity of entries: 0..*), type: String. Property description: Each string Property: modification (multiplicity of entries: 0..*), contains the full array specification (e.g. "[1,3,:]") type: String.

Stereotype: «ExtendsRelation» Description: This stereotype has attributes which allow the capturing of type modifications.

ModelicaRequirementConstructs Stereotype: «MeasureOfEffectiveness» (is not a Modelica concept)

Extends the UML meta-class: Generalization

Description: This stereotype is used to represent a model that measures performances of other system Property: modification (multiplicity of entries: 0..*), models and compares them in order to determine the type: String. Property description: Each entry best potential design solution. represents a Modelica type modification. Commas and the parenthesis "(" and ")" are omitted. Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, Stereotype: iconImagePath

«PartialDerivativeOfFunctionRelation» Description:

151

C. ModelicaML

Stereotype: «Requirement» (is not a Modelica concept)

requirement. It is used to bind same requirements to multiple design models.

Description: The concept of textual requirements is reused from the OMG SysML. This stereotype is used to represent a requirement with properties such as id, text (representing the textual statement), etc. Moreover, a requirement can have variables and behavior defined which can be evaluated during simulations.

Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath

Extends the UML meta-class: Class Inherits from the Stereotype: «ModelicaClassDefinition» the properties: encapsulated, partial, final, replaceable, iconImagePath Property: id (multiplicity of entries: 1..1), type: String. Property description: Requirement ID. Property: text (multiplicity of entries: 1..1), type: String. Property description: Textual requirement statement. Property: specifiesType (multiplicity of entries: 0..*), type: ModelicaClassDefinition. Property description: This property implies that all instantiated objects of the referenced types shall fulfill this requirement. Property: specifiesObject (multiplicity of entries: 0..*), type: String. Property description: This property implies that only the referenced objects shall fulfill this requirement.

Property: specifiesType (multiplicity of entries: 0..*), type: ModelicaClassDefinition. Property: specifiesObject (multiplicity of entries: 0..*), type: String. Property: designModelReference (multiplicity of entries: 1..1), type: ModelicaClassDefinition. Property description: A reference to the system desing model.

Stereotype: «Traceability» (is not a Modelica concept) Description: This stereotype can be applied to any model element. It has properties that can be used for setting up the traceability between requirements and design artifacts. Extends the UML meta-class: NamedElement Property: specifiedByRequirement (multiplicity of entries: 0..*), type: Requirement.

ModelicaSimulationConstructs

Stereotype: «CodeGeneration» (is not a Stereotype: «RequirementInstance» (is not Modelica concept) a Modelica concept) Description: This stereotype indicates that this component is an instantiation of a requirement.

Description: This stereotype is used for caturing of code generation specific information.

Extends the UML meta-class: Element Inherits from the Stereotype: «Component» the properties: final, modification, arraySize, Property: generateInteractiveSimInitFile replaceable, conditionalExpression, iconImagePath (multiplicity of entries: 1..1), type: Boolean. Property description: If this property is set for a Stereotype: «RequirementRepresentative» class the code generator will generate an init-file that is required for the interactive simulation (OMC (is not a Modelica concept) specific). Description: The requirement observer represents a 152

Property: excludeFromCG (multiplicity of entries: for the parameter if necessary. 1..1), type: Boolean. Property description: This flag indicates that no code shall be generated for this Extends the UML meta-class: Property element. Property: declaration (multiplicity of entries: 0..1), type: String. Property description: Declaration value Stereotype: for the parameter.

«ExcludeFromCGIfUserInteractive» (is not a Modelica concept)

ModelicaAnnotationConstructs

Description: This stereotypes is used to indicate that this behavior shall be excluded from the code generation if the referenced variable is set to be user Stereotype: interactive (variability is set to "parameter"). «Annotation(CodeGeneration)»

Description: See the Modelica specification. Extends the UML meta-class: Comment Property: Evaluate (multiplicity of entries: 0..1), Property: variableReference (multiplicity of entries:type: Boolean. Property: HideResult (multiplicity of entries: 0..1), 1..1), type: Variable. Property description: type: Boolean. Reference to the variable that is user interactive (must have the stereotype applied) and thus does Property: Inline (multiplicity of entries: 0..1), type: not need the behavior (equations or algorithm) for its Boolean. Property: LateInline (multiplicity of entries: 0..1), calculation. type: Boolean. Property: smoothOrder (multiplicity of entries: Stereotype: «Simulation» 0..1), type: Integer. Description: This stereotype contains the properties which are used in the "simulate()" command in Stereotype: «Annotation(Documentation)» Modelica tools. Description: See the Modelica specification. Extends the UML meta-class: Comment Extends the UML meta-class: Class Property: info (multiplicity of entries: 0..1), type: Property: startTime (multiplicity of entries: 0..1), String. Property: revisions (multiplicity of entries: 0..1), type: UnlimitedNatural. Property: stopTime (multiplicity of entries: 0..1), type: String. Extends the UML meta-class: StateMachine, OpaqueBehavior, Activity

type: UnlimitedNatural. Property: numberOfIntervals (multiplicity of entries: 0..1), type: Integer. Property: tolerance (multiplicity of entries: 0..1), type: String.

Stereotype: «UserInteractive» (is not a Modelica concept)

Stereotype: «Annotation(Icon)» Extends the UML meta-class: Comment Property: iconAnnotationString (multiplicity of entries: 0..1), type: String.

Stereotype: Description: This stereotype is used to indicate that «Annotation(SimulationExperiment)»

the value of this variable shall be manipulated by the Description: The experiment annotation defines the user. Therefore it is necessary to set the variability to default start time (StartTime) in [s], the default stop "parameter" (this requirement is OMC-specific). time (StopTime) in [s], Moreover, the modeler can define declaration value 153

C. ModelicaML

and the default relative integration tolerance with all annotations from this chapter and all vendor(Tolerance) for simulation experiments to be carried specific annotations intact. To ensure this, out with the model or block at hand. annotations must be represented with constructs according to the Modelica grammar. The Extends the UML meta-class: Comment specification in this document defines the semantic meaning if a tool implements any of these Property: StartTime (multiplicity of entries: 0..1), annotations. type: UnlimitedNatural. Property: StopTime (multiplicity of entries: 0..1), Extends the UML meta-class: Comment type: UnlimitedNatural. Property: Tolerance (multiplicity of entries: 0..1), Property: fullAnnotationString (multiplicity of type: UnlimitedNatural. entries: 0..1), type: String. Property description: This is a qualified annotation string. The first "(" and the last ")" are omitted.

Stereotype: «Annotation(VersionHandling)»

Description: A top-level package or model can specify the version of top-level classes it uses, its own version number, and if possible how to convert from previous versions. This can be used by a tool to guarantee that consistent versions are used, and if possible to upgrade usage from an earlier version to a current one. Extends the UML meta-class: Comment

ModelicaPredefinedTypes Primitive Type: ModelicaBoolean Property: quantity (multiplicity of entries: 0..1), type: String. Property: fixed (multiplicity of entries: 0..1), type: Boolean. Property: start (multiplicity of entries: 0..1), type: Boolean.

Property: version (multiplicity of entries: 0..*), type: String. Property description: Defines the version Primitive Type: ModelicaInteger number of the model or package. All classes within Property: quantity (multiplicity of entries: 0..1), this top-level class have this version number. type: String. Property: min (multiplicity of entries: 0..1), type: Property: conversion (multiplicity of entries: 0..*), Integer. type: String. Property description: The first "(" and Property: max (multiplicity of entries: 0..1), type: the last ")" are omitted. Integer. Property: fixed (multiplicity of entries: 0..1), type: Property: uses (multiplicity of entries: 1..1), type: Boolean. String. Property description: The first "(" and the Property: start (multiplicity of entries: 0..1), type: last ")" are omitted. Integer.

Stereotype: «Annotation»

Primitive Type: ModelicaReal

Description: Annotations are intended for storing Property: quantity (multiplicity of entries: 0..1), extra information about a model, such as graphics, type: String. documentation or versioning, etc. A Modelica tool is Property: unit (multiplicity of entries: 0..1), type: free to define and use other annotations, in addition String. to those defined here, according to section 14.1. of Property: displayUnit (multiplicity of entries: 1..1), the Modelica specification. type: String. The only requirement is that any tool shall save files Property: min (multiplicity of entries: 0..1), type: 154

UnlimitedNatural. Property: max (multiplicity of entries: 0..1), type: UnlimitedNatural. Property: fixed (multiplicity of entries: 0..1), type: Boolean. Property: nominal (multiplicity of entries: 0..1), type: UnlimitedNatural. Property: start (multiplicity of entries: 0..1), type: UnlimitedNatural. Property: stateSelect (multiplicity of entries: 0..1), type: ModelicaStateSelect (default, never, avoid, prefer, always).

Primitive Type: ModelicaString Property: quantity (multiplicity of entries: 0..1), type: String. Property: start (multiplicity of entries: 0..1), type: String.

155

Appendix D CD-ROM The developed plug-ins and some validation examples are stored on the attached CD-ROM. Figure D.1 shows the file structure of the CD-ROM. The CD-ROM consists of the Eclipse framework with all in this thesis developed and required plug-ins. Further, the CD has stored an Eclipse workspace, which contains the source of the developed plug-ins and some small validation examples. The plugin jars for Eclipse and the source are also provided separately in the archives plugins.zip and sourcePlugins.zip. In the archive file validationExamples.zip is a bunch of small examples provided. These are modeled with ModelicaML and can be opened with Papyrus UML. It is possible to generate Modelica code for these examples and to simulate the generated code with Dymola. An electronic form of this thesis is also stored on the CD-ROM.

157

D. CD-ROM

Figure D.1: CD-ROM Structure

158

Bibliography [Acc09]

Acceleo, MDA: Generator, Acceleo. (2009). eclipse.org/modeling/m2t/?project=acceleo

[ACHH93]

Alur, R. ; Courcoubetis, C. ; Henzinger, T. ; Ho, P.: Hybrid automata: An algorithmic approach to the specification and verification of hybrid systems. In: Hybrid systems (1993), p. 209–229

[AD94]

Alur, R. ; Dill, D.L.: A theory of timed automata* 1. In: Theoretical computer science 126 (1994), No. 2, p. 183–235

[And03]

´, C.: Semantics of SSM (Safe State Machine). In: Esterel Andre Technologies (2003)

[ASK04]

Agrawal, A. ; Simon, G. ; Karsai, G.: Semantic translation of Simulink/Stateflow models to hybrid automata using graph transformations. In: Electronic Notes in Theoretical Computer Science 109 (2004), p. 43–56

[Bee94]

Beeck, M. Von d.: A comparison of statecharts variants. In: Formal Techniques in Real-Time and Fault-Tolerant Systems Springer, 1994, p. 128–148

[BG03]

Burmester, Sven ; Giese, Holger: The Fujaba Real-Time State¨ ndorf, Albert (Hrsg.): chart PlugIn. In: Giese, Holger (Hrsg.) ; Zu Proc. of the first International Fujaba Days 2003, Kassel, Germany Bd. tr-ri-04-247, University of Paderborn, 10 2003 (Technical Report), p. 1–8

[BGH+ 07]

Burmester, Sven ; Giese, Holger ; Henkler, Stefan ; Hirsch, ¨ nch, EckeMartin ; Tichy, Matthias ; Gambuzza, Alfonso ; Mu ¨ cking, Henner: Tool Support for Developing Advanced hard ; Vo Mechatronic Systems: Integrating the Fujaba Real-Time Tool Suite with CAMeL-View. In: ICSE, 2007, p. 801–804

[BGS03]

¨ fer, W.: Code Generation for Burmester, S. ; Giese, H. ; Scha Hard Real-time Systems from Real-time Statecharts / University of Paderborn. 2003. – Technical Report

http://www.

159

Bibliography [BGS05]

¨ fer, W.: Model-Driven ArBurmester, S. ; Giese, H. ; Scha chitecture for Hard Real-Time Systems: From Platform Independent Models to Code. In: Proc. of the European Conference on Model Driven Architecture - Foundations and Applications (ECMDAFA’05), N¨ urnberg, Germany, 2005

[BGT04]

Burmester, Sven ; Giese, Holger ; Tichy, Matthias: ModelDriven Development of Reconfigurable Mechatronic Systems with Mechatronic UML. In: MDAFA, 2004, p. 47–61

[BGT05]

Burmester, S. ; Giese, H. ; Tichy, M.: Model-driven development of reconfigurable mechatronic systems with mechatronic UML. In: Model Driven Architecture (2005), p. 47–61

[BH08]

Bruck, James ; Hussey, Kenn: Customizing UML: Which Technique is Right for You?,. (2008). "http://www.eclipse.org/ modeling/mdt/uml2/docs/articles/Customizing_UML2_Which_ Technique_is_Right_For_You/article.html". – [Online; accessed 06-July-2010]

[Bir27]

Birkhoff, G.D.: Dynamical systems. In: American Mathematical Society, New York 9 (1927). – Colloquium Publications

[BKK02]

Borshchev, A. ; Karpov, Y. ; Kharitonov, V.: Distributed simulation of hybrid systems with AnyLogic and HLA. In: Future Generation Computer Systems 18 (2002), No. 6, p. 829–839

[Boe]

Boerger, E.: The Abstract State Machines method for high-level system design and analysis. In: Formal Methods: State of the Art and New Directions

[Boo86]

Booch, G.: Object-oriented development. In: IEEE Trans. Softw. Eng. 12 (1986), No. 2, 211–221. http://portal.acm.org/ citation.cfm?id=9797. – ISSN 0098–5589

[Boo93]

Booch, Grady: Object-Oriented Analysis and Design with Applications. Second. Addison-Wesley Professional, 1993. – ISBN 0805353402

[Bre08]

Breitenecker, Felix: Development of Simulation Software - from Simple ODE Modelling to Structural Dynamic Systems. In: Proceedings of ECMS2008 (2008). – Keynote Speech

[BRJ96]

Booch, G. ; Rumbaugh, J. ; Jacobson, I.: The unified modeling language. In: Unix Review 14 (1996), No. 13, p. 5

160

Bibliography [Bur02]

Burmester, Sven: Generierung von Java Real-Time Code f¨ ur zeitbehaftete UML Modelle, University of Paderborn, Department of Computer Science, Paderborn, Germany, Diplomarbeit, September 2002

[CBIB99]

Christen, E. ; Bakalar, K. ; Inc, A. ; Beaverton, OR: VHDLAMS-a hardware description language for analog andmixed-signal applications. In: IEEE Transactions on Circuits and Systems II: Analog and Digital Signal Processing 46 (1999), No. 10, p. 1263–1272

[CCG+ 02]

Cimatti, A. ; Clarke, E. ; Giunchiglia, E. ; Giunchiglia, F. ; Pistore, M. ; Roveri, M. ; Sebastiani, R. ; Tacchella, A.: Nusmv 2: An opensource tool for symbolic model checking. In: Computer Aided Verification Springer, 2002, p. 241–268

[CD07]

Crane, Michelle L. ; Dingel, J¨ urgen: UML vs. classical vs. rhapsody statecharts: not all models are created equal. In: Software and System Modeling 6 (2007), No. 4, p. 415–435

[Cel79]

Cellier, F.E.: Combined continuous/discrete system simulation by use of digital computers: Techniques and tools, Swiss Federal Institute of Technology Zurich, Diss., 1979

[CEO96]

Cellier, F.E. ; Elmqvist, H. ; Otter, M.: Modeling from physical principles. In: The control handbook (1996), p. 99–108

[CH03]

Czarnecki, Krzysztof ; Helsen, Simon: Classification of model transformation approaches. In: OOPSLA’03, Workshop on Generative Techniques in the Context of Model-Driven Architecture University of Waterloo, Canada, 2003

[Cra09]

Craig, K.: Mechatronic System Design. In: 2009 Motor, Drive & Automation Systems Conference (2009)

[Dav95]

David, R.: Grafcet: A powerful tool for specification of logic controllers. In: IEEE transactions on control systems technology 3 (1995), No. 3, p. 253–268

[DHBN08]

Donath, U. ; Haufe, J. ; Blochwitz, T. ; Neidhold, T.: A new approach for modeling and verification of discrete control components within a Modelica environment. In: Proceedings of the 6th Modelica Conference, Bielefeld, 2008, p. 269–276

[Dru]

Drusinsky, D.: Modeling and Verification Using UML Statecharts. In: Elsevier 400, p. 978–0

161

Bibliography [EKR+ 10]

Engels, G. ; Kleppe, A. ; Rensink, A. ; Semenyak, M. ; Soltenborn, C. ; Wehrheim, H.: From UML Activities to TAALTowards Behaviour-Preserving Model Transformations. In: Model Driven Architecture–Foundations and Applications Springer, 2010, p. 94–109

[Elm78]

Elmqvist, H.: A structured model language for large continuous systems. Sweden, Lund Institute of Technology, Diss., 1978

[EMO98]

Elmqvist, H. ; Mattsson, S.E. ; Otter, M.: Modelica: The new object-oriented modeling language. In: 12th European Simulation Multiconference, Manchester, UK (1998)

[Fri04]

Fritzson, Peter: Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. 1., Auflage. Wiley-IEEE Press, 2004 http://www.worldcat.org/isbn/0471471631. – ISBN 0471471631

[GB03]

Giese, Holger ; Burmester, Sven: Real-Time Statechart Semantics / Lehrstuhl f¨ ur Softwaretechnik, Universität Paderborn. Paderborn, Germany, June 2003 (tr-ri-03-239). – Technical Report. – 1–32 S.

[GBSO04]

¨ fer, Wilhelm ; OberGiese, Holger ; Burmester, Sven ; Scha schelp, Oliver: Modular design and verification of component-based mechatronic systems with online-reconfiguration. In: SIGSOFT FSE, 2004, p. 179–188

[GHJV95]

Gamma, E. ; Helm, R. ; Johnson, R. ; Vlissides, J.: Design patterns: elements of reusable object-oriented software. Addison-wesley Reading, MA, 1995

[Gil62]

Gill, A.: Introduction to the Theory of Finite-state Machines. McGraw-Hill New York, 1962

[GK07]

Greenyer, J. ; Kindler, E.: Reconciling TGGs with QVT. In: Model Driven Engineering Languages and Systems (2007), p. 16–30

[Gov81]

Gove, P.B.: Webster’s third new international dictionary of the English language, unabridged. G. & C. Merriam Co., 1981

[GP06]

Girard, A. ; Pappas, G.: Verification using simulation. In: Hybrid Systems: Computation and Control (2006), p. 272–286

[GT05]

Giese, H. ; Tissen, S.: The SceBaSy Plugin for the Scenario-Based Synthesis of Real-Time Coordination Patterns for Mechatronic UML. In: Proc. of the 3rd International Fujaba Days 2005, Paderborn, Germany, 2005

162

Bibliography [GVN47]

Goldstine, H.H. ; Von Neumann, J.: Planning and coding of problems for an electronic computing instrument. Institute for Advanced Study, 1947

[Har87]

Harel, D.: Statecharts: A visual formalism for complex systems. In: Science of computer programming 8 (1987), No. 3, p. 231–274

[Hen96]

Henzinger, T. A.: ”The Theory of Hybrid Automata”. In: In Proc. of IEEE Symposium on Logic in Computer Science (LICS’96) 11 (1996), p. 278–292

[HH08]

Henkler, S. ; Hirsch, M.: Tool Support for Developing Advanced Mechatronic Systems: Integrating the Fujaba Real-Time Tool Suite with CAMeL-View. In: Proc. of the Dagstuhl-Workshop: ModelBased Development of Embedded Systems (MBEES), 7.3.-12.3.2008, Schloss Dagstuhl, Germany, 2008

[Hir08]

Hirsch, M.: Modell-basierte Verifikation von vernetzten mechatronischen Systemen, University of Paderborn, Paderborn, Germany, Diss., 2008

[HK04]

Harel, D. ; Kugler, H.: The RHAPSODY Semantics of Statecharts (or, On the Executable Core of the UML). In: Integration of software specification techniques for applications in engineering: Priority Program SoftSpez of the German Research Foundation (DFG): final report (2004), p. 325

[HMS+ 10]

¨ fer, W. ; Nickel, U. ; Detten, Henkler, S. ; Meyer, J. ; Scha M. von: Legacy Component Integration by the Fujaba Real-Time Tool Suite. In: Proceedings of the 32nd International Conference on Software Engineering (ICSE 2010), Cape Town, South Africa, 2010

[HN96]

Harel, D. ; Naamad, A.: The STATEMATE semantics of statecharts. In: ACM Transactions on Software Engineering and Methodology (TOSEM) 5 (1996), No. 4, p. 333

[HPI99]

Hahn, Martin. ; Paderborn., Universität-Gesamthochschule ; Ingenieure., Verein D.: OMD–ein Objektmodell fur den Mechatronikentwurf :–Anwendung in der objektorientierten Modellbildung mechatronischer Systeme unter Verwendung von Mehrkörpersystemformalismen /–Martin Hahn., Universität-Gesamthochschule Paderborn, Diss., 1999

[HR07]

Hamon, G. ; Rushby, J.: An operational semantics for Stateflow. In: International Journal on Software Tools for Technology Transfer (STTT) 9 (2007), No. 5, p. 447–456

163

Bibliography [Hus06]

Hussey, Kenn: Introduction to UML2 Profiles. (2006). "http://www.eclipse.org/modeling/mdt/uml2/docs/articles/ Introduction_to_UML2_Profiles/article.html"

[Jac92]

Jacobson, I.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Professional, 1992. – ISBN 0201544350

[Kle99]

Klein, Thomas: Rekonstruktion von UML-Aktivitäts- und Kollaborationsdiagrammen aus Java-Quelltexten, University of Paderborn, Department of Computer Science, Paderborn, Germany, Diplomarbeit, October 1999

[Kön08]

¨ nigs, Alexander: Ko Model Integration and Transformation - A Triple Graph Grammar-based QVT Implementation, TU Darmstadt, Diss., 2008. http://dx.doi.org/urn:nbn:de: tuda-tuprints-11949. – DOI urn:nbn:de:tuda–tuprints–11949

[KW78]

Korn, G.A. ; Wait, J.V.: Digital continuous-system simulation. Prentice Hall, 1978

[MEB97]

Mattson, S.E. ; Elmqvist, H. ; Broenink, J.F.: Modelica: An international effort to design the next generation modelling language. In: Journal A 38 (1997), No. 3, p. 16–19

[MEM+ 08] Malmheden, M. ; Elmqvist, H. ; Mattsson, S.E. ; Henriksson, D. ; Otter, M.: ModeGraph-A Modelica Library for Embedded Control Based on Mode-Automata. In: in Proc. of Modelica 2008 conference, Bielefeld, Germany., 2008 [MG76]

Mitchell, E.E.L. ; Gauthier, J.S.: Advanced continuous simulation language (ACSL). In: Simulation 26 (1976), No. 3, p. 72

[MG06]

Morris, SJ ; Gotel, OCZ: Flow Diagrams: Rise and fall of the first software engineering notation. In: Lecture Notes in Computer Science 4045 (2006), p. 130

[Mod10]

Modelica, Association: Modelica - A Unified Object-Oriented Language for Physical Systems Modeling, Language Specification, Version 3.2. Version: 2010. http://www.modelica.org/documents/ ModelicaSpec32.pdf. 2010. – Technical Report

[MOF06]

MOF, Object Management G.: OMG MetaObject Facility (OMG MOF), V2.0. Version: January 2006. http://www.omg.org/spec/ MOF/2.0/PDF/. 2006. – Technical Report

164

Bibliography [MR98]

´mond, Y.: Mode-automata: About modes Maraninchi, F. ; Re and states for reactive systems. In: Programming Languages and Systems (1998), p. 105–115

[NG07]

Nytsch-Geusen, C.: The use of the UML within the modelling process of Modelica-models. In: EOOLT (2007), p. 1

[NGEN+ 05] Nytsch-Geusen, C. ; Ernst, T. ; Nordwig, A. ; Schneider, P. ; Schwarz, P. ; Vetter, M. ; Wittwer, C. ; Holm, A. ; Nouidui, T. ; Leopold, J. et al.: MOSILAB: Development of a Modelica based generic simulation tool supporting model structural dynamics. In: Paper presented at the 4th International Modelica Conference, 2005 [NGEN+ 06] Nytsch-Geusen, C. ; Ernst, T. ; Nordwig, A. ; Schwarz, P. ; Schneider, P. ; Vetter, M. ; Wittwer, C. ; Holm, A. ; Nouidui, T. ; Leopold, J. et al.: Advanced modeling and simulation techniques in MOSILAB: A system development case study. In: Proceedings of the 5th International Modelica Conference, Arsenal Research, Wien, 2006 [O˚ AD05]

˚rze ń, K.E. ; Dressler, I.: StateGraph–A Modelica Otter, M. ; A Library for Hierarchical State Machines. In: Paper presented at the 4th International Modelica Conference, 2005

[OCL10]

OCL, Object Management G.: OMG Object Constraint Language (OMG OCL), V. 2.2. Version: February 2010. http://www.omg. org/spec/OCL/2.2/PDF/. 2010. – Technical Report

[OEM]

Otter, M. ; Elmqvist, H. ; Mattsson, S.E.: Hybrid modeling in Modelica based on the synchronous data flow principle. In: Proceedings of the International Symposium on Computer Aided Control System Design Citeseer, p. 151–157

[OEM+ 99]

Otter, M. ; Elmqvist, H. ; Mattsson, S.E. ; Oberpfaffenhofen, D. ; Ab, D. ; Ab, D.: Hybrid Modeling in Modelica based on the Synchronous Data Flow Principle. In: Accepted for the 1999 IEEE Symposium on Computer-Aided Control System design, CACSD’99 Citeseer, 1999, p. 22–27

[OKK97]

Oliver, D.W. ; Kelliher, T.P. ; Keegan, J.G.: Engineering complex systems with models and objects. McGraw-Hill Companies, 1997

[OME+ 09]

Otter, M. ; Malmheden, M. ; Elmqvist, H. ; Mattsson, S.E. ; `mes, D. ; Lund, S.D.: A New Formalism for Johnsson, C. ; Syste Modeling of Reactive and Hybrid Systems. (2009)

165

Bibliography [OMG08]

OMG: MOF Model to Text Transformation Language (MOFM2T), 1.0. (2008), June, No. OMG document formal/08-01-16.pdf. http: //www.omg.org/spec/MOFM2T/1.0/PDF

[PAF07a]

Pop, A. ; Akhlevidiani, D. ; Fritzson, P.: Towards unified system modeling with the ModelicaML UML profile. In: EOOLT (2007), p. 13

[PAF07b]

Pop, A. ; Akhvlediani, D. ; Fritzson, P.: Integrated UML and modelica system modeling with ModelicaML in Eclipse. In: Proceedings of the 11th IASTED International Conference on Software Engineering and Applications (SEA’07), 2007

[Pap09]

Papyrus, MDA: Papyrus-Proposal. "http://wiki.eclipse.org/ MDT/Papyrus-Proposal". Version: 2009. – [Online; accessed 06July-2010]

[Pet82]

Petzold, LR: Description of DASSL: a differential/algebraic system solver. In: 10. international mathematics and computers simulation congress on systems simulation and scientific computation Bd. 9, 1982

[Pil09]

Pilgrim, Jens von: GEF goes 3D. Teil 1: Dreidimensionale Editoren erstellen mit GEF3D. In: Eclipse Magazin, Software & Support Verlag GmbH 6.09 (2009), p. 60–66. – ISSN 1861-2296

[Qua01]

Quatrani, T: Introduction to the unified modeling language. In: Objec-Time Limited/Rational Sofware Corp. white paper (2001)

[RBL+ 90]

Rumbaugh, James R. ; Blaha, Michael R. ; Lorensen, William ; Eddy, Frederick ; Premerlani, William: Object-Oriented Modeling and Design. Prentice Hall, 1990. – ISBN 0136298419

[SAF+ 67]

Strauss, J.C. ; Augustin, D.C. ; Fineberg, M.S. ; Johnson, B.B. ; Linebarger, R.N. ; Sanson, FJ: The SCi continuous system simulation language (CSSL). In: Simulation 9 (1967), No. 6, p. 281– 303

[Sch09]

Schamai, Wladimir: Modelica Modeling Language (ModelicaML) : A UML Profile for Modelica / Linköping University, Department of Computer and Information Science, The Institute of Technology. Version: 2009. http://urn.kb.se/resolve?urn=urn:nbn:se:liu: diva-20553. Linköping University Electronic Press, 2009 (Technical reports in Computer and Information Science 2009:5). – Technical Report. – 49 S.

166

Bibliography [Sys08]

SysML, Object Management G.: OMG Systems Modeling Language (OMG SysML), V1.1. Version: November 2008. http://www.omg. org/spec/SysML/1.1/PDF/. 2008. – Technical Report

[Tum02]

Tummescheit, H.: Design and Implementation of Object-Oriented Model Libraries using Modelica. In: PhD-Arbeit, Department of Automatic Control, Lund Institute of Technology, Lund, Schweden (2002)

[UML09]

UML, Object Management G.: OMG Unified Modeling Language (OMG UML), Superstructure, V2.2. Version: February 2009. http://www.omg.org/spec/UML/2.2/Superstructure/PDF/. 2009. – Technical Report

[Wel79]

Wellstead, P.E.: Introduction to physical system modelling. Academic Press London, 1979

[ZLB07]

Zauner, G. ; Leitner, D. ; Breitenecker, F.: Modeling Structural-Dynamics Systems in MODELICA/Dymola, MODELICA/Mosilab and AnyLogic. In: EOOLT (2007), p. 99

[Z¨ un01]

¨ ndorf, A.: Rigorous Object Oriented Software Development. HaZu bilitation Thesis, University of Paderborn, 2001

167

A UML Based Modeling Language With Operational ...

A UML Based Modeling Language With Operational ...

Suggest Documents

UML - A Universal Modeling Language?

A UML-Based Domain Specific Modeling Language for the Availability

Applying a UML-based Agent Modeling Language ... - Semantic Scholar

A UML-Based Domain Specific Modeling Language for the Availability ...

The Unified Modeling Language (UML)

Object Modeling with UML:

Towards an UML Based Modeling Language to Design Adaptive Web ...

An Analysis of Unified Modeling Language (UML

Unified Modeling Language (UML) - Semantic Scholar

Modeling Web Services with UML

Chapter 2 Modeling with UML

Modeling Systems with UML - Akira

UML (Unified Modeling Language): Standard Language for Software ...

UML-F: A Modeling Language for Object-Oriented ... - SE@RWTH

towards a formal operational semantics of uml

UML-based Cloud Application Modeling with Libraries, Profiles, and ...

UML-based Cloud Application Modeling with Libraries, Profiles, and

Modeling adaptation with a tuple-based coordination language*

A UML-based language for specifying domain ... - Semantic Scholar

A UML-Based Metamodeling Language to Specify Design Patterns

A UML-Based Metamodeling Language to Specify Design ... - CiteSeerX

business process modeling with uml - CiteSeerX

Multidimensional Modeling with UML Package ... - Semantic Scholar

Agile Modeling with the UML - SE@RWTH