Transparent Uppaal-based Verification of MechatronicUML Models. Christopher Gerking

Transcription

1 Transparent Uppaal-based Verification of MechatronicUML Models by Christopher Gerking

2

3 Fakultät für Elektrotechnik, Informatik und Mathematik Heinz Nixdorf Institut und Institut für Informatik Fachgebiet Softwaretechnik Zukunftsmeile Paderborn Transparent Uppaal-based Verification of MechatronicUML Models Master s Thesis Submitted to the Software Engineering Research Group in Partial Fulfillment of the Requirements for the Degree of Master of Science by Christopher Gerking Grevestraße Paderborn Thesis Supervisor: Prof. Dr. Wilhelm Schäfer and Prof. Dr. Gregor Engels Paderborn, May 2013

4

5 Declaration (Translation from German) I hereby declare that I prepared this thesis entirely on my own and have not used outside sources without declaration in the text. Any concepts or quotations applicable to these sources are clearly attributed to them. This thesis has not been submitted in the same or substantially similar version, not even in part, to any other authority for grading and has not been published elsewhere. Original Declaration Text in German: Erklärung Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen, die wörtlich oder sinngemäß übernommen worden sind, sind als solche gekennzeichnet. City, Date Signature v

6

7 Contents 1 Introduction Problem Objective Approach Structure Basics Model-Driven Software Development Timed Automata Temporal Logic Timed Model Checking MechatronicUML Goal Question Metric Related Work Transforming MechatronicUML to External Formalisms Transforming External Formalisms to Uppaal Transparent Verification Interim Conclusion MechatronicUML to Uppaal Transformation Overview Normalization of Deadlines Normalization of Composite Transitions Normalization of Hierarchical States MechatronicUML to Uppaal Migration Uppaal to MechatronicUML Trace Transformation Traces Requirements Transformation Approach Modeling Uppaal Concrete Traces Real-Time Statechart Zone Graphs Inverse Resolution of Traceability Links Clock Valuations and Variable Bindings Asynchronous Message Exchange vii

8 Contents 6 Implementation Meta-Modeling Model-To-Model Transformation Model-to-Text Transformation Parsing Visualization Evaluation Definition Data Collection Interpretation Threats to Validity Conclusion Summary Insights Outlook A Trace Visualization 119 B CD Contents 121 Bibliography 123 viii

9 List of Figures 1.1 Vehicle-to-Vehicle Communication in an Overtaking Scenario MechatronicUML Component Instance Configuration Transformation Approach between MechatronicUML and Uppaal Timed Automaton Uppaal Timed Automata Hierarchical Timed Automaton MechatronicUML Vehicle Component MechatronicUML Component Instance Configuration MechatronicUML Coordination Protocol MechatronicUML Real-Time Statechart Relative Deadline Inside a Real-Time Statechart Entry-Action Inside a Real-Time Statechart Entry-/ and Exit-Point Inside a Real-Time Statechart Asynchronous Message Exchange Automata for hugo/rt CIF Transformation Approach [BCN + 09] Overtaking Coordination Protocol Role Real-Time Statecharts Different Verification Use Cases Action Steps of the Transformation from MechatronicUML to Uppaal Schematic Representation of the Normalization Step for Deadlines Normalization of Deadlines Schematic Representation of the Normalization Step for Composite Transitions Normalization of Composite Transitions Schematic Representation of the Normalization Step for Hierarchical States Normalization of Hierarchical States Normalization of Hierarchical States Join Trees of Composite State noovertaking Bundled Representation of the Flattened Real-Time Statecharts Uppaal Network of Timed Automata Meta-Model Uppaal Timed Automata Templates Representation of Clock Instances Representation of Operations ix

10 List of Figures 4.18 Different Approaches of Representing Asynchronous Message Exchange Transmission Time Clocks Dispatching an Asynchronous Message inside an Uppaal Template Generic Asynchronous Message Exchange Template Consuming an Asynchronous Message inside an Uppaal Template Asynchronous Message Exchange Runtime Example Uppaal Overtaking Snapshot Action Steps of the MechatronicUML Trace Generation Snapshot inside an Uppaal Trace Uppaal Trace Meta-Model Real-Time Statechart Snapshot inside a Linear Zone Graph Real-Time Statechart Zone Graph Meta-Model Inverse Resolution of Traceability Links Reproduction of Uppaal Traces by Real-Time Statechart Zone Graphs Action Steps of the Verification and Associated Technologies Meta-Model Dependencies Model-to-Model Transformation Structure Case Study Real-Time Statecharts Exemplary Non-Progressive Snapshot Exemplary Incomplete Trace Snapshot A.1 Liveness Trace Visualized by Graphviz x

11 List of Tables 7.1 Case Study Models Verification Properties Refinement of the Semantics Preservation Goal for the MechatronicUML to Uppaal Transformation Refinement of the Semantics Preservation Goal for the Uppaal to MechatronicUML Trace Transformation Data Collection Hypotheses and Results xi

12

13 1 Introduction Nowadays, software is ubiquitous in mechatronic systems like cars or other vehicles. It realizes the information processing in complex control loops involving sensor and actuator technology. We are faced with the environmental impacts of software in terms of comfort functions related to information, entertainment, and safety. Impressive indicators for today s role of software in automotive systems are numbers like 100 electronic control units per car [EZK + 13], running one gigabyte of software [PBKS07] with 100 million lines of code [Mös10] in order to provide up to 2000 individual functions [Bro06]. 90 percent of today s innovations in the automotive industry stem from electronics including software [HMG11]. Due to the inherent connection of mechatronic systems to real-world physical processes, software systems face hard real-time requirements, i.e. software must react to external stimuli within specific time bounds. Along with the exponential rise of software in the automotive industry [PBKS07], the consequences of unsatisfied real-time requirements tend to be increasingly drastic. To avoid costs from contractual penalties, or even loss of human life, safety-critical computer systems require the guaranteed absence of errors in the software they are running [Sto96]. A plain testing of systems under certain selected conditions is therefore inappropriate in the domain of mechatronics. Instead, there is a pressing need for reliable verification techniques that cover the entire real-time behavior under all possible conditions. Beside the ongoing trend towards real-time computing, today s systems are increasingly distributed and networked. An amount of 2500 signals [Alb04] exchanged on top of five bus systems per car [Bro06] gives evidence for the rising importance of interaction. However, this trend is not limited to single systems, but involves an increasing information exchange between different autonomous systems for coordination purposes [SW07]. Hence, such networked systems act as systems of systems [Luk98]. Overcoming the dynamic structure of the underlying ad-hoc communication networks, the interaction tends to be carried out by an asynchronous exchange of discrete messages [SS11], controlled by state-based software. As an example, Figure 1.1 illustrates the approach of vehicle-to-vehicle communication for an increased safety in overtaking situations. Safe overtaking is always limited in time and therefore involves hard real-time requirements. Coordination over message exchange protocols can prevent a sudden acceleration of an overtaken vehicle, alleviating a serious safety hazard. Whereas safety is among the key functions that software addresses in today s systems, the rising software complexity poses huge challenges with respect to guaranteed safety. The combination of complex designs and guaranteed safety is a key challenge to mechatronic systems and requires consideration at an early stage of the development 1

14 1. Introduction Figure 1.1: Vehicle-to-Vehicle Communication in an Overtaking Scenario process. Model-driven design [Sch06] is a promising approach towards this combination. Relying on reusable models as abstract domain-specific design elements, the manageability of the overall design improves drastically. In addition, due to the formal characteristics of models, formal verification techniques are applicable to prove the compliance with specific requirements. Model checking [CGP00] is a prominent formal verification technique that operates on the model level, exhaustively hedging a system against corner case design errors. To enable formal verification techniques like model checking and improve the overall design manageability, the MechatronicUML design method [EHH + 13; BBB + 12] proposes a model-driven approach to the construction of networked mechatronic systems. MechatronicUML provides modeling support for component-based software systems [Szy98] involving real-time coordination behavior. Figure 1.2 shows two MechatronicUML component instances representing networked vehicles. Connected for message exchange, the component ports specify a real-time coordination behavior that implements a dedicated message exchange protocol for safe overtaking scenarios. The state-based port behavior is specified using so called Real-Time Statecharts, a combination of state machines [OMG11c] provided by the Unified Modeling Language (UML) and timed automata [AD90]. The Real-Time Statecharts ensure that the overtaken front vehicle refrains from acceleration during overtaking by the rear vehicle. Along with this crucial safety challenge, the protocol also faces the requirements of deadlock freedom and to properly enable the overtaking. Figure 1.2 also illustrates these requirements in terms of formalized properties attached to the coordination protocol. 1.1 Problem Existing tool-support for model checking is nowadays limited to general-purpose specification techniques for the system under consideration, relying on low-level modeling formalisms. The result is a significant semantic gap between domain-specific languages like MechatronicUML on the one hand, and verification formalisms on the other hand. For instance, concepts like the hierarchical composition of components and the asynchronous exchange of messages are unknown to most verification formalisms. To bridge the semantic gap, engineers are required to leave familiar domain concepts behind and bother with low-level verification formalisms to encode system 2

