The MechatronicUML Design Method Process and Language for Platform-Independent Modeling M ECHATRONIC UML. Technical Report tr-ri

Transcription

1 The MechatronicUML Design Method Process and Language for Platform-Independent Modeling M ECHATRONIC UML Technical Report tr-ri Steffen Becker, Stefan Dziwok, Christopher Gerking Christian Heinzemann, Sebastian Thiele, Wilhelm Schäfer Software Engineering Group, Heinz Nixdorf Institute, University of Paderborn Zukunftsmeile 1, Paderborn, Germany [stefan.dziwok wilhelm]@upb.de Matthias Meyer, Uwe Pohlmann, Claudia Priesterjahn Fraunhofer IPT, Project Group Mechatronic Systems Design Zukunftsmeile 1, Paderborn, Germany Matthias Tichy Software Engineering Group Chalmers Technical University and University of Gothenburg, Sweden Version: 0.4 Paderborn, March 7, 2014 HEINZ NIXDORF INSTITUTE University of Paderborn Software Engineering

2

3 Contents 1. Introduction Example Benefits for the Developer MECHATRONICUML Overview 7 3. Modeling Language Data Type Specification Primitive Data Type Ranged Primitive Data Type Array Data Type Component Model Data Type Message Type Specification Message Type Repository Message Type Real-Time Coordination Protocol Example of a Real-Time Coordination Protocol Role Coordination Direction of Roles Cardinality of Roles Incoming Message Buffer Role Connector Steps of a Message Transmission QoS Assumption of the Role Connector Classification of Real-Time Coordination Protocols Directions of Coordination Forms of Coordination Real-Time Coordination Protocol Instance Protocol Behavior Specification Real-Time Model Checking of Protocol Properties Real-Time Statechart Clock Time Value Clock Constraint III

4 IV CONTENTS Clock Reset State Invariant State Events Initial State Final State Simple State Composite State Transition Types of Transitions Conditions Urgency Effects Deadlines State Connection Point Entry Point Exit Point Effect Action Variable Operation Asynchronous Messages Exchange Raise Message Trigger Message Synchronization Synchronization with Selector Execution Semantics of Synchronizations Multi Role and Multi Port Real-Time Statechart Execution Semantics Enabling Transitions Selection Criteria for Firing Transitions Firing Transitions Action Language Block Local Variable Declaration and Initialization Expression Selector Expressions Operation Call Operation Implementation Assignment Loop If-Statement

5 CONTENTS V Operator Terminal Grammar Component Model Atomic Component Type Atomic Component Port Port Behavior Specification Discrete Component Behavior Specification Structured Component Type Structured Component Port Component Part Delegation Connector Assembly Connector Component Instance Configuration Component Instance Atomic Component Instance Structured Component Instance Port Instance Discrete Port Instance Continuous And Hybrid Port Instance Connector Instance Assembly Connector Instance Delegation Connector Instance Component Instance Configuration Modeling Extensions for Reconfigurable Systems Requirements Component Model Extensions Reconfigurable Atomic Component Reconfiguration of Single Port Instances Reconfiguration of Multi Port Instances Reconfigurable Structured Component Component Story Diagrams Component Story Pattern Specification of the Control Flow Development Process Process for Self-Optimizing Mechatronic Systems The MECHATRONICUML Platform-Independent Modeling Process Determination of Coordination Protocols (Step 3)

6 VI CONTENTS Modeling of a Real-Time Coordination Protocol (Step 3.2) Determination of the Components Behavior (Step 4) Modeling of the Components Behavior (Step 4.3) Complete Example Real-Time Coordination Protocols and Message Interfaces Navigation Protocol and Message Interface Role Navigator Role Provider Delegation Protocol and Message Interface Role Master Role Slave Distribution Protocol Role Distributor Role Client PositionTransmission Protocol and Message Interface Role Sender Role Receiver AllPositionsTransmission Protocol and Message Interface Role Sender Role Receiver System Structure Structured Components Atomic Components Exploration Navigation BeBot Observer Collision Control PosData MotionCtrl Real-Time Statechart Exploration Navigation BeBot Observer Collision Control Component Instance Configuration Single BeBot Networks of BeBots Related Work Contract-Based Design Contract Levels

7 CONTENTS VII Automata Models for Supporting the Contract Levels Untimed Automata Models SPEEDS Behavioral Connectors Higher-Order Architectural Connectors Reo Multi-Agent-Systems Specification Languages for Systems Engineering SysML MATLAB/Simulink Stateflow Modelica CHARON Masaccio/Giotto Process Models for Systems Engineering Software Component Models Component Models for Business Information Systems Supporting Run-Time Reconfiguration Component Models for Embedded and Real-Time Systems Specifications of Self-Adaptive Systems Reference Architectures for Self-Adaptive Systems Modeling of Self-Adaptive Systems Graph Transformation based Approaches Process Algebra based Approaches Formal Logic based Approaches Approaches Defining an Own Semantics Run-Time Frameworks for Self-Adaptation Formal Models for Modeling of Real-time Behavior Discrete time models Dense time models Conclusions and Future Work Bibliography Own Publications Bachelor Theses, Master Theses and Ph.D. Theses Foreign Publications A. Meta-model Documentation 211 A.1. EPackage modelinstance A.1.1. EClass ModelElementCategory A.1.2. EClass RootNode

8 VIII CONTENTS A.2. EPackage muml::behavior A.2.1. Abstract EClass Behavior A.2.2. Abstract EClass BehavioralElement A.2.3. EClass Operation A.2.4. EClass Parameter A.2.5. EClass ParameterBinding A.2.6. Abstract EClass TypedNamedElement A.2.7. EClass Variable A.3. EPackage muml::component A.3.1. EClass AssemblyConnector A.3.2. Abstract EClass AtomicComponent A.3.3. Abstract EClass Component A.3.4. EEnumeration ComponentKind A.3.5. EClass ComponentPart A.3.6. EClass ContinuousPort A.3.7. EClass CoordinationProtocolPart A.3.8. EClass DelegationConnector A.3.9. Abstract EClass DirectedTypedPort A EClass DiscretePort A EClass HybridPort A Abstract EClass Port A Abstract EClass PortConnector A EEnumeration PortDirectionKind A EClass PortPart A EClass StaticAtomicComponent A Abstract EClass StaticComponent A EClass StaticStructuredComponent A Abstract EClass StructuredComponent A.4. EPackage muml::connector A.4.1. Abstract EClass Connector A.4.2. Abstract EClass ConnectorEndpoint A.4.3. Abstract EClass ConnectorEndpointInstance A.4.4. Abstract EClass ConnectorInstance A.4.5. Abstract EClass DiscreteInteractionEndpoint A.4.6. Abstract EClass DiscreteInteractionEndpointInstance 242 A.4.7. Abstract EClass DiscreteMultiInteractionEndpointInstance A.4.8. Abstract EClass DiscreteSingleInteractionEndpointInstance A.4.9. EClass MessageBuffer A.5. EPackage muml::constraint A.5.1. Abstract EClass ConstrainableElement

9 CONTENTS IX A.5.2. Abstract EClass Constraint A.5.3. EEnumeration Correctness A.5.4. Abstract EClass ModelingConstraint A.5.5. EClass TextualConstraint A.5.6. Abstract EClass VerifiableConstraint A.6. EPackage muml::instance A.6.1. EClass AssemblyConnectorInstance A.6.2. EClass AtomicComponentInstance A.6.3. Abstract EClass ComponentInstance A.6.4. EClass ComponentInstanceConfiguration A.6.5. EClass ContinuousPortInstance A.6.6. EClass CoordinationProtocolInstance A.6.7. EClass DelegationConnectorInstance A.6.8. EClass DiscreteMultiPortInstance A.6.9. Abstract EClass DiscretePortInstance A EClass DiscreteSinglePortInstance A EClass HybridPortInstance A Abstract EClass PortConnectorInstance A Abstract EClass PortInstance A EClass StructuredComponentInstance A.7. EPackage muml::msgtype A.7.1. EClass MessageType A.7.2. EClass MessageTypeRepository A.8. EPackage muml::protocol A.8.1. Abstract EClass AbstractCoordinationSpecification A.8.2. EClass ConnectorQualityOfServiceAssumptions A.8.3. EClass CoordinationProtocol A.8.4. EClass Role A.8.5. EClass RoleConnector A.9. EPackage muml::realtimestatechart A.9.1. EClass AbsoluteDeadline A.9.2. EClass Action A.9.3. EClass AsynchronousMessageEvent A.9.4. EClass Clock A.9.5. EClass ClockConstraint A.9.6. Abstract EClass Deadline A.9.7. EClass DoEvent A.9.8. EClass EntryEvent A.9.9. Abstract EClass EntryOrExitEvent A EClass EntryPoint A Abstract EClass Event A EEnumeration EventKind

10 X CONTENTS A EClass ExitEvent A EClass ExitPoint A EClass Message A Abstract EClass PrioritizedElement A EClass RealtimeStatechart A EClass Region A EClass RelativeDeadline A EClass State A Abstract EClass StateConnectionPoint A Abstract EClass StateEvent A EClass Synchronization A EClass SynchronizationChannel A EEnumeration SynchronizationKind A EClass Transition A Abstract EClass TransitionEvent A Abstract EClass Vertex A.10.EPackage muml::types A EClass ArrayDataType A Abstract EClass DataType A EClass PrimitiveDataType A EEnumeration PrimitiveTypes A EClass RangedPrimitiveDataType A.11.EPackage muml::valuetype A EClass Cardinality A EClass NaturalNumber A EClass Range A EDataType TimeUnit A EClass TimeValue A.12.EPackage actionlanguage A EClass ArrayInitializeExpression A EEnumeration AssignOperator A EClass Assignment A EClass Block A EClass DiscreteInteractionEndpointReference A EClass DoWhileLoop A EClass ForLoop A EClass IfStatement A EEnumeration IncrementDecrementOperator A EClass LocalVariableDeclarationStatement A Abstract EClass Loop A EClass NondeterministicChoiceExpression A EClass OperationCall

11 CONTENTS XI A EClass PositionSelector A EEnumeration PositionSelectorKind A EClass ReturnStatement A EClass TriggerMessageExpression A EClass TypedNamedElementExpression A EClass WhileLoop A.13.EPackage core A Abstract EClass CommentableElement A Abstract EClass ExtendableElement A Abstract EClass Extension A Abstract EClass NamedElement A Abstract EClass TypedElement A.14.EPackage core::expressions A Abstract EClass Expression A EClass TextualExpression A.15.EPackage core::expressions::common A EClass ArithmeticExpression A EEnumeration ArithmeticOperator A Abstract EClass BinaryExpression A EEnumeration ComparingOperator A EClass ComparisonExpression A EClass LiteralExpression A EEnumeration LogicOperator A EClass LogicalExpression A EClass UnaryExpression A EEnumeration UnaryOperator A.16.EPackage storydiagrams A Abstract EClass Variable A.17.EPackage storydiagrams::activities A EClass Activity A EClass ActivityCallNode A EClass ActivityEdge A EClass ActivityFinalNode A Abstract EClass ActivityNode A EEnumeration EdgeGuard A EClass ExceptionVariable A EClass FlowFinalNode A EClass InitialNode A EClass JunctionNode A EClass MatchingStoryNode A EClass ModifyingStoryNode A EClass OperationExtension

12 XII CONTENTS A EClass StatementNode A Abstract EClass StoryNode A EClass StructuredNode A.18.EPackage storydiagrams::activities::expressions A EClass ExceptionVariableExpression A.19.EPackage storydiagrams::calls A Abstract EClass Callable A Abstract EClass Invocation A EClass OpaqueCallable A EClass ParameterBinding A EClass ParameterExtension A.20.EPackage storydiagrams::calls::expressions A EClass MethodCallExpression A EClass ParameterExpression A.21.EPackage storydiagrams::patterns A Abstract EClass AbstractLinkVariable A Abstract EClass AbstractVariable A EClass AttributeAssignment A EEnumeration BindingOperator A EEnumeration BindingSemantics A EEnumeration BindingState A EClass CollectionVariable A EClass Constraint A EClass InclusionLink A EClass LinkConstraint A EEnumeration LinkConstraintType A EClass LinkVariable A EClass MatchingPattern A EClass MaybeLink A EClass ObjectVariable A EClass Path A EClass PrimitiveVariable A EClass StoryPattern A.22.EPackage storydiagrams::patterns::expressions A EClass AttributeValueExpression A EClass CollectionSizeExpression A EClass ObjectVariableExpression A EClass PrimitiveVariableExpression A.23.EPackage storydiagrams::templates A EClass PropertyBinding A EClass TemplateBinding A EClass TemplateSignature

13 CONTENTS XIII B. Action Language XText Grammar 361

14

15 CONTENTS XV Contributors and Acknowledgments MECHATRONICUML is the result of many people s work, which we are greatly indebted to. Current Contributors Today, Prof. Dr. Wilhelm Schäfer is the chair of MECHATRONICUML. It is jointly developed by the Software Engineering Group of the University of Paderborn, the Project Group Mechatronic Systems Design of Fraunhofer IPT, and the Software Engineering Group of Chalmers Technical University and University of Gothenburg. As a consequence, the authors of this document are members of these three groups. We thank the PhD students Anas Anis, Christian Brenner, Jens Frieben, David Schmelter, and Lars Stockmann for reviewing this document and for the helping in the marketing of MECHATRONICUML (in aphabetical order). Moreover, many students helped us to improve the document and to develop our modeling tool-suite for MECHATRONICUML, the Fujaba Real-Time Tool Suite. In particular, we thank in alphabetical order Ingo Budde, Andres Dann, Johannes Geismann, Marcus Huewe, Jennifer Kane, David Schubert, and Christian Stroh. Former Contributors Prof. Dr. Holger Giese, now Professor at the Hasso-Plattner-Institut at the University of Potsdam, started MECHATRONICUML while he was with the Software Engineering Group at the University of Paderborn. He designed the initial MECHATRONICUML approach (called UML-RT) and developed the foundations. Thus, he greatly influenced the current state of MECHATRONICUML. Additional work has been done by the following doctoral students during their time at the Software Engineering Group in Paderborn (in alphabetical order): Dr. Sven Burmester [Bur06], Tobias Eckardt, Dr. Stefan Henkler [Hen12], Prof. Dr. Martin Hirsch [Hir08], Renate Löffer, Dr. Claudia Priesterjahn [Pri13], Julian Suck, Dr. Florian Stallmann [Sta08], Dr. Daniela Schilling [Sch06], and Prof. Dr. Matthias Tichy [Tic09]. We thank the following people who contributed as authors to earlier versions of this document: Christian Brenner, Christopher Brink, Thomas Gewering, Julian Suck, and Oliver Sudmann. Additionally, we thank all former students of the Software engineering Group of Paderborn who helped us to improve previous versions of the document or who developed previous version of the Fujaba Real-Time Tool Suite. In particular, we thank Jannis Drewello and Boris Wolf.

