Test automata-based Verification

"Test automata are used by Aceto et al. [ABBL03] for model checking temporal properties specified in SBBL (Safety Model Property Language) on timed automata rather than verify-

ing correct refinements. Their test automata construction encodes a temporal logic formula. Consequently, they use a different set of test constructs compared to our approach.

The approaches by Gerth et al. [GPVW96] and Tripakis et al. [Tri09] perform LTL model checking [BK08] on (timed) Büchi automata and encode the properties in automata as well. Again, they use a different construction because they encode a temporal logic formula instead of a refinement definition.

Li et al. [LBD+10] specify safety and liveness properties for timed automata as live se- quence charts (LSC, [HM03]). They translate the LSC into an observer timed automaton that enters a special error location if the property is violated. Since they encode a LSC, they also use different test constructs compared to our approach." [HBDS15]

5.8 Summary

In this chapter, we extend the compositional verification approach of MECHATRONICUML by five additional refinement definitions and an integrated refinement check. Our refinement check may automatically select a suitable refinement definition based on the role RTSC, the port RTSC, and the properties that have been verified for the RTCP. Then, our refinement check generates a so-called test automaton that encodes the behavior of the role RTSC and the conditions of the applied refinement definition. Our approach extends the construction of test automata by Jensen et al. [JLS00] by additional test constructs that enable to check all of the six considered refinement definitions. In our evaluation, we showed that our approach was successfully applied to a RTCP of the RailCab system.

Our refinement check relieves developers of NMS from choosing a refinement definition manually. As a result, developers require less detailed expertise in refinements when refining roles of a RTCP to ports of a component. An additional advantage of our refinement check is that additional refinement definitions, if needed, only require minor extensions of the de- cision tree and the test automaton construction. The remaining algorithms do not need to be changed.

Systems in MATLAB/Simulink

Our component model as introduced in Chapter 3 supports to specify a software architec- ture for a self-adaptive mechatronic system. Therefore, it enables to specify and connect discrete components that contain event-discrete behavior specified by RTSCs and continu- ous components that contain feedback controllers. In addition, our concept for hierarchical reconfiguration as introduced in Chapter 4 enables to jointly reconfigure both kinds of com- ponents. Such joint reconfiguration is necessary, for example, for a RailCab that wants to join a convoy as a member. As described in Section 4.2, this reconfiguration requires (1) to instantiate a discrete component, (2) to replace a continuous component instance by another one, and (3) to connect these component instances. As a result, correctness of the RailCab’s behavior with respect to this reconfiguration depends on the correct interaction of discrete and continuous components as well as the correct integration of fading functions, which are used for replacing continuous component instances, in a hierarchical reconfiguration. Thus, an error in the interaction or an erroneous fading function may lead to a crash when a RailCab enters a convoy.

Therefore, it is desirable to verify the correctness of the behavior by applying formal verifi- cation techniques for proving that such errors may not occur. Verifying the behavior of a Rail- Cab for joining a convoy as a member, however, induces a so-called hybrid model checking problem [Hen96] because it includes event-discrete RTSCs as well as time-continuous feed- back controllers and fading functions. At present, hybrid model checking approaches like PHAVer [Fre05] or SpaceEx [FLGD+11] either use very simple models of time-continuous behavior or rely on several, manual overapproximation steps. Both kinds of approaches suf- fer from a loss of precision leading to potentially wrong verification results and may still only be applied to small models of academic nature [ERNF12]. Therefore, the correctness of the behavior of mechatronic systems is typically only assessed by testing, which cannot prove the absence of errors.

Our goal is to provide the best possible compromise between formal verification and test- ing approaches while avoiding the need for hybrid verification. In particular, we want to fully verify all of the discrete components for proving that they are free of errors. Then, testing is only necessary for checking the behavior of continuous components and their in- tegration with the discrete components. As a basis, the MECHATRONICUML component

model syntactically decouples the event-discrete part of the behavior specification from the time-continuous part. Discrete components may only interact with continuous components based on hybrid ports whose values are only updated in fixed, predefined time intervals. We do not apply any assumptions on how the values of hybrid ports change and we do not allow, in particular, to include time-continuous variables in RTSCs. This enables to efficiently verify the discrete components based on MECHATRONICUML’s compositional