15 1.1 Problem A[] not deadlock A[] rear.overtaking implies front.noacceleration E<> rear.overtaking :Overtaking :rear :front v1 : Vehicle rear front v2 : Vehicle Figure 1.2: MechatronicUML Component Instance Configuration behavior manually. The results are drawbacks like the huge manual effort in combination with increased development times, and also the possibility for undetected deficiencies resulting from an erroneous encoding of the system behavior. Beside the crucial task of proving the absence of errors, model checking tools also aim at providing diagnostic user feedback along with the identification of an existing error. The diagnostics usually comprise a counter-example of the system behavior with respect to the verified requirement. Obviously, presented counter-examples are based on the underlying verification formalism and are therefore of little avail for domain engineers. Even if an engineer successfully bridges the semantic gap from the domain-specific language to the verification formalism, he is likely to stumble over the additional challenge of interpreting the counter-example against the original domainspecific design model. This manual interpretation is not only complex but error-prone, and therefore still suffers from problems like increased development times or undetected design deficiencies. As a remedy to the problematic integration of domain-specific modeling and formal verification, in the year 2004, Hirsch [Hir04] connected Real-Time Statecharts to the Uppaal 1 tool environment [BLL + 96] by prototyping an automatic transformation. Uppaal is a state-of-the-art model checker that enables formal verification for systems affected by real-time requirements. Apart from incompatibility problems with evolved MechatronicUML versions, the transformation lacks important concepts like quality-of-service assumptions with respect to the asynchronous interaction, like message delay or loss. Hence, a vast range of real-world circumstances remains unconsidered by this verification approach. As another major disadvantage, the approach is restricted to the connection from domain-specific models to verification formalism, but puts the burden of interpreting counter-examples into the opposite direction on the domain engineer. Hence, the diagnostic capabilities of the Uppaal integration by Hirsch [Hir04] face serious limitations with respect to the cause study for counterexamples

16 1. Introduction 1.2 Objective The objective of this thesis is to integrate the Uppaal model checker with MechatronicUML in a transparent way. Transparency refers to the option for MechatronicUML domain engineers to remain unaware of the formal verification details, still obtaining accurate and meaningful verification results including counter-examples. We focus on redesigning the transformation approach by Hirsch [Hir04] for today s state of the MechatronicUML design method. In addition, we explicitly address the presentation of counter-examples at the MechatronicUML level, saving domain engineers from the need for a manual interpretation of formal verification details against domain-specific concepts. We therefore alleviate the necessity to make contact with the underlying verification formalism at all, and therefore prevent engineers from the need to understand how the formalism relates to domain-specific concepts. A well-structured evaluation will enable conclusions with respect to the goal of semantics preservation for our connections between MechatronicUML and Uppaal. By improving the analyzability of MechatronicUML-based models on top of a transparent Uppaal model checking, the overall goal of this thesis is to promote the maturity of end products in the context of the MechatronicUML design method. 1.3 Approach This thesis tackles the problems described in Section 1.1 by enabling Uppaal-based model checking for MechatronicUML in a transparent way. Similar to Hirsch [Hir04], we aim at a model transformation that automatically converts MechatronicUMLbased system models to a format suitable for offhand verification by Uppaal, as depicted in Figure 1.3. A transparent integration of Uppaal into MechatronicUML requires a certain accuracy of the verification results, i.e. the transformation should preserve the semantics of the initial MechatronicUML-based design model. The seamless Uppaal interoperability will comprise a chain of numerous transformation steps, conceptually aligning the formalisms step by step. The transformation from MechatronicUML towards Uppaal gives rise to an automatic model checking. Counter-examples generated by Uppaal have the form of a trace, i.e. a sequence of behavioral runtime snapshots towards the violation of a specified requirement. In order to establish transparency of the verification from the viewpoint of MechatronicUML domain engineers, our approach is to align the traces with the original MechatronicUML language elements. We therefore introduce a second transformation for traces back towards MechatronicUML, as also shown in Figure 1.3. We address this transformation challenge by resolving Uppaal-specific trace elements towards their corresponding MechatronicUML elements in the original design model, generating a trace representation which is familiar to the domain engineer. As an obvious prerequisite for this strategy, we have to ensure traceability of the initial transformation from MechatronicUML towards Uppaal. 4

17 1.4 Structure System Model Counter-Example Trace Figure 1.3: Transformation Approach between MechatronicUML and Uppaal We will obtain meaningful conclusions from our approach by systematically evaluating the semantics preservation, which is a key aspect for the construction of the entire transformation approach. We refer to a standardized and well-understood evaluation technique in the field of software engineering in terms of the Goal Question Metric (GQM) approach [BW84]. Due to its well-defined composition and field-tested concepts, GQM appears to be suitable for the delivery of meaningful evaluation results, based on a systematic refinement of the relevant aspects. The evaluation will concentrate on representative MechatronicUML-based test models. 1.4 Structure The remainder of this thesis is structured as follows: Section 2 describes fundamental basics in terms of the underlying model-driven software development approach, realtime verification concepts, the MechatronicUML design method, and GQM-based evaluation. In Section 3, we study related work with respect to other transformations towards the Uppaal model checker, transformations from MechatronicUML to other verification or simulation formalisms, and also existing verification approaches addressing transparency. Section 4 describes our transformation approach from MechatronicUML towards Uppaal, whereas in Section 5, we address the challenge of resolving Uppaal traces back to the MechatronicUML level. Our implementation approach is subject to Section 6, before presenting the evaluation results in Section 7. Finally, we give concluding remarks and address topics left for future work in Section 8. 5

18

19 2 Basics This section introduces fundamental basics which are relevant in the scope of this thesis. As our basic engineering paradigm, we describe the model-driven software development approach in Section 2.1. Section 2.2 introduces timed automata as a basic modeling formalism. In Section 2.3, we address the formalization of real-time requirements. Based on the above formalisms, we capture the approach of timed model checking in Section 2.4. The MechatronicUML design method is subject to explanation in Section 2.5, whereas the final Section 2.6 captures our Goal Question Metric evaluation method. 2.1 Model-Driven Software Development The concept of a model [Sta73] refers to an abstract representation of some real-world entity. Its key concepts are listed below: Abstraction is the approach of creating an entity s representation in such a way, that it reduces to specific essential attributes, leaving out non-essential attributes of the original. Essentiality of an attribute is not given a priori, but depends on a certain intended task. Despite the abstraction of specific attributes, the pragmatics of a model with respect to this task must still be given. Pragmatics with respect to a task are ensured by retaining a certain correspondence, i.e. a model must substitute its original under specific conditions. In general, models contribute to the solution of problems. Abstraction enables simplified reasoning about problems and aids the construction of solutions. In order to establish pragmatics, the correspondence between model and its original must ensure that the solution obtained from the abstract model is also a valid solution to the original Model-Based Software Development Focusing on the domain of software engineering, challenging problems are basically concerned with the construction of software systems. Modeling software systems constitutes a prescriptive [Sta73] approach, since the original system only emerges from its abstract representation. We refer to the following definition with respect to the role of models in software engineering: 7

20 2. Basics Definition 2.1 (Model) A model is an abstract representation of a system s structure, function or behavior [SV06, p. 18]. Abstraction actually has a long tradition in software engineering, since new technologies tend to abstract from the complexity of preliminary ones. In the presence of abstraction, the problem of software construction merely corresponds to transforming an abstract software specification into a concrete software system running on a specific platform. A platform provides specific computing capabilities as a foundation for concrete software systems. As opposed to models, that basically serve for problem description, a platform is said to reside in the solution space [SV06, p. 59]. The application of the model concepts to software engineering led to the notion of model-based software development. An application implies some solution strategy to transform an abstract model into a concrete software system. Nowadays, the UML family of diagram types [OMG11c] forms the basis of most model-based software development approaches Automatization Combining model concepts with computing is quite obvious, since computers allow reasoning to be automatized. Automatization gives rise to reuse of existing solution strategies, i.e. enables the automatic construction of solutions to specific problems. In particular, this pertains to the transformation task from an abstract model to a concrete software system mentioned in Section New technologies often still rely on the proven effectiveness of their predecessors by automatically transforming abstract specifications into more concrete specifications of software systems. Consequently, we identify automatization as a key principle of model-driven software development, as opposed to approaches termed model-based. Connected to a certain platform by means of an automatic transformations, a model acts as central artifact [SV06, p. 79] in model-driven software development Domain-Specific Languages Beside the automatization aspect, approaches termed model-driven differ from modelbased techniques by a shift in the underlying domain. Definition 2.2 (Domain) A domain is a bounded field of interest or knowledge [SV06, p. 56]. Paradigms like high-level programming languages or UML [OMG11c] are still closely linked to the domain of computing as such. Although the aforementioned approaches provide software solutions for a wide range of application domains, responsible engineers are restricted to general-purpose specification techniques. We refer to the challenge of expressing domain concepts adequately by means of general-purpose languages as semantic gap. 8

21 2.1 Model-Driven Software Development In contrast, model-driven software development [SV06] focuses on the use of domainspecific languages for the specification of software systems. Hence, transformations produce concrete software solutions from domain-specific models and thus bridge the semantic gap. Schmidt [Sch06] describes the use of domain-specific modeling languages in combination with transformation engines and generators as key aspects of model-driven software development. Domain-specific languages enable the explicit specification of abstract solution strategies developed by domain experts, and also reuse of these strategies via automatic transformations. By bridging the semantic gap between specific domains on the one hand, and computing platforms on the other hand, the usage of domain-specific languages constitutes another key principle in model-driven software development Meta-Modeling In order to automatize transformations by means of computers, the specifications to be transformed must be machine-readable, i.e. formal with respect to some metaspecification. Relying on models, meta-modeling describes the approach of providing the meta-specification for models in terms of another model. This so called meta-model acts as model of a domain, including its elements and construction rules. It defines the set of valid constructable models as instances of the meta-model, i.e. sentences of a domain-specific modeling language. Hence, a meta-model gives rise to a typeinstance-relationship with models. The essential components of a meta-model are an abstract syntax, defining domain elements and construction rules, and static semantics, giving a meaning to models without considering them in some execution context 1. In the scope of a domain-specific modeling language, the above meta-model concepts are linked to at least one concrete syntax, defining how to express models in a concrete manner, and dynamic semantics, charged with semantics definition fotr models during execution Model Transformation Section emphasized the essential role of automatic transformations with respect to reuse of existing solution strategies. Stahl and Völter describe the task of transformations as to map models to the respective next level [SV06, p. 21] on the way to some platform. Hence, to solve the problem of transforming models to a platform, it 1 This definition of static semantics is in accordance with the notes of Harel and Rumpe in [HR04]. Stahl and Völter [SV06] put static semantics on a level with additional syntax constraints referred to as context conditions" [HR04, p. 65]. However, adhering to this definition would lead to the inconsistency that static semantics belong to the syntax rather than to the semantics of a language [SV06, p. 58]. 9

