Component instances and port instances may not be deleted at any point in time. In particular, they may not be deleted if they currently perform a computation or if they are
engaged in executing a communication protocol that is required for the safe operation of the system. Quiescence [KM98, ZC06] defines whether it is safe to delete a compo- nent instance or one of its port instances at a certain point of time. Then, executing a reconfiguration safely demands that all affected component instances are quiescent. As an example, consider a member RailCab that leaves a convoy. As a consequence, the RailCab will destroy its instance ofMemberControl and it will switch back to the
StandaloneDrivefeedback controller (cf. Section 4.2.2). However, the RailCab may not perform this reconfiguration if it is still driving closely behind another RailCab. If it performs the reconfiguration, it will not be notified about braking maneuvers of the convoy and, thus, a crash is likely to occur.
Therefore, we need a concept for defining quiescence of component instances in MECH-
ATRONICUML. In particular, we need to define quiescence of discrete atomic compo- nent instances. For continuous atomic component instances, the fading functions define how they may be safely replaced. A structured component instance is quiescent with respect to a particular reconfiguration if all children that are affected by this reconfigu- ration are quiescent.
The concept for quiescence of discrete atomic component instances needs to answer the following three questions for being usable in our 2-phase-commit protocol.
1. Is the component instance quiescent?
2. If the component instance is quiescent, how long will it remain quiescent? 3. If the component instance is not quiescent, when will it be quiescent again? These questions need to be answered by the discrete atomic component instance during the voting phase of the 2-phase-commit protocol. Question 1 and 3 are important for deriving the voting result. A discrete atomic component instance may only vote for commit if it is presently quiescent or if it will become quiescent early enough. Question 2 is important for deriving the commit time that defines how long the component instance will stick to its commit. However, the component instance will only vote for commit if the commit time is above a threshold that is defined by the developer as we discuss in Section 4.3.4.
An approach that may answer the three questions given above for a self-adaptive mecha- tronic system has been developed as part of a Master’s thesis [Sch15]. We will sketch its core ideas in the following. Our ideas are inspired by the approach of Zhang and Cheng [ZC06]. Their approach considers a state-based functional behavior specification of components based on petri nets (cf. [ZC06]) or UML Statecharts (cf. [RC08]), but they do not consider real-time constraints or properties of the physical system in their specification. For performing a reconfiguration, the system switches between source and target functional behaviors by executing an adaptation behavior (cf. Section 2.1.2). In our approach, the source and target functional behaviors correspond to the CICs before
and after executing a reconfiguration, while the adaptation behavior is represented by our 2-phase-commit protocol.
For guaranteeing quiescence, Zhang and Cheng define a set of global invariants using temporal logic that need to be fulfilled during the adaptation process. Then, a state s of the source functional behavior is quiescent if there exists a state t in the target functional behavior such that the adaptation from s to t does not violate any global invariant [ZC06]. This is ensured at design time by model checking the functional behaviors and the adap- tation behavior [ZGC09]. Then, all states s of the source functional behavior are marked as quiescent with respect to a given adaptation.
In a self-adaptive mechatronic system, the state of a component instance is not only determined by the active state of its RTSC but also by the current clock values of the RTSC and, potentially, the physical state of the mechatronic system. The physical state of a mechatronic system is given, for example, by its current spatial position, its speed, or its acceleration. Consider a member RailCab that wants to leave a convoy as an example. There, we need to consider the RailCab’s distance to the preceding RailCab and its current speed for deciding whether the component instance is quiescent. Therefore, it is not possible to simply mark states of an RTSC as quiescent as proposed by Zhang and Cheng.
As an additional problem, considering the clock values and the physical state of the sys- tem induces a so-called hybrid model checking problem [Hen96]. Such model checking problems cannot be solved efficiently with current techniques [ERNF12] as we discuss in more detail in Chapter 6. As a possible solution, we can use our approach of motion profiles [FHK+13, FHK+14] for avoiding hybrid verification. A motion profiles gives an assertion on the limits of a change of the physical parameters of the mechatronic system in the future. Each motion profile is defined with respect to a particular control strategy, with respect to the current driving maneuver, e.g., braking or accelerating, and with respect to optimization criteria, e.g., braking strongly vs. braking smoothly. As a result, each system is equipped with a multitude of motion profiles. However, even in this case the state-space that needs to be explored is significantly larger compared to Zhang et al. [ZGC09] because we need to consider clocks and all possible motion pro- files of the RailCab based on each possible point in time of the maneuver that is defined by the motion profile.
Therefore, our idea is to identify quiescent states at runtime as a part of the voting phase of our 2-phase-commit protocol. This is more efficient than computing all possible sym- bolic states at design time [GCZ08] because we only need to check a few symbolic states. In particular, we only need to consider symbolic states that are reachable from the current snapshot of the component instance in a short period of time. In addition, we only need to consider the currently applied motion profile instead of considering all n available motion profiles which reduces the state space by factor n. Figure 4.10 summarizes the idea of our approach.
At design time, the developer needs to specify a set of conditions for quiescence. These conditions refer to the different parts of the atomic component instance, e.g., an active state of the RTSC, messages that are located in the message buffer of a port instance, or values regarding the physical state of the system that are received via a hybrid port in- stance. In our example, we might require that the distance of the member RailCab to the RailCab directly driving in front of it must be larger than 50 m. Then, any symbolic state of the RTSC that fulfills all of the imposed conditions at runtime is considered to be qui- escent. Thus, the conditions correspond to the invariants used by Zhang et al. [ZGC09]. For supporting the developer, we provide him with a checklist for typical influence fac- tors that need to be considered for quiescence. The checklist will be derived by analyzing influence factors on quiescence in different self-adaptive mechatronic systems such as RailCabs or self-coordinating cars [PHMG14].
Design Time Runtime
Discrete Atomic Component Checklist for Influence Factors
Developer Set of Conditions for Quiescence
refers to
Evaluation of Conditions via Reachability Analysis model@runtime
Vote
Commit Time
of
Figure 4.10: Approach for Identifying Quiescent States in MECHATRONICUML
At runtime, we use our model@runtime of the atomic component instance for evaluating the conditions as a part of the voting phase of the 2-phase-commit protocol. If the atomic component instance is requested to execute a reconfiguration by its parent, we start a reachability analysis on the current snapshot of the model@runtime. Then, we calcu- late the symbolic states that the atomic component instance may reach in a short time frame starting from the current snapshot. The time frame that needs to be considered is defined by the time for execution of our 2-phase-commit protocol and the threshold for the commit time. For each of the symbolic states, we evaluate the conditions that the developer has specified at design time. The result is a zone graph (cf. Section 2.2.1) where each symbolic state is marked as quiescent or non-quiescent. Thereby, we only need to consider the currently active motion profile and the current physical state of the system. Based on the clock values of the symbolic states, we may utilize the paths of the
zone graph for calculating whether the component instance is quiescent and how long it will remain quiescent. From this information, we derive the voting result and the commit time that are passed to the parent.
The reachability analysis may be carried out by a variant of the reachability analysis for RTSCs introduced in Appendix C.3 that is optimized for being executed on embedded computing devices. This rechability analysis needs to be implemented such that its run- time is predictable. This is necessary for guaranteeing that the component instance will obtain a voting result within a given time that the component asserts to its parent as we describe in more detail in Section 4.3.4. Predictability may be achieved, e.g., by limiting the number of symbolic states that are investigated for each trace of the zone graph as proposed by bounded model checking techniques [BCC+03].