16 XVI CONTENTS Involved Projects MECHATRONICUML is and was partially developed in the course of the Special Research Initiative Self-optimizing Concepts and Structures in Mechanical Engineering - University of Paderborn, and was published on its behalf and funded by the Deutsche Forschungsgemeinschaft.... in the course of the Special Research Initiative On-The-Fly Computing - University of Paderborn, and was published on its behalf and funded by the Deutsche Forschungsgemeinschaft.... in the project ENTIME: Entwurfstechnik Intelligente Mechatronik (Design Methods for Intelligent Mechatronic Systems). The project ENTIME was funded by the state of North Rhine-Westphalia (NRW), Germany and the EUROPEAN UNION, European Regional Development Fund, Investing in your future.... in the Leading-Edge Cluster Intelligent Technical Systems OstWestfalenLippe (it s OWL). The Leading-Edge Cluster is funded by the German Federal Ministry of Education and Research (BMBF).... by PhD students that were funded by the International Graduate School Dynamic Intelligent Systems.

17 CONTENTS XVII Document Changelog Since this document is updated regularly, we list here the major changes compared to the preceding versions. Version 0.4 Version 0.4 includes the following major changes compared to the preceding version 0.3. General Changed title from The MechatronicUML Design Method Process, Syntax and Semantics to The MechatronicUML Design Method Process and Language for Platform-Independent Modeling. The document now focuses on the platform-independent modeling. Requirements and platform-specific modeling will be published in separate technical documents. Revised Chapter Introduction Revised Chapter Overview Revised Chapter Modeling Language Revised Chapter Complete Example Revised Chapter Conclusions and Future Work Document Structure Reordered the Sections of Chapter Modeling Language Added Section Data Type Specification in Chapter Modeling Language Extracted Section Action Language from Section Real-Time Statechart Added Chapter Modeling Extensions for Reconfigurable Systems Added Section Requirements Added Section Reconfiguration in Real-Time Coordination Protocols Added Section Component Model Extensions Added Section Component Story Diagrams Extracted Section Acknowledgements from Section Conclusions and Future Work and moved it before the Changelog Modeling Language Separated concrete syntax description from abstract syntax and semantics for each modeling element. Defined the allowed data types of MECHATRONICUML.

18 XVIII CONTENTS Message interfaces have been removed from MECHATRONICUML. Instead, developers can use message type repositories for grouping message types. Ports and Roles directly refer to sets of message types they send or receive. Revised Action Language and its Grammar Real-Time Coordination Patterns are now called Real-Time Coordination Protocols. Added descriptions about buffers for incoming messages of a role of a Real-Time Coordination Protocol Connectors of Real-Time Coordination Protocols now specify quality of service assumptions. Real-Time Coordination Protocol: Multi-Roles are always considered to be ordered. Since the ordered property is implicitly true, we removed it. Revised and extended concept for specifying behaviors of multi roles, e.g., replaced operations for exploiting the order of a multi role by keywords Revised Real-Time Statecharts (new contents, new order, new images) Real-Time Statechart: Synchronization Channels no longer define parameters because synchronizations are part of the precondition for firing a transition. Component Model: Hybrid Ports now only specify a sampling interval, but no Real- Time Statechart because the Real-Time Statechart is always the same and is only needed for model checking. Continuous and hybrid ports define expressions for initialization. Continuous and hybrid in-port instances can now fork the information they send. Extracted the deployment section into a new document that defines the platform-specific design method. We will publish this document as a technical report, too. Revised Metamodel Version 0.3 Version 0.3 includes the following major changes compared to the preceding version 0.2. General Changed title from The MechatronicUML Method Process, Syntax and Semantics to The MechatronicUML Design Method Process Syntax and Semantics. Added Changelog Overview Change of process overview: If the formal use case specification is changed (Step 5b), instead of repeating only Steps 3, 4a, and 5a, the whole process needs to be repeated.

19 CONTENTS XIX Modeling Languages Real-Time Coordination Protocol: Multi roles have a property ordered which implies an order of the sub-role instances at run-time Message Interfaces: Made concrete syntax of parameter definition consistent to the concrete syntax of parameter definitions in Real-Time Statechart operations Real-Time Statechart: Changed concrete syntax for trigger messages at a transition: Parameters and their types are no longer displayed. Added new Section about Action Language for Real-Time Statechart. Revised and extended concept for specifying behaviors of multi roles, e.g., added operations for exploiting the order of an ordered multi-role Component parts of structured components now have a name. Component instances are now typed over a component type and a component part. Changed specification for deployment. Adapted new concrete syntax to all figures Development Process Adapted MECHATRONICUML process to use Modal Sequence Diagrams as a formal basis for the application scenarios. Affected processes: integration into development process for advanced mechatronic systems, overall MECHATRONICUML process, determine coordination pattern, model new coordination pattern. Distinguished between the principle solution and the system model. Simplified the subprocess model new coordination pattern. Complete Example Adapted new concrete syntax to all figures Removed errors in the Real-Time Statecharts Changed deployment example Theoretical Background Updated description of the compositional verification approach Related Work Added related work concerning Contract-Based Design Added related work concerning Behavioral Connectors Added related work concerning Multi-Agent-Systems Extended again related work concerning Specification Languages for Systems Engineering Extended again related work concerning Software Component Models

20 XX CONTENTS Extended again related work concerning Specifications of Self-Adaptive Systems Extended related work concerning Formal Models for Modeling of Real-time Behavior Meta-model Documentation Replaced use of EAttribute, EOperation, EParameter by own meta-classes for attributes, operations, and parameters Added type model for defining simple data types and array data types Added action language meta-model Action Language XText Grammar Added this new appendix for the grammar of our action language Version 0.2 Version 0.2 includes the following major changes compared to the preceding version 0.1. General Changed title from MechatronicUML Syntax and Semantics to The MechatronicUML Design Method Process Syntax and Semantics. Overview Added Chapter MECHATRONICUML Overview Modeling Languages Rewrote section Real-Time Coordination Patterns to add further details and to improve understandability Improved images and explanations in section Real-Time Statechart Improved description for Component Model Extracted Hardware Components from section Component Instance Configuration and defined an own section for them Development Process Defined an own chapter for the development process Complete Example Corrected several errors

21 CONTENTS XXI Theoretical Background Added chapter for describing the theoretical background Related Work Extended related work concerning Specification Languages for Systems Engineering Extended related work concerning Software Component Models Extended related work concerning Specifications of Self-Adaptive Systems Meta-model Documentation Improved package muml::model::component Added Package muml::model::deployment Deleted class Infinity from package muml::model::core Improved package muml::model::instance Improved package muml::model::pattern Improved package muml::model::realtimestatechart Version 0.1 The initial version of this document.

22

23 Chapter 1. Introduction Nowadays, software drives all kinds of systems that interact with their physical environment [GRS14]. Examples for such systems are autonomously driving cars or trains, self-coordinating robots, or production systems in smart factories. These systems are referred to as mechatronic systems or cyber-physical systems (CPS) [aca11]. The number of such mechatronic systems in our world is growing rapidly [Pal08]. Mechatronic systems are developed in a joint effort by mechanical engineers, electrical engineers, control engineers, and software engineers [VDI04a]. Innovation in mechatronic systems is largely driven by embedded software. For example, it has been estimated that the current generation of upper class cars will contain about one gigabyte of software [PBKS07]. Mechatronic systems pose a challenge for software development as their software has to execute in a safety-critical, real-time environment, i.e., human life may be harmed if the software does not always produce correct results on time. As a consequence, the software must be correct in its first release. Therefore, incremental testing-based development approaches are not applicable to such software. Instead, a software engineering method for mechatronic systems has to provide effective and efficient means to develop the software and prove its correctness. The software development is further complicated by additional characteristics of mechatronic systems. Software controls continuous physical processes, e.g., the movement and braking of a vehicle. Thus, the software is bound to physical laws that imply further real-time constraints. Mechatronic and especially cyber-physical systems involve several autonomous, coordinating subsystems, e.g., in a platoon of vehicles. Such systems are not working in isolation but heavily interact and coordinate each other. This requires asynchronous message communication realized by discrete, state-based software, which needs to be carefully integrated with continuous controllers [Kil05] for controlling the dynamic behavior of the physical system parts. Mechatronic systems have to adapt flexibly to changing environments, e.g., additional autonomous vehicles willing to join a platoon, or failing hardware systems. This requires the integration of self-x behavior [CdLG + 09], such as self-adaptation, selfoptimization, self-organizing, and self-healing. 1

24 2 CHAPTER 1. INTRODUCTION Finally, the software runs on embedded devices that limit the available hardware resources. A software engineering method for mechatronic systems needs to treat the combination of these characteristics. All these trends lead to complex mechatronic systems whose structure and behavior cannot be fully determined a priori. The key issue for the successful development of such systems is handling the inherent complexity. Consequently, developers require appropriate development methods and languages as well as development tools. The key principles for handling the complexity are abstraction and reuse. Model-driven development approaches enable abstraction from technical implementation details and, thus, allow for verification and validation, e.g., concerning safety and availability. Further, recurring solutions are stored as reusable development artifacts. With MECHATRONICUML, we provide a model-driven method for the development of the software embedded in mechatronic systems. MECHATRONICUML takes up the aforementioned principles of abstraction and reuse and provides a modeling language and process based on concepts of the well-known UML [Obj09]. Thereby, MECHATRONICUML supports the development of structural as well as behavioral aspects of mechatronic software. It adapts the component-based approach [Szy98] for software development. The behavior of components is specified in a state-based manner using Real-Time Statecharts, which are a combination of UML state machines and Timed Automata. MECHATRONICUML particularly focuses on the software for the real-time coordination of mechatronic systems. The coordination is achieved by exchanging messages between systems which amounts to complex discrete state-based behavior in each of the systems. In addition, the coordination affects the dynamic behavior of the physical parts of the systems, which are controlled by continuous control software. Consequently, MECHATRONICUML provides means for the safe integration of the discrete state-based coordination behavior with the continuous software of feedback controllers. MECHATRONICUML introduces reusable Real-Time Coordination Protocols as first-class modeling constructs for formalizing the realtime coordination and for separating it from the rest of the system behavior. Thereby, Real- Time Coordination Protocols facilitate the reuse of established solutions and help to reduce development time and effort. In order to allow mechatronic systems to adapt to a changing environment and to coordinate and communicate with changing communication partners, MECHATRONICUML supports modeling the exchange of software components at runtime. MECHATRONICUML thereby lays the ground for explicitly modeling self-x behavior. Besides the precise modeling of embedded software, another major aim of MECHATRONICUML is the formal verification of safety critical properties of mechatronic systems, which often operate in safety-critical contexts. However, even a single, isolated mechatronic system cannot be formally verified with respect to safety properties by classical techniques in reasonable time. The problem increases when verifying modern mechatronic systems, which coordinate and communicate with other systems in an ad-hoc fashion and/or integrate self-x behavior. MECHATRONICUML again draws on the separation of

25 1.1. EXAMPLE 3 coordination behavior from the single component behavior. This separation enables a compositional verification by partitioning the system s state space into verifiable chunks, i.e., Real-Time Coordination Protocols and single component behavior. Real-Time Coordination Protocols and single component behavior can be verified independently of each other using the model checker UPPAAL 1. Thus, by reusing Real-Time Coordination Protocols, MECHATRONICUML enables reusing the verification results without repeatedly reverifying communication behaviors. This technical report extends the previous versions [BBB + 12, BBD + 12, BDG + 11]. It consolidates the older publications [Bur02, Gie03, GB03, GST + 03, GTB + 03, BGT05, GHH + 08, EHH + 13, SSGR11, HPB12] and theses [Hir04, Bur06, Hir08] in a single document. In [GS12], a consolidated version of MECHATRONICUML up to 2007 is presented whose concepts are continuously merged into this technical report. We present the current version of MECHATRONICUML in detail and give formal specifications for abstract and concrete syntax as well as an informal description of its semantics. The report is structured as follows. In the next section, we introduce a running example. In Chapter 2, we provide a brief overview of the MECHATRONICUML method. This overview includes a short description of the development process as well as the modeling languages of MECHATRONICUML. Chapter 3 describes informally the syntax and the semantics of the modeling language used in MECHATRONICUML based on the running example. Chapter 4 extends the modeling language by run-time reconfiguration of software component structures. In Chapter 5, we illustrate the development process of MECHATRONICUML. The complete models of the running example are presented in Chapter 6. After a discussion of related approaches in Chapter 7, we conclude with an outlook on future work in Chapter 8. Appendix A contains a thorough definition of the abstract syntax. Finally, appendix B contains the Xtext grammar for the action language of our Real-Time Statecharts Example In this document, we will use an environment exploration scenario as an ongoing example in which several autonomous robots have to explore an unknown environment. As robots, we will use the intelligent miniature robot BeBot 2 (see Figure 1.1). The BeBot is a test carrier for intelligent machines and cooperative networks developed at the Heinz Nixdorf Institute at the University of Paderborn 3. As shown in Figure 1.1, the BeBot uses two chain-drives with DC motors to move around. It has twelve infrared-sensors and a front camera to sense its environment. The BeBot may utilize a Bluetooth and a wireless LAN module for communicating with other BeBots. The functionality of the BeBot may be extended using the USB ports. In our example, we extend

26 4 CHAPTER 1. INTRODUCTION the functionality of the BeBot by a GPS-Receiver for detecting the current position of the BeBot. Figure 1.1.: BeBot In our scenario, several BeBots explore an unknown area as shown in Figure 1.2. For reasons of simplicity, we assume that the area is unbounded and contains no obstacles. We will enhance our example with obstacles in future versions of this document in order to make the scenario more realistic. At present, the BeBots only have the task to explore the area without colliding with each other. The BeBot performs a step-wise movement instead of moving at a constant speed. In each step, the BeBot performs the following operations: it chooses randomly a target position within a fixed distance around it to move to. Then, the BeBot turns and moves to this position. After reaching the target position, the BeBot stops and performs another step as described before. A BeBot may only move to its intended target position if it cannot collide with another BeBot while moving there. That decision requires knowledge about the positions of the other BeBots in the area. While a BeBot may use its GPS sensor for obtaining its current position, it cannot sense the position of the other BeBots by itself. Therefore, one of the BeBots acts as a position distributor. Each BeBot transmits regularly its own current position to the position distributor. The position distributor stores the current positions of all BeBots and sends them regularly to all BeBots. This ensures that each BeBot receives regular updates of the current positions of all BeBots in the area. The BeBot uses the position data of the other BeBots to avoid collisions. In each step, the BeBot compares its calculated target position to the positions of the other BeBots and decides whether a collision may occur or not. If a collision can occur, the BeBot does not move to its target position, but remains at its current position. In principle, the position distributor may be elected during run-time. In case of a failure in the position distributor, the position distributor may also be reelected during run-time. At present, we restrict ourselves to a preset position distributor and support no reelection at run-