22 2. Basics may also be desirable to engage with existing solution strategies. This approach implies the transformation of models into other models, traversing various intermediate modeling levels on the way to a platform. Definition 2.3 (Model Transformation) Model transformations take one or more source models as input and produce one or more target models as output, while following a set of transformation rules [SK03, pp ]. Noteworthy, although the above definition describes n-way transformations [CH06] with an arbitrary number of models on both sides, it also covers the typical case of a 1:1 transformation with single source/target models. The most common scenario is an exogenous [MCG05] model transformation which carries out a change in the underlying modeling language, i.e. source and target meta-model differ. Focusing on program transformation in general, Visser addresses the same concept as translation [Vis01]. However, it is also possible to specify endogenous [MCG05] transformations where source and target meta-model are the same. Speaking in terms of Visser s program transformation terminology, the approach corresponds to a rephrasing [Vis01]. A rephrasing that reduces the amount of syntax features in use is known as normalization [Vis01]. Another specific type of rephrasing aims at an equivalent meaning of source and target models, i.e. despite syntactical differences, the semantics of the underlying modeling language assigns an equivalent meaning to both. We refer to this characteristic as semantics preservation, whereas the associated transformation approach is known as refactoring [OJ90; Opd92]. Another specific type of model rephrasing is a so called in-place transformation [CH03] where source and target model are the same, i.e. the transformation manipulates an existing model. An important distinction is made according to the way that target models are provided: Model-to-Model is the approach of providing target models in terms of their abstract syntax. Hence, a model-to-model transformation preserves the model aspect in terms of platform-independence and explicitly specified structures. Model-to-Text is the approach of providing target models in terms of some concrete textual syntax. By engaging with platform-specific text formats, a model-to-text transformation weakens the model aspect. Czarnecki and Helsen [CH06] identify a relevant quality characteristic for model transformations in terms of traceability. It refers to the ability of transformations to record a relationship between source and target model elements during execution, and provide access to these trace records later on Model-Driven Architecture The model-driven architecture (MDA) [OMG03] is a paradigm for the model-driven software development provided by the Object Management Group (OMG). Its major 10

23 2.2 Timed Automata objective is platform-independent engineering with a focus on stepwise transformations from models to platforms. MDA refines the approach of model-driven software development according to three modeling levels: The computation-independent model (CIM) corresponds to a requirements specification independent of any computational solution. The platform-independent model (PIM) gives rise to the design of a software solution, yet independent from concepts of any concrete platform. The platform-specific model (PSM) is concerned with a model-driven specification of a software solution, focusing on a specific target platform. Along with its MDA, the OMG provides a range of standards suitable for specific model-driven software development tasks: The Meta-Object Facility (MOF) [OMG11b] constitutes a general meta-model that serves for the definition of other domain-specific meta-models, i.e. it takes the role of a meta-meta-model. Noteworthy, MOF is self-explanatory in the sense that it represents its own meta-model. As an example, the meta-model of the prominent UML [OMG11c] is actually an instance of MOF. The Object Constraint Language (OCL) [OMG10] enables navigation and queries in MOF-based models. It is originally concerned with the specification of detailed syntactical constraints that models must comply with. Query/View/Transformations (QVT) [OMG11a] represents an OMG standard for model-to-model transformation. It subsumes different imperative and declarative language approaches to support model transformation between MOF-based meta-models. As an extension to OCL, the naming QVT reflects the ability to not only specify sophisticated queries on models, but also to provide alternative model views, i.e. to focus on specific meta-model aspects by means of transformations [SV06, p. 206]. 2.2 Timed Automata By involving mechanical parts, mechatronic systems interact with their environments. Sensor and actuator technology imply an interaction of systems with physical environmental processes. As a result, a mechatronic system usually meets the criteria of a so called real-time system which changes as a function of physical time [Kop97]. Hence, the environment poses certain restrictions on the time that the system requires for a reaction to environmental stimuli. These real-time requirements also affect the computing part of mechatronic systems, for which the correctness depends not only on the logical results of the computation, but also on the physical instant at which these results are produced [Kop97]. 11

24 2. Basics Focusing on a model-driven engineering of real-time systems for the purpose of formal verification against real-time requirements, an appropriate modeling formalism is required. Mechatronic systems meet the criteria of reactive systems: they are repeatedly prompted by the outside world and their role is to continuously respond to external inputs [HP85, p. 479]. Hence, approaches building on the classical finite automata formalism come into play. Finite automata are state-based in the sense that they describe a system s behavior by a sequence of inputs from an alphabet Σ, leading to state transitions within the state space S Dense-Time Model As a crucial limitation, finite automata do not consider temporal information about the occurrence of inputs, and are not capable of expressing an effect of time on the system behavior. Hence, classical finite automata are not sufficient for the modeling of real-time systems due to the lack of a concept of time. Real-time systems require a modeling concept for physical time as a continuous magnitude. Relying on a dense-time model [AD90], the time of an event occurrence is a real number τ i R. A system s behavior becomes expressible by a sequence of timed words (σ, τ), associating strictly monotonically increasing time values τ i R with the input events σ i Σ Formalism Considering real-time systems as a function of physical time [Kop97], the occurrence times of input events are of importance with respect to the system behavior. In a dense-time model, the occurrence times τ i must be considered with respect to state transitions. However, constraining a state transition by a direct comparison involving the value τ i is non-intuitive, as in most real-time applications, not the concrete time value is of importance, but rather the time elapsed since another preceding input event occurred. The timed automata formalism [AD90] extends finite automata and introduces the concept of clocks to allow this more flexible way of specifying timed behavior. A clock is a continuously increasing real-valued variable, which is, however, resettable during state transitions. A timed automaton can include a finite set of clocks that increase at the same rate from the system start. The value of a clock is always the time elapsed since its last reset, respectively since the system start if it was never reset. From the time when being reset during a state transition, a clock value represents the amount of time elapsed since this reset, which is equivalent to the time elapsed since the occurrence of a specific input event that triggered the resetting state transition. By comparing clock values with constants, a state transition can specify a clock constraint. A clock constraint expresses a temporal dependency of the state transition with respect to other past state transitions which were responsible for resetting certain clocks. A transition can only fire if its clock constraint is fulfilled, i.e. all specified clocks adopt a time value that lies within their specified intervals. The bounds 12

25 2.2 Timed Automata of intervals correspond to a rational number from the set Q, whereas this set is often restricted to N. Intervals can be left- or right-bounded, whereas the comparison operators and < enable both closed and open intervals. The original definition of timed automata [AD90] was later extended to support also clock constraints for states [AFH91], so called invariants. As an intuitive way of forcing execution progress, a system may only stay in a specific state as long as its invariant is fulfilled. A state transition is required to take place before the invariant becomes unfulfilled. For a formal definition, we refer to a version of timed automata extended by state invariants [Alu99]. Definition 2.4 (Timed Automaton) A timed automaton A is a tuple L, L 0, Σ, X, I, E, where L is a finite set of locations, L 0 L is a set of initial locations, Σ is a finite set of labels, X is a finite set of clocks, I is a mapping that labels each location s with some clock constraint in Φ(X), and E L Σ 2 X Φ(X) L is a set of switches. A switch s, a, ϕ, λ, s represents an edge from location s to location s on symbol a. ϕ is a clock constraint over X that specifies when the switch is enabled, and the set λ X gives the clocks to be reset with this switch. Figure 2.1 shows an exemplary timed automaton modeling a vehicle. After switching to the overtaking location, an invariant in combination with a guard label ensure overtaking to finish after two time units. c = 0 overtaking c <= 2 c >= 2 idle Figure 2.1: Timed Automaton 13

26 2. Basics Uppaal Timed Automata Enabling formal modeling of real-time systems, timed automata give rise to an application of formal verification techniques. The timed automata used within the realtime verification tool Uppaal are not restricted to a single timed automaton. Instead, Uppaal supports modeling of concurrent real-time systems by means of a parallel composition of timed automata. Consisting of locations and edges, timed automata in Uppaal specify a unique initial location in contrast to Definition 2.4. As a syntactic extension, Uppaal supports so called urgent locations in which no time is allowed to pass. An urgent location is equivalent to an ordinary location that resets an auxiliary clock on all its incoming edges and restricts this clock s time value to not exceed 0 as its invariant. Furthermore, Uppaal introduces another semantic extension in terms of so called committed locations, which are urgent but have strict precedence over ordinary locations with respect to the execution of outgoing edges. Although Uppaal relies on a dense-time model, it only supports the specification of integer values, which affects also clock constraints. As another extension of classical timed automata, Uppaal supports integer- or boolean-based data variables, which are also part of the overall system state space. Both clocks and data variables can be referenced as part of state invariants or guards of edges. Synchronization A network of timed automata A 1... A n is defined as the parallel composition of timed automata A i [Pet99]. The composition via the synchronization function gives rise to restrictions on the autonomous, interleaving execution of timed automata. Data variables and also clocks can be either private to a single automaton, or globally shared between all automata of a network as part of the synchronization function. Synchronization also applies to edges, since a state transition in one timed automaton may be indivisible from a second state transition in a parallel timed automaton, and vice versa. The edges may only be executed in combination and simultaneously. The synchronization function applied for Uppaal networks of timed automata is inspired by the parallel composition operator defined as part of the Calculus of Communicating Systems (CSS) [Mil89]. Unlike parallel compositions of classical timed automata [AD90], Uppaal supports point-to-point synchronization on top of the handshaking (or synchronous message passing) approach [BK08]. Hence, not all timed automata of a network are required to participate in a synchronization. Handshaking refers to a synchronizing execution of two edges in two timed automata A i and A j, which is restricted to a common input symbol σ Σ i Σ j. Based on the theory of channel systems [BK08], σ is referred to as channel 2, and the state transitions to be synchronized are distinguished between sender and receiver. The sender transition of a handshake synchronization via channel σ is labelled σ!, whereas σ? denotes the 2 Conceptually, Uppaal channels are of size zero, which enforces synchronization between sender and receiver due to the absence of buffering capacity. 14

