Keywords

1 Introduction

Cyber-physical systems in which software components operate in a physical environment often encompass complex concurrent behavior. The development or synthesis of such control software achieving a given set of goals while also ensuring the satisfaction of a given safety-specification is crucial. In model-predictive control, a model of the expected system behavior is employed to obtain look-ahead controllers. Such controllers derive control decisions based on the set of all behavior sequences of a chosen look-ahead length starting in the current state.

However, the set of such behavior sequences is exponential in the look-ahead length limiting the look-ahead to values allowing admissible reaction times.

As a running example, we consider a variation of the RailCab system from [30, 38]. In this system, shuttles navigate on a large-scale track topology, which intersects with a road topology at level crossings. Ambulances, which can be monitored by shuttles with a certain degree of uncertainty, navigate on the road topology and may traverse level crossings. The shuttle control to be derived, must avoid collisions with ambulances when possible by adjusting the speed of the shuttle taking potential ambulance behavior into account. To focus on our approach and to simplify our presentation, we reduce the possible number of steps of actors in the system model by employing a small topology fragment with one level crossing, a single shuttle, and one ambulance.

Besides run-time efficiency, controller synthesis approaches for cyber-physical systems must solve an array of further problems. P1 (Sets of Start States): The start state of the system is often not precisely known requiring the consideration of a large or even infinite set of start states. These start states may differ in rigid components but also in the number, the state, and the interconnection of active components. For our running example, the underlying rigid topology and the location of shuttles and ambulances on this topology may vary greatly. P2 (State space explosion): Even when selecting a single start state, the state space of the system is often intractably large or even infinite because all steps of all components must be captured in the system model. P3 (Uncertainty): The uncontrolled part of the system can often not be modeled faithfully at design time due to uncertainty. For example, uncertainty arises due to behavioral or configuration adaptation as well as from unknown, unreliable, or unpredictable components/actors (such as humans) performing additional steps that cannot be foreseen at design time or fail to perform such steps [45]. P4 (Unsafe Systems): Avoidance of unsafe states is not always feasible due to uncertainty or in contexts where unsafe states cannot be avoided by control at all.

For the modeling of the expected future system behavior, we employ Graph Transformation Systems (GTSs), which can be used when system states can be captured by graphs and when the steps of the involved components can be captured using local graph modifications. In the past, various GTS-variants have been developed and employed for the modeling, design, and analysis of such systems in an abundance of publications such as [18,19,20,21,22, 29, 30, 49] focusing on different system aspects and requirements.

To accommodate for these problems (discussed in more detail in the subsequent section), we propose a model-driven approach based on GTSs and the MAPE-K control framework where we employ a sliding window technique considering actor-specific state fragments to reduce the computational effort (problems P1 and P2) and combine design-time control synthesis with run-time control synthesis as a look-ahead extension technique to efficiently obtain best-effort control (to tackle problems P3 and P4). Both, at design-time and run-time, we employ an extension of Supervisory Control Theory (SCT) with priorities for the synthesis of controllers where the uncontrolled system is modeled using an extension of GTSs with controllability notions.

Fig. 1.
figure 1

Overview of MAPE-K-based approach

Full size image

This paper is structured as follows. In section 2, we discuss our conceptual approach in the context of the MAPE-K framework including the sliding window technique. In section 3, we consider related work. In section 4, we present our extension of SCT with priorities. In section 5, we integrate controllability notions into the GTS framework and present our running example. In section 6, we discuss control synthesis at design-time. In section 7, we discuss control synthesis at run-time based on the design-time results. In section 8, we evaluate our approach for a larger case study. Finally, in section 9, we conclude the paper and provide an outlook on future work.

2 MAPE-K Closed-Loop Approach

Software being executed in a cyber-physical system on a device often follows (at least implicitly) the MAPE-K closed-loop design [1, 53] depicted in Figure 1a developed for systems with a high degree of complexity, uncertainty, and dynamicity. Such software interacts with its context in that system via sensors and effectors and keeps a Runtime Model (RTM) to store its local state across its looped executions. It executes (a) the monitoring phase to react to sensor information by updating the RTM accordingly, (b) the analysis phase to determine the impact of the most recent events on its options to achieve its control goals, (c) the planning phase to derive a control plan satisfying suitable quality standards, and (d) the execution phase to send events to the effectors to implement the steps of the derived control plan. Ideally, such a MAPE-K control architecture adapts to unexpected situations at run-time in an ad-hoc manner.

In our approach, the RTM (see Figure 1b) contains (a) a Bounded Forward State Space (BFSS) from the current system state s (derived and maintained at run-time) and (b) a Bounded Backward State Space (BBSS) from unsafe states us (derived at design-time). Both of theses state spaces are (similarly to bounded model checking [50]) derived from the GTS capturing the expected system behavior. Moreover, the RTM contains the controllers derived from these two state spaces, which capture for each depicted state the exiting steps that the shuttle may perform. At run-time the controller obtained from the BFSS and the BBSS are combined by attempting to identify boundary graphs of the BBSS in the leaf states of the BFSS. For a BFSS and BBSS of depth n and k, this combination grants an effective look-ahead of \(n+k\) to the controller. Clearly, the look-ahead should be maximized (taking other aspects such as required response time into account) to provide the controller synthesis procedure with as much information as possible to avoid the execution of overly conservative behavior (such as unnecessarily slowing down the shuttle). Not employing a BBSS only constructing a BFSS of depth \(n+k\) to achieve the same look-ahead \(n+k\) would be exponentially more expensive and, moreover, this additional cost would be incurred at run-time whereas at least the BBSS is obtained in our approach at design-time rendering its cost of construction negligible.