27 1.2. BENEFITS FOR THE DEVELOPER 5 Figure 1.2.: Area of the Exploration scenario time. However, we plan to extend our example to capture such behavior in a future version of this document Benefits for the Developer Using MECHATRONICUML, the developer benefits from all advantages of model-based development: abstraction, reuse, decomposition, verification, and simulation. The real-time behavior of components and their real-time communication protocols are specified and verified on type level. Components and communication protocols (connecting the components) may be instantiated multiple times and thereby used multiple times. For example, the protocol which specifies the exchange of position data is specified only once, but instantiated on all pairs of BeBots that need to exchange position data. Behavior is modeled by state-machines that are extended by clocks and constraints over the clock to allow for the specification of timed behavior. The state-based modeling of the behavior and the component-based architecture provide an abstraction from the source code. This, in turn, allows for an overview of the whole system in different levels of abstraction and thereby facilitates the understanding of the system. The verification helps the developer guaranteeing all required safety and liveness properties of the embedded software including timing properties. An example of such a property is the successful avoidance of collisions by guaranteeing a safe and timely exchange of position data.

28 6 CHAPTER 1. INTRODUCTION Source code may be generated from the MECHATRONICUML models and then used in a simulation to check, for example, if reaction times are short enough to stop a BeBot on time before a collision happens.

29 Chapter 2. MECHATRONICUML Overview The MECHATRONICUML method supports the model-driven design of the discrete-event and continuous time software of self-adaptive mechatronic systems. The key concepts of MECHATRONICUML are a component-based system model which enables scalable compositional verification [GTB + 03] of safety-properties, the model-driven specification and verification of reconfiguration operations, and the integration of the discrete software with the continuous software of the feedback controllers of mechatronic systems. Therefore, MECHATRONICUML provides a set of domain specific visual languages (DSVL) as well as a defined development process. Figure 2.1 provides an overview of the development process of MECHATRONICUML which we will briefly illustrate in the following. For a detailed description of the development process, please refer to Section 5. Requirements 1 Specify Formal Requirements 2 Design Platform- Independent Software Model 3 Design SW/HW Platform 4 Design Platform- Specific Software Software Artifacts (Code, Binary) Formal Use Cases 2.1 Derive Components 2.2 Determine Coordination Protocols Timed Model Checking 2.3 Determine Component Behavior Timed Refinement Check 2.4 Integrate with Controller and Environment Integrated System Simulation Platform- Independent Software Model Legend Artifact Process Step Integrated Analysis Step Figure 2.1.: Overview of the MECHATRONICUML Process The starting point of system development is typically a set of informal natural language requirements. Natural language requirements are not formally analyzable due to various possible interpretations of natural language. Consequently, Step 1 of MECHATRONICUML is the translation of informal requirements into formal use cases, which are modeled by Modal Sequence Diagrams [HM07]. Modal Sequence Diagrams are a formalized variant of UML sequence diagrams [Obj09] and specify the interactions among system elements as well as real-time constraints on these interactions. Modal Sequence Diagrams are used to analyze 7

30 8 CHAPTER 2. MECHATRONICUML OVERVIEW inconsistencies and contradictions by using synthesis or simulation based approaches [Gre11]. A detailed description of how to use Modal Sequence Diagrams in MECHATRONICUML will be added to future versions of this document. In Step 2, the formal use cases of Step 1 are used to derive the platform-independent software model. Step 2 consists of four substeps. In Step 2.1, we derive the initial set of components that describes the system structure. A component is a software entity that encapsulates a part of the system behavior, which implements a certain function. Each component defines a set of external interaction points, called ports, for accessing its functionality. In contrast to other component-based approaches [Szy98, LW07], MECHATRONICUML employs active components that execute a behavior specification in a single task. The component model is structured hierarchically: Components are either atomic components, i.e., they are implemented directly (atomic components) or they are structured components, i.e., they are decomposed into further components. Only atomic components have a behavior. For a description of the component model, please refer to Section 3.6. Feedback controllers are integrated as continuous components into the component model. MECHATRONICUML provides no behavior specification for feedback controllers. Instead, we assume that this behavior is specified by a control engineering tool like CamelView or MATLAB/Simulink. In Step 2.2, the Real-Time Coordination Protocols are specified. Real-Time Coordination Protocols define the communication between components and consist of multiple communication partners, called roles. Roles are linked by connectors. For a description of Real-Time Coordination Protocols, please refer to Section 3.3. Components and Real-Time Coordination Protocols are instantiated in component instance configurations as component instances and port instances. The port instances the roles of Real-Time Coordination Protocols and thereby the connectors between the respective roles connect the refining port instances. In this way, a software architecture is defined which is represented by a component instance configuration. For a description of component instance configurations, please refer to Section 3.7. The behavior of the roles of a Real-Time Coordination Protocol is specified by Real-Time Statecharts. Real-Time Statecharts are a combination of UML state machines [Obj09] and timed automata [DM01, BY03, AD94]. In Real-Time Coordination Protocols, Real-Time Statecharts specify the message exchange of the roles with respect to the real-time properties that the roles must obey. The safety and liveness properties of each Real-Time Coordination Protocol is verified formally using timed model checking [GTB + 03, BGHS04]. For a detailed description of Real-Time Statecharts, please refer to Section 3.4. In Step 2.3, the Real-Time Coordination Protocols of Step 2.2 are used to determine the behavior of the components that were identified in Step 2.1. First, roles of Real-Time Coordination Protocols are assigned to the components ports which then refine the role behavior. This means, the ports implement the external behavior of the components as specified in the role behavior. The refinement has to respect rot role behavior (must not add possible behavior or block guaranteed behavior) and additionally das to respect the guaranteed

31 9 behavior of the roles given by their [GTB + 03]. The correct refinement is verified automatically by a refinement check [BHSH13]. The internal behavior of atomic components is derived from the Real-Time Statecharts of their ports. Each atomic component has exactly one Real-Time Statechart that specifies its internal behavior, which for example resolves dependencies between the port behaviors. For a detailed description of the behavior of atomic components, please refer to Section The component is then formally verified for deadlock freedom to ensure that all ports of a component communicate safely with each other. We now apply the compositional verification approach of MECHATRONICUML. Real-Time Coordination Protocols have already been verified in Step 2.2. In this step, the verified correctness of the Real-Time Coordination Protocols with respect to the safety properties is used to verify each component separately. Compositional verification enables the verification of Real-Time Coordination Protocols and components isolated from each other and thereby avoids verifying a large system in a single step which is, in general, infeasible. For background information on the compositional verification theorem, we refer to the definition of Giese [Gie03]. In Step 2.4, the model of the discrete behavior is integrated with the feedback controllers of the mechatronic system. The formal verification of a correct integration of the controllers, however, is not feasible for real-world systems [ERNF12]. Instead, we simulate the system model in the respective control engineering tools [HPR + 12, HRS13, PDM + 14]. Such simulation requires a complete instance of the specified system including its controllers. MECHATRONICUML supports such instances by means of component instance configurations which are discussed in detail in Section 3.7. If the verification of the components or the simulation of the whole system fails, either the system model or the formal requirements need to be changed. This requires the repetition of Steps 1 to 2.4. The model-driven design and verification of reconfiguration is not explained in this document. For now, we refer to [EHH + 13, HPB12, THHO08, BGO06] for information on reconfiguration. A detailed description, however, will be added to future versions of this document. Figure 2.2 summarizes the modeling languages that are used during the development and their relationships. Modal Sequence Diagrams define the formal requirements of Real- Time Coordination Protocols. Real-Time Coordination Protocols are used to model the communication behavior of the components of the system. We use Real-Time Statecharts to define the behavior of the roles of Real-Time Coordination Protocols. The messages that are exchanged between the roles are declared formally by message types (cf. Section 3.2). The components ports instantiate and refine Real-Time Coordination Protocols by adding internal computations. We distinguish components into atomic components and structured components. Structured components are composed of a set of other components while atomic components have a behavior. This behavior is, again, specified by Real-Time Statecharts. Components are instantiated in a component instance configuration.

32 10 CHAPTER 2. MECHATRONICUML OVERVIEW Modal Sequence Diagrams MechatronicUML Requirements Language define formal requirements for composed of instantiate + refine behavior Component Structured Component instantiate Real-Time Coordination Protocol Component Instance Configuration define communication behavior of Atomic Component MechatronicUML Design Language for Platform-Independent Modeling (PIM) define behavior of Real-Time Statechart define behavior of Message Type Specification type asynchronous messages using Legend... Modeling Language Artifact Relationship Figure 2.2.: Overview of the Modeling Languages used in MECHATRONICUML In conclusion, MECHATRONICUML provides a component-based system model that separates components and their interactions by means of Real-Time Coordination Protocols. This separation is the key enabler for the compositional verification theorem which permits the formal verification of large systems. MECHATRONICUML supports the development of discrete event and time continuous software for mechatronic systems and the integration of models of feedback controllers by means of continuous components. Furthermore, the correct timing behavior of reconfiguration of feedback controllers at runtime may be analyzed formally [Bur06, Hir08].

33 Chapter 3. Modeling Language In this chapter, we will introduce the different modeling formalisms that MECHATRONICUML offers. First, we introduce our data type concept in Section 3.1. Then, we introduce message types that may be used for the asynchronous communication. In Section 3.3, we introduce our contract-specification for the asynchronous message-based coordination called Real-Time Coordination Protocols. The behavior of the coordinating entities is specified by Real-Time Statecharts (cf. Section 3.4), a combination of UML Statemachines [Obj09] and (UPPAAL) timed automata [AD94]. For specifying executable behavior expressions and boolean evaluations, we introduce our action languge in Section 3.5. In Section 3.6, we introduce the MECHATRONICUML component model, which uses Real-Time Coordination Protocols and Real-Time Statecharts. Finally, MECHATRONICUML provides an instance model to specify concrete system configurations which we explain in Section Data Type Specification MECHATRONICUML has an own data type concept. We distinguish between (i) primitive data types, (ii) ranged primitive data types, (iii) array data types, and (iv) component model data types (i.e., data types that originate from our component model) Primitive Data Type In the following, we list the primitive data types that MECHATRONICUML currently supports. They are based on the primitive types of Java. All primitive data types have the default value 0. Void Allows no values and is only used to define that an operation returns without a value. Boolean Allows the values true false Byte Contains by default a 8 Bit signed Integer from -128 to 127 Short Contains by default a 16 Bit signed Integer from -32,768 to 32,767 Int Contains by default a 32 Bit signed Integer from to

34 12 CHAPTER 3. MODELING LANGUAGE Long Contains by default a 64 Bit signed Integer from to Double Contains by default a 64 Bit floating point number (1 bit for sign, 11 bits for the exponent, 52 for the fraction) with 15 significant decimal digits precision Ranged Primitive Data Type A developer may define ranged primitive data types. Such a data type consists of a primitive data type that has a lower and upper bound. The lower and upper bound may only constrain the default value range, but not extend it Array Data Type An array data type enables to store an indexed value list of a defined MECHATRONICUML data type, i.e., each value has the same data type. The number of values is defined by the cardinality of the array. The values of the array are accessed by their indexes. For a cardinality of n, the indexes range from 0 to n 1. The developer can define a cardinality between 1 and the maximum value of Long ( ). As an array data type is a data type itself, the developer can define multi-dimensional arrays. Each dimension of an array may specify an own cardinality. As an restriction all dimensions of one level need to reference the same data type Component Model Data Type The components that are created as part of a MECHATRONICUML model (cf. Section 3.6) provide a set of data types, called component model data types. A developer may use component model data types for (1) message parameters, (2) variables in Real-Time Statecharts, and, in particular, (3) for specifying reconfigurations by component story diagrams (cf. Section 4.3). In the following, we list the elements of our component model that also serve as component model data types: Role A developer can use this data type for synchronization inside the behavior of a multirole (cf. Section ) and for reconfiguring the multi-role (cf. Section 4). Port A developer can use this data type for synchronization inside the behavior of a multiport (cf. Section ), for reconfiguring the multi-port (cf. Section ), and for typing port variables in a component story diagram (cf. Section 4.3). Component A developer can use this data type for typing variables referring to components in a component story diagram (cf. Section 4.3).

35 3.1. DATA TYPE SPECIFICATION 13 Component Part A developer can use this data type typing variables referring to embedded component parts of a structured component in a component story diagram (cf. Section 4.3).

36 14 CHAPTER 3. MODELING LANGUAGE 3.2. Message Type Specification Message types are types of messages that may be exchanged between the roles of Real-Time Coordination Protocols (cf. Section 3.3) and the ports of components (cf. Section 3.6). Therefore, each role and port refers to a set of message types that it sends or receives. Since messages are always attached to a role or port, they are considered as second class objects in MECHATRONICUML. Message types can be grouped into message type repositories, e.g., for collecting all message types used in a Real-Time Coordination Protocol in a single container. Besides their grouping function, message type repositories have no further semantics Message Type Repository A message type repository contains a set of message types for asynchronous messages that may be exchanged between the roles of a Real-Time Coordination Protocol or between the ports. Each message type repository specifies a name. The names of all message type repositories are recommended to be unique with a project although it is not required. A message type repository must contain at least one message type. Concrete Syntax of a Message Type Repository Figure 3.1 shows an example of a message type repository Delegation containing three message types with a varying number of parameters. The message type repository groups all message types that may be used in a Real-Time Coordination Protocol for delegating a task and receiving an answer if the task was successful or not. message type repository message type name of message type repository Delegation check(int[2] target, bool priority) accepted() declined(int errorid) parameter Figure 3.1.: Concrete Syntax Example of a Message Type Repository and Message Types Message type repositories are visualized as rectangles with two compartments that are separated by a horizontal line. The upper compartment contains the name of the message type repository, the lower compartment contains a list of message types where each line contains one message type.

37 3.2. MESSAGE TYPE SPECIFICATION Message Type A message type declares a name and an ordered parameter list for an asynchronous message. The names of all message types need to be unique within a system. Each parameter specifies a name and its concrete type. The parameter names of a message must be unique. The parameter list is optional, i.e., a message type may also declare no parameters. Concrete Syntax of a Message Type In our concrete syntax, a message type is represented as a string adhering to the following EBNF. Elements which have the prefix # are references to the meta model elements of class MessageType. < messagetype > : : = #name ( [ < p a r a m e t e r l i s t >] ) < p a r a m e t e r l i s t > : : = < p a r a m e t e r > < p a r a m e t e r >, < p a r a m e t e r l i s t > < p a r a m e t e r > : : = # p a r a m e t e r s [ i ]. t y p e. name # p a r a m e t e r s [ i ]. name In Figure 3.1, the message type repository Delegation contains the message types check, accepted, and declined. The message type check specifies two parameters named target and priority. target is of type integer array with length 2. priority is of data type Boolean. The message type accepted specifies no parameters. The message type declined defines the parameter errorid which is of data type Int. Thus, the concrete syntax of a message type is similar to the concrete syntax of a method declaration in UML [Gro10b].