27 2.2 Timed Automata complementary receiving transition. Figure 2.2 shows two Uppaal timed automata that synchronize in order to ensure safe overtaking. overtake! c = 0 overtaking c <= 2 overtake? c = 0 noacceleration c <= 2 c >= 2 c >= 2 idle idle (a) Rear Vehicle Automaton (b) Front Vehicle Automaton Figure 2.2: Uppaal Timed Automata In order to enable synchronization between more than two participating automata, channels can be declared as broadcasting. A timed automaton executing an edge labelled σ! synchronizes with all other timed automata that provide an edge labelled σ? outgoing from their currently active locations. Using broadcast synchronization, however, no receivers are required at all to perform the sending synchronization, i.e. the edge labelled σ! may also fire in isolation. Template Instantiation Unlike classical approaches, Uppaal distinguishes between templates for timed automata, and the actual process instantiations resulting from those templates. Only the latter ones represent a particular system at runtime. By this distinction, Uppaal provides an efficient means towards a compact modeling for systems composed of numerous equal subsystems with common attributes and behavior, differing in their parametrization only. Such systems are expressible by modeling a single timed automaton template that gives rise to multiple process instantiations, which form the actual network of timed automata. Focusing on the formal modeling of software systems, this is a prominent use case, since modern object-oriented programming relies on a similar distinction between a class and its instance objects Hierarchical Timed Automata Formalisms like timed automata encode the current situation that a system resides in by means of a single state. This technique is practical for primitive systems with a single encoded aspect. However, it leads to a drastic increase in the number of states 15

28 2. Basics and state transitions if numerous aspects require encoding in complex system models. The result is an individual state for each possible combination of relevant aspects, and also a huge number of state transitions representing each and every slight change in the overall system state. In general, this blowup is unavoidable when it comes to model checking, since all possible combinations of aspects must be explored. However, it unnecessarily complicates the modeling task, where an explicit specification of concurrency and refinement is desirable. One remedy is decoupling of autonomous behavior by modeling concurrency explicitly, as applied for Uppaal networks of timed automata. An unaddressed problem remains in terms of refinement of abstract high-level aspects by more fine-grained low-level aspects. Hierarchical modeling is a common means to increase manageability of models by considering refinement explicitly. Composition Hierarchical timed automata (HTA) are an extension to Uppaal timed automata [DM01] engaging with other modeling formalisms that support behavior refinement. Inspired by the statecharts-formalism [Har87], HTA enable the hierarchical composition of states, giving rise to a refinement via sub-states. In addition to XOR-refinement, where at most one sub-state is active, the formalism supports AND-composition. Using this kind of refinement, all sub-states are active at the same time, enabling the specification of concurrent behavior on all levels of hierarchy. The hierarchical timed automaton depicted in Figure 2.3 comprises an AND-composition of two vehicle automata, that synchronize in order to initiate an overtaking situation. active rear overtake! c = 0 noovertaking c >= 2 overtaking c <= 2 idle front overtake? c = 0 noovertaking c >= 2 noacceleration c <= 2 Figure 2.3: Hierarchical Timed Automaton 16

29 2.3 Temporal Logic To specify the control flow in case of hierarchical state refinement, HTA introduce specific pseudo-states. On the one hand, an entry serves as target for edges originating externally to a hierarchical state, providing a connection to its internal sub-states. Hence, an entry constitutes an activation of a hierarchical state and gives rise to a refinement of the control flow (forking it in case of an AND-state). The hierarchical timed automaton in Figure 2.3 comprises an entry that activates the hierarchical active location and forks the control flow. On the other hand, an exit is a designated pseudo-state that constitutes the ending of a refined control flow (which was forked in case of an AND-state). Exits act as target for edges originating internally to a hierarchical states and provide an external connection. They represent the deactivation of the parent hierarchical state and, in case of an AND-state, also the joining of the forked control flow. Flattening Considering the hierarchical composition as a reduction technique operating on the modeling level only, HTA were equipped with a flattening algorithm [DM01]. Given a single HTA, the algorithm expands the hierarchical composition to obtain a semantically equivalent network of non-hierarchical timed automata as an input to Uppaal s verification engine. Basically, the algorithm maps the contents of every hierarchical state to an individual timed automaton, extended by an additional idle location representing the case that the hierarchical state is itself inactive. Thus, the approach encodes the hierarchical composition by means of a parallel composition. 2.3 Temporal Logic Modeling reactive systems (especially real-time systems) gives rise to their verification against formally specified requirements. Along with state changes of reactive systems during execution, the truth value of certain propositions about a system varies over time. Propositional logic, which assigns a constant truth value to propositions, is therefore not capable of specifying requirements for reactive systems adequately. The application of temporal logic [RU71] for the specification of requirements aims at overcoming the limitation of constant truth values. Temporal logic considers the time dependence [Pnu77] of propositions, i.e. enables truth contents varying over time. It enables references to a proposition s future (or past) truth values and the specification of a relative order [BK08] of particular truth assignments. In doing so, temporal logic supports the specification of requirements with respect to the temporal evolution of truth content. Temporal logic formulas allow the quantification of propositions over points in time, considering their truth contents within (not necessarily bounded) time intervals. Dedicated temporal operators provide references to future truth values and quantification over these: Next: XΦ is true if the formula Φ is true in the next state. 17

30 2. Basics Globally: GΦ is true if the formula Φ is true in all future states. Future: F Φ is true if the formula Φ is true in some future state. Until: Φ 1 UΦ 2 is true if the formula Φ 1 is true in all future states before the proposition Φ 2 is eventually true in some future state. Temporal logic distinguishes between two types of expressible properties [Lam77]. On the one hand, a safety property corresponds to a formula that excludes harmful situations in all future states relying on the globally operator. A typical safety property is the restriction for an overtaken vehicle to refrain from acceleration until overtaking is terminated. On the other hand, a liveness property corresponds to a formula that requires a desired situation to occur in some future states by means of the future operator. As an example, the requirement that overtaking is possible at all corresponds to a liveness property. Two basic types of temporal logic exist, which differ according to how they handle branching in the underlying computation tree [CD88]: Linear Time Logic supports references to future truth values, without consideration of the different branches that a system may operate on. Hence, this type of temporal logic is linear in the sense that it abstracts from branching. Instead, semantics are defined in terms of all possible execution paths, abstracting from the structure of the computation tree that these paths traverse. Branching Time Logic also enables future truth value references, but additionally requires quantification over branches. Hence, this type of temporal logic explicitly considers branching as a structural property of the underlying computation tree. Consequently, its semantics operate on the structure of the computation tree itself Computation Tree Logic Uppaal s verification engine supports requirements based on the Computation Tree Logic (CTL) [EC82] which is a branching time logic. Hence, we focus on CTL specification throughout this thesis. Basically, the set of CTL formulas is an extension of propositional formulas over some set of atoms P by path quantifiers E and A, representing existential and universal quantification over paths. Definition 2.5 (CTL Syntax) CTL formulas are defined by the following grammar for state formulas Φ [EC82]: Φ ::= p Φ 1 Φ 2 Φ Eϕ Aϕ where p P and 18

31 2.3 Temporal Logic ϕ is a path formula. Path formulas ϕ are defined by the following grammar: ϕ ::= XΦ Φ 1 UΦ 2 where Φ, Φ 1, and Φ 2 are state formulas. The above definition considers the temporal operators X and U as fundamental, deriving G and F according to the following equivalences 3 : EF Φ E(true U Φ) (2.1) AF Φ A(true U Φ) (2.2) EGΦ AF Φ (2.3) AGΦ EF Φ (2.4) Our exemplary safety requirement from Section 2.3 corresponds to the CTL property AG overtaking noacceleration, where overtaking and noacceleration represent propositions from the set P. The exemplary liveness requirement can be expressed by the formula EF overtaking. Syntactically, CTL is an extension of the Linear Temporal Logic (LTL) due to the addition of path quantifiers. However, caused by the differences in terms of semantic interpretation, both types of logic are in fact incomparable with respect to their expressivity [CD88; KV98]. There is, however, a branching time temporal logic called CTL* that subsumes both CTL and LTL [EH86] Timed Computation Tree Logic Temporal logic is said to be time-abstract since it only supports the relative ordering of truth assignments over time [BK08]. In doing so, it abstracts from the concrete timing during the evolution of truth content. Hence, classical temporal logic is not capable of specifying requirements for real-time systems, where concrete time constraints underlying a dense-time model need to be expressed. As a remedy, Alur et al. proposed a real-time extension of CTL called Timed Computation Tree Logic (TCTL) [ACD90], which supports concrete time constraints for the specified relative ordering. Noteworthy, TCTL differs from CTL in terms of the missing X operator. The reason is that, due to the explicit assumption of a dense-time model, a unique next state does not exist. We refer to a version of the TCTL in which clock values can be directly referenced within formulas. The requirement that overtaking must not last longer than two time units can be expressed by referencing the clock c within the TCTL formula AG (overtaking c>2). To take full advantage of this approach, so called specification clocks represent additional auxiliary clock variables within TCTL formulas [HNSY92]. A so called freeze 3 Strictly speaking, also the combination AX is non-fundamental since it can be derived by AXΦ EX Φ. 19