approaches based on model-in-the-loop (MIL) simulation [Plu06] for testing the continu- ous components of the mechatronic system using tools like MATLAB/Simulink [Matg] or Dymola [Das]/Modelica [Mod09]. MIL simulation and the corresponding tools are already successfully applied in industry [TDH11, KSHL12]. In contrast to MECHATRONICUML, the tools for MIL simulation of mechatronic systems do not support modifications of a sim- ulation model during a simulation run. Consequently, these tools do not natively support runtime reconfiguration that we need, for example, for realizing the convoy mode of the RailCab system. In addition, they do not support communication between systems based on asynchronous messages.

In this chapter, we define an approach for performing a MIL simulation for a self-adaptive mechatronic system whose software architecture and behavior have been specified using MECHATRONICUML. In our approach, we consider both, the reflective operator and the controller level of the OCM. As our main contribution, we define how a model specified in MECHATRONICUML may be represented in a simulation environment that provides no built-

in support for message-based communication and runtime reconfiguration. As a simulation tool, we use MATLAB/Simulink because it is widely used in industry and well supported by code generators like TargetLink [dSP] or ASCET [ETA] that enable to generate production code for the final system.

Our approach solves three particular challenges. First, the reconfiguration controller of a structured component operates on a model@runtime that is shared between manager, execu- tor, and runtime risk manager. Since MATLAB/Simulink does not have a model@runtime, we define an explicit encoding of the model@runtime in MATLAB/Simulink. Second, since MATLAB/Simulink does not allow to modify the simulation model during a simulation run, we enumerate and encode all configurations beforehand in the MATLAB/Simulink model such that we may switch between these encoded configurations at runtime. Third, MAT- LAB/Simulink only supports communication via synchronous signals that may only be re- ceived as long as they are sent. Therefore, we provide helper blocks for MATLAB/Simulink that realize message-based communication and respect the QoS assumptions of MECHA-

TRONICUML. The helper blocks only use build-in features of MATLAB/Simulink. In con- trast to related works like Mosilab [ZJS08], Sol [Zim07], or the block library by Kovácsházy et al. [KSP03], this retains the ability to use the code generators for generating production code for the system out of the resulting MATLAB/Simulink model.

Our translation needs to preserve the semantics of the (verified) MECHATRONICUML model. Proving correct preservation of semantics is currently not possible because the oper- ational semantics of Simulink and Stateflow are intellectual property of The MathWorks and solely defined by the implementation of the simulator and code generators [TSCC05]. Al- though approaches for defining a formal semantics exist for both, Simulink [TSCC05, BC12] and Stateflow [Ham05, HR07, Wha10], these are incomplete with respect to the features that we require and cannot guarantee to be correct because they also have only been checked based on a few test cases [TSCC05, BC12]. Therefore, we only provide an informal descrip- tion of how we preserve semantics. In addition, we have tested the semantics of the resulting Simulink and Stateflow models using our implementation.

In the following, we first introduce basic concepts of Simulink and Stateflow that are re- quired for understanding the concepts of our translation (Section 6.1). Thereafter, Section 6.2 introduces our approach for MIL simulation in MATLAB/Simulink. As part of this section, we define an algorithm consisting of several steps for translating a MECHATRONICUML

model into a MATLAB/Simulink model. Sections 6.3 to 6.5 describe the steps of the algo- rithm in more detail. Then, we describe our implementation of the algorithm in Section 6.6. Section 6.7 discusses the limitations of our approach and our implementation. Section 6.8 presents the results of our case study. Finally, we discuss related works in Section 6.9 before summarizing the approach in Section 6.10.

The contents presented in this section have been published in [HPR+12] and [HRS13]. The translation of the reconfiguration specification has been contributed by the Bachelor’s Thesis of Pines [Pin12] and the Master’s Thesis of Volk [Vol13].

6.1 MATLAB/Simulink and Stateflow

MATLAB R _{is a tool environment for numeric computations and visualizations [ABRW09,}

Matd]. MATLAB is extended by a set of tool boxes that provide additional modeling and simulation capabilities. The most important tool box for modeling and simulating mecha- tronic systems is Simulink R _{[Matg]. Simulink, in turn, is extended by the Stateflow} R _[Math]

tool box for specifying state-based behavior. Since all features of MATLAB that we require for performing MIL simulations of mechatronic systems are offered by Simulink and State- flow, we restrict our descriptions in Sections 6.1.1 and 6.1.2 to these tool boxes. We refer to Angermann et al. [ABRW09] for a detailed introduction to MATLAB.