38 16 CHAPTER 3. MODELING LANGUAGE 3.3. Real-Time Coordination Protocol The discrete interaction of components in MECHATRONICUML takes place via discrete ports that exchange asynchronous messages. Due to the asynchronicity, discrete ports must not block while sending and receiving messages. Furthermore, by storing incoming messages into a buffer first, discrete ports may delay to consume the message. However, the developer may define hard deadlines for consuming messages. For enabling a loose coupling between the discrete ports, MECHATRONICUML does not just provide message interfaces that define the messages the discrete port can send and receive. Instead, MECHATRONICUML provides rich contracts that focus on the whole coordination via message-based communication including hard real-time constraints and safety-critical aspects. We call these contracts Real-Time Coordination Protocols. Components that agree to this contract must always obey it. Real-Time Coordination Protocols define at application level the behavior of the coordination that is defined using communication, e.g., when must which message be sent or received. Thus, they are at a more abstract level than communication protocols like TCP/IP that define basic application-independent data exchange. For the remainder of this section, we will use the term coordinate for addressing the application-specific communication. A Real-Time Coordination Protocol consists of the participants of the coordination we call them roles (cf. Section 3.3.2) and the role connector that defines the message transmission assumptions (cf. Section 3.3.3). For example, a Real-Time Coordination Protocol for distributing position data defines the coordination aspects between the roles distributor and client. The definition of Real-Time Coordination Protocols 1 is as follows: A Real-Time Coordination Protocol unambiguously describes for each role its assumed and guaranteed (1) structure, (2) real-time behavior, and (3) message-based interaction as well for the role connector the assumed quality of service characteristics of the message transmission. We classify Real-Time Coordination Protocols on the direction of coordination and on the form of coordination (cf. Section 3.3.4). A developer has to instantiate a Real-Time Coordination Protocol for specifying a coordination among two or more role instances (cf. Section ). The developer, for example, can define a coordination between one role instance that acts as the server and multiple role instances that act as a client. The behavior of each role is described by a Real-Time Statechart (cf. Section 3.3.6). Furthermore, a developer can apply real-time model checking to analyze a Real-Time Coordination Protocol. As a prerequisite, the developer has to specify verification properties regarding the coordination (cf. Section 3.3.7). 1 The definition of Real-Time Coordination Protocol is similar to the contract definition of Giese and Vilbig [GV03].

39 3.3. REAL-TIME COORDINATION PROTOCOL Example of a Real-Time Coordination Protocol A simple example for a real-time coordination use-case is as follows: A system consists of up to nine BeBots. The BeBots shall coordinate the exchange of their current position. One BeBot is the distributor and one to eight BeBots are the clients. The distributor periodically receives the position of all clients, combines all positions into a list (including its own position), and distributes the list of all positions to all clients using a multicast. If one of the clients does not send its position within a certain time, the distributor informs all clients, that a safety-critical situation occurred, because collisions are possible now. As soon as all clients have sent their position again within the same period, the safety-critical situation ends. For modeling this coordination, the developer defines a Real-Time Coordination Protocol with the name Distribution. The two types of roles in this coordination are distributor and client. Each instance of role distributor can coordinate with up to eight instances of role client. The coordination is bidirectionally. Furthermore, each instance of role client can coordinate only with the one instance of role distributor. The instances of role client cannot coordinate each other. The formal behavior of each role is defined by a Real-Time Statechart (cf. Section 3.4. Section shows and describes the Real-Time Statecharts of these roles in detail. protocol name role name distributor Distribution client role name role role cardinality [1..8] [1] role connector role role cardinality Figure 3.2.: The Real-Time Coordination Protocol Distribution Concrete Syntax of a Real-Time Coordination Protocol Figure 3.2 shows the Real-Time Coordination Protocol Distribution in concrete graphical syntax. A dashed ellipse contains the name of the protocol. Furthermore, a protocol consists of additional concrete syntax elements, which are defined in the next section. A dashed (cascaded) square represents a role. The square is cascaded if the role is a multi role. A dashed line connects each role with the protocol ellipse. A label at the dashed line shows the name of the role. The solid line, which represents the role connector, connects the roles. The two triangles within both roles define that they coordinate bidirectionally with each other. If the protocol supports one-to-many coordination, then a label at each role (under the role connector) defines the so-called role-cardinality the number of connections a role may have.

40 18 CHAPTER 3. MODELING LANGUAGE Role A role is a discrete interaction endpoint and represents the type of a coordination participant of a Real-Time Coordination Protocol. Each role of a Real-Time Coordination Protocol has a unique name within a system specification. A role instance represents a concrete coordination participant and is typed over a role. Instances of roles can coordinate each other via discrete, asynchronous messages. A role may reference two unsorted sets of discrete, asynchronous messages that are typed over a message type (cf. Section 3.2). We call these sets sender message types and receiver message types. The sender message types define which types of messages the role sends; the receiver message types define which types of messages the role receives. The sender message types of one role must be equal to the receiver message types of its opposite role, and vice versa. In the following, we will distinguish roles (i) by their coordination direction and (ii) by their cardinality. Afterwards, we will define the incoming message buffer specification, which MECHATRONICUML currently supports. Concrete Syntax of a Role Figure 3.3 shows the concrete syntax of roles. We illustrate roles by dotted squares. A dashed line connects the role to the protocol ellipse, which contains the name of the protocol (cf. Figure 3.2). In addition, the name of the role is shown next to the dashed line and is positioned on the outside of the protocol. single role multi role sender message types receiver message types out-role in-role <role> [1] <role> [1] <role> <role> [i..j] <role> [i..j] <role> in/out-role [1] <role> [i..j] <role> [1] [i..j] Figure 3.3.: Concrete Syntax of Roles and their Messages Type Specification

41 3.3. REAL-TIME COORDINATION PROTOCOL Coordination Direction of Roles The direction of a role specifies that a role may (i) send, (ii) receive, or (iii) send and receive messages. A role that may only send messages is an out-role. A role that may only receive messages is an in-role. A role that may send and receive messages is an in/out-role. The direction of a role can be derived from its message type specification (cf. Section 3.2). We illustrate this with the Figure 3.3. If a role references only sender message types, it is an out-role; if it references only receiver message types, it is an in-role; if it references both, it is an in/out-role. An out-role instance can only send one message at a time; an in-role instance can only consume one message at a time 2. However, an in/out-role instance can send and receive one message at the same time. Concrete Syntax of a Coordination Direction As depicted in Figure 3.3, the concrete syntax of the out-role has a filled isosceles triangle within its square (the so-called out-triangle) whose top points to the connector of the protocol. The in-role has a triangle (the so-called in-triangle) whose top points away from the connector of the protocol. The in/out-role is visualized with two triangles. The top of the upper one points to the left and the top of the lower one points to the right Cardinality of Roles For establishing the message-exchange between role instances, each instance of a role has one or more connections to other role instances. For each connection, a so-called subrole instance exists within the role instance. Therefore, each connection consists of exactly two subrole instances of different role instances. The number of connections and therefore the number of subrole instances, a role instance may have, is limited. Therefore, each role has a cardinality that defines the minimum and maximum number of subrole instances of a multi role instance. We describe the role-cardinality by the Min-Max-Notation [Abr74]. Developers should be aware that the Min-Max-Notation is contrary to the multiplicity notation of the UML. The Min-Max-Notation defines for each entity of type x how many associations of type y (at minimum and at maximum) to entities of type z it may have. In contrast to this, the multiplicity notation of the UML defines how many entities of type x may be (at minimum and at maximum) associated over associations of type y to one entity of type z. By using the Min-Max-Notation, a developer has to determine for each role how many subrole instances an instance of this role may have at minimum and at maximum. Consequently, we can derive the minimum and maximum number of connections of this role instance. 2 This constraint could change in the future if we we allow that the atomic component execution behavior is executable with more than one task that run in parallel.

42 20 CHAPTER 3. MODELING LANGUAGE The role-cardinality may be variable or fixed. If it is variable, then the minimum-cardinality and the maximum-cardinality are different. If it is fixed, then minimum and maximum are equal. If the role-cardinality has a fixed value of 1, which means this role coordinates with exactly one other role instance, we call this role a single role. If the role-cardinality has an upper bound greater than 1, which means this role can coordinate more than one other role instance, we call this role a multi role. The subrole instances of a multi role are always ordered in a list. A developer can use the order within the behavior specification of the multi role to define the order of message sequences. We explain this in detail in Section Concrete Syntax of a Role Cardinality A square with a dashed, single borderline visualizes the single role; a square with a dashed, cascaded borderline visualizes the multi role (cf. Figure 3.3). The role-cardinality is depicted as a label that is located next to the role under the role connector. The label consists of square brackets and one number or two numbers separated by two dots within. If the cardinality is fixed, then only one number shows the value of the fixed cardinality; if the cardinality is variable, then two numbers are shown: the lower bound is the first number, the upper bound is the second number Incoming Message Buffer An instance of an in-role buffers all incoming messages first, before it consumes the messages. Therefore, an in-role must specify at least one incoming message buffer. A message buffer is a strict queue with a fixed size, i.e., it follows the FIFO (First In, First Out) principle. A message buffer enqueues a received message at the back of the queue and dequeues messages at the front of the queue. Consequently, a message buffer sorts messages regarding their arrival time. In MECHATRONICUML, a message buffer must not overflow, i.e., it may never be the case that the buffer is full but still enqueues a message. However, the developer can choose if the buffer is allowed to displace messages. If displacement is desired then the developer has to choose between two different displacement strategies: OldIsBetter: Discard arriving messages as long as the buffer is full (the buffer stays the same). NewIsBetter: Delete the oldest message in the buffer (i.e., the message at the head of the queue) and enqueue the new arriving message. As an important note, this is the only possibility in MECHATRONICUML to delete a message from the buffer without consuming it. A developer may specify a message filter for each buffer by defining a blacklist. If a message type is on the blacklist, the buffer will not enqueue this message, but will immediately remove it. This feature is especially important if the sender of this message is a legacy component that must not be changed.

43 3.3. REAL-TIME COORDINATION PROTOCOL 21 An in-role may have more than one message buffer, but each message type is associated to exactly one message buffer. Therefore, the developer has to define which buffer stores which incoming message type. If the developer specifies more than one buffer for a role, it is possible that more than one message buffer contains at least one message at runtime. Then, the associated Real-Time Statechart may enqueue from all message buffers. Thus, there is no priority defined among the message buffers of an in-role. A developer should be aware that having no buffer priorities results in non-determinism. Buffer Assumptions We assume that underlying software layers (i.e., the middleware) handle the details of the asynchronous message exchange. Thus, we assume the following statements: The middleware buffers incoming messages in FIFO style. All messages of the protocol have the same time to live (TTL), i.e., the message is deleted if it exceeds its maximum transmission delay. A message is not handed over to the level of MECHATRONICUML (i.e., the application layer) before its minimum transmission delay or after its maximum transmission delay. Therefore, the buffer may only contain messages that were transmitted within the assumed transmission time range. The middleware hands the message over to the level of MECHATRONICUML when the scheduler of the application layer starts the task of updating the role buffers. The message will be processed as described above (it will be enqueued or discarded). The middleware cannot change the buffer during enabling and firing a transition. The developer must not specify outgoing message buffers on the level of MECHATRONICUML because we assume that the message is handed over to the middleware immediately, which does the job of sending the message and if needed buffering the message. In upcoming versions of MECHATRONICUML, we plan to provide an adapter layer which fulfills our assumptions. This layer can be used to deploy MECHATRONICUML components to different software platforms, e.g., CORBA-based middleware [Gro11b]. Concrete Syntax of an Incoming Message Buffer The message buffer specifications is an optional label that is placed next to the role. The label consists of the name of the buffer, its size, and its displacement strategy. Figure 3.4 shows an exemplary message buffer specification for the in-role receiver. Here, the role has one incoming message buffer. It contains one message and displacement of messages is not allowed Role Connector A role connector connects the roles of a Real-Time Coordination Protocol. It represents a coordination connection between the roles. If two roles are connected then their role instances

44 22 CHAPTER 3. MODELING LANGUAGE Distribution buffer1 size=1, no displacement distributor [1..8] [1] client buffer1 size=1, no displacement Figure 3.4.: Exemplary Message Buffer Specification for Role receiver can exchange messages. For each connection between two role instances, an instance of the role connector is used. Concrete Syntax of a Role Connector A role connector is a dashed line that connects the roles Steps of a Message Transmission In MECHATRONICUML, transmitting a message contains the following steps: 1. The transmission starts by raising the message (including its parameters) within the application layer. 2. The message is delivered to the middleware. 3. The middleware decides if the receiver is deployed on the same or another system (at the PIM level we must assume that both is possible). If it is deployed on the same system, we continue with step 6, otherwise with step The middleware delivers the message to OSI layer 1 and sends it to the other system via the physical connection (this can contain several hops). 5. The other system receives the message and delivers it to its own middleware. 6. The middleware of the receiver delivers the message to the application layer of the receiver, which will enqueue it into the appropriate buffer QoS Assumption of the Role Connector Concerning the connector behavior, the developer has to define the following quality of service (QoS) assumptions: The minimum and maximum message transmission delay that is accepted by the connector. The probability that a message will arrive at the buffer of the receiver role. We distinguish three cases: 0% The message eventually arrives at the application layer of the receiving role > 0% The message may arrives at the application layer of the receiving role. However, it might by the case that the message does not arrive before the maximum transmission delay, e.g., due to message loss or too long transmission time.

45 3.3. REAL-TIME COORDINATION PROTOCOL % The message will never arrive at the buffer Furthermore, MECHATRONICUML has some fixed QoS assumptions that the middleware must always guarantee: If a message arrives before the accepted lower transmission delay, then the receiver s middleware will delay the enqueueing until the lower delay is reached. The accepted maximum transmission delay is equal to the time to live (TTL) of the message. Thus, if the TTL exceeds during transmission, the message will be deleted, e.g., by the receivers middleware. Consequently, it will never reach the level of MECHATRONICUML. From the viewpoint of MECHATRONICUML, it is transparent where the message is deleted because we are only interested if it could be the case that the message does not arrive at the receiver buffer within the minimum and maximum transmission delay. We do not state explicitly if a message can get lost during transmission and if the sender middleware tries (several times) to resend it. As stated before, this is transparent from the viewpoint of the MECHATRONICUML level The receiver s middleware handles corrupt messages. Consequently, corrupted messages will not be enqueued into the buffer. The sending message order is the same as the receiving message order. This means if the sender role sends message m1 first and then message m2, then the receiver role will not enqueue m2 first and m1 afterwards. However, if m1 does not fulfill its maximum transmission delay, then the receiver role may enqueue m2 without enqueueing m1 first. As a consequence, the receivers middleware must know the correct message order and must be able to delay the enqueueing, e.g., the middleware must delay the enqueueing of m2 as long as m1 arrives or its maximum transmission delay is violated. In former version of MECHATRONICUML, the developer had to describe the connector behavior via Real-Time Statecharts [Bur06]. The current version of MECHATRONICUML does not support this because the behavior description is generic. Thus, describing the behavior with a Real-Time Statechart has no benefits in our opinion. Concrete Syntax of a Role Connector We visualize the role connector by a black line between the two squares for the roles (cf. Figure 3.5). Optionally, the QoS assumptions defined by the developer can be annotated as a textual label next to the role connector. The range of the transmission delay is defined using the keyword delay; the probability that a message will arrive the buffer of the receiver role is defined using the keyword failure ratio Classification of Real-Time Coordination Protocols We classify Real-Time Coordination Protocols on the direction of coordination (unidirectional or bidirectional) and on the form of coordination (one-to-one or one-to-many). Figure 3.6 shows the five kinds of a Real-Time Coordination Protocol: a) unidirectional, one-to-one, b)