32 2. Basics quantification z. of a specification clock z saves the point in time of a specified truth assignment. A frozen specification clock gives rise to time constraints referring to the frozen clock value, restricting later (or earlier) truth assignments in the clock s scope. This enables the specification of non-local requirements in the sense that they involve temporal dependencies reaching beyond one single temporal operator [AH92]. Definition 2.6 (TCTL Syntax) TCTL formulas Φ are defined by the following grammar [HNSY92]: Φ ::= p x + c y + d Φ Φ 1 Φ 2 EΦ 1 UΦ 2 AΦ 1 UΦ 2 z.φ for propositions p P, clocks x, y C, specification clocks z C φ C, and non-negative integer constants c, d N. The formalization of requirements in Uppaal is based on TCTL formulas. The temporal operators G and F correspond to the Uppaal operators [] and. As a restriction of the original TCTL syntax, Uppaal does not support nested path quantifiers, i.e. quantification over branches is limited to the root level of a formula. The only exception is Uppaal s additional - -> operator. A formula p - -> q corresponds to the formula A[] (p imply A<> q). All nested formulas are restricted to so called state properties, consisting of time and data constraints, as well as activity constraints with respect to certain locations. Time constraints are expressible by a direct reference to the value of a clock in the underlying network of timed automata. A clock local to a certain process is referenced by the statement process.clock. Uppaal does not support additional specification clocks. The activity of a certain location for a process is expressible via the statement process.location. Besides references to clocks, Uppaal also enables its data variables to be part of state properties, whereas a local variable is referenced by process.variable. As a specific feature, the deadlock statement enables the specification of execution progress requirements. In its negated form not deadlock, the statement expresses the requirement of a well-defined successor state. 2.4 Timed Model Checking Model checking [CE82] is the process of checking whether a temporal logic formula Φ is modelled by a transition system M, i.e. whether M = Φ holds. It answers the question whether the model M of a reactive system meets its specification in terms of the formula Φ. Compared against other verification approaches, key characteristics of model checking are 1.) operation on the model level rather than testing a real system, 2.) automatic conclusion rather than carrying out a manual prove, and 3.) exhaustive state space exploration rather than simulation of only some execution paths. 20

33 2.4 Timed Model Checking A basic approach towards model checking transition systems M against CTL formulas Φ was proposed by Clarke et al. [CES86]. It is carried out by labelling each state of M with the set of sub-formulas it fulfills. Starting with sub-formulas of size 1 (i.e. atomic propositions), the algorithm successively considers formulas with increasing size and derives their compliance for each state from the existing information about smaller formulas. Finally, the overall question M = Φ corresponds to the compliance of an initial state of M with the complete formula Φ. Extending the approach towards model checking of real-time systems, a problem arises in terms of the dense-time model. It gives rise to an infinite state-space, since on the one hand, infinitely small amounts of time can elapse, whereas on the other hand, no upper bound for clock values is given. Hence, a finite transition system cannot be easily constructed. Consequently, there is no offhand application of the original CTL model checking which operates on a finite transition system Clock Regions A technique to obtain a finite representation of the infinite state space for real-time systems was first reported by Dill [Dil90]. Since for timed automata, time constraints only refer to natural number constants, a real-time system behaves in an equal manner for two situations if the referenced system state is identical, the integral values of all clocks are identical, and the ordering of the fractional parts of all clocks are identical. The fractional ordering is important with respect to the sequence in which transitions get enabled over time. The above observations allow for the partitioning of all clock valuations ν : C R into equivalence classes [ν], i.e. a system behaves in an equal manner given a common state and two clock valuations ν 1, ν 2 [ν], i.e. ν 1 = ν2. The set of equivalence classes [ν] is still infinite due to lack of an explicit upper bound for clock values. Nevertheless, it holds that once a clock exceeds the greatest constant it is compared to as part of some clock constraint, its concrete time value does not affect the system behavior. Hence, ν 1 = ν2 also holds for two clock valuations if in both cases, all clocks exceed these individual constants. Due to this observation, there exists a maximum equivalence class consisting of all clock valuations that comply with this condition. Hence, the overall number of equivalence classes is finite. As a result, the equivalence classes [ν] give rise to a finite number of so called regions s, [ν], consisting of a state s and an equivalence class [ν]. The abstraction of the infinite number of clock valuations by finitely many regions enables the construction of a transition system that refers to regions as states. Consequently, two kinds of state transitions exist: 21

34 2. Basics 1. Elapsing of time during the activity of one state s in the underlying timed automaton corresponds to a transition s, [ν] s, [ν ] where [ν ] is the direct successor of [ν]. 2. A state transition s s in the underlying timed automaton corresponds to a transition s, [ν] s, [ν ] where [ν ] is obtained from [ν] by considering the time constraint and clock resets of s s as well as the invariant of s. Since the set of transitions described above is also finite, the constructed transition system gives rise to an application of the CTL model checking procedure by Clarke et al. [CES86]. Hence, TCTL model checking reduces to CTL model checking by abstracting the infinite number of clock valuations by finitely many regions Clock Zones When abstracting the behavior of a real-time system by means of clock regions, their number grows exponentially. Hence, the approach described in Section faces problems in terms of efficiency. To overcome the huge amount of regions, Alur et al. [ACH + 92] applied a minimization algorithm to the construction of the finite transition system. The approach is based on the observation that the partitioning into equivalence classes is unnecessarily fine-grained. Below the constructed upper bound, each and every integral clock value gives rise to individual equivalence classes. Hence, there may be distinct equivalence classes that are still equivalent in terms of the underlying system behavior, because their represented clock valuations fulfill the same set of clock constraints. Alur et al. generalize the concept of regions, such that the equivalence classes reach beyond an interval bounded by two contiguous integral clock values. In more detail, they minimize the constructed finite transition system by unification of multiple equivalence classes representing a so called zone. A zone is the set of all clock valuations that fulfill a certain set of clock constraints, and therefore enable certain state transitions. For a region s, Z, the zone Z corresponds to the maximal set of clock valuations under which s may be active and under which certain state transitions are enabled. Hence, Z encodes the state invariant of s as well as time constraints of specific state transitions originating from s which are considered enabled. Technically, a zone Z corresponds to the solution space to a system of linear inequalities over clock values. The resulting finite transition system consisting of states s, Z is called zone graph. As described in Section 2.4.1, its transitions correspond either to the elapsing of time, or to an explicit state transition in the underlying timed automaton. The minimization by means of zones is also applied for timed model checking in Uppaal [BY04]. 22

35 2.5 MechatronicUML 2.5 MechatronicUML Mechatronics is a multidisciplinary engineering domain that combines mechanical and electrical aspects with controlling and computing. Hence, the design of mechatronic systems inherently comprises software development tasks, with the particularity that software is embedded in a diverse system context. The interaction of software with mechanical, electrical, or control devices gives rise to specific characteristics of software systems in the domain of mechatronics. Today s mechatronic systems are increasingly distributed to various autonomous sub-systems, which are interconnected for coordination purposes by means of asynchronous communication. Moreover, due to the fact that systems comprise sensor and actuator technology, this coordination behavior is affected by environmental real-time requirements. Other characteristics of mechatronic systems like self-reconfiguration as response to environmental circumstances are out of the scope of this thesis. Due to the above characteristics, the software part of mechatronic systems exhibits a highly domain-specific nature, which requires a certain recognition during design. However, model-based approaches like the UML [OMG11c] aim at a general purpose design of arbitrary software systems. Especially due to the specific combination of interconnectedness and real-time coordination behavior, the UML design approach is likely to fail in the context of mechatronics due to its inability to manage the design of complex systems. Striving towards a model-driven design of mechatronic systems with an increased design manageability, the MechatronicUML design method [BBB + 12] proposes various domain-specific modeling languages as extensions to the UML. MechatronicUML supports structural as well as behavioral models as abstract design elements. It provides transformations towards simulation platforms like MATLAB/Simulink [HPR + 12] and Dymola/Modelica [Wol11] and also gives rise to formal verification techniques Components MechatronicUML adopts the approach of component-based development of software [Szy98]. Its principles are encapsulation of functionality with high cohesion into reusable components, and low coupling between single components in order to avoid spreading changes. Coupling refers to a public accessibility of a component s functionality to other components via ports. Interaction between components corresponds to connectors between two ports. MechatronicUML distinguishes ports according to the type of interaction: discrete ports enable an asynchronous exchange of discrete messages, whereas continuous ports specify a continuous data flow. The component in Figure 2.4 represents a vehicle with two discrete ports that carry out message exchange in overtaking scenarios. A property of discrete ports is their cardinality concept. Unlike other types of ports, which represent a single point of interaction, the number of interaction points represented by a discrete port is variable within a specified range. A discrete port is referred 23

36 2. Basics front Vehicle rear Figure 2.4: MechatronicUML Vehicle Component to as single-port if the range is bounded by 1. If the range gives rise to more than one interaction point, it is a multi-port. Hierarchical Component Structure MechatronicUML supports a hierarchical component structure that gives rise to refining components into sub-components. Refined components are structured, whereas atomic components do not have further sub-components. As a direct result of this distinction, MechatronicUML supports two different types of connectors. A so called assembly connects two components on the same hierarchy level, representing the structural aspect of coordination between different components. In contrast to that, a so called delegation connects a structured component to one of its embedded sub-components, delegating coordination behavior to a lower hierarchy level within one and the same component. Component Instance Configurations The above constructs enable system modeling on the type level, i.e. modeling of component types. MechatronicUML additionally supports modeling of component instance configurations. By transferring the above concepts to the instance level, it enables the specification of runtime situations for mechatronic systems. A component instance configuration specifies an arbitrary number of instances for certain components, as shown in Figure 1.2. The ports of two vehicle instances are connected to exchange asynchronous messages during overtaking. v1 : Vehicle rear front v2 : Vehicle Figure 2.5: MechatronicUML Component Instance Configuration 24

37 2.5 MechatronicUML A component instance configuration also implies a concretization with respect to the cardinality concept of discrete ports by attaching a concrete number of so called sub-port instances of a discrete port to a component instance. A single-port supports at most one sub-port instance and only enables 1:1 communication of a component instance over one connector instance. A multi-port gives rise to numerous sub-port instances and enables 1:n interaction of one component instance with n other component instances over n connector instances.w Coordination Protocols MechatronicUML s discrete ports enable the asynchronous exchange of discrete messages via connectors in order to coordinate different components. This gives rise to the specification of entire protocols for coordination purposes, carried out by successive message exchange via assemblies. MechatronicUML considers such coordination protocols autonomously from the underlying component structure, enabling protocol reuse in different settings. A coordination protocol abstracts from the concrete assembly it represents, considering the essential behavior of the connected ports in terms of so called roles. Figure 2.6 depicts an instantiation of an coordination protocol to ensure safe overtaking of the front vehicle by the rear vehicle. :Overtaking :rear :front v1 : Vehicle rear front v2 : Vehicle Figure 2.6: MechatronicUML Coordination Protocol A role that corresponds to a multi-port is termed multi-role. A component s behavior comprises the message exchange of all roles that correspond to its ports. Roles specify their concrete message exchange behavior in terms of Real-Time Statecharts, which are described in the subsequent section. Dziwok et al. specify numerous recurring patterns for coordination protocols in [DBHT12] Real-Time Statecharts Coordination protocols correspond to well-defined sequences of sent/received messages, whereas the messages to be sent are highly depending on the messages received before. A state-based behavior is very suitable to describe such complex message exchange sequences. However, classical finite automata suffer from the inability 25

