Log In Sign Up

Robustifying Controller Specifications of Cyber-Physical Systems Against Perceptual Uncertainty

Formal reasoning on the safety of controller systems interacting with plants is complex because developers need to specify behavior while taking into account perceptual uncertainty. To address this, we propose an automated workflow that takes an Event-B model of an uncertainty-unaware controller and a specification of uncertainty as input. First, our workflow automatically injects the uncertainty into the original model to obtain an uncertainty-aware but potentially unsafe controller. Then, it automatically robustifies the controller so that it satisfies safety even under the uncertainty. The case study shows how our workflow helps developers to explore multiple levels of perceptual uncertainty. We conclude that our workflow makes design and analysis of uncertainty-aware controller systems easier and more systematic.


Workflow Automation for Cyber Physical System Development Processes

Development of Cyber Physical Systems (CPSs) requires close interaction ...

YAP: Tool Support for Deriving Safety Controllers from Hazard Analysis and Risk Assessments

Safety controllers are system or software components responsible for han...

Offline and online monitoring of scattered uncertain logs using uncertain linear dynamical systems

Monitoring the correctness of distributed cyber-physical systems is esse...

Neural Simplex Architecture

We present the Neural Simplex Architecture (NSA), a new approach to runt...

Input-to-State Safety with Input Delay in Longitudinal Vehicle Control

Safe longitudinal control is discussed for a connected automated truck t...

Bounded and Approximate Strong Satisfiability in Workflows

There has been a considerable amount of interest in recent years in the ...

A Case for Microservices Orchestration Using Workflow Engines

Microservices have become the de-facto software architecture for cloud-n...

1 Introduction

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 [12]. 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.

Figure 1: Overview of our uncertainty handling workflow

Our workflow assumes Event-B [2] as the modeling formalism and we have implemented the workflow as a plug-in of the IDE for Event-B (§ 5).

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 § 36, we describe the following contributions, before discussing related work and concluding in § 78.

  • A method for injecting given perceptual uncertainty into a given model (§ 3).

  • Two methods for automated robustification of a controller (§ 4).

  • An implementation of the whole workflow (§ 5).

  • A case study of analyzing the maximum allowed level of uncertainty (§ 6).

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.

2  State space 
3  Invariants
4    Safety invariant 
5  Initial states 
6  Transition function , given by
7     where
8    Plant event 
9      Parameter set 
10      Guard 
11      Action 
12    Controller event 
13      Parameter set 
14      Guard 
15      Action 
16  Subject to :  ‘\label{line:CPModelPartitioning}‘
Figure 2: A controller-plant model

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 into

    plant 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 [2]. 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 [2]. 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:e1Begin3), the controller uses the heater to increase the temperature by an appropriate amount . If the temperature is already appropriate (Lines LABEL:ex:ht0:e2Begin3), the controller changes the temperature within the safety region . If the temperature is too hot (Lines LABEL:ex:ht0:e3BeginLABEL:ex:ht0:e3End), the controller cools the water appropriately.

2  State space                 /* variables  and  */
3  Invariants
4    Safety invariant 
5  Initial states 
6  Plant event                 /*  */
7    Parameter set                 /* parameter  */
8    Guard 
9    Action 
10  Controller event                 /*  */‘\label{ex:ht0:e1Begin}Parameter set /* parameter */ Guard Action   Controller event                 /*  */‘\label{ex:ht0:e2Begin}Parameter set /* parameter */ Guard Action   Controller event                 /*  */‘\label{ex:ht0:e3Begin}    Parameter set                 /* parameter  */
11    Guard 
12    Action ‘\label{ex:ht0:e3End}‘
Figure 3: The heater model

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 ).

Let be a controller-plant model (Def. 1, Fig. 2), and be a function such that . We call uncertainty specification. Uncertainty injection is a construction that returns the Event-B model shown in Fig. 4.

2State space 
3Invariants ()
4  Safety invariant  /* events may violate this */ ‘\label{line:UncertaintyInjectedSafetyInvariant}Uncertainty invariant Initial states  ‘\label{line:UncertaintyInjectedUncertaintyInitState}Transition function , given by where Plant event Parameter set Guard     Action  ‘\label{line:UncertaintyInjectedPlantAction}Controller event Parameter set Guard     Action  ‘\label{line:UncertaintyInjectedCtrlAction}Subject to :  ‘\label{line:UncertaintyInjectedPartitioning}‘
Figure 4: The controller-plant model given by uncertainty injection from (Fig. 2) and . Here are true states while are perceived states. Note that may not preserve due to the uncertainty.

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:UncertaintyInjectedPlantActionLABEL: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:UncertaintyInjectedPlantActionLABEL: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 ).

Fig. 5 is the model given by injecting the uncertainty to (Fig. 3). Here the uncertainty specification is

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 .

3  Invariants
4    Safety invariant ‘\label{line:exampleInjected:safetyInvariant}Uncertainty invariant Controller event /* */‘    Parameter set                 /* parameter  */
5    Guard  ‘\label{line:exampleInjected:guard}    Action  
Figure 5: The heater model produced by uncertainty injection

4 Robustification

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 .

Figure 6: Uncertainty robustification

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.

There are different ways that the actions of these heterogeneous events can be defined, leading to the two robustification methods presented in §4.24.3.

  • 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 .

2(State space, invariant, and initial states are the same as )
3  Transition function , given by
5    Plant event 
6    Controller event ‘\label{line:PreservingRobustificationEvent}Parameter set       Guard 
7        ‘\label{line:PreservingRobustificationUGuard}‘ /* : a potential true state */
8         ‘\label{line:PreservingRobustificationParameter}       Action 
9        ‘\label{line:PreservingRobustificationAction}  Subject to :  ‘\label{line:PreservingRobustificationPartitioning}‘
Figure 7: A controller-plant model produced by action-preserving robustification from from Fig. 4

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:PreservingRobustificationParameter7).

Theorem 4.1.

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.

Then satisfies the partitioning requirement (Fig. 7, Line LABEL:line:PreservingRobustificationPartitioning), and is invariant-preserving and feasible (Def. 2).

We judge the success of the action-preserving robustification by the condition in Thm. 4.1. If it fails, then we try the action-repurposing robustification (Fig. 1).

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:stateGuardBegin8) mean that in this event (Line LABEL:line:PreservingRobustificationUGuard of Fig.7). Constraints on parameters (Lines LABEL:line:examplePreserving:paramGuardBegin8) 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:stateGuardBegin8 mean that . Also, Lines LABEL:line:examplePreserving:paramGuardBegin8 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 .

3  Controller event           /*  */
4    Parameter set                 /* parameter  and  */
5    Guard 
6      ‘\label{line:examplePreserving:stateGuardBegin}       ‘\label{line:examplePreserving:paramGuardBegin}        ‘\label{line:examplePreserving:actionNonemptyGuard}    Action  
Figure 8: The heater model produced by action-preserving robustification

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