46 24 CHAPTER 3. MODELING LANGUAGE Distribution [1..8] [1] QoS assumptions delay = [2 ms, 5 ms], fail. ratio = 0% Figure 3.5.: Role Connector with annotated Quality of Service Assumptions unidirectional, one-to-many, c) unidirectional, many-to-one, d) bidirectional, one-to-one, and e) bidirectional, one-to-many. We describe them in the following Directions of Coordination A unidirectional coordination means that only one role can send messages and the other role can only receive messages. Therefore, this coordination consists of an out-role and an in-role. Figures 3.6 a), b) + c) show the three possibilities for this coordination. A bidirectional coordination means that all roles can send and receive messages. Thus, all roles must be in-out-roles. Figures 3.6 d) + e) show the two possibilities for such a coordination Forms of Coordination In MECHATRONICUML, two possible forms of coordination exist: one-to-one and one-tomany. These forms of coordination define to how many other instances one role can coordinate and how many instances participate in this coordination. One-to-one means that two roles coordinate each other and both roles have only one role instance per instantiated Real-Time Coordination Protocol. Both roles have a role-cardinality of 1. Therefore, both roles must be single roles. Figures 3.6 a) + d) show the two possibilities for a one-to-one coordination. One-to-many means that two roles coordinate each other and one role has only one instance and coordinates itself with multiple instances of the other role. The role with one instance may have multiple subrole instances and can therefore coordinate multiple instances of the other role. The role, which may have multiple instances, has a role-cardinality of 1, because there is only one instance of the other role. A protocol, which specifies such a coordination has one multi role and one single role. Figures 3.6 b), c) + e) show the three possibilities for specifying a one-to-many form of coordination.

47 3.3. REAL-TIME COORDINATION PROTOCOL 25 <rolename> <protocolname> <rolename> <rolename> <protocolname> <rolename> a) unidirectional, one-to-one d) bidirectional, one-to-one <rolename> <protocolname> <rolename> <rolename> <protocolname> <rolename> [i..j] [1] b) unidirectional, one-to-many [i..j] [1] e) bidirectional, one-to-many <rolename> <protocolname> <rolename> [1] [i..j] c) unidirectional, many-to-one Figure 3.6.: The Five Classes of a Real-Time Coordination Protocol Real-Time Coordination Protocol Instance An instance of a Real-Time Coordination Protocol consists of (i) a set of role instances that are typed over the roles specified in the Real-Time Coordination Protocol and (ii) a set of role connector instances that are typed over the role connector of the Real-Time Coordination Protocol. The variable parts of the Real-Time Coordination Protocol are determined during instantiation. If the Real-Time Coordination Protocol has the form one-to-one, there exist no variable parts, because the protocol consists of two single roles that are both connected to an instance of each other. Consequently, the only possible protocol instance consists of one instance per single role and one connector instance that connects the two role instances. If the Real-Time Coordination Protocol has the form one-to-many, the variable parts include the variable role-cardinality of the multi role and the number of role instances of the single role. A developer determines both parts at the same time, because they depend on each other: A specific role-cardinality defines of how many subrole instances a multi role instance may consists. Each subrole instance of a multi role is connected to a different single role instance. Thus, in a one-to-many coordination, there exists only one multi role instance but several single role instances, where the number of single role instances depends on the specific role-

48 26 CHAPTER 3. MODELING LANGUAGE cardinality of the multi role instance. Each pair of a subrole instance and a single role instance is connected by a different role connector instance. For example, an instance of Real-Time Coordination Protocol Distribution (cf. Figure 3.2) specifies a coordination between four role instances. One instance is typed over the role distributor and contains three subrole instances. Each of these three is connected via different role connector instances to one of the three role instances which are typed over the role client. This instance of the Real-Time Coordination Protocol Distribution is valid because the maximum role-cardinality of role distributor is eight and the current role-cardinality of the role instance, which is typed over role distributor, is three. To conclude, this instantiation defines a 1:3 coordination with one distributor and three clients. protocol instance label role instance label :distributor multi role instance subrole instance :Distribution :client :client :client role instance label single role instance role connector instance Figure 3.7.: Instance of Real-Time Coordination Protocol Delegation Concrete Syntax of a Real-Time Coordination Protocol Instance Figure 3.7 shows the aforementioned instance of Real-Time Coordination Protocol Distribution in concrete graphical syntax. All concrete syntax elements of the example are annotated in gray. A dashed ellipse contains the protocol instance label which consists of the name of the protocol. The name is underlined and prefixed by a colon. Each instance of a single role has its own dotted square and its own dashed line, which connects the ellipse. A multi port instance contains a fixed number of subrole instances, which are framed by a dashed line. Each subrole instance has its own dotted square. A multi port instance connects the ellipse via a dashed line. A label is placed next to the dashed line of each role instance (single and multi) and consists of the name of the role that is underlined and prefixed with a colon. Single role instances and subrole instances contain triangles to show the direction of the role instance. The solid line, which represents the role connector instance, connects a single role instance and a subrole instance. We use the same graphical syntax for the role connector instance if a protocol instance has a one-to-one form of coordination where two single role instances are connected.