38 2. Basics to represent orthogonal and refined behavior adequately, and therefore appear inappropriate in the context of MechatronicUML. Based on Harel s statecharts [Har87], UML s protocol statecharts enable advanced concepts for the specification of behavior refinement and orthogonality [OMG11c]. MechatronicUML adopts these concepts and provides an extension of UML s protocol statecharts called Real-Time Statecharts [GB03]. Consisting of states and transitions, Real-Time Statecharts implement the roles of coordination protocols, whereas transitions specify asynchronous sending and receiving of messages. An exemplary Real-Time Statechart for the rear role of our exemplary coordination protocol is shown in Figure 2.7. A trigger message (as specified for the transition noovertaking overtaking) represents a condition for a state transition with respect to the availability of a certain message type. An appropriate message must have been received by the role in order to fire the transition. A raise message, as specified for the transition init requested in Figure 2.7, refers to a side-effect with respect to sending a certain message type to the counterpart role. region1 init noovertaking / request() {reset: c} [c >= 2s] requested invariant c <= 2s 1 accept / {reset: c} [c>=10s] / terminate() overtaking invariant c <= 10s Figure 2.7: MechatronicUML Real-Time Statechart Real-Time Statecharts support behavior refinement and concurrency on arbitrary hierarchy levels. In contrast to Hierarchical Timed Automata, there is no distinction between the concepts of XOR-refinement resp. AND-refinement. Real-Time Statecharts treat these concepts in a uniform manner by letting a state reference an arbitrary number of regions. Every single region contains an individual sub-statechart, whereas all sub-statecharts of a state are considered to be executing in parallel during the parent state s activity. A state with at least one sub-statechart is called composite state, the states in its sub-statecharts are termed sub-states. Similar to Uppaal, state transitions in parallel sub-statecharts can synchronize explicitly over dedicated channels. A transition activating a composite state refines the control flow in terms of its sub-statecharts. In case of more than one sub-statechart, this refinement corresponds 26

39 2.5 MechatronicUML to a fork. A transition that deactivates a composite state coarsens the control flow again. If there is more than one sub-statechart, this coarsening corresponds to a join. As a limitation of UML s protocol statecharts, their concept of time is inflexible in the sense that it only supports the specification of absolute points of time for state transitions, or delaying of state transitions by a certain amount of time relative to the activation of the source state. Real-Time Statecharts enable more sophisticated real-time behavior by combining UML with timed automata concepts. A Real-Time Statechart is provided with numerous clock variables that measure the time since their last reset. As for timed automata, clock values can restrict state transitions as well as the activity of certain states via invariants. Deadlines Timed automata specify state transitions dependent on clock values, however rely on the assumption that a state transition is executed without consuming time. Hence, a firing transition leads to an immediate state change. This concept is inappropriate for real-time systems that tend to carry out complex time-consuming computations during state transitions [Lee09]. Real-Time Statecharts give rise to the explicit specification of time-consuming state transitions by means of deadlines. An absolute deadline specifies a time interval restricted by bounds on certain clock values, in which a state transition must complete. A relative deadline specifies a concrete interval for the duration of a state transition, relative to the point in time where it starts firing. In Figure 2.8, we represent the front role s reaction to an overtaking request. The relative deadline expresses an evaluation delay of two seconds, before accepting the request. noovertaking request / accept() [2s;2s] noacceleration Figure 2.8: Relative Deadline Inside a Real-Time Statechart Actions Besides state-based behavior, Real-Time Statecharts also introduce a concept for data types and variables. On top of a well-defined action language, state transitions can depend on certain variable values by means of guards, and can especially involve modifications of variable values in terms of side-effects. The action language supports 27

40 2. Basics encapsulation of behavior into parametrizable operations. Additionally, Real-Time Statecharts enable the specification of actions which are executed along with certain events specific to states: An entry-action is executed along with the activation of a specific state, i.e. along with all entering transitions. A do-action is repeatedly executed during the activity of a specific state according to a given sampling interval. An exit-action is executed along with the deactivation of a specific state, i.e. along with all exiting transitions. Figure 2.8 illustrates the application of an entry-event inside the rear role statechart. The clock c is reset on every activation of state requested. init / request() requested invariant c <= 2s entry / {reset: c} Figure 2.9: Entry-Action Inside a Real-Time Statechart History The activity of a Real-Time Statechart corresponds to a sequence of state activations and deactivations. On activation of a composite state, the default behavior is to activate a predefined initial sub-state in each sub-statechart. If the composite state gets reactivated after it was deactivated before, the default behavior corresponds to a reinitialization. This may be inappropriate if the prior deactivation is regarded as an interrupt rather than a termination, requiring resumption instead of reinitialization. In other words, a reactivated composite state may require a recovery of its last active sub-states. The concept of storing and reactivating the last active state in a sub-statechart is referred to as history. Real-Time Statecharts only support a shallow history variant, that just reactivates the last active state without applying the history concept recursively to its sub-states. History can be enabled independently for each statechart. Entry-/Exit-Points Composite states face certain limitations in two ways. Firstly, there is only one explicit initial configuration for a composite state, which corresponds to all its initial 28

41 2.5 MechatronicUML sub-states. Under specific circumstances, it may be desirable to specify different initial configurations for composite states that can be chosen exclusively. Secondly, the deactivation of a composite state is independent of the current internal configuration consisting of all its currently active sub-states. Under specific circumstances, it may be required to allow deactivation of a composite state only for specific internal configurations. Real-Time Statecharts enable these use cases by providing composite states with entry- and exit-points that act as interface between hierarchy levels. Figure 2.10 shows the rear role statechart provided with entry- and exit-points. noovertaking region1 1 / request() {reset: c} requested 1 invariant c <= 2s init 1 2 [c >= 2s] 2 accept / accept / / terminate() {reset: c} [c>=10s] overtaking invariant c <= 10s Figure 2.10: Entry-/ and Exit-Point Inside a Real-Time Statechart An entry-point attached to a composite state serves as target for transitions activating that state by means of a specific internal configuration. This configuration is defined by means of internal transitions leading from the entry-point to one state in each sub-statechart. A transition leading to an entry-point corresponds to firing exactly those specific internal transitions, activating the composite state by means of specific sub-states. An exit-point attached to a composite state serves as source for transitions deactivating that state on condition of a specific internal configuration. This configuration is defined by means of at least one internal transition per sub-statechart leading from a sub-state to the exit-point. A transition originating from an exit-point corresponds to firing such a specific internal transition in each sub-statechart, deactivating the composite state on condition of specific active sub-states Compositional Verification Due to its model-driven nature, MechatronicUML enables formal verification techniques. Giese proposed a compositional verification approach for MechatronicUML 29

42 2. Basics in [Gie03]. The approach operates on a given component instance configuration and enables the verification of specific safety properties. According to its compositional strategy, the approach is underlying the divide-and-conquer concept: a component instance configuration is not verified in its entirety, but is split into sub-parts which are verifiable on their own. More precisely, the compositional verification approach proposes the decomposition of a component instance configuration into coordination protocols and components, and the verification of safety properties on these smaller system elements. After verification, the approach ensures semantic validity of the verification results by means of a syntactically correct re-composition of protocols and components. The approach tackles the exploration problem for huge state spaces by means of composition, focusing on scalability with respect to system size. The major compositional verification steps are the following: 1. The first step corresponds to an isolated verification of the single coordination protocols against certain safety properties, i.e. properties concerning all execution paths. In addition, verifying also the absence of deadlocks enables advanced reasoning in the subsequent steps. 2. Subsequently, the approach composes coordination protocol instances without introducing interdependency between roles. Consequently, due to the independence, all properties and the deadlock-freedom verified in the first step are still valid after the composition. 3. This next step considers interdependency between roles. The interdependency arises from the fact that a component instance s concrete behavior may extend the composed role behavior in terms of interactions between ports. However, if it is guaranteed that the extended composition corresponds to a restriction of the execution paths considered before, then all pre-verified safety-properties still hold and the extended behavior is a valid refinement. Under specific conditions, the refinement validity check corresponds to a check for deadlock-freedom of the extended role composition [BBB + 12], which ensures that no previously considered path may result in a deadlock due to the interaction. 4. Finally, component instances are verified against certain safety properties in isolation, disregarding coordination behavior between different component instances. The verified properties may now refer to interdependency between different roles of one component, e.g. synchronous activity of certain states. Due to the disregarded coordination behavior, the set of execution paths considered in this step comprises the paths that the overall system may actually operate on. Hence, safety properties verified in this final step are valid for the overall system. Obviously, steps 1. and 2. comprise typical verification tasks against safety properties, which can be carried out by means of model checking techniques. Also the 30