In our approach, the four MAPE phases are as follows.

  • Monitor phase: when the controller is informed via its sensors about a state change from the BFSS root s to state \(s'\), it selects \(s'\) as the new root of the BFSS. Unless the step to \(s'\) was not expected due to uncertainty, \(s'\) is already one of the successors of s contained in the BFSS.

  • Analysis phase: States of the BFSS unreachable from \(s'\) are removed and the GTS model is used to re-extend the BFSS to the chosen depth n. To identify states to be avoided, all leaf states of the BFSS are checked for occurrences of unsafe boundary states of the BBSS. Finally, the run-time controller is then adjusted to the modified BFSS by selecting steps to be prevented that would lead to the states to be avoided.

  • Planning phase: The controller can then plan the execution of any controllable step exiting the new root state \(s'\) of the BFSS (in the running example, these steps are the steps of the shuttle) or let the plant perform the next step.Footnote 1

  • Execute phase: If a step has been selected in the planning phase, this step is send for execution to the corresponding effector (in the running example, a hardware controller of the shuttle will receive and implement such a signal).

The worst-case controller response time depends on the time required for (a) the full reconstruction of the BFSS and the corresponding controller synthesis thereon (upon an occurrence of an unexpected step) and (b) the identification of leaf states of the BFSS containing unsafe boundary states of the BBSS. The usage of the BBSS exponentially reduces the computational effort for (a) as discussed but, regarding (b), it also requires that the leaf states of the BFSS need to be checked against a potentially large number of unsafe boundary states instead of only the unsafe states. In our evaluation in section 8, we measure and further discuss these effects for a considered case study.

As mentioned in the introduction already, we employ a sliding window approach reducing the size of the BFSS and BBSS to be constructed. Instead of assuming that each agent maintains a perspective on the entire system state, we adopt the technique from [30] where, in a compositional approach, agent-specific scopes are used. On the one hand, this greatly reduces the number of steps (and thereby the size of the BFSS and BBSS) as only a small number of agents will be typically in the view range of an agent. On the other hand, a smaller view range may result (closely related to the look-ahead) in an overly conservative controller behavior. Besides mitigating the effect of state space explosion, this sliding window approach has the additional advantage that start states must only be determined for each actor individually and not globally. Intuitively, each system step must be followed by suitable postprocessing to update the reached state to the view range of the actor. These postprocessing steps are part of the system model and therefore define changes in the context of the agent to which the controller must suitably respond. In our evaluation in section 8, we further discuss this sliding window technique as we abstract from it in our running example to focus on controller synthesis via BFSS and BBSS.

3 Related Work

Model checking [2] is often inadequate for complex systems due to the state space explosion problem and uncertainty. Bounded Model Checking (BMC) [24, 25, 50] has been devised to reduce analysis costs providing, however, weaker guarantees and no support for uncertainty.

When formal fully-automatic verification is infeasible, Runtime Verification also called Runtime Monitoring [28] is an approach for monitoring the system’s states and steps at run-time for notable behavior such as violations of invariants that require a manual or automatic response. However, without look-ahead capabilities, potential near-future unsafe states cannot be detected. Therefore, some RV approaches such as [15, 16, 23, 32, 45, 52] integrate a behavioral model describing expected future evolutions of the system.

In [45], the expected future evolutions of a Timed Automata (TA) are analyzed at run-time using BMC. In [15], Deterministic Timed Markov Chains modeling the system are analyzed at design-time to obtain expressions on step-probabilities that will become available at run-time to make probability-maximizing decisions at run-time by evaluating the expressions at run-time instead of performing computationally expensive analysis. In [23], a run-time statistical model checking component has been integrated into a self-adaptive system. However, these approaches also rely on BMC and thereby suffer from state space explosion and in some cases such as [15, 45] also from being unable to react to uncertain events.

The approach of k-induction [11, 26] that has been adopted for variants of GTSs in [3, 47, 48] establishes state invariants by symbolically applying GT rules backwards from unsafe states to accumulate context capturing why and how the symbolic violation could be reached. This approach is thereby a symbolic version of backward BMC. We use a similar approach in this paper tackling the problem of a large number of undesirable backward steps constructed by k-induction.

A combination of forward and backward BMC similar to our approach for the analysis of Hybrid Automata in [54] applies depth first search forward and backward in parallel to find paths to unsafe states for Hybrid Automata with complex state space structure.

SCT as established in [39,40,41] for capturing, analyzing, and synthesizing supervisory control when the controllers, the plants, and their closed loops are given by regular languages over events (see also [27, 46] for an in-depth introduction and a discussion of derived approaches) has to our knowledge not been combined with event-priorities. However, priorities have been used to combine supervised modules preventing blocking situations in [6, 7]. Also, approaches in the Model Predictive Control domain (see [51] for a survey) employ models to predict the future system behavior as in our approach but focus usually on continuous time systems minimizing costs as in [4, 5] and have not been combined with SCT to the best of our knowledge. Besides the approach to distinguish between controllable and uncontrollable events as customary in SCT, other approaches of identifying actions of different actors and capturing interactions among such actors in the GT domain include [9] but also SCT for TA (related to [45] above) has been considered in [42, 43]. [33,34,35,36] where a safety constraint has already been violated due to uncertainty or adversarial effects requiring the derivation and execution of recovery mechanisms.

4 Priority-aware Supervisory Control Theory

We recall SCT as introduced in the seminal work of Ramadge and Wonham [39,40,41] in which the closed loop is given by the event-synchronizing composition of controller and plant. To provide the essentials of this approach in our notation and to extend this approach with the concept of event priorities, we introduce a variant of Labeled Transition Systems (LTSs) extending finite automata thereby capturing regular languages over an event alphabet as considered in standard SCT. In such an LTS, events are grouped into controllable and uncontrollable events (cf. the MAPE-K closed-loop in Figure 1a), which are executed by the controller (e.g., signals to effectors) and the plant (e.g., signals from sensors). The controller may restrict the execution of controllable events in the closed-loop.

We aim at controller synthesis such that event-prevention ensures that the closed-loop avoids undesirable states (this notion is formalized below as non-blockingness) and no steps executing uncontrollable events have been prevented at the model level (this notion is formalized below as controllability) while not preventing event executions unnecessarily to retain the highest possible degree of freedom for further control steps.Footnote 2 We equip events with a priority as motivated in the next section by our running example: steps executing (un)controllable events are then only enabled when no steps executing higher-priority (un)controllable events are enabled (i.e., priorities are checked within the two groups of controllable and uncontrollable events separately).

Definition 1

(Labeled Transition System (LTS)). A Labeled Transition System (LTS) \(\varGamma \) contains the following components.

  • \(\textsf{states}(\varGamma )\) contains all states and its subsets \(\textsf{start}(\varGamma )\), \(\textsf{safe}(\varGamma )\), and \(\textsf{unsafe}(\varGamma )\) contain the start, safe, and unsafe states.

  • \(\textsf{events}(\varGamma )\) contains the controllable and uncontrollable events \(\textsf{eventsC}(\varGamma )\) and \(\textsf{eventsUC}(\varGamma )\).

  •   assigns a priority to each event.

  • \(\textsf{steps}(\varGamma ) \subseteq \textsf{states}(\varGamma ) \times \textsf{events}(\varGamma ) \times \textsf{states}(\varGamma ) \) is a set of event-labelled steps.

Moreover, \(\varGamma _{1} \) is a sub-LTS of \(\varGamma _{2} \), written \(\varGamma _{1} \le \varGamma _{2} \), when the components of \(\varGamma _{1} \) are contained in the corresponding components of \(\varGamma _{2} \) and the reversed LTS \(\textsf{rev}(\varGamma ) \) is obtained by reversing \(\textsf{steps}(\varGamma )\) and swapping \(\textsf{start}(\varGamma )\) and \(\textsf{unsafe}(\varGamma )\).

The priority-resolved LTS is obtained by omitting all controllable/uncontrollable steps disabled by higher-priority controllable/uncontrollable steps. Only the paths through this priority-resolved LTS can actually be observed.

Definition 2

(Priority-resolved LTS). For an LTS \(\varGamma \) and a set of events E, \(\varGamma '=\textsf{resPrio}(\varGamma ,E) \) is the largest sub-LTS of \(\varGamma \) such that for all \((s,e_1,s_1)\in \textsf{steps}(\varGamma ') \) with \(e_1\in E\) there is no \((s,e_2,s_2)\in \textsf{steps}(\varGamma ') \) with \(e_2\in E\) and \(\textsf{prio}(\varGamma ') (e_2)>\textsf{prio}(\varGamma ') (e_1)\). Then, the priority-resolved LTS of \(\varGamma \) is given by \(\textsf{resPrio}(\varGamma ) =\textsf{resPrio}(\textsf{resPrio}(\varGamma ,\textsf{eventsUC}(\varGamma )),\textsf{eventsC}(\varGamma )) \).Footnote 3

A controller \(\varGamma _{C} \) to be synthesized for a given plant \(\varGamma _{P} \) is a sub-LTS of \(\varGamma _{P} \) and, hence, the event-synchronizing closed loop of \(\varGamma _{C} \) and \(\varGamma _{P} \) is just \(\varGamma _{C} \).

The notion of controllability requires that the controller cannot prevent uncontrollable events that the plant can execute.

Definition 3

(Controllability). A plant \(\varGamma _{P}\) and a controller \(\varGamma _{C} \le \varGamma _{P} \) satisfy controllability, if every path \(\pi \) of \(\textsf{resPrio}(\varGamma _{C})\) that can be extended by \(\textsf{resPrio}(\varGamma _{P})\) with a step executing an uncontrollable event \(u\in \textsf{eventsUC}(\varGamma _{P}) \) can be extended by \(\textsf{resPrio}(\varGamma _{C})\) with a step executing u as well.

The notion of non-blockingness requires the liveness property that the closed loop may eventually reach a safe state from any of its states. In our approach, we define unsafe states as those violating a state invariant and safe states as those not having paths to any unsafe states.

Definition 4

(Non-blockingness). A plant \(\varGamma _{P}\) and a controller \(\varGamma _{C} \le \varGamma _{P} \) satisfy non-blockingness, if every path \(\pi \) of \(\textsf{resPrio}(\varGamma _{C})\) can be extended to a state in \(\textsf{safe}(\varGamma _{P})\).

For the case of controllers and plants generating regular languages considered here, admissible controllers satisfying controllability and non-blockingness are closed under arbitrary unions [27, 39,40,41, 46]. Desired controllers are therefore defined as those admissible controllers that result in the largest closed loops in terms of sets of executable event sequences. Admissible controllers are also closed under arbitrary union in the presence of event priorities because the union of controllers will result in a controller that favors the highest priority steps from any of the controllers and, moreover, LTSs are memoryless (beyond their current state) implying that choosing higher priority steps from different controllers can not lead to states not traversable using any of the controllers. However, only the priority resolved versions of synthesized controllers for which the classic results from [27, 39,40,41, 46] readily apply are to be used anyway.

Following SCT, the first controller candidate is the plant LTS \(\varGamma \). This candidate is then incrementally refined by preventing events enforcing controllability and non-blockingness least-restrictively until an admissible controller \(\textsf{control}(\varGamma )\) is obtained (closedness under arbitrary union also implies that the order in which violations of controllability and non-blockingness are resolved is insignificant).

Note that this fixed-point procedure supports also cyclic LTSs in general (in which, as usual, loops may delay the visiting of safe states indefinitely as opposed to [55]). To handle the case with priorities, we resolve priorities among uncontrollable events before applying the fixed-point procedure and resolving priorities of remaining controllable steps afterwards to obtain the priority-aware controller \(\textsf{pControl}(\varGamma )\).

Definition 5

(Priority-Aware Controller). An LTS \(\varGamma \) induces the LTS \(\varGamma '=\textsf{control}(\varGamma ) \) by adapting \(\varGamma \) as follows:Footnote 4

  • \(\textsf{steps}(\varGamma ') \) is the largest subset of \(\textsf{steps}(\varGamma )\) such that for each \((s,e_1,s_1)\in \textsf{steps}(\varGamma ') \) (non-blockingness) there is some path from \(s_1\) to a state in \(\textsf{safe}(\varGamma ') \) using steps in \(\textsf{steps}(\varGamma ')\) and (controllability) when \((s_1,u_2,s_2)\in \textsf{steps}(\varGamma ) \) is a step using an uncontrollable event \(u_2\) from \(\textsf{eventsUC}(\varGamma )\) then \((s_1,u_2,s_2)\) is also a step in \(\textsf{steps}(\varGamma ') \).

Moreover, \(\textsf{pControl}(\varGamma ) =\textsf{resPrio}(\textsf{control}(\textsf{resPrio}(\varGamma ,\textsf{eventsUC}(\varGamma ))),\textsf{eventsC}(\varGamma )) \) is the priority-aware controller for \(\varGamma \).

Fig. 2.
figure 2

Example of controllability and non-blockingness. The unsafe states \(\{s_3,s_4\}\) are given in red with dotted border, the safe state \(s_2\) is given in green with exiting arrow symbol, the remaining orange states have paths to unsafe states, the start state \(s_0\) has an entering arrow symbol, the bold steps execute the uncontrollable events \(\textsf{uc}_i\), the non-bold steps execute the controllable events \(\textsf{c}_i\), the dashed steps have been prevented, the event \(\textsf{c}_2\) has priority 2, the event \(\textsf{c}_1\) has priority 1, the other events have priority 0, and only the boxed event \(\textsf{uc}_1\) can be executed since the steps executing \(\{\textsf{c}_1,\textsf{c}_2\}\) have been prevented.

Full size image

As an example for controller synthesis, consider the LTS in Figure 2 representing an uncontrolled plant and the priority-aware controller synthesized for it.Footnote 5 First, to resolve blocking at \(s_4\), the controllable priority 2 event \(\textsf{c}_2\) from \(s_0\) is prevented enabling the priority 1 event \(\textsf{c}_1\) from \(s_0\). Second, to resolve blocking at \(s_3\), the uncontrollable event \( uc _3\) from \(s_1\) is prevented. Third, to resolve non-controllability at \(s_1\), the controllable priority 1 event \(\textsf{c}_1\) from \(s_0\) is prevented enabling the priority 0 event \(\textsf{uc}_1\) from \(s_0\). The resulting controller will only contain the path from \(s_0\) to \(s_2\) executing the event \(\textsf{uc}_1\). Note that maintaining the steps of all priorities in the LTS simplifies controller synthesis since the effect of preventing controllable events (such as \(\textsf{c}_2\) and \(\textsf{c}_1\)) becomes apparent immediately without the need to derive such steps intermittently for then enabled steps (e.g., only the step executing \(\textsf{c}_2\) was enabled initially due to its priority) decoupling LTS generation and control synthesis.

Note that \(\textsf{control}(\textsf{resPrio}(\varGamma )) \ne \textsf{resPrio}(\textsf{control}(\varGamma )) \) in general because first resolving the priorities restricts the possible controllers to be synthesized. For example, first resolving priorities in Figure 2 would remove the step with the event \(\textsf{uc}_1\), which would otherwise be the only remaining step.

5 Control-oriented Graph Transformation

We first introduce control-oriented GTSs before discussing the modeling of our running example using this formalism.

To ease presentation, we employ the simple class of typed directed graphs (short graphs) (see [12,13,14] for details). In our running example, we employ the type graph \( TG \) from Figure 3a, which can be understood to be a simple UML class diagram, and graphs, which can be understood to be simple UML object diagrams. In visualizations of graphs such as Figure 3b, types of nodes are indicated by their names (i.e., \(S_i\) and \(T_i\) are nodes of type Shuttle and Track), names of edges are omitted, types of edges are only given when required to avoid ambiguity (the only edge types with equal source and target node types are fast, slow, and halt). We denote monomorphisms (monos) from graph H to graph \(H'\) mapping nodes and edges injectively by .

To introduce control-oriented GTSs, we first introduce GT rules used to derive GT steps between graphs. A Graph Transformation (GT) rule \(\rho \) consists of two monos and describing the removal and addition of elements and a set N of monos of Negative Application Conditions (NACs) describing forbidden extensions of L.Footnote 6 We use the abbreviation \(\textsf{lhs}(\rho ) =L\) later on. In visualizations of GT rules (see Figure 3), we use an integrated notation in which L, K, and R are given in a single graph where graph elements marked with \(\ominus \) are from \(L-K\) and will be deleted, graph elements marked with \(\oplus \) are from \(R-K\) and will be created, and where all other graph elements are in K and will be preserved. When NACs are present, they are given on the left side of the \(\triangleright \) symbol. For example, consider the GT rule in Figure 3c which preserves the ambulance and shuttle nodes \(A_1\) and \(S_1\), removes the edge from \(S_1\) to \(A_1\), creates an edge from \(A_1\) to \(S_1\), and is only applicable when \(A_1\) has no edge to some road node \(R_1\).

We now introduce our novel notion of control-oriented GTSs. Such a GTS \(S \) contains a set \(\textsf{start}(S)\) of start graphs, a set \(\textsf{unsafe}(S)\) of unsafe graphs representing violations of invariants, a set \(\textsf{rules}(S)\) of GT rules with the subsets of controllable and uncontrollable GT rules \(\textsf{rulesC}(S)\) and \(\textsf{rulesUC}(S)\), and a mapping \(\textsf{prio}(S)\) assigning a natural number as a priority to each GT rule. Note that, similarly as in our presentation of SCT in section 4, we assign priorities to GT rules and group them into controllable/uncontrollable GT rules capturing which steps can/cannot be prevented by the controller to be synthesized.

GT steps from a graph G to a graph \(G'\) are labeled with a pair \(\sigma =(\rho ,m)\) consisting of a GT rule \(\rho \) and a match identifying an occurrence of \(\textsf{lhs}(\rho )\) in G. The match m must satisfy the requirement that there is no NAC contained in \(\rho \) for which some satisfying \(m_i'\circ n_i=m\) exists. The graph \(G'\) is then constructed from G via the usual Double Pushout (DPO) diagram (see [12,13,14] for a details).

A GTS induces a forward LTS by deriving GT steps from already included graphs and adds these steps as well as their target states in the resulting LTS. Note that we merely propagate the priorities of the GT rules into the constructed LTS instead of enforcing them by excluding lower-priority steps when higher-priority steps are present.

Definition 6

(Forward LTS of a GTS, BFSS). A GTS \(S \) induces the unique LTS as follows:

  • \(\textsf{states}(\varGamma )\) contains \(\textsf{start}(\varGamma )\) and the target states of all steps in \(\textsf{steps}(\varGamma )\).

  • \(\textsf{start}(\varGamma )\) contains the graphs from \(\textsf{start}(S)\).

  • \(\textsf{safe}(\varGamma ) \subseteq \textsf{states}(\varGamma ) \) contains the graphs from which \(\textsf{unsafe}(\varGamma )\) can’t be reached.

  • \(\textsf{unsafe}(\varGamma ) \subseteq \textsf{states}(\varGamma ) \) contains the graphs G into which a mono from some graph \(H\in \textsf{unsafe}(S) \) exists.

  • \(\textsf{eventsC}(\varGamma )\) and \(\textsf{eventsUC}(\varGamma )\) contain the step labels \(\sigma =(\rho ,m)\) of the steps in \(\textsf{steps}(\varGamma )\) where \(\rho \in \textsf{rulesC}(S) \) and \(\rho \in \textsf{rulesUC}(S) \).

  • \(\textsf{prio}(\varGamma ) (\rho ,m)=\textsf{prio}(S) (\rho )\) assigns the priority of the used GT rule \(\rho \).

  • \(\textsf{steps}(\varGamma ) \) is the least relation containing all GT steps from states in \(\textsf{states}(\varGamma )\).

Moreover, the BFSS of depth n, denoted , is the largest sub-LTS of in which all paths starting in \(\textsf{start}(\varGamma )\) through distinct states have length \(\le n\).

Fig. 3.
figure 3

Details on the running example.

Full size image

We now discuss the modeling of our running example, which is a simplification of the case study considered in our evaluation in section 8. We model shuttles driving on a track topology where subsequent tracks are connected using next edges as in Figure 3b. The driving speed of each shuttle is either fast, slow, or halt (as marked using fast, slow, or halt loops). Level crossings (where track and road topology intersect) are indicated by the node type Crossing and are connected to the corresponding track and road segments. Ambulances may appear and drive on the road topology including the level crossings.

The graph in Figure 3b represents the current view of the shuttle on the system state. The ambulance \(A_1\) is not yet connected to a road meaning that it can be ignored by the shuttle at this point. Ambulance and shuttle perform steps alternatingly by switching the directed edge between them in each step to ensure a certain level of fairness since the system would otherwise be fundamentally unsafe as the shuttle could not rule out collisions anymore. The edge from the ambulance to the shuttle indicates that the shuttle will perform the next step.

Shuttles may maintain their speed (events \(\textsf{ff} \), \(\textsf{ss} \), and \(\textsf{hh} \)) or switch between fast and slow (events \(\textsf{fs} \) and \(\textsf{sf} \)) as well as between slow and halt (events \(\textsf{sh} \) and \(\textsf{hs} \)), modeling the stopping and acceleration distance. These seven driving speed transitions are controllable for the shuttle controller but all steps of ambulances are uncontrollable. To allow the shuttle to make timely control decisions, an ambulance detection mechanism informs the shuttle when ambulances are two roads ahead of an upcoming level crossing (i.e., an ambulance would be detected in Figure 3b when it enters the road \(R_2\)). We derive shuttle control assuming that this detection mechanism is reliable but analysis will reveal partial robustness against unreliability in situations where ambulances are detected first on the closer road segments \(R_1\) or even \(R_0\). Note that shuttle and ambulance performing steps alternatingly will result in violations of non-blockingness when the controller prevents all controllable steps of the shuttle in a given state, which is thereby implicitly excluded as well.

We use GT rule priorities to model that the shuttle prefers faster driving speeds over slower driving speeds. Therefore, without preventing any steps, the shuttle will maintain its fast speed.

We now discuss the GT rules used in these GTSs in more detail. Again, shuttle and ambulance steps alternate as implemented by switching the direction of the edge between them in every GT rule. When its the ambulances turn, the GT rules \(\rho _{\textsf{ace}}\), \(\rho _{\textsf{acu}}\), and \(\rho _{\textsf{acp}}\) are applicable when the ambulance has no edge to some road segment yet and the GT rule \(\rho _{\textsf{a}}\) is used otherwise. The GT rule \(\rho _{\textsf{ace}}\) models the expected creation of the ambulance by creating an edge from the ambulance to the road \(R_2\) in Figure 3b (the three NACs check that \(A_1\) is not yet on \(R_1\), that \(A_1\) is not yet on some other road, and that the matched road \(R_1\) has no predecessor). The GT rule \(\rho _{\textsf{acu}}\) models the unexpected creation of the ambulance by creating an edge from the ambulance to an arbitrary road unless this road is at the level crossing with a shuttle being already located there as well (the three NACs check that \(A_1\) is not yet on \(R_1\), that \(A_1\) is not yet on some other road, and that \(S_1\) is not on a track connected by a crossing to \(R_1\)). The GT rule \(\rho _{\textsf{acp}}\) models the case that the ambulance is not yet created meaning that ambulance detection is postponed (the NAC checks that the ambulance is not yet on a road). Lastly, the GT rule \(\rho _{\textsf{a}}\) models the moving of a detected ambulance to the next road segment (by removing the edge from \(A_1\) to the current road segment \(R_1\) and creating such an edge to the road segment \(R_2\) reached). When its the shuttles turn, the GT rules \(\rho _{\textsf{ff}}\), \(\rho _{\textsf{fs}}\), \(\rho _{\textsf{sf}}\), \(\rho _{\textsf{ss}}\), \(\rho _{\textsf{sh}}\), \(\rho _{\textsf{hs}}\), and \(\rho _{\textsf{hh}}\) are used. The GT rules \(\rho _{\textsf{sh}}\) and \(\rho _{\textsf{hh}}\) do not move the shuttle to the next track while the other GT rules do so. Here, the movement of the shuttle is implemented as for the GT rule \(\rho _{\textsf{a}}\) by deleting and creating an edge and the driving speed transitions are encoded by deleting and creating the driving speed loop at the shuttle.

In our running example, we first consider the GTS \(S_{\textsf{FE}} \) with expected ambulance detection: for this GTS, we employ the graph from Figure 3b as start graph, use 10 of the 11 GT rules from Figure 3, split GT rules into controllable and uncontrollable GT rules, and employ priorities as listed in Figure 3i. In particular, when its the ambulances turn, each enabled GT rule has the same priority 0 making all steps derivable using the GT rules \(\rho _{\textsf{ace}}\) and \(\rho _{\textsf{acp}}\) viable. When its the shuttles turn, GT rules setting the speed to halt, slow, and fast have priorities 0, 1, and 2 favoring a faster driving speed. Also, the GT rules for slowing down or remaining halted (\(\rho _{\textsf{fs}}\), \(\rho _{\textsf{sh}}\), and \(\rho _{\textsf{hh}}\)) cannot be prevented as this would lead to a violation of non-blockingness as discussed. Additionally, we consider a second GTS \(S_{\textsf{FU}} \) in which ambulances are possibly detected closer or on the level crossing: this GTS differs from \(S_{\textsf{FE}} \) by replacing the GT rule \(\rho _{\textsf{ace}}\) with \(\rho _{\textsf{acu}}\) for detecting an ambulance, which may result in up to four steps detecting the ambulance on any of the four road segments.

In the considered GTSs, only a finite number of graphs can be reached and, in the remainder, we represent each graph using an element of where (a) means that the ambulance has not been detected yet, \(\textsf{0}\)–\(\textsf{2}\) is the distance of the ambulance to the crossing, and means that the ambulance has advanced beyond the crossing, (b) \(\textsf{0}\)–\(\textsf{4}\) is the distance of the shuttle to the crossing and means that the shuttle has advanced beyond the crossing, (c) \(\textsf{f}\), \(\textsf{s}\), and \(\textsf{h}\) is the driving speed of the shuttle, and (d) \(\textsf{s}\) or \(\textsf{a}\) means that the shuttle or the ambulance performs the next step. The start graph from Figure 3b is therefore represented by as the ambulance has not yet been detected, the shuttle is four tracks away from the level crossing, the shuttle is in fast driving speed, and the shuttle will perform the next step.

The 6 unsafe graphs in \(\{\mathsf 0\}\times \{\mathsf 0\}\times \{\textsf{f},\textsf{s},\textsf{h}\}\times \{\textsf{s},\textsf{a}\}\) of the considered GTSs \(S_{\textsf{FE}} \) and \(S_{\textsf{FU}} \) all contain a shuttle and an ambulance on the level crossing but differ in the three possible driving speeds of the shuttle and the two cases of which entity performs the next step. While we specify the set of all unsafe states in our GTS by providing it explicitly, unsafe states could also be identified using advanced approaches such as nested graph conditions, Linear Temporal Logic [37], Computation Tree Logic [2, 8], or Metric Temporal Graph Logic [49].

The controller to be synthesized should force the shuttle to drive fast unless an ambulance is present, in which case the controller should ensure that the shuttle reaches the track \(T_1\) with slow speed and then halts there until the ambulance has passed the level crossing. The controller synthesized by our integrated approach results in this controller as discussed subsequently.

6 Design-time Control-synthesis

We now discuss design-time control synthesis based on (a) BBSS generation from unsafe states and (b) control synthesis based on SCT together resulting in an LTS with unsafe boundary to be avoided at run-time to avoid unsafe states and a safe boundary for which the LTS is a controller avoiding unsafe states.

For our running example, we start the BBSS generation using only two unsafe states for presentation purposes. We depict the obtained BBSS in Figure 4, which is constructed by adding up to k steps backwards from \(X_0\). From all additional states \(X_1\), unsafe states in \(X_0\) can be reached by construction; to derive viable alternative steps avoiding unsafe states, we include all missing forward steps from states in \(X_1\) to additional states \(X_2\). The states \(X_2\) are by construction safe states (indicated by the exiting arrow symbol) of the resulting LTS from which unsafe states in \(X_0\) cannot be reached (within k steps). The start states of the constructed backward LTS are the last states traversed on each backward path (indicated by the entering arrow symbol). These start states will be grouped into the safe and unsafe boundary in the next step.

We construct a controller from the BBSS given in Figure 4 by applying SCT. First, the two unsafe states and violate non-blockingness. To make these states unreachable, all five steps with one of them as a target are prevented resulting in a violation of non-blockingness at . To make this state unreachable, the step is prevented resulting in a violation of controllability at . To make this state unreachable, all three steps with as target are prevented. Due to event-priorities, only the boxed events can be actually executed. Intuitively, the depicted controller ensures that, in the presence of an ambulance approaching the upcoming level crossing, the shuttle will avoid collisions, e.g., by halting in state . When the ambulance is created unexpectedly closer to the crossing using \(\rho _{\textsf{acu}}\) in \(S_{\textsf{FU}} \), the controller obtained here will fail since it would enter track \(T_1\) with fast speed when no ambulance is detected reaching state and then not be able to halt in front of the level crossing when the ambulance is then unexpectedly detected on the level crossing in the next step reaching state .

Fig. 4.
figure 4

Design-time controller synthesis based on BBSSs. We reuse the notation from Figure 2 for start states, unsafe states, safe states, potentially unsafe states, steps executing controllable/uncontrollable events, and prevented steps. The depicted BBSS of depth 3 and the resulting synthesized controller for the GTS \(S_{\textsf{BE}} \) (or the GTS \(S_{\textsf{BU}} \)) based for brevity on only two of the six unsafe states. The two unsafe states can be avoided resulting in an empty unsafe boundary.

Full size image

Technically, we construct the BBSS for a given GTS relying on a secondary GTS called the backward GTS: We generate the BFSS for the backward GTS (according to Definition 6), reverse the obtained LTS (according to Definition 1), and then add the missing forward steps to safe states as explained above. For our running example, we employ the backward GTSs \(S_{\textsf{BE}} \) and \(S_{\textsf{BU}} \), which can be obtained from their forward counterpart GTSs \(S_{\textsf{FE}} \) and \(S_{\textsf{FU}} \) by reversing their GT rules (see, e.g., [14, Lemma 3.14] for rule reversal based on the L operation) and switching the sets of unsafe and start graphs. The reason for using a backward GTS is a reduced size of the BBSS, since (not simply using rule reversal) modeling the backward GTS separately (while still ensuring that it agrees with the forward GTS as discussed in the next section) as in the case study considered in section 8 allows to enforce known system invariants (such as a minimum distance between level crossings or upper bounds of shuttles in certain areas) to reduce the number of derived steps.

Definition 7

(Backward LTS of a GTS, BBSS). A (backward) GTS \(S \) induces the LTS by adapting as follows:

  • \(\textsf{states}(\varGamma ) \) contains \(\textsf{states}(\varGamma ') \) and the safe states \(\textsf{safe}(\varGamma )\).

  • \(\textsf{safe}(\varGamma ) \) contains the target graphs of all steps in \(\textsf{steps}(\varGamma )-\textsf{steps}(\varGamma ') \).

  • \(\textsf{steps}(\varGamma ) \) contains \(\textsf{steps}(\varGamma ') \) and all GT steps from states in \(\textsf{states}(\varGamma ') \).

Moreover, the BBSS of depth k, denoted , is the largest sub-LTS of in which all paths through distinct states ending in \(\textsf{unsafe}(\varGamma )\) have length \(\le k\).

We now apply the procedure \(\textsf{pControl}\) to the BBSS to derive the design-time controller. The unsafe boundary for which no suitable control could be derived is then given by all start states without an outgoing step and the safe boundary is given by the remaining start states (for which a controllable path to a safe state could be established).

Definition 8

(Design-time Controller). If \(S \) is a (backward) GTS and , then is the design-time controller with unsafe boundary \(\textsf{uBoundary}(S,k) =\{s\in \textsf{start}(\varGamma ) \mid \not \exists (s,e,s')\in \textsf{steps}(\varGamma ) \}\).

The design-time controller for the BBSS in Figure 4 is constructed for \(k=3\) and has an empty unsafe boundary. However, when using \(k=2\) (removing the states in the first row and the safe states in the second row), we obtain a design-time controller with safe boundary and unsafe boundary .

Fig. 5.
figure 5

Design-time controller synthesis with unexpected shuttle detection

Full size image

As a further example, consider Figure 5 in which the uncontrollable event \(\textsf{acu} \) is used by the GTS \(S_{\textsf{FU}} \) for an unexpected shuttle detection leading to a non-empty unsafe boundary . In comparison, the controller obtained for \(S_{\textsf{FE}} \) not assuming unreliable ambulances detection as in the step is robust by also avoiding (according to Figure 4) the state preceding a collision in Figure 5. Moreover, this controller is robust against ambulances appearing unexpectedly directly on the crossing using the step unless the shuttle is already closer via step . Also, when an ambulance appears one track ahead of the crossing, either no collision occurs (after step ) or the ambulance crashes into the shuttle (after step ).

7 Run-time Control-synthesis

At run-time, we employ a given (forward) GTS \(S_{\textsf{FS}} \) to derive the run-time controller as follows. First, we adapt \(S_{\textsf{FS}} \) into \(S_{\textsf{FS}} '\) by using the current state of the system as the unique start state and add \(\textsf{uBoundary}(S_{\textsf{BS}},k)\) to the set of unsafe states. Second, we construct the BFSS of depth n (which is assumed to be maintained throughout system execution as described in section 2) for \(S_{\textsf{FS}} '\). Third, we apply SCT to obtain the least-restrictive controller.

Definition 9

(Run-time Controller). If \(S \) is the GTS obtained from the forward GTS as the adjustment to the current system state and the unsafe boundary of the design-time controller and , then is the run-time controller with leaf set \(\textsf{leafs}(S,n) =\{s\in \textsf{states}(\varGamma ) \mid \not \exists (s,e,s')\in \textsf{steps}(\varGamma ) \}\).

We now discuss in more detail how our run-time control synthesis obtains an effective look-ahead of \(n+k\) steps towards unsafe states given by the n steps of \(\varGamma \) and the k steps of the design-time BBSS.Footnote 7 To this end, we first define a simulation relation to capture when a backward GTS such as \(S_{\textsf{BE}} \) and \(S_{\textsf{BU}} \) for our running example is correct w.r.t. a forward GTS such as \(S_{\textsf{FE}} \) and \(S_{\textsf{FU}} \) for our running example. Since we do not consider the step labels (containing the GT rules or matches applied in these steps), we can understand this simulation to be a weak simulation in which one step of the forward GTS is simulated (backwards) by the backward GTS using any number of GT steps.

Definition 10

([Simulation Relation for GTS-based LTSs). Given two LTSs \(\varGamma \) and \(\varGamma '\) induced from GTSs according to Definition 6 and Definition 7. A set R of morphisms from states \(G_1'\in \textsf{states}(\varGamma ') \) to states \(G_1\in \textsf{states}(\varGamma ) \) is a simulation relation from \(\varGamma \) to \(\varGamma '\), if for every \((G_2,\sigma ,G_1)\in \textsf{steps}(\varGamma ) \) capturing the forward GT span there is a sequence of GT steps that can be combined (using an iterated E-concurrent GT rule, [12, Theorem 3.26]) into the backward GT span such that and exist satisfying \(f_2\in R\), \(f_2\circ g_2'=g_2\circ d_1\), and \(f_1\circ g_1'=g_1\circ d_1\).

figure az

The following theorem then states that the existence of such a simulation relation R from the forward GTS to the backward GTS containing at least all embeddings of unsafe states V into the graphs reachable in the forward GTS within k steps is sufficient to ensure that any safety violation of the forward GTS within n to \(n+k\) steps is detected by checking the states reachable by n steps in against the start states of . Note that Theorem 1 does not exclude spurious violation paths in terms of path pairs \((\pi _1,\pi _2)\) that are not composable to a path \(\pi \) of \(S_{\textsf{FS}} \) due to application conditions in GT rules used in \(\pi _1\) or \(\pi _2\). Moreover, note that paths to unsafe states of length at most n steps are detected by constructing already.

Theorem 1

(Violation Detection). Given a forward GTS \(S_{\textsf{FS}}\), a backward GTS \(S_{\textsf{BS}}\), and an unsafe graph V contained in \(\textsf{unsafe}(S_{\textsf{FS}})\) and \(\textsf{unsafe}(S_{\textsf{BS}})\), every violation detected in in terms of some path \(\pi \) of length \(>n\) from \(\textsf{start}(S_{\textsf{FS}})\) to a graph containing V is correspondingly detected by the combined technique using and by two paths \(\pi _1\) of length n from \(\textsf{start}(S_{\textsf{FS}})\) to a graph containing B and \(\pi _2\) of length \(\le k\) from some \(B'\) (for which some exists) to the graph V whenever there is a simulation relation R from to containing every mono into states G of .

Proof

(sketch). By induction on k, we derive the existence of an embedding of the last graph B of \(\pi _2\) into the last graph of \(\pi _1\) ensuring that steps in \(\pi \) reaching a violating graph can be mimicked backwards via the simulation relation.

This theorem thereby ensures that the system has an effective look-ahead of \(n+k\) steps at run-time towards unsafe states allowing it to derive suitable control decisions to avoid such unsafe states (if possible for that effective look-ahead).

8 Evaluation

As a case study, we now consider a more complex variation of the running example, including additional track features such as junctions, explicit modeling of monitoring and signals (traffic lights for shuttles and ambulances). The used GTSs modeling this case study ensure that the sliding window perspective of the controlled shuttle is enforced by removing track and road segments behind the shuttle and enlarging the track/road topology forwards, potentially also including junctions, level crossing, and further components in a way to be expected by the shuttle. While we simply used the reversed rules for the backward GTSs in the running example, this would generate here for our case study, as for typical applications of the related approach of k-induction, a large number of unrealistic track topologies that would need to be singled out using other techniques such as structural constraints reducing the applicability and performance of our approach at design-time. Applying Theorem 1, we constructed a backward GTS with 31 GT rules by hand such that all steps of the forward GTS with 34 GT rules can be mimicked by at most two backward steps while minimizing the overapproximation of additional track topologies that are never reachable in the forward GTS. We used the tool Groove [17, 44] and provide the documented model files an explanation of our evaluation steps online.Footnote 8

Fig. 6.
figure 6

Evaluation results. Look-ahead for “forward to collision”, effective look-ahead for “forward to unsafe boundary”, and depth of BBSS for “backward from collision”.

Full size image

We evaluated the efficiency of our integrated approach in terms of consumed time by comparing it to the case where only a BFSS is constructed at run-time.Footnote 9 First, we use Groove to construct BFSSs of the forward GTS (for different bounds) thereby simulating the case where our approach is not used. Second, we use Groove to construct BBSSs of the backward GTS (for different bounds) also acquiring the unsafe boundary graphs thereby simulating the design-time aspect of our approach. Finally, we use Groove to construct the BFSS of the forward GTS (for different bounds) using the unsafe boundary graphs as target graphs (which means that the overhead of attempting to match the unsafe boundary graphs is included in our measurement) thereby simulating the run-time aspect of our approach. Generating the entire BFSS (for a given bound) instead of only adjusting it to the last observed step means that we consider the worst-case situation in which the entire BFSS is to be reconstructed due to, e.g., an unexpected step of the system. According to Figure 6 (forward to collision), the BFSS construction requires exponential run-time. In particular, collisions are detected at depth 13 requiring 188min, indicating that only using a BFSS may incur inacceptable costs at run-time. According to Figure 6 (backward to collision), the BBSS grows much slower compared to the BFSS because of (a) our usage of a separate backward GTS and (b) the restriction of considering paths that definitely lead to unsafe states. Hence, increasing the bound k for this BBSS is more advantageous compared to increasing the bound n for the BFSS in this scenario. Lastly, according to Figure 6 (forward to unsafe boundary), the first member of the unsafe boundary is found at run-time in the BFSS at depth 8 requiring 8s with an effective look-ahead of 13 (as the depth 7 BBSS captures 5 forward steps of the forward GTS), which is 1423 times faster. We conclude from our evaluation that the goal of shifting computation time (and memory costs) from run-time to design-time is achieved by a factor of 1423 for the case study.

We note that applying our approach using a value \(k>0\) can increase the run-time cost. This would be the case when the forward/backward GTSs are constructed and the values of n and k are selected such that the time required for checking the leaf states of the run-time controller against the unsafe boundary of the design-time controller exceeds the time saved by generating at run-time a BFSS of depth n instead of \(n+k\). This may be the case when, e.g., the BBSS contains a large number of infeasible paths (in the sense that the forward GTS cannot exhibit (instantiations of) them for the considered start states) resulting in an unsafe boundary containing a large number of states that can never be matched. While this issue did not arise for the case study considered here where run-time cost was decreased by a factor of 1423, this issue can be mitigated when it arises by employing assumed state invariants (capturing infeasibility of paths) to exclude states from the BBSS following the approaches in [3, 47, 48].

9 Conclusion and Future Work

In this paper, we presented a novel control-theoretic approach to run-time control for Graph Transformation Systems (GTSs) with priorities modeling large-scale systems with the threat of unexpected events. For the actor to be controller, we combine controllers synthesized at design-time and run-time with look-aheads n and k to obtain combined controllers with look-ahead \(n+k\). An evaluation based on a shuttle transportation system shows a decrease of run-time computation cost by a factor of 1423 compared to using only run-time controllers with the same look-ahead suggesting that our approach successfully shifts a large amount of run-time computation cost to design-time. Moreover, we exemplified the robustness of the devised controlled system against unexpected events.

In the future, we will extend our approach to Interval Probabilistic Timed Graph Transformation Systems [31] to model cyber-physical systems and the steps of the contained actors more precisely, incorporate techniques to minimize checking time against unsafe boundary nodes, and combine k-induction with hand-coded backward GTSs to obtain small Bounded Backward State Spaces (BBSSs) that are correct w.r.t. the forward GTS by design.