49 3.3. REAL-TIME COORDINATION PROTOCOL Protocol Behavior Specification The concurrent execution of the roles of a Real-Time Coordination Protocol specifies the execution behavior of the Real-Time Coordination Protocol. Therefore, the developer has to specify the coordination behavior for each role. This role behavior specification can be seen as a contract that a port must fulfill, when a role is applied to it. If a role is applied to a port of an atomic component, the port has to fulfill the role behavior specification directly. If the developer applies a role to a port p of a structured component, the behavior specification of the role must be fulfilled by the port the port p delegates to. The behavior of a role is state-based and is subject to real-time restrictions (e. g., the maximum time the system dwells within a certain state). The developer specifies the behavior of a role by a Real-Time Statechart (cf. Section 3.4). The concurrent execution of all role instances of an instantiated Real-Time Coordination Protocol determines its overall behavior. Within the Real-Time Statechart of a role, only asynchronous messages can be used (cf. Section 3.4.9) to specify the message exchange between the roles. These message events are typed over the message types declared in the message type specification of the role (cf. Section 3.2. Asynchronous messages may not be used for coordination within the role (e. g., to coordinate between several regions of the role statechart). A role may define variables to store information concerning the coordination (e. g., the current physical position of the system). The Real-Time Statechart of the role can read and write the values of these variables, e.g., in conditions and effects of transitions. The Real- Time Statechart of the role cannot access the variables that are defined by other role instances. Furthermore, a role can define operations (e. g., to calculate the current position of the system). The Real-Time Statechart of the role instance can call its defined operations, but cannot call operations that are defined by other role instances. Distribution distributor client [1..8] [1] distributor client adaptation distributor_main sub-role [k] Figure 3.8.: A Multi Role and a Single Role Specified by Real-Time Statecharts

50 28 CHAPTER 3. MODELING LANGUAGE Figure 3.8 shows the Real-Time Coordination Protocol Distribution with its roles distributor and client. The behavior of the single role client is defined by a Real-Time Statechart without further restrictions. The behavior of the multi role distributor is separated into an adaptation behavior and a subrole behavior. This separation results from the one-to-many coordination where the multi role has to coordinate several instances of the single role. The behavior of each instance of the single role has to be identical and is defined by one common subrole behavior. The adaptation behavior defines an order of the different coordination behaviors to each instance of the other role and will be used for specifying run-time adaptations of the coordination as introduced in [EHH + 13] in future versions of this document. We introduce the different parts of a Real-Time Statechart for a multi role in more detail in Section Real-Time Model Checking of Protocol Properties The behavior specification of a Real-Time Coordination Protocol usually has to fulfill requirements that are important for the safety of the real-time system under development. Analyzing the system using tests or simulation is typically not enough, because these analysis techniques only check a subset of all possible execution traces. Hence, it might be the case that an execution trace that violates (safety-critical) requirements is not analyzed by testing. This may result in a critical system failure. A formal analysis technique that checks all possible execution traces w.r.t. a formal requirement is model checking [BK08]. For each requirement of the accepted requirement language, the model checker is able to state if the requirement is fulfilled on all execution traces or not. This raises the trust in the model significantly. Furthermore, a model checker is able to present a counter example that shows the execution path for a (un-)satisfied requirement. For the domain of real-time systems, a specialized form of model checking, called real-time model checking, exists. Real-time model checking uses as inputs timed automata and a realtime constraint language (e.g., the Timed Computation Tree Logic, TCTL [ACD93]). One exemplary real-time model checker is UPPAAL [BDL04]. In MECHATRONICUML, we support the real-time model checking of Real-Time Coordination Protocols via a model transformation to UPPAAL in a transparent manner [Ger13]. We achieve this by a model translation to UPPAAL, the automated execution of UPPAAL, and a back-translation to MECHATRONICUML. Therefore, the developer does not need to understand the technical details of the transformations (translation and backtranslation) nor UPPAAL and its model checking itself. Until now, MECHATRONICUML does not provide an own verification property language. Thus, a developer has to specify its verification properties using UPPAAL s TCTL subset. Moreover, the specified properties must be applicable to the translated timed automata of UPPAAL and not to the Real-Time Coordination Protocol of the level of MECHATRONICUML. As this is a major obstacle for a fully transparent model checking, we will define a MECHATRONICUML verification property language in upcoming revisions of this document. This property language will be translatable into the properties supported by UPPAAL.

51 3.3. REAL-TIME COORDINATION PROTOCOL 29 Concrete Syntax of a Protocol Verification Properties Figure 3.9 visualizes the Real-Time Coordination Protocol Distribution and shows the UPPAAL-specific properties for its role distributor and for the protocol itself. A black-lined rectangle contains all verification properties of a role or a protocol. The rectangle links via a black line to the dashed square of a role (here: to the role distributor) or to the black-dashed ellipse, which displays the name of the protocol (here: to the protocol Distribution). If a role or a protocol has no verification properties (like the role client), the rectangle and its link are not shown. A[] not deadlock distributor.adaptation.error --> (client_1.receive.error and and client_8.receive.error) Distribution distributor client A[] adaptation.c0 <= 50 [1..8] [1] Figure 3.9.: The Real-Time Coordination Protocol Distribution with Verification Properties for the Role distributor and for the whole Protocol In our example, two TCTL-properties are specified for the protocol Distribution using the verification property language of the model checker UPPAAL: The first property states A[] no deadlock, which expresses that there exists no deadlock within this protocol. The second property states distributor.adaptation.error > (client_1.receive.error and... and client_8.receive.error), which expresses that if role distributor is in state Error (which is embedded in region adaptation), then all clients will eventually enter state Error of region receive. In other words, if the distributor cannot collect the position data of all clients, then the clients will be informed so that they can react to this error. Additionally, the role distributor specifies the verification property A[] adaptation.c0 <= 50ms, which formally expresses that the clock c0 of region adaption never exceeds 50 ms. If this constraint always holds, then the developer can ensure that the distributor can distribute its information every 50 ms.

52 30 CHAPTER 3. MODELING LANGUAGE 3.4. Real-Time Statechart Real-Time Statecharts are state-based behavior specification models that are used for defining the behavior of atomic components (cf. Section ), discrete ports (cf. Section ), or roles (cf. Section 3.3.6). Both syntactically and semantically, Real-Time Statecharts are a combination of Harel s statecharts [Har87], UML state machines [Gro10b], and (UPPAAL) timed automata [BDL04, AD94, DM01]: Concepts and syntactical elements for supporting hierarchy are derived from statecharts and state machines, while notions and notations from timed automata allow for defining time-based behavior. Giese and Burmester [GB03] defined a previous version of Real-Time Statecharts in the year 2003, defining the semantics by mapping Real-Time Statechart to hierarchical timed automata [DM01]. Within this document, we refine the execution semantics further (cf. Section ). A Real-Time Statechart has a name. For describing behavior, a Real-Time Statechart may contain several different types of modeling elements. Like in timed automata, time-based behavior is modeled using clocks (cf. Section 3.4.1) that are stored within a Real-Time Statechart. Certain situations within the system are modeled as states (cf. Section 3.4.2). For keeping the behavior model compact, Real-Time Statecharts additionally support hierarchical and orthogonal states [Har87]. A change of the active state is modeled using transitions (cf. Section 3.4.3). Moreover, Real-Time Statecharts support state connection points (cf. Section 3.4.4) to chain transitions between different hierarchy levels. Within a Real-Time Statechart, effects (cf. Section 3.4.5) define an executable behavior. One type of an effect is executing actions (cf. Section 3.4.6), e.g. for specifying an assignment. Moreover, a Real-Time Statechart can store values within variables (cf. Section 3.4.7) and can call operations (cf. Section 3.4.8). Real-Time Statecharts enable an asynchronous message exchange (cf. Section 3.4.9) between (i) atomic components of different systems and (ii) atomic components within a system. Similar to timed automata, within a state orthogonal Real-Time Statecharts may synchronize the firing of their transitions using synchronization (cf. Section ). For specifying the behavior of multi roles and multi ports, we define a strict structure of the Real-Time Statechart (cf. Section ). Concrete Syntax of a Real-Time Statechart Figure 3.10 shows a template for the concrete syntax of a Real-Time Statechart: The visual representation of a Real-Time Statechart is a rectangle with the name of the statechart (rtscnamelabel) shown in the upper left corner. In the upper right corner, the rtscdefinitionlabel shows the defined variables, operations, and clocks of a statechart. Concerning the defined operation, only the operation signatur is visualized. The remainder of the Real-Time Statechart s rectangle may contain state compartments, the visual representation of states and their transitions.

53 3.4. REAL-TIME STATECHART 31 <rtscnamelabel> <rtscdefinitionlabel> StateCompartment Figure 3.10.: Concrete Syntax Template of a Real-Time Statechart The following EBNF grammar defines the default notation of the rtscdefinitionlabel. It reuses the EBNF grammars for defining variables (cf. Section 3.4.7), operation signatures (cf. Section 3.4.8), and clocks (cf. Section 3.4.1). < r t s c D e f i n i t i o n L a b e l > = [ < r t s c V a r i a b l e D e f i n i t i o n >] [ < r t s c O p e r a t i o n S i g n a t u r e >] [ < r t s c C l o c k D e f i n i t i o n > ] ; < r t s c V a r i a b l e D e f i n i t i o n > = v a r i a b l e < v a r i a b l e D e f i n i t i o n > [, < v a r i a b l e D e f i n i t i o n > ] ; < r t s c O p e r a t i o n S i g n a t u r e > = o p e r a t i o n < o p e r a t i o n S i g n a t u r e > [, < o p e r a t i o n S i g n a t u r e > ] ; < r t s c C l o c k D e f i n i t i o n > = c l o c k < c l o c k D e f i n i t i o n > [, < c l o c k D e f i n i t i o n > ] ; Figure 3.11 shows an example of the concrete syntax for Real-Time Statecharts, except for the state compartments. For a description of the concrete syntax for states, see Section Statechart1 variable int[10] a, string s operation int op1(int i, boolean b) clock c1, c2 StateCompartment Figure 3.11.: Concrete Syntax Example of a Statechart Clock Like a timed automaton, a Real-Time Statechart has a finite number of clocks. A clock models the elapsing of time during the execution of a system. Since time elapses continuously and not in discrete steps [AD94], we consider clock values from the set R of real numbers. All clocks within a Real-Time Statechart have a unique name. The initial value of a clock is zero.

54 32 CHAPTER 3. MODELING LANGUAGE Concrete Syntax of a Clock Definition The following EBNF grammar clockdefinition defines the default notation for defining. Elements which have the prefix # are references to the meta model elements of class Clock. < c l o c k D e f i n i t i o n > = #name ; Time Value A time value represents a concrete system time. It consists of an expression and a time unit. The expression (e.g., an algorithmic expression) may reference variables and operations. Furthermore, the value must evaluate to a natural number from the set N. We support the time units of the Java class java.util.concurrent.timeunit: nanoseconds (ns), microseconds (µs), milliseconds (ms), seconds (s), minutes (min), hours (h), and days (d). Concrete Syntax of a Time Value The time value label consists of a value label and a time unit label. Valid concrete syntax examples are 15 ms, (2 i + j + 3) ns, and (op1(i, 5) j) d Clock Constraint A clock constraint restricts the values of a particular clock to a certain range. A developer uses clock constraints for defining a state invariant (cf. Section ) or for restricting the enabling conditions of a transition. We only allow clock constraints that compare the current value of a clock to an expression (cf. Section 3.5.3) representing a natural number from the set N. In general, we allow the following comparison operators: less (<), less or equal ( ), equal (==), greater or equal ( ), and greater (>). Elements that use clock constraint, e.g., invariants, may further constraint this. Concrete Syntax of a Clock Constraint The following EBNF grammar defines the default notation for defining clock constraints. Elements which have the prefix # are references to the meta model elements of class ClockConstraint. < c l o c k C o n s t r a i n t > = # c l o c k. name # operator <upperbound >; <upperbound > = # bound. v a l u e [# bound. u n i t ] ; The clock constraint label consists of a clock name, a comparison operator, and a time value including an optional time unit. Valid concrete syntax examples are c1 > 15 ms and c2 (2 i + j + 3) ns.

55 3.4. REAL-TIME STATECHART Clock Reset A developer may force a clock to start running from zero again. We refer to this as a clock reset. A clock reset is an effect. A set of clock resets is either part of a state s entry or exit event (cf. Section ), or part of a transition effect Thus, a clock s value is always relative to its last reset time. There is no possibility to change the value of a clock other than resetting it to zero. Concrete Syntax of a Clock Reset The following EBNF grammar defines the default notation for defining clock resets. Elements which have the prefix # are references to the meta model elements of class Clock. < c l o c k R e s e t > = r e s e t #name [, #name ] ; The clock reset label consists of the keyword reset and a clock label. Valid concrete syntax examples are reset c1 and reset c1, c State A state refers to a certain situation within the system. At runtime, a state may be active or inactive. If it is active, then the system currently resides in this situation; if it is inactive, then the system does currently not reside in this situation. A Real-Time Statechart contains a non-empty set of states with a unique name for each state. Typically, all states of a Real-Time Statechart define distinct situations. Thus, while a running Real-Time Statechart is active, at most one state is active, too. If no state is active, then a transition (cf. Section 3.4.3) of this Real-Time Statechart must be active. A state change within a Real-Time Statechart describes a deactivation of the currently active state (the source state) and the activation of a currently inactive state (the target state). Transitions (cf. Section 3.4.3) describe all possible state changes within a Real-Time Statechart. A developer may constrain the duration that a state is active using an invariant (cf. Section ). Furthermore, a state may have state events. These events define effects that are executed at certain points of time while the state is active, e.g. on state entry or state exit (cf. Section ). The initial state of a Real-Time Statechart is the first state that is active when the containing Real-Time Statechart is active itself (cf. Section ). Moreover, a state may be final, i.e., a subsequent state change on this hierarchy level is not allowed (cf. Section ). States differ in their support of hierarchy. We distinguish between (i) simple states (cf. Section ) that do not support hierarchy, and (ii) composite states (cf. Section ) that support hierarchy by using the concept of regions that embed Real-Time Statecharts (called embedded statecharts). As an embedded statechart can contain embedded statecharts itself, the hierarchical structure of a Real-Time Statechart can be graphically represented as a tree. We refer to the root of the tree as the root statechart.

56 34 CHAPTER 3. MODELING LANGUAGE Concrete Syntax of a State Figure 3.12 shows the template for the concrete syntax of a state. In general, we visualize a state by means of a rectangle with rounded corners, showing the state name inside the rectangle. Please note that we will define extensions for the concrete syntax of a state in the following. <statenamelabel> Figure 3.12.: Concrete Syntax Template of a State Invariant For specifying hard real-time constraints concerning a specific state, a developer may assign an invariant for constraining the time that a state may be active. An invariant must always hold as long as the state is active. In contrast to the invariants of UPPAAL, MECHATRONICUML only supports clock-based state invariants which restrict the time this state may be active, whereas UPPAAL supports all possible expressions that result to true or false (including data conditions). A developer specifies an invariant by means of a non-empty set of clock constraints (cf. Section ). All clock constraints must be always true as long as the state is active. However, each clock constraint may only use the operators < and. Therefore, the clock constraints can only define an upper bound of the clock. An invariant requires the system to leave the corresponding state at the latest when its upper time bound is reached. A situation where the specification of a Real-Time Statechart enforces to remain in a certain state longer than the upper time bound of its invariant is called a time-stopping deadlock [DMY02a], because time in the model can not progress anymore as this would violate the invariant. Time-stopping deadlocks constitute serious problems in the behavioral design, and thus require detection and elimination before implementing a real system. Thus, in Real-Time Statecharts, time-stopping deadlock must not occur. Detecting these deadlocks is possible by means of exhaustive formal verification techniques such as UPPAAL model checking. Formal verification, however, will only prove the system correct under the following assumptions: (i) all concrete models including platform-specific models and the generated platform code refine the Real-Time Statechart-model correctly and (ii) the platform can guarantee that all defined invariants will always hold. Concrete Syntax of an Invariant The following EBNF grammar defines the default notation for an invariant. It references the EBNF grammar of clock constraints. < i n v a r i a n t > = i n v a r i a n t < c l o c k C o n s t r a i n t > [, < c l o c k C o n s t r a i n t > ] ;

57 3.4. REAL-TIME STATECHART State Events A state may have state events that are triggered at certain points in time. We support three different kinds of state events: (i) entry, (ii) do, and (iii) exit. For each state event, a developer may define effects that are invoked when the event is triggered. All events are only triggered if an effect is defined. The effects cannot be canceled nor interrupted and are executed synchronously and not in a task that runs in parallel, i.e., a state change must not happen while executing the effect. Entry Event This event is triggered whenever the associated state gets activated due to a firing transition. The effect may consist of an action (cf. Section 3.4.6) and a set of clock resets (cf. Section ). The action is executed before resetting the concerning clocks. Concrete Syntax of an Entry Event The following EBNF grammar specifies the default notation for an entry event definition. Here, we reuse the EBNF grammar for clock resets. Elements which have the prefix # are references to the meta model elements of class State: < e n t r y E v e n t > = e n t r y / [ < e n t r y E f f e c t >] [ < e n t r y C l o c k R e s e t > ] ; < e n t r y E f f e c t > = { (# e n t r y E v e n t. a c t i o n. e x p r e s s i o n s # e n t r y E v e n t. a c t i o n. name ) } ; < e n t r y C l o c k R e s e t > = { < c l o c k R e s e t > } ; Do Event This event is triggered periodically as long as the state is active. The effect may only consist of an action. Within each period, the action is executed once. The period is strict. We define the period by means of a time value (cf. Section ). We assume that the worst case execution time of the effect is shorter than the period. Furthermore, the effect does not have to start at the beginning of the period, but has to end before the end of the period. A scheduler may define the starting time individually. Concrete Syntax of a Do Event The following EBNF grammar defines the default notation for a do event definition. Elements which have the prefix # are references to the meta model elements of class State: <doevent > = do / [ < d o E f f e c t > ] ; < d o E f f e c t > = { (# doevent. a c t i o n. e x p r e s s i o n s # e x i t E v e n t. a c t i o n. name ) } [ p e r i o d : # doevent. p e r i o d. v a l u e [ # doevent. p e r i o d. u n i t ] ] ; Exit Event This event is triggered whenever the associated state gets deactivated due to a firing transition. The effect may consist of an action (cf. Section 3.4.6) and a set of clock resets (cf. Section ). The action is executed before the clock resets.

58 36 CHAPTER 3. MODELING LANGUAGE Concrete Syntax of an Exit Event The following EBNF grammar defines the default notation for an exit event definition. Here, we reuse the EBNF grammar for clock resets. Elements which have the prefix # are references to the meta model elements of class State. < e x i t E v e n t > = e x i t / [ < e x i t E f f e c t >] [ < e x i t C l o c k R e s e t > ] ; < e x i t E f f e c t > = { (# e x i t E v e n t. a c t i o n. e x p r e s s i o n s # e x i t E v e n t. a c t i o n. name ) } ; < e x i t C l o c k R e s e t > = { < c l o c k R e s e t > } ; Initial State For each Real-Time Statechart, the developer has to declare exactly one state as the initial state. This state is the first one that is active if the parent Real-Time Statechart is active itself. Concrete Syntax of an Initial State Figure 3.13 shows the template for an initial state. If a state is an initial state, a black-filled circle and a directed edge from the black-filled circle to the initial state are shown at the top left border of this state. <statenamelabel> Figure 3.13.: Concrete Syntax Template of an Initial State Final State The developer may declare one or more states of a Real-Time Statechart as final. This denotes that a statechart is in a stable configuration. This implies that the embedding statechart of the state cannot change its state or variables anymore (clocks will go on nevertheless). Thus, a final state has no outgoing transitions. Furthermore, a final state is always a simple state (cf. Section ). We demand this to prevent changes to the stable configuration. In contrast to the UML, reaching a final state in a Real-Time Statechart does not lead to the statechart s termination. Another distinction to the UML is that a developer may define an entry-event (cf. Section ) to a final state. We allow this, because the semantics of our entry-events differ from the UML s: in a Real-Time Statechart, a state is active after executing the entry event. In UML statemachines, the state is already active while executing entry events. However, like the UML, a final state must not have a do-event or exit-event to ensure the stable configuration. A deactivation of a parent composite state is the only possibility to leave a final state.

59 3.4. REAL-TIME STATECHART 37 Concrete Syntax of a Final State Figure 3.14 shows a final state. A final state is shown as a state with a border drawn as a double line. <statenamelabel> Figure 3.14.: Concrete Syntax Template of a Final State Simple State A state in a Real-Time Statechart is called a simple state if it does not contain any further states, i.e., it does not have any substates. A simple state may have invariants and state events. Additionally, it may be an initial or final state. Concrete Syntax of a Simple State Figure 3.15 shows the concrete syntax template of a simple state. A simple state consists of three compartments: (i) the name compartment, (ii) the invariant compartment, and (iii) the state event compartment. Compartments (ii) and (iii) are only visualized if the developer defines an invariant or state events for this state. If more than one compartment is used, solid borders separate the compartments. <statenamelabel> <invariantlabel> <stateeventlabel> Figure 3.15.: Concrete Syntax Template of a Simple State The statenamelabel contains the name of the state. The invariant compartment contains the invariantlabel, which reuses the concrete syntax definition of an invariant. The state event compartment contains the stateeventlabel. The following EBNF grammar defines the default notation for a stateeventlabel. The stateeventlabel reuses the concrete syntax definition of entry, do, and exit events. < s t a t e E v e n t L a b e l > = [ < e n t r y E v e n t >] [ \ n <doevent >] [ \ n < e x i t E v e n t > ] ; Figure 3.16 shows an example of a simple state. The name of the state is SimpleState1. A state invariant is defined for this state which defines that as long as this state is active clock c1 must be smaller than 15 seconds and clock c2 must be smaller or equal to 2 i 5 milliseconds. Moreover, all three kinds of state events are defined. The entry event executes action action1 and resets the clock c0; the do event executes action action2 periodically (the period is 50 milliseconds); the exit event executes action action3 and resets the clocks c1 and c2.

60 38 CHAPTER 3. MODELING LANGUAGE SimpleState1 invariant c1 < 15 s, c2 <= 2 i-5 ms entry / {action1} {reset: c0} do / {action2} [period: 50 ms] exit / {action3} {reset: c1,c2} Figure 3.16.: Concrete Syntax Example of a Simple State Composite State A state in a Real-Time Statechart is called a composite state if it contains further states, i.e. if it has substates. A composite state is an extension of a simple state. Thus, it may also have invariants and state events, and it may be an initial or final state. To enable the composition of states within a composite state, we use the concept of regions. Each region contains exactly one Real-Time Statechart (the so-called embedded statechart) that contains the substates. As composite states may contain more than one region, composite states do not only enable hierarchical statecharts, but also concurrent behavior within a Real- Time Statechart. We distinguish non-orthogonal composite and orthogonal composite states. A nonorthogonal composite state contains exactly one region. An orthogonal composite state contains two or more orthogonal regions and defines concurrent behavior. Each region of a composite state has a name, which is the same as the name of the embedded Real-Time Statechart. Hence, the names of all regions of an orthogonal composite state and thus of all embedded statecharts at this level must be unique. In contrast to the submachine states defined in the UML, we do not permit to reference the same Real-Time Statechart from more than one region [Gro10b, p. 551]. We impose this restriction to avoid additional complexity concerning the scopes of clocks and variables. As we already offer explicit support for re-using components and Real-Time Coordination Protocols, we consider a reuse of single Real-Time Statecharts as unnecessary. Thus, an embedded statechart has exactly one embedding region. As a consequence, the structure of a Real-Time Statechart is always a tree with one root. Currently, the regions of an orthogonal composite state may not be executed in parallel because we currently assume that the root Real-Time Statechart is executed within one task. Thus, we enforce sequential semantics as defined by Zündorf [Zü01, p. 159]. Therefore, a developer has to define the processing sequence of the regions for each composite state. For this purpose, each region has a fixed priority defined by means of a natural number (excluding zero). A larger number indicates a higher priority. Thus, the lowest priority is 1. The highest possible priority is the number of regions of the affected composite state. Within an orthogonal composite state, embedded statecharts can synchronize the firing of their transitions via synchronization channels (cf. Section ). A developer defines these

61 3.4. REAL-TIME STATECHART 39 channels within the orthogonal composite state that (indirectly) contains the transitions that shall synchronize. Concrete Syntax of a Non-Orthogonal Composite State Figure 3.17 shows the concrete syntax template of a non-orthogonal composite state. Compared to the concrete syntax template of a simple state (cf. Figure 3.15), a non-orthogonal composite state has an additional compartment for displaying the embedded statechart for its single region and the corresponding embedded statechart. The name of the region is displayed in the upper left corner of the statechart compartment. The region s priority is not displayed, because in case of a single region, there is no order to represent. Moreover, defined variables, operations, and clocks of the embedded statechart are shown within the rtscdefinitionlabel in the top right corner of the compartment. As this is the same label that is defined for Fig. 3.10), the same definition applies. <statenamelabel> <invariantlabel> <stateactionlabel> <regionnamelabel> <rtscdefinitionlabel> StateCompartment Figure 3.17.: Concrete Syntax Template of a Non-Orthogonal Composite State Figure 3.18 shows an example of a composite state named NonOrtogonalCompositeState1. Compared to the example for a simple state (cf. Figure 3.16), a region and a corresponding Real-Time Statechart are added. As the Real-Time Statechart s name is rtsc_a, the region has this name, too. The corresponding Real-Time Statechart defines a variable and a clock. Moreover, the statechart contains two simple states and a transition. NonOrthogonalCompositeState1 invariant c1 < 15 s, c2 <= 2 i-5 ms entry / {action1} {reset: c0} do / {action2} [period: 50 ms] exit / {action3} {reset: c1,c2} rtsc_a variable int i1 clock c4 State1a State1b Figure 3.18.: Concrete Syntax Example of a Non-Orthogonal Composite State

