The core function of controller systems is perceiving the state of the plant and taking appropriate actions to satisfy desirable properties of the plant. In reality, however, such interactions have uncertainty. Particularly, perceptual uncertainty, namely the gap between the true value of the plant and a perceived value is significant, because basing a controller’s action on an incorrect state can cause safety risk. For example, misperceiving the position of a car ahead may make the difference between a collision and safely following it . Therefore, for safety, developers need to account for perceptual uncertainty when constructing controllers.
However, designing a controller to address its core requirements at the same time as addressing perceptual uncertainty can be complex. In addition, the details of perceptual uncertainty may be unclear at the design phase since they can depend on the environment where the controller system is deployed. An alternative is to add support for perceptual uncertainty to an existing controller in such a way that it provides formal safety guarantees.
In this paper, we propose a workflow for robustifying a model of an uncertainty-unaware controller against perceptual uncertainty. Specifically, the whole workflow (Fig. 1) is composed of three methods. The first method (uncertainty injection, § 3) takes an uncertainty-unaware model of the controller and plant (original model , § 2) and a specification of perceptual uncertainty (uncertainty specification ) as the input, and injects into to obtain an uncertainty-aware version, . The model may be unsafe and the next two methods attempt to robustify it to return it to safety. The more conservative action-preserving robustification method is attempted first producing model . If this model is not feasible, the more aggressive action-repurposing robustification method is applied to to obtain model . When the level of uncertainty is too large, will too fail to be feasible. In this case, the developer may take other manual actions such as upgrading sensor devices to decrease the level of uncertainty or relax the safety invariant.
With our workflow, developers can start with constructing and analyzing controllers without considering perceptual uncertainty, and then handle the uncertainty as a second step. Moreover, the generated model of a robustified controller is suitable for analysis because it defines a set of constraints the controller should satisfy. For instance, if we use an uncertainty specification parameterized with the level of uncertainty, then the generated model is also parameterized with the level, and therefore it facilitates the exploration of different levels such as finding the maximum allowed uncertainty. We demonstrate this in § 6.
Contributions and paper structure.
In § 2, we introduce a special sort of Event-B model of controller systems, assumed as input. In § 3–6, we describe the following contributions, before discussing related work and concluding in § 7–8.
2 Controller-Plant Models in Event-B
We require a specific format for an input Event-B model to our workflow.
Definition 1 (A controller-plant model).
A controller-plant model is an Event-B model that follows the format shown in Fig. 2.
In essence, an Event-B model is a transition system with a designated set of initial states, equipped with invariants that are meant to be transition-preserved (i.e., ). (In an Event-B model, “invariants” are something stated as invariants and checked if they are indeed transition-preserved—see Def. 2.) In Event-B, transitions are specified by events , each coming with a parameter set , a guard (the transition is enabled if the guard is true), and a function called an action.
Def. 1 imposes the following additional key assumptions on Event-B models.
Events are classified intoplant events and controller events, since our target systems are closed-loop control systems with controllers and plants. and denote the numbers of plant and controller events, respectively.
A partitioning requirement is imposed in Line LABEL:line:CPModelPartitioning—it is the responsibility of the modeler to ensure that satisfies this property. The requirement says that, from each state , only one controller event is enabled.
The following “correctness” notions are standard in Event-B . The presentation here is adapted to controller-plant models.
Definition 2 (Invariant preservation, feasibility).
Let be a controller-plant model presented as in Def. 1.
is invariant-preserving if 1) the safety invariant is indeed transition-preserved (i.e., ), and 2) .
’s controller is feasible if controller events have feasible actions, that is precisely,
When using a controller-plant model as the input to the workflow in Fig. 1, we assume that is invariant-preserving and feasible.
Example 1 (The heater model ).
The Event-B model in Fig. 3 models a heater(-cooler) system in a pool.111For clarity, we use a different notation than Event-B’s standard syntax . Due to an unstable water source, the pool temperature can randomly change (the plant event ). The system heats or cools the pool so that the temperature becomes between C and C.
To state that the safety invariant should be checked only after the behavior of the controller (the heater system), the “turn” variable indicates if the current state is after plant’s () or controller’s () behavior. There are three controller events (events ). If the temperature is too cold (Lines LABEL:ex:ht0:e1Begin–3), the controller uses the heater to increase the temperature by an appropriate amount . If the temperature is already appropriate (Lines LABEL:ex:ht0:e2Begin–3), the controller changes the temperature within the safety region . If the temperature is too hot (Lines LABEL:ex:ht0:e3Begin–LABEL:ex:ht0:e3End), the controller cools the water appropriately.
3 Uncertainty Injection
The first step of our workflow (Fig. 1) is to inject specification of potential perceptual uncertainty to an input model —a controller-plant model that does not include perceptual uncertainty. In the following definition, the function specifies the kind of uncertainty to be taken into account.
Definition 3 (Uncertainty injection ).
The key difference of from (Fig. 2) is that the state space is duplicated— i.e., is the state space of . In , is a true state and is a perceived state. The rest of the model closely follows , but whether a plant event is enabled or not is decided based on the true state (Line 4); while, the guard of a controller event looks at the perceived state (Line 4). Note, however, that, all actions and act on true states ( and ). In particular, controller actions are assumed to operate on the plant (i.e., the physical reality) via actuators. In Line LABEL:line:UncertaintyInjectedSafetyInvariant, the safety invariant checks if the true state is safe.
The uncertainty specification occurs in Lines 4, LABEL:line:UncertaintyInjectedUncertaintyInitState, LABEL:line:UncertaintyInjectedPlantAction, LABEL:line:UncertaintyInjectedCtrlAction. Lines LABEL:line:UncertaintyInjectedPlantAction & LABEL:line:UncertaintyInjectedCtrlAction model the assumption that perception is made after each action with respect to the current true state ()—this means in particular that perception errors do not accumulate over time. The uncertainty invariant is added in (Line 4); this is maintained by the definition of actions (Lines LABEL:line:UncertaintyInjectedPlantAction & LABEL:line:UncertaintyInjectedCtrlAction). We also note that the partitioning requirement (Line LABEL:line:UncertaintyInjectedPartitioning) for remains satisfied.
Although the original model is “safe” (in the Event-B sense of invariant preservation, see §2), the uncertainty-injected model may not be invariant-preserving. In §4, we present syntactic model transformations to make it safe.
Example 2 (The heater model ).
This specifies that sensed values of temperature can have errors up to 3C.
The controller does not preserve the safety invariant (Line LABEL:line:exampleInjected:safetyInvariant). For example, when and , the event (Line 5) can fire with parameter — i.e., with perceived and maximum safe temperature , the controller thinks that it can raise the temperature by . This leads to , violating the safety invariant .
We propose two syntactic transformations that modify the uncertainty-injected controller for the purpose of regaining safety. They are called action-preserving robustification and action-repurposing robustification , respectively.
4.1 Types of Robustified Events
The basic idea is as follows, common to the two robustification transformations.
Assume the situation on the left in Fig. 6. If the controller was sure that the true state belonged to the region of ,222This is the same as , see Fig. 4, Line 4. then the controller could take the action . This way the controller can achieve the system’s safety, since the original model is safe. (Note that we implicitly rely on the partitioning requirement of , Fig. 2, Line LABEL:line:CPModelPartitioning). Unfortunately, the controller cannot be sure that the true state belongs to the region of because, due to uncertainty, the set of potential true states overlaps with the region of another guard . Therefore, it is not clear from just looking at the perceived state whether the controller should take the controller action or .
To overcome the challenge, we first refine the partitioning of the state space—so that each compartment stands for the set of controller actions that are potentially enabled. For example, on the right in Fig. 6, we have seven compartments, such as for “the true state must be either in or in .”
We create new events for the new compartments that arise this way (i.e., for those states that potentially enable multiple controller actions). These new events are called heterogeneous events. For example, on the right in Fig. 6, we have four heterogeneous events , in addition to the homogeneous events , which are for cases where the controller is sure that it can use a particular action.
In action-preserving robustification , the set of states reachable with a heterogeneous event is the intersection of those reachable with . Therefore, the action of a heterogeneous event satisfies all requirements satisfied by . This way, the system generated with this method can be forward-simulated333This does not mean the refinement in Event-B, which requires every concrete event to have guards stronger than guards of abstract events. by the original system , that is, any execution trace of is an execution trace of (). In particular, is safe since so is .
In action-repurposing robustification , the action of a heterogenerous event does not consider satisfying all requirements satisfied by . The event uses at least one (but not necessarily all) of with parameters that are guaranteed to preserve the safety invariant regardless of which guard can be satisfied by the true state. Therefore, an action originally from may be invoked from the region of the guard of with , making the behavior of the resulting model different from that of . In this way, actions from one event may be “repurposed” for another event, hence the name of the method.
In our workflow (Fig. 1), we prefer the action-preserving robustification since it yields a controller that can be forward-simulated by the original one. In case it is not feasible (i.e., when no action is shared by the events ), we try the action-repurposing robustification.
4.2 Action-Preserving Robustification
Definition 4 (Action-preserving robustification ).
Action-preserving robustification is a construction that takes an Event-B model as shown in Fig. 4 as input, and returns the Event-B model in Fig. 7. In Fig. 7 (and elsewhere below), we use the following functions.
The function returns, for each state (in the original system ), the index of the unique controller event enabled at in the original model . That is, holds.
The function takes a state and returns the set of parameter values that are compatible, that is, .
The function takes a state and returns , i.e., the set of parameter values compatible with any state that is in the -neighborhood of and enables .
The parameter value for the index may be (Line 7) such that . means that there is no -th parameter that satisfies constraints on parameters for safety and feasibility (Lines LABEL:line:PreservingRobustificationParameter–7).
Regarding the model in Def. 4 (Fig. 7), assume the following condition (i.e., for all events, there exist parameter values such that they are compatible with all possible states under the -uncertainty and there exist actions common in all original actions) is satisfied.
Example 3 (The heater model ).
Fig. 8 is an excerpt from the model obtained by applying the action-preserving robustification to (Fig. 5) showing the heterogeneous event generated from the event and the event from . Constraints on the perceived temperature (Lines LABEL:line:examplePreserving:stateGuardBegin–8) mean that in this event (Line LABEL:line:PreservingRobustificationUGuard of Fig.7). Constraints on parameters (Lines LABEL:line:examplePreserving:paramGuardBegin–8) mean that and are compatible with every state around (Line LABEL:line:PreservingRobustificationParameter of Fig.7). Line LABEL:line:examplePreserving:actionNonemptyGuard means that there are common actions in and (Line 7 of Fig.7).
The event is indeed feasible and it preserves the safety invariant as all other events of do. Lines LABEL:line:examplePreserving:stateGuardBegin–8 mean that . Also, Lines LABEL:line:examplePreserving:paramGuardBegin–8 mean that and . In addition, line LABEL:line:examplePreserving:actionNonemptyGuard requests that , thus . Since , we can guarantee that is preserved, namely . For example, if , then . In case of , the event would heat to increase the temperature by where (Line LABEL:line:examplePreserving:paramGuardBegin). Otherwise (i.e., ), the event would change the temperature for where (Line 8). The common actions here are changing temperature by , which is safe for all .
4.3 Action-Repurposing Robustification
Definition 5 (Action-repurposing robustification ).
Action-repurposing robustification is a construction that takes an Event-B model as shown in Fig. 4 as input, and returns the Event-B model