43 2.6 Goal Question Metric refinement check in step 3. corresponds to a verification task with respect to deadlockfreedom. Hence, MechatronicUML s compositional verification approach involves specific model checking use cases that correspond to the aforementioned verification steps. 2.6 Goal Question Metric Model-driven approaches apply engineering techniques to the domain of software development, motivating the notion of software engineering. Standardized and systematic software development raises a need for a quality measurement approach that meets these engineering requirements. The Goal Question Metric (GQM) approach is a means to derive project-specific operational quality models, designed to enable quality measurement in the domain of software engineering [BW84]. It follows a top-down paradigm and is based on the refinement of quality models in a stepwise, goal-driven manner. In the presence of error-proneness, GQM is a systematic approach to enable numerous tasks [SB99]: planning of resource requirements before a project starts evaluating the quality of products or processes process improvements on top of adaptation and refinement feedback with respect to the progress of a project GQM Model GQM suggests the development of quality models according to three hierarchy levels [BCR94]: 1. The conceptual level is concerned with the definition of major project goals. An essential aspect to be specified is the object of measurement, which can be a product, process or resource. The level furthermore comprises a statement regarding the measurement purpose and the concrete issue under consideration. The conceptual level comprises a specification of the viewpoint from which quality measurement should take place. 2. The operational level constitutes a refinement of the goals specified on the first level. Refinement corresponds to the derivation of questions that characterize the object of measurement in terms of the pertaining quality attribute and describe under which aspect its quality can be measured from the specified viewpoint. 3. The quantitative level takes the role of refining the derived questions in terms of concrete quantitative metrics. These metrics enable the answering of the specified questions in a quantitative manner. Metrics can be objective, i.e. depend on 31

44 2. Basics the object of measurement only, or subjective, i.e. depending also on a certain viewpoint GQM Process The GQM approach also proposes a measurement process consisting of four phases [SB99]. The process is not based on the pre-existence of a GQM model, but rather gives rise to the definition of such a model in a dedicated phase. 1. The planning phase corresponds to the development of a project plan with respect to a certain software development project under consideration. 2. The definition phase is concerned with the development of a GQM model including goals, questions, and metrics. Additionally, this phase produces measurement expectations, so called hypotheses, which highly affect the later interpretation of measurement results. 3. During the data collection phase, data concerning the object of measurement is collected as an input to the measurement process. 4. During the interpretation phase, metrics are evaluated based on the collected input data, producing measurement results. Measurement hypotheses enable the assessment of the result in terms of the overall goals. 32

45 3 Related Work We discuss related work from three different areas. Section 3.1 focuses on transformations from MechatronicUML to external verification and simulation formalisms, whereas Section 3.2 covers transformations from other real-time formalisms towards Uppaal. Finally, in Section 3.3, we consider related work that emphasizes a certain transparency with respect to formal details of the verification. 3.1 Transforming MechatronicUML to External Formalisms In this section, we are interested in transformations from MechatronicUML to external formalisms for the purpose of verification or simulation. These transformations may provide reusable concepts for the translation of specific MechatronicUML features as the asynchronous message exchange, quality-of-service assumptions, or hierarchy towards Uppaal. The verification approaches captured in Sections to are basically orthogonal to our approach. However, none of the contributions emphasizes transparency of the underlying verification formalism, e.g. by providing MechatronicUML-specific verification feedback or simplifying the specification of verification properties from the viewpoint of MechatronicUML engineers. The simulation approaches discussed in Sections and address a more downstream phase of the design process, testing the integration of continuous aspects into the discrete state-based model that was formally verified before Uppaal We described the underlying formalism of the Uppaal model checker in Section Hirsch connected Real-Time Statecharts to Uppaal s verification engine in [Hir04]. The transformation relies on the Hierarchical Timed Automata (HTA) formalism introduced in Section for an intermediate representation. Based on the HTA formalism, the Vanilla tool [DM01] carries out the final transformation into flat Uppaal timed automata as described in Section The transformation of Real-Time Statecharts into HTA maps composite states, orthogonality, and synchronizations to their associated HTA constructs. Additionally, it performs normalizations with respect to state entry-, do-, and exit-events, deadlines, transition priorities, history, final states, and asynchronous message exchange. However, the transformation lacks concepts for the execution of entry- and exit-events in case of composite transitions that activate or deactivate a certain state indirectly. The 33

46 3. Related Work representation of asynchronous message exchange [Hir04, pp ] does not consider quality-of-service assumptions like message delay or message loss. The transformation of final states [Hir04, p. 63] prevents the identification of deadlocks during verification, since an active final state in its normalized form always involves an enabled transition. Hirsch also proposes the concept of background model checking [Hir04, pp ] to automatically provide live verification results whenever a designed model changes. Whereas this approach implies a certain transparency of the Uppaal verification, it only addresses the visualization of plain verification results like success or failure, and does not aim at the presentation of traces leading to counter-examples. Obviously, background model checking relies on fast verification feedback, whereas performance is not of primary relevance in the scope of this thesis. Still, we identify the required performance analysis and further activities towards background model checking as an interesting topic for future work. A serious transparency barrier to the Uppaal integration by Hirsch is the usage of Vanilla as a third-party tool, which raises issues with respect to the traceability (cf. Section 2.1.5) of the overall model transformation. Since Vanilla acts as black box with respect to the concrete executed transformation rules, the integration of the tool into a fully transparent verification approach seems unpromising. Hirsch focuses on efficient strategies to verify non-local properties [HG03] that go beyond the compositional verification approach discussed in Section Such properties exceed the scope of one coordination protocol by comprising message exchange between more than two components. Although this use case is not of primary interest in the scope of this thesis, we identify the verification of non-local properties as a relevant requirement to be considered during our transformation design RAVEN RAVEN 1 [Ruf01] is a real-time model checker that accepts flat finite transition systems extended by time, so called I/O interval structures. Model checking in RAVEN is symbolic, i.e. it encodes the state-space in an implicit manner via Binary Decision Diagrams (BDD). As a major restriction, I/O interval structures are not able to specify clocks. In contrast to MechatronicUML and Uppaal that rely on a dense-time model as discussed in Section 2.2.1, the underlying model of time in RAVEN is discrete. RA- VEN enables the specification of verification properties using a timed variant of the CTL described in Section called Clocked CTL (CCTL). Communication between processes modelled as I/O interval structures is limited to exporting and importing of data signals. States carry valuations of exported signals, whereas state transitions may depend on the values of imported signals. The concept of synchronization between transitions is unknown to RAVEN. However, RAVEN emphasizes diagnostics with re- 1 Real-Time Analyzing and Verification Environment 34

47 3.1 Transforming MechatronicUML to External Formalisms spect to identified counter-examples by providing a wave-form browser that traces the evolution of signals over time in a visual fashion. Stecker developed an integration of Real-Time Statecharts and RAVEN in [Ste05] based on a transformation towards I/O interval structures. To overcome the lack of clocks and the inability to specify complex measurements of time, dedicated automata are introduced that encode clocks by means of discrete signals [Ste05, pp ]. These automata ensure the elapsing of time by repeatedly adjusting dedicated data signals, and also represent clock resets. Since I/O interval structures have no notion of hierarchy, the transformation addresses a representation of composite states by means of orthogonality [Ste05, pp ]. The transformation approach also covers synchronization between transitions, and aims at encoding the ability to synchronize over a certain channel by means of signal export/import [Ste05, pp ]. Obviously, the effort to represent synchronization is much greater compared to a target formalism like Uppaal, which supports offhand synchronization. Since RAVEN does not enable asynchronous message exchange as well, this concept gives rise to another complex transformation aspect [Ste05, pp ]. The information whether a message of a certain type is available is encoded via dedicated counter signals that represent the current buffer status. Since quality-of-service assumptions about the asynchronous transmission remain unconsidered, every dispatched message gets immediately delivered PHAVer PHAVer 2 [Fre05] is a verification tool for hybrid systems that combine discrete state changes with continuous behavior. PHAVer operates on flat hybrid I/O automata that embed differential equations into discrete states. It performs polyhedral computations to explore the state space of the underlying system. In contrast to usual model checking approaches that enable queries in terms of temporal logic formulas, PHAVer performs a reachability analysis that yields a plain enumeration of the reachable system states. Hence, obtaining concrete verification results with respect to temporal requirements still requires a significant manual effort. Additionally, PHAVer does not provide any traces. Dorociak developed a transformation from MechatronicUML to hybrid I/O automata as an input to PHAVer in [Dor08]. More precisely, the approach focuses on the representation of hybrid reconfiguration charts [GBSO04]. These diagrams extend Real-Time Statecharts by reconfiguration behavior between different continuous control strategies. The transformation encodes clocks by means of dedicated continuous variables that are subject to differential equations. Whereas hybrid I/O automata support synchronization labels on transitions, the transformation addresses the task of encoding asynchronous communication, but does not consider any quality-of-service assumptions. Dorociak also addresses the need to establish a transparent verification 2 Polyhedral Hybrid Automaton Verifyer 35

48 3. Related Work by indicating the verification result at the level of the Fujaba tool [Dor08, pp ]. However, this transparency challenge is complicated by the fact that PHAVer provides plain reachability findings instead of a concrete verification result Modelica The Modelica modeling language is an object-oriented approach for the specification of physical systems. Similar to the CIF approach discussed in Section 3.2.5, Modelica aims at the exchange and reuse of models based on a unique formalism. In combination with the StateGraph2 library, Modelica enables modeling of discrete state-based behavior. The modeling and simulation environment Dymola 3 provides well-established tool support for the creation and execution of Modelica models. A transformation from MechatronicUML to Modelica was originally developed by Wolf [Wol11]. Pohlmann et al. present the underlying extensions to the StateGraph2 library in [PDS + 12]. Due to Modelica s object-oriented nature, it enables offhand representation of hierarchical states and transition priorities in Real-Time Statecharts, whereas the underlying differences between shallow and deep history in MechatronicUML and Modelica give rise to small adaptations [Wol11, pp ]. State entry-, do-, and exit-events can be represented with manageable effort by means of algorithmic code [Wol11, pp ,56-57]. Clocks are considered relative to the overall execution time [Wol11, pp ]. The transformation encodes synchronous and asynchronous communication among statecharts by means of explicit connectors between the affected transitions. These connectors carry out the required data exchange. After transmission, asynchronous messages and their parameters are buffered by dedicated queues before the consumption by the receiver Real-Time Statechart. The difference between formal verification approaches on the one hand, and simulation of Modelica models on the other hand, gives rise to certain behavioral restrictions for specific syntactic features. As an example, enabled transitions fire without residing in the source state, which corresponds to an urgent behavior. State invariants do not force any execution progress, but rather give rise to an abnormal termination of the simulation if an active state s invariant is violated [Wol11, p. 53]. The above restrictions correspond to an underapproximation of the execution traces originally specified, which is a valid practice for simulations. Addressing StateGraph2 s inability to form transition cycles that do not consume any time, the transformation to Modelica aims at identifying and eliminating such cycles. The elimination is carried out by inserting additional delaying transitions, such that time is forced to pass throughout the cycle. Although the induced delay is very small, this technique implies modifications of the specified real-time behavior, which is an unacceptable practice in case of formal verification. 3 Dynamic Modeling Laboratory 36