62 40 CHAPTER 3. MODELING LANGUAGE Concrete Syntax of an Orthogonal Composite State Figure 3.19 shows the template for an orthogonal composite state, which is an extension of the non-orthogonal composite state template (cf. Figure 3.17). The state s channels are shown within a channeldefinitionlabel below the stateactionlabel and separated by a solid line. The following EBNF grammar defines the default notation for a channeldefinitionlabel. Elements which have the prefix # are references to the meta model elements of class State: < c h a n n e l D e f i n i t i o n L a b e l > = c h a n n e l < channel >, [ < channel > ] ; < channel > = # c h a n n e l s. name [ # c h a n n e l s. s e l e c t o r T y p e ] ; Like non-orthogonal composite states, orthogonal composite states have additional compartments for showing the regions. For each region, an own compartment exists. A solid line separates the compartments for the orthogonal regions from the rest of the state (the compartments for name, invariant, state events, and channel definitions). The compartments are separated horizontal by dashed lines. A small circle in the upper right corner of the region s area contains the priority value. Like non-orthogonal composite states, each compartment consists of a regionnamelabel, a rtscdefinitionlabel, and a compartment for showing the states and transitions. <statenamelabel> <invariantlabel> <stateactionlabel> <channeldefinitionlabel> <regionnamelabel> <rtscdefinitionlabel> n StateCompartment_1... <regionnamelabel> <rtscdefinitionlabel> 1 StateCompartment_n Figure 3.19.: Concrete Syntax Template of an Orthogonal Composite State Figure 3.20 shows an example for an orthogonal composite state with two regions. The state s name is OrthogonalCompositeState1. In addition to the example of Fig. 3.18, a second region rtsc_b and a corresponding Real-Time Statechart (including two variables, an operation, two states, and one transition) were added to the state. Region rtsc_b has a lower priority than rtsc_a. Moreover, two synchronization channels ch1 and ch2 are added that enable the regions to synchronize their transition firing Transition A transition represents a change of the active state inside a Real-Time Statechart. Since transitions are directed, every transition connects a source vertex to a target vertex. Vertices

63 3.4. REAL-TIME STATECHART 41 OrthogonalCompositeState1 invariant c1 < 15 s, c2 <= 2 i-5 ms entry / {action1} {reset: c0} do / {action2} [period: 50 ms] exit / {action3} {reset: c1,c2} channel ch1, ch2 rtsc_a variable int i1 clock c4 2 State1a State1b rtsc_b variable int i1, float f1 1 operation bool p1() State2a State2b Figure 3.20.: Concrete Syntax Example of an Orthogonal Composite State with two Regions may be states (cf. Section 3.4.2) or state connection points (cf. Section 3.4.4). We distinguish between different types of transitions according to the types of their sourve and target vertices (cf. Section ). When a transition is involved in a state change, it is said to fire. However, a transition may only fire if it is enabled according to specific enabling conditions that restrict the circumstances for firing (cf. Section ). The urgency value of an enabled transition determines whether it starts to fire without delay (cf. Section ). When a transition fires, it may cause certain effects (cf. Section ). In addition, a transition may have deadlines to specify requirements concerning the firing duration (cf. Section ) Types of Transitions The different types of vertices in Real-Time Statecharts give rise to various types of transitions, distinguished according to the types of their source and target vertices. Figure 3.21 illustrates the eight types of possible transitions in Real-Time Statecharts. The standard case for a transition is to connect two states on the same hierarchy level, as depicted in Figure 3.21(a). Two states on the same hierarchy level may also be connected indirectly using an exit point as source or an entry point as target. We illustrate these types of transitions in Figure 3.21(b) to 3.21(d). In addition, by using entry or exit points as source or target, transitions may also indirectly connect states on different hierarchy levels. However, this type of transition is restricted to the case that one of the affected states is a direct substate of the other one. In Figure 3.21(e) to 3.21(h), we illustrate these types of transitions. All other types of transitions not depicted in Figure 3.21 are invalid inside Real-Time Statecharts. In particular, this applies to so-called inter-level transitions that directly connect two states on different hierarchy levels (without using entry or exit points). In particular, we also prohibit the case that a transition connects directly from an entry point to an exit point.

64 42 CHAPTER 3. MODELING LANGUAGE State1 State2 State1 State2 (a) State to State (b) State to Entry Point State1 State2 State1 State2 (c) Exit Point to State (d) Exit Point to Entry Point State1 State2 State1 State2 State1 State2 (e) Entry Point to State (f) State to Exit Point (g) Entry Point to Entry Point State1 State2 (h) Exit Point to Exit Point Figure 3.21.: Possible Types of Transitions in Real-Time Statecharts Composite Transition A special type of transition is a so-called composite transition. A transition is composite if its source or target vertex is a composite state (cf. Section ). Such transitions are abbreviations for compositions of numerous ordinary transitions. In Figure 3.22, we illustrate this abbreviating role of composite transitions. In Figure 3.22(a), an incoming composite transition (depicted in purple) is a shorthand for an entry point that connects to the initial states of every embedded statechart. In contrast, an outgoing composite transition (depicted in green) is a shorthand for an exit point which all substates in all embedded statecharts connect to. In Figure 3.22(b), we illustrate how the same abbreviation logic applies to a composite transition that is both incoming and outgoing.

65 3.4. REAL-TIME STATECHART 43 State1 [g1] / {a1} region2 State2 2 [g2] / {a2} State3 State2a State2b region1 1 State2c State2d region2 State2 [g2] 2 State1 [g1] / {a1} State2a State2b [g2] / {a2} State3 region1 1 State2c State2d (a) Incoming/Outgoing Composite Transitions region2 State2 2 State2a State2b region1 1 [g3] / {a3} State2c State2d State2 region2 [g3] / {a3} State2a State2b [g3] 2 region1 1 State2c State2d (b) Incoming and Outgoing Composite Transition Figure 3.22.: Composite Transitions as Shorthand Notation

66 44 CHAPTER 3. MODELING LANGUAGE Syntactic Restrictions Although state connection points (i.e., entry or exit points) act as source or target of transitions, a system may not reside in a state connection point (as opposed to a state). Hence, a chain of transitions with intermediate connection points is considered as a single transition step. As a consequence, a particular transition leading to a state connection point only represents a leading part of an entire transition step and is therefore restricted to not involve any effects like action, raise message, or clock resets. In addition, a transition leading to a state connection point must not specify deadlines. Analogously, a particular transition originating from a state connection point only represents a trailing part of an entire transition step. Therefore, it is restricted to not involve any conditions like guard, trigger message, synchronization, or clock constraints Conditions If the source of a transition is a state, the developer may specify additional enabling conditions. All of them must be fulfilled in order to fire the transition. As a crucial prerequisite for the enabling, the source state must be active. We describe the additional enabling conditions below: Guard A guard is a boolean expression that restricts the enabling of a transition to specific variable values. If a transition specifies a guard, it may only be enabled if the guard evaluates to true. Guards are expressions without side effects, specified using the action language described in Section The guard expression may refer to all variables and operations inside the transition s statechart or one of its direct or indirect parent statecharts. Clock Constraint A clock constraint is a boolean expression that restricts the enabling of a transition to specific clock values. We refer to Section for a general description of clock constraints. A transition may specify an arbitrary number of clock constraint. All of them must hold at the same time in order to enable the transition. A transition may refer to all clocks defined in a direct or indirect parent statechart. Synchronization A synchronization causes a transition to fire only in combination with another transition that belongs to an orthogonal Real-Time Statechart. In order to associate transitions, every synchronization refers to a particular synchronization channel. Two transitions may only synchronize if their synchronizations refer to the same channel. In addition, their synchronizations must specify a complementary synchronization kind: there must be a unique sender transition denoted by! and a complementary receiver transition denoted by?. Optionally, a synchronization comprises a selector expression, which restricts synchronization

67 3.4. REAL-TIME STATECHART 45 to take place only between two transitions for which the evaluation results of the selector expressions are equal. We refer to Section for a detailed description of synchronization. Trigger Message A transition that specifies a trigger message may only be enabled if a message of a particular type has been received by the associated role (cf. Section 3.3.2) or discrete port (cf. Section ). We describe message types in Section 3.2. The respective message must be available from the buffer for received messages. We refer to Section for a detailed explanation of message buffers. Section illustrates the exchange of asynchronous messages in general. Priority The priority of a transition is represented by a fixed natural number greater than 0, whereas a larger number indicates a higher priority. If the enabling conditions described above apply to more than one transition within the same Real-Time Statechart, we consider only the transition as enabled which has got the highest priority Urgency If an urgent transition fires, it does so immediately when it is enabled, i.e., no time passes between enabling and firing. In contrast, a non-urgent transition may postpone the firing even if it is enabled. Consequently, it may also become disabled again, especially due to another transition with a higher priority becoming enabled. In MECHATRONICUML, nonurgent transitions enable the modeling of uncertain situations in which the firing of a transition is beyond the developer s control. Verification techniques such as UPPAAL model checking are required to resolve the above non-determinism by considering all possible points in time at which the transition may fire. In addition, urgent transitions have precedence over non-urgent transitions, i.e., as long as an urgent transition is enabled, no non-urgent transition may fire. If two transitions synchronize via a synchronization channel, then they only fire urgently if both transitions are urgent Effects If an enabled transition fires, it may involve specific effects. In Section , we define the execution order for the different types of effects described below: Action If a transition specifies an action, the firing causes its execution. On execution, the action may manipulate dedicated variables, or call dedicated operations, defined in a direct or indirect parent statechart. We refer to Section for further details on actions.

68 46 CHAPTER 3. MODELING LANGUAGE Raise Message A transition that specifies a raise message will generate and release a message of the specified type if it fires. This implies that the message is sent over a connector attached to the associated role or discrete port. If the message type has parameters, the raise message comprises additional parameter bindings given in terms of expressions. We refer to Section for details on the exchange of asynchronous messages. Clock Reset A firing transition may cause resets for one or more clocks which reside in a direct or indirect parent statechart. We describe the general concept of clock resets in Section Deadlines Real-Time Statecharts are not restricted to the assumption that transitions fire without consuming time [Lee09]. A typical reason for time-consuming transitions is the execution of effects as described in Section Consequently, deadlines may be attached to a transition in order to define a time interval in which the firing needs to be finished. We distinguish between relative and absolute deadlines. A transition may either specify one relative deadline, or an arbitrary number of absolute deadlines. If there is no deadline, a transition is considered to fire without consuming additional time. Relative Deadline A relative deadline defines the interval where the firing of a transition needs to be finished relatively to the point in time when the firing started. The lower bound specifies the minimum time the transition may take to fire and the upper bound specifies the maximum time it may take. Absolute Deadline An absolute deadline defines an interval for the values of a specific clock, in which the firing of the associated transition needs to be finished. The lower bound defines the minimum clock value at which the firing must terminate. The upper bound defines the maximum clock value accordingly. Concrete Syntax of a Transition A transition is drawn as a line with an open arrowhead. A solid line depicts an urgent transition, whereas non-urgent transitions use a dashed line. The arrow originates at the border of a source vertex and ends at the border of a target vertex. The priority value is displayed within a circle at the origin of the transition. If the source is not a state, the transition s priority is of no semantic relevance and is therefore omitted. Elements annotated to a transition are visualized within a transitionlabel that splits into a conditionlabel, a slash, and a effectlabel. The only exception is the definition of a deadline for which a special deadlinelabel is used. Figure 3.23 shows a template for the transition syntax.

69 3.4. REAL-TIME STATECHART 47 transition priority transition label urgent transition source vertex <conditionlabel> / <effectlabel> 1 <deadlinelabel> 2 <conditionlabel> / <effectlabel> <deadlinelabel> non-urgent transition Figure 3.23.: Concrete Syntax Template of a Transition target vertex The following EBNF grammar defines the default notation for a transitionlabel. Elements which have the prefix # are references to the meta model elements of class Transition: < t r a n s i t i o n L a b e l > = [ < c o n d i t i o n L a b e l > ] [ / < e f f e c t L a b e l > ] ; < c o n d i t i o n L a b e l > = [ < c l C o n s t r a i n t s >][ < guard >][ < r e c e i v e r M e s s a g e >][ < sync > ] ; < c l C o n s t r a i n t s > = [ < c l o c k C o n s t r a i n t > [, < c l o c k C o n s t r a i n t > ] ] ; <guard > = [ # guard ] ; < r e c e i v e r M e s s a g e > = # r e c e i v e r M e s s a g e T y p e. name ; <sync > = < r e c e i v e d S y n c > < sentsync >; < r e c e i v e d S y n c > = syncexpr? ; < sentsync > = syncexpr! ; <syncexpr > = # s y n c h r o n i z a t i o n. name [ [ # s e l e c t o r E x p r e s s i o n ] ] ; < e f f e c t L a b e l > = [ < a c t i o n >] [ < sendermessage >] [ < c l o c k R e s e t s > ] ; < a c t i o n > = { (# t r a n s i t i o n A c t i o n. e x p r e s s i o n s # t r a n s i t i o n A c t i o n. name ) } ; <sendermessage > = # sendermessagetype. name [ ( < p a r a m e t e r L i s t > ) ] ; < p a r a m e t e r L i s t > = # p a r a m e t e r V a l u e [, # p a r a m e t e r V a l u e ] ; The following EBNF grammar defines the default notation for a deadlinelabel. Elements which have the prefix # are references to the meta model elements of class Transition: < d e a d l i n e L a b e l > = [ < r e l D e a d l i n e L a b e l >] [ < a b s D e a d l i n e L a b e l >] ; < r e l D e a d l i n e L a b e l > = [ # r e l a t i v e D e a d l i n e. lowerbound. v a l u e ; # r e l a t i v e D e a d l i n e. upperbound. v a l u e ] ; < a b s D e a d l i n e L a b e l > = # a b s o l u t e D e a d l i n e. c l o c k. name [ # a b s o l u t e D e a d l i n e. lowerbound. v a l u e ; # a b s o l u t e D e a d l i n e. upperbound. v a l u e ] ; Figure 3.24 shows an example of an urgent transition. The condition label defines (i) a clock constraint that clock c1 must be smaller or equal to 10, (ii) restricts the integer variable i to a value less than 5, (iii) a message of type msg1 being be at the head of the associated message buffer, and finally (iv) that another transition with a complementary sent synchronization over channel ch1 must be able to fire. For synchronizing, the selector expression must evaluate to