49 3.2 Transforming External Formalisms to Uppaal MATLAB/Simulink MATLAB 4 is an environment for mathematical computations. Its toolboxes Simulink and Stateflow offer modeling support for block diagrams combining continuous data flow with discrete state-based behavior. The MATLAB toolchain enables visual simulation as well as code generation for target platforms. Heinzemann et al. present an approach of connecting MechatronicUML to MAT- LAB/Simulink in [HPR + 12]. Pines extends the Simulink transformation by structural reconfiguration in [Pin12]. Previous work by Steinke [Ste07] addresses the transformation of hybrid reconfiguration charts as mentioned in Section Whereas MechatronicUML s component structure enables offhand representation in terms of Simulink block diagrams, Real-Time Statecharts are transformed to hierarchical Stateflow charts. Similar to the Modelica integration described in Section 3.1.4, the Simulink transformation encodes clocks relative to the overall simulation time. A certain effort is spent on the representation of asynchronous message communication by means of data exchange. Simulink does not provide offhand means to buffer received data, which is crucial to the asynchronous communication in MechatronicUML. Hence, a dedicated infrastructure at the Simulink level carries out typical link layer tasks concerned with the dispatching and delivering of discrete messages using continuous data exchange. At this point, the approach explicitly tackles message loss by means of an acknowledge mechanism, sending a message again if there is no acknowledgement of receipt. Hence, the transformation does not only represent quality-of-service characteristics, but explicitly addresses the emergent shortcomings. In doing so, the generated Simulink models meet crucial requirements for a straight application to target hardware as one of Simulink s key features. Since message loss actually occurs in real systems, abstracting from the system s reaction only in terms of a plain transmission delay would make the approach inapplicable to target hardware. 3.2 Transforming External Formalisms to Uppaal In this section, we focus on the representation of different real-time modeling formalisms at the level of Uppaal. We restrict ourselves to systematic, reusable transformation approaches, disregarding manual ad hoc mappings of individual case study models. We are particularly interested in the way that other formalisms and transformations cope with specific characteristics of the MechatronicUML design method, such as hierarchical, component-based modeling, dense real-time behavior, asynchronous message exchange, and quality-of-service assumptions. We only refer to these concepts if they are particularly supported by an approach. We also investigate the significance of transparency, i.e. we discuss which Uppaal transformations are integrated to a transparent verification procedure. 4 Matrix Laboratory 37

50 3. Related Work hugo/rt The real-time verification tool hugo/rt 5 was proposed by Knapp et al. in [KMR02]. hugo/rt relies on hierarchical UML state machines as the underlying behavior formalism, whereas requirements are also subject to graphical modeling via UML interaction diagrams. The approach connects to different model checking tools that carry out the actual verification, Uppaal among them. For verification, the UML interaction diagrams that encode the requirements are translated into dedicated observer automata that interact with the specified system and identify violations. The transformation from hierarchical UML state machines towards Uppaal does not only introduce a buffering mechanism for asynchronous communication, but also considers a crucial quality-of-service assumption in terms of the message latency in the underlying network [KMR02]. A message buffer automaton with a first-in-first-out logic for two event types e1 and e2 is depicted in Figure 3.1(a) [KMR02]. For instance, event e1 may be received from the network by synchronizing with a dedicated network automaton on channel e1fromnet. The receiving state machine automaton may consume a message via synchronization on channel e1dispatch. The automaton does not maintain its level of performance in case of a buffer overflow, switching to the dedicated Overflow location instead. Figure 3.1(b) [KMR02] shows the associated network automaton that induces a certain maximum delay for the message type e1. Buckets are available for at most two transferred messages, representing the fill level of these buckets via four locations. The location names in Figure 3.1(b) encode the fill level of the two buckets: location 00 represents an empty network, whereas Overflow is reached after receiving another event in location 11. Noteworthy, the modeled network faces a fixed maximum capacity. By associating dedicated clocks with pending messages, the automaton ensures a maximum transmission delay denoted by. The network automaton does not necessarily preserve the order of sent messages, which is, however, a crucial assumption for MechatronicUML [Kri13]. Kriger also identified the need for a minimum transmission delay, the possibility of message loss, and alternative overflow strategies that maintain the message exchange service, which are unconsidered concepts for hugo/rt. hugo/rt addresses transparency of the Uppaal verification procedure not only by encoding requirements at the UML level, but also by transforming identified counterexamples traces back to the UML. Nowadays, the hugo/rt approach mainly suffers from stagnating development. In addition, due to its general purpose modeling approach, it differs from the domain-specific MechatronicUML method in terms of missing support for structural component-based modeling and the integration of continuous system aspects

51 3.2 Transforming External Formalisms to Uppaal queue[0] == e1 e1dispatch! queue[0] = queue[1], queue[1] = queue[2], queue[2] = 0, tail = tail 1 e1fromnet? tail = tail+1, queue[tail] = e1 Idle tail <= 2 c tail > 2 Overflow queue[0] == e2 e2dispatch! queue[0] = queue[1], queue[1] = queue[2], queue[2] = 0, tail = tail 1 e2fromnet? tail = tail+1, queue[tail] = e2 (a) Message Buffer Automaton [KMR02] clock1 <= bucket[0] == 0, bucket[1] == 0 e1rcvd! bucket[0]!= 0, bucket[1] == 0 e1rcvd! e1tonet? bucket[0] = e1 buffer[0] == e1 efromnet! buffer[0] = 0 c bucket[1] == e1 e1fromnet! bucket[1] = 0 e1tonet? bucket[0] = e1 bucket[0] == e1 e1fromnet! bucket[0] = 0 bucket[0] == 0, bucket[1]!= 0 e1rcvd! bucket[1] == e1 e1fromnet! bucket[1] = 0 Overflow 10 clock0 <= e1tonet? bucket[1] = e1 11 clock0 <= clock1 <= e1tonet? (b) Network Automaton [KMR02] Figure 3.1: Asynchronous Message Exchange Automata for hugo/rt 39

52 3. Related Work COMDES-II COMDES-II [KSA07] focuses on component-based modeling of embedded control systems underlying hard real-time requirements. Similar to MechatronicUML, COMDES- II relies on hierarchically structured models of distributed systems, comprising several communicating actors. Non-hierarchical state-machine blocks for actors enable the specification of reactive behavior, which has a direct impact on reconfiguration between different control modes. These modes correspond to different ways of how the concerning actor processes the underlying data-flow signals. Communication between actors is carried out on top of a non-blocking producer-consumer protocol, which does not consider a message delay. In contrast to MechatronicUML, COMDES-II underlies a discrete time model and a restrictive scheduling policy with preemption based on fixed priorities. These distinctions from MechatronicUML also imply crucial differences for transformation approach towards Uppaal by Ke et al. [KPSA08] RT-DEVS Another modeling formalism for concurrent real-time systems is RT-DEVS 6 [HSKP97], which is subject to an Uppaal transformation proposed by Furfaro and Nigro [FN08]. The approach relies on a hierarchical component structure and state-based controlling behavior affected by real-time requirements. Both discrete and dense time models are supported. Inter-component communication corresponds to a weak synchronization [FN08], i.e. communication is always instant but non-blocking. As a result, messages are lost if they can t be immediately received. Consequently, Uppaal s broadcast synchronization channels are utilized to encode weak synchronization, that give rise to an immediate non-blocking interaction. In contrast to MechatronicUML, there is no concept of message buffering or message delay AADL AADL 7 [FG12] addresses modeling of software and hardware architectures for embedded real-time systems. It is used to analyse architectural decisions by identifying certain design faults. An AADL specification comprises application software components like processes and threads as well as execution platform components like processors. Connectors representing control and data flow are subject to reconfiguration between different modes at runtime. The underlying application behavior within processes and threads is modeled in terms of state machines that may trigger mode switches. AADL also enables the specification of quality-of-service assumptions with respect to reliability and timing. An Uppaal transformation approach for AADL has been proposed by Johnsen et al. in [JLPJ12]. It aims at verifying executability and data compatibility requirements 6 Discrete Event System Specification 7 Architecture Analysis & Design Language 40

53 3.2 Transforming External Formalisms to Uppaal in the presence of concurrency. The transformation considers models for application software as well as the execution platform, and is described in terms of formal rules. However, as a crucial limitation, it supports only a subset of AADL restricted to synchronous data interaction Compositional Interchange Format The Compositional Interchange Format (CIF) addresses interoperability problems between different coexisting modeling formalisms for hybrid real-time systems [BRSR07]. By representing continuous variables in terms of differential equations, CIF s hybrid characteristics go beyond the scope of MechatronicUML. The basic intent of CIF is to overcome a variety of bilateral transformations between different modeling formalisms. Instead, transformations are intended to rely on CIF for an intermediate representation as depicted in Figure 3.2 [BCN + 09]. Hence, the approach focuses on reusable transformation steps, reducing the effort to establish interoperability between different formalisms for modeling, simulation, analysis, or verification. Figure 3.2: CIF Transformation Approach [BCN + 09] At the core of CIF is the concept of (originally non-hierarchical) hybrid interchange automata as generic modeling formalism, enabling the specification of discrete statebased behavior along with discrete and continuous variables, urgent behavior, and synchronizations. By providing interchange automata with formal semantics, CIF focuses on proven semantics preservation for its model transformations. Although en- 41