70 48 CHAPTER 3. MODELING LANGUAGE 5 (we refer to the forthcoming Section for details on synchronizations with selector). The effect label comprises (i) an increment of variable i, (ii) the sending of a message with type m2 and parameter value i, and (iii) the reset of clock c0 to zero. The deadline label comprises an absolute deadline which states that the value of clock c1 must be between 5 and 15 seconds when the firing finishes. clock constraint guard trigger synchronization with message selector expression State1 1 [c1<=10] [i<5] msg1 ch1[5]? / {i++;} m2(i) {reset: c0} action raised message with parameter value clock reset c1 [5s;15s] absolute deadline State2 Figure 3.24.: Concrete Syntax Example of a Transition State Connection Point The activation and deactivation of composite states via composite transitions faces certain limitations. On activation of a composite state using an incoming composite transition, all embedded statecharts are activated by setting their initial states active. Thus, there is only one possible initial configuration of active substates, regardless of which transition causes the activation. As an example, the composite state State2 in Figure 3.25 can be entered via State0 or State1. However, in both cases, the internal start configuration corresponds to the initial substates State2a and State2c. region1 State2 2 State0 State2a State2b State3 State1 region2 1 State2c State2d Figure 3.25.: Activation and Deactivation via Composite Transitions On deactivation of a composite state using an outgoing composite transition, all embedded statecharts are deactivated as well. The deactivation is independent from the internal state configuration, i.e., the combination of currently active substates. In Figure 3.25, State2 can

71 3.4. REAL-TIME STATECHART 49 be deactivated by firing the transition to State3 independently from the currently active states in region1 and region2. To overcome the above limitations, Real-Time Statecharts support state connection points for composite states. Each state connection point of a particular composite state has a unique name. State connection points enable chaining of transitions between different hierarchy levels, enabling more flexible activation and deactivation of composite states. For these purposes, we distinguish between entry and exit points similar to the UML. Both variants are shown in Figure region1 State2 2 State0 State2a State2b State3 State1 region2 1 State2c State2d Figure 3.26.: Usage of Entry and Exit Points Entry Point An entry point of a composite state serves as target for transitions activating the composite state by means of a specific initial configuration of active substates. In order to do so, an entry point specifies exactly one outgoing transition to each embedded statechart. A firing transition leading to an entry point activates a specific state in each embedded statechart according to the entry point s outgoing transitions. This results in a specific initial state configuration, which usually differs from the default set of initial states. Especially, in case of an orthogonal composite state with more than one region, an entry point forks the control flow and activates a specific combination of substates. For example, the transition leading from State0 to the entry point of State2 in Figure 3.26 corresponds to an activation of the substates State2a and State2d, which differs from the default initial configuration consisting of State2a and State2c. Although multiple transitions are involved, activating a composite state via an entry point is carried out as an atomic step, i.e., the composite state and the substates are activated altogether. To avoid superflous entry points, there must be at least one incoming transition to the entry point. Concrete Syntax of an Entry Point We depict an entry point by means of a small circle on the border of a composite state. As illustrated in Figure 3.27, the name of an entry point is not part of the concrete syntax.

72 50 CHAPTER 3. MODELING LANGUAGE State1 Figure 3.27.: Concrete Syntax Example of an Entry Point Exit Point An exit point of a composite state serves as source for transitions deactivating the composite state, provided a specific final state configuration. The deactivating transition originating from the exit point can only fire, if the currently active states in all embedded statecharts have an enabled transition leading to the exit point. Hence, in case of an orthogonal composite state with more than one region, an exit point joins the control flow of all embedded statecharts, before deactivating the composite state. For example, the transition leading to State3 in Figure 3.26 can only fire and deactivate State2 if the substates State2b and State2d are active. Although multiple transitions are involved, deactivating a composite state via an exit point is carried out as an atomic step, i.e., the substates and the composite state are deactivated altogether. Obviously, to avoid exit points with outgoing transitions that can never fire, each embedded statechart must connect to each exit point at least once. Concrete Syntax of an Exit Point We depict an exit point by means of a small circle on the border of a composite state. In contrast to an entry point, the circle is supplemented by a cross as depicted in Figure The name of an exit point is not part of the concrete syntax. State1 Figure 3.28.: Concrete Syntax Example of an Exit Point Effect An effect defines an executable behavior that is part of a state or a transition inside a Real-Time Statechart. We distinguish the following effect types: executing actions (cf. Section 3.4.6),

73 3.4. REAL-TIME STATECHART 51 resetting clocks (cf. Section ), sending asynchronous messages (cf. Section 3.4.9), and consuming asynchronous messages (cf. Section 3.4.9). Depending on the concrete modeling element that defines a particular effect, not all effect types are available. For example, the effect of an entry event may only execute actions and reset clocks, but may not send an asynchronous message. Concerning execution semantics, an effect can be neither canceled nor interrupted. Moreover, the execution of an effect is synchronous, i.e., the Real-Time Statechart execution does not continue until the effect execution is done. The types of an effect are executed in a strict order. This order is defined separately for each Real-Time Statechart modeling element that may define effects Action A developer may define actions that execute a behavior, e.g., to manipulate the values of variables (cf. Section 3.4.7). An action has a fixed name and contains an ordered list of arbitrary implementation expressions. For example, an implementation expression may be a block of the action language (cf. Section 3.5) or a reconfiguration rule (cf. Section ). An action may only be part of an effect (cf. Section 3.4.5). Regarding the execution semantics, we currently assume that an action can neither be canceled nor interrupted. Moreover, expressions are executed according to the ordered list they are contained. Concrete Syntax of an Action We encapsulate an action within curly brackets. There are two possibilities to visualize an action: (i) we show the name of the action, or (ii) we directly show the expressions of the action, e.g., using our action language (cf. Section 3.5) Variable A variable is a storage location with a unique name that is used to reference the stored value. A variable is defined within a Real-Time Statechart. The value of a variable may be manipulated by an action (cf. Section 3.4.6). The scope of a variable is the Real-Time Statechart that defines the variable and all embedded statecharts. A variable has a fixed data type that restricts its possible values. All data types of MECHATRONICUML (cf. Section 3.1) are available as variable data types. Optionally, the developer can define an initial value for a variable. We define the initial value using an expression from our action language (cf. Section 3.5). Moreover, a variable may be a constant, i.e. it must have an initial value and this value may not change at runtime. Concrete Syntax of a Variable The following EBNF grammar variabledefinition specifies the default notation for defining a variable. Elements which have the prefix # are references to the meta model elements of class Variable:

74 52 CHAPTER 3. MODELING LANGUAGE < v a r i a b l e D e f i n i t i o n > = [ c o n s t ] # datatype #name [ := # i n i t i a l i z e E x p r e s s i o n ] ; The keyword const is shown if the variable is a constant. An exemplary variable definition is const int i := Operation An operation is a callable behavioral feature of a Real-Time Statechart that encapsulates an implementation. The definition of an operation consists of a signature and its implementation. An operation is callable from the Real-Time Statechart that defines it and from all embedded statecharts of this statechart. Only an action s implementation (cf. Section 3.4.6) may call an operation. The operation signature consists of the name of the operation, an ordered set of input parameters, and one return type. All operations of a Real-Time Statechart must have unique names. Each input parameter is defined by a data type and a name which uniquely identifies the parameter in the set of parameters of an operation. Moreover, the return type is also defined by a data type. All available data types of MECHATRONICUML (cf. Section 3.1) are valid return data types, whereas a parameter must not be of type void. Like actions, the implementation of an operation is defined by an expression using our action language (cf. Section 3.5.5). In future versions of this document, we will also enable to specify operations by means of story diagrams [FNTZ00a, vdhp + 12] that combine UML Activity Diagrams [Gro10b] and graph rewrite rules [Roz97]. Concrete Syntax of an Operation Signature The following EBNF grammar defines the default notation for a operationsignature. Elements which have the prefix # are references to the meta model elements of class Operation: < o p e r a t i o n S i g n a t u r e > = # r e t u r n T y p e #name ( < o p e r a t i o n P a r a m > [, < o p e r a t i o n P a r a m >] ) ; < o p e r a t i o n P a r a m > = # p a r a m e t e r s [ i ]. t y p e # p a r a m e t e r s [ i ]. name ; An exemplary operation definition is int operation1 ( int i, int j ). The action language (cf. Section 3.5) defines a concrete syntax for implementing an operation (cf. Section 3.5.5) and calling an operation (cf. Section 3.5.4) Asynchronous Messages Exchange Messages enable the asynchronous communication between two discrete interaction endpoints that are assembled by means of a connector. A discrete interaction endpoint either corresponds to the role of a Real-Time Coordination Protocol (cf. Section 3.3.2) or to a discrete port (cf. Section ) that refines a role s behavior. Each discrete interaction endpoint refers to

75 3.4. REAL-TIME STATECHART 53 specific message types (cf. Section 3.2) that it may send or receive. In addition, it may declare an arbitrary number of message buffers to store received messages. In MECHATRONICUML, we use Real-Time Statecharts to specify the behavior of discrete interaction endpoints. In particular, to control the sending and receiving of asynchronous messages, the transitions inside Real-Time Statecharts may specify raise messages and trigger messages Raise Message A raise message is one of the possible effects when firing a transition. Thus, if the transition fires, a message of a specified type is sent via the associated discrete interaction endpoint, and transferred over an attached connector. After successful transmission, the message is stored into an associated message buffer of the receiving discrete interaction endpoint. A message type may specify parameter types for transferring additional information from the sender to the receiver of a message. Thus, the developer can specify for each parameter of a raise message an expression that defines the parameter binding. For example, the action language (cf. Section 3.5) enables to define parameter binding expressions. A transition that raises a parametrized message binds concrete values to the parameters by evaluating the parameter binding expression. After successful transmission, the concrete parameter values are accessible to the receiver of the message Trigger Message A trigger message is one of the conditions for enabling a transition. A transition may only be enabled if the defined trigger message of the specified type is available in a message buffer of the associated discrete interaction endpoint. This implies that a message of the specified type has been successfully transferred over the connector and stored in the associated message buffer. We refer to Section for details on message buffers. If a transition specifies a trigger message, it consumes the respective message when firing, i.e., it removes this message from the respective message buffer. As a consequence, every message may only be consumed by one firing transition. The firing transition may also access the message s parameters. More precisely, the concrete parameter values may be processed inside the transition action, and may be used to specify the concrete parameter values for the transition s own raise message. For example, using the action language (cf. Section 3.5), the developer can access the parameter values Synchronization A common use case when modeling orthogonal composite states is to allow two statecharts (embedded in orthogonal regions) to change their state only in an atomic way. Therefore, in MECHATRONICUML, a developer may constraint that a transition may not fire alone, but only

76 54 CHAPTER 3. MODELING LANGUAGE with a second transition of another orthogonal Real-Time Statechart. We call such a constraint a synchronization. For defining a synchronization, the developer has to specify a synchronization channel at an orthogonal state. This state must be a common ancestor state of the orthogonal Real-Time Statecharts that embed the transitions that shall synchronize (cf. Section 3.4.2). Per orthogonal composite state, the developer may define more than one channel. For distinguishing channels, each channel has name. If a synchronization channel is defined, the developer can specify a synchronization by adding the channel to the condition part of the transitions. Additionally, the developer has to define the firing order of the two transition that shall synchronize. For doing this, the developer has to define the synchronization kind for each transition. The transition that shall fire first, must be of kind sender (we call it the sender transition); the transition that shall fire afterwards, must be of kind receiver (we call it the receiver transition). Thus, two transitions that shall synchronize must specify a complementary synchronization kind. Noteworthy, we allow only one synchronization channel (receiving or sending) per transition. Optionally, a synchronization comprises a selector, which restricts synchronization to take place only between two transitions for which the evaluation results of the selector s expressions are equal (cf. Section ). Thus, we distinguish between plain synchronization (synchronizations without selector) and synchronization with selector. Applying synchronization may change the prioritization and execution order of orthogonal Real-Time Statecharts. We define the execution semantics of synchronizations in Section Concrete Syntax of a Plain Synchronization A synchronization is part of the condition label of a transition. For a sending transition, we write the name of the channel followed by an exclamation mark (!); for a receiving transition, we write the name of the channel followed by a question mark (?). Figure 3.29 shows a concrete syntax example for a plain synchronization. The orthogonal composite state A1 defines the channel sync. This channel is used to synchronize the two transitions of the regions B and C. Thus, the transition with source state B1 is the sender transition and the transition with the source state C1 is the receiver transition Synchronization with Selector A synchronization with selector extends a plain synchronization by an additional condition for the firing. Selectors are a generalization of UPPAAL s synchronization channel arrays, which essentially are ordinary arrays containing synchronization channels [BDL04]. In the case of using a selector, the synchronization channel defines a type for the selector. Then, each synchronization using this synchronization channel needs to provide a selector expression that resolves to this type. In addition to the conditions for synchronization as defined for plain synchronization in the previous section, synchronizations with selectors may

77 3.4. REAL-TIME STATECHART 55 A1 channel sync B 2 sync! B1 B2 C 1 sync? C1 C2 Figure 3.29.: Concrete Syntax Example for a Plain Synchronization only synchronize if both, the sending and the receiving synchronization, provide the same value in their selector expression. In general, we support the selector expressions of types Boolean and Integer. In case of multi roles, we also support to use selector expressions of type Role and Port as explained in Section Using the selector type Integer, we can model UPPAAL s synchronization arrays. As mentioned before, a synchronization channel array of a given size is an ordinary array whose elements are synchronization channels. Concrete Syntax of a Synchronization with Selector The concrete syntax of a synchronization with a selector extends the concrete syntax of a plain synchronization. If a selector type is defined for a synchronization channel, then we write the type in square brackets after the name of the channel. For example, Figure 3.30 shows a Real-Time Statechart that has one state A1 and a variable i of type int with the initial value zero. The state A1 defines a synchronization channel named sync with the selector type Int. A specific synchronization channel can be used by specifying an integer expression in square bracket just like the selector expression used in Figure In contrast to UPPAAL, however, our specification does not require to specify a number of channels as an array size, because we only use one channel with a condition that may use arbitrary integers Execution Semantics of Synchronizations In contrast to older publications, the synchronizing transitions do not get the minimum (absolute) priority of both (cf. [GB03, p. 18]). Instead a synchronization affects the prioritization and execution order of orthogonal Real-Time Statecharts as described in the following.