Supervisory controller synthesis and implementation for safety PLCs

Abstract

The development of supervisory controllers for cyber-physical systems is a laborious and error-prone process. Supervisor synthesis enables control designers to automatically synthesize a correct-by-construction supervisor from a model of the plant combined with a model of the control requirements. From the supervisor model, controller code can be generated which is suitable for the implementation on a programmable logic controller (PLC). Supervisors for industrial systems that operate in close proximity to humans have to adhere to strict safety standards. To achieve these standards, safety PLCs (SPLCs) are used. For SPLC implementation, the supervisor has to be split into a regular part and a safety part. In previous work, a method is proposed to automatically split a supervisor model for this purpose. The method assumes that the provided plant model is a collection of finite automata. In this paper, the extension to extended finite automata is described. Additionally, guidelines are provided for modeling the plant and the requirements to achieve a favorable splitting. A case study on a rotating bridge is elaborated which has been used to validate the method. The case study spans all development steps, including the implementation of the resulting supervisor to control the real bridge.

1 Introduction

Due to the large number of sensors and actuators present in modern cyber-physical systems and the growing functionality that has to be provided by the control system, the development of the associated supervisory controllers is a laborious and error-prone process. Supervisor synthesis, introduced in Ramadge and Wonham (1987), enables control designers to automatically construct a supervisor from a discrete-event model of the uncontrolled system (the plant) combined with a model of the control requirements. Subsequently, from this supervisor a supervisory controller can be derived which can be used for controller code generation. The use of supervisor synthesis significantly reduces the development time and increases the quality of the supervisory controller, as — by construction — it adheres to the requirements and it is nonblocking. This way of developing a supervisor for a system is referred to as synthesis-based engineering in Baeten et al. (2016).

In industrial systems, supervisory controllers are often implemented on programmable logic controllers (PLCs). A PLC is connected to sensors and actuators in the system. Based on the sensor observations, the PLC program controls the actuators. Derivation of controller software from a synthesized supervisor has extensively been studied in the literature. In Fabian and Hellgren (1998), undesired situations were identified that can occur when such a supervisor is used. In Malik (2003), conditions are given to establish if a supervisor can be used for controller software generation. In Zaytoon and Riera (2017), a review on implementation of discrete-event supervisors on PLCs is provided. Examples of tools that, given a discrete-event model, can automatically generate PLC code are CIF (van Beek et al. 2014) and Supremica (Malik et al. 2017; Prenzel and Provost 2018).

Industrial systems that operate in close proximity to humans are required to adhere to safety standards. For example, control systems for infrastructural systems such as waterway locks and movable bridges are required to adhere to the machinery directive (European Commission 2006), by means of complying with the IEC 62061 standard regarding machine safety (IEC 62061 2005). Safety functions of the control systems used to be hard-wired, but are now generally implemented in the controller software. PLC manufacturers support this by offering so-called safety PLCs (SPLCs), providing the hardware which adheres to the IEC standards.

SPLCs differ from regular PLCs (RPLCs — PLCs without safety functionality), as they have additional dedicated inputs and outputs for safety certified sensors and actuators, and they require separate safety controller code. In other words, the supervisory controller and the inputs and outputs are both split into a safety part and a regular part. The safety part contains the safety-critical control functions and the regular part all other functions. The developed safety controller code has to be certified to comply with the required safety standards.

The previously mentioned code generation tools do not support distributed implementation of a single supervisor on the regular part and the safety part of the SPLC. A solution is to separately develop a regular supervisor and a safety supervisor. This is difficult, as the behavior of the system depends on the joint control of both supervisors. As a result, reasoning about the behavior of each of these two supervisors separately is complicated. Another solution is to synthesize a single supervisor and then split this supervisor in the two parts. Following Reijnen et al. (2020a), the latter option is further investigated in this paper. It should be noted that beforehand, it is not known how the inputs and outputs are split. In the proposed method, this is automatically derived from the requirement model.

1.1 Related work

In the literature, SPLCs have been studied mostly in the context of formal verification. For example, in Soliman and Frey (2011) and Darvas et al. (2016), formal verification methods of safety-critical PLC programs are proposed. These methods are based on model checking and equivalence checking using formal specifications and apply to manually developed function blocks or supervisory controller code. A complementing aspect is elaborated in Ljungkrantz et al. (2012), namely a procedure for developing specifications for safety PLC program components. Resulting formal specifications dispose of ambiguity and enable the use of model checking for automatic verification. In Thönnessen et al. (2019) and Khan et al. (2019), automatic testing of SPLCs is investigated. There, the focus is on generating and executing test cases to determine whether an implementation conforms to a specification. To this end, the QuickCheck tool is used that generates randomized tests from a specification. Differently, in our approach, when supervisor synthesis is applied, the implementation conforms to the specification by construction.

Splitting a global supervisor in multiple local supervisors has also been studied before, for example, in the context of distributed control in Cai and Wonham (2010). There, the goal is to control multiple individual systems, such that they collectively realize the controlled behavior identical to that achieved by optimal and nonblocking monolithic control. For SPLCs, a single system has to be controlled with two supervisors. In the former study, the system decomposition is given, whereas for SPLCs, the decomposition is not known beforehand.

In other studies, such as de Queiroz and Cury (2000), division of the plant and the requirement models is proposed to reduce the computational effort of synthesizing the supervisor. State-space explosion can be avoided by computing many small supervisors instead of a single large supervisor. However, in our paper, the goal is to divide the supervisor to adhere to certain safety standards, not to reduce the computation effort. In fact, synthesis is done on the original, undivided model. Afterwards, the supervisor is divided.

In Reijnen et al. (2020a), a splitting method for implementing a supervisor on an SPLC has been presented. There, finite automata (FAs) and Boolean variables are used to model the plant and event-condition requirements are used to model the requirements. The requirements are manually partitioned into regular requirements and safety requirements. From that partitioning, the supervisor is split into a regular part and a safety part.

1.2 Contributions

The contribution of this paper is as follows. Firstly, the method of Reijnen et al. (2020a) is generalized by proposing a splitting method for extended finite-state automata (EFAs), which are FAs enhanced with discrete variables. EFAs offer advantages over FAs as they result in a more compact model representation and they are more suitable to model signal-based systems such as PLCs. We prove that splitting does not influence the behavior of the supervisory controller, by expanding the proof given in Reijnen et al. (2020a). Secondly, we provide guidelines for modeling the plant and for modeling the requirements that result in a favorable splitting. Lastly, a case study on a rotating bridge is described in detail. For the case study, all process steps, i.e., modeling, splitting, code generation, implementation, and testing, are performed.

1.3 Paper outline

This paper is structured as follows. In Section 2, the way of working of RPLCs and SPLCs is discussed. The preliminaries for discrete-event modeling, supervisor synthesis, and supervisor implementation are provided in Section 3. Modeling guidelines that result in a favorable splitting are provided in Section 4. The method to split a synthesized supervisor on an SPLC is provided in Section 5. In Section 6, the case study on a rotating bridge is described. Finally, Section 7 concludes this paper.

2 Programmable logic controllers

In this section, the way of working of a PLC is discussed. First, it is shown how a regular PLC operates, then the safety PLC operation is explained.

2.1 Regular PLCs

An RPLC can be represented by six components, of which a schematic overview is shown in Fig. 1. In this figure, the components are as follows: X and Y are the input signals (sensors) and the output signals (actuators), respectively, I and Q are the images of the input and output, respectively, C contains the control code (the supervisor), and M is the data memory of C. The arrows indicate the direction of data flows, e.g., C reads data from I, M, and Q and writes data to M and Q. The control code of C can be programmed using ladder diagrams, function block diagrams, structured text, instruction lists, or sequential function charts, as standardized in IEC (2013).

Fig. 1

RPLC component architecture

An RPLC operates in so-called scan cycles, as shown in Fig. 2. In an RPLC cycle, first, the ‘get’ action copies the values of the input signals to the input image. Then, the control code is executed. Finally, the ‘put’ action copies the values of the output image to the output signals. The images ensure that data available to the program is consistent during the program execution. One full scan cycle takes a few milliseconds.

Fig. 2

Two RPLC scan cycles

2.2 Safety PLCs

In Fig. 3, the component architecture of an SPLC is shown. Compared to the architecture of an RPLC, an SPLC has an additional layer of safety components (depicted in yellow) with interaction between the regular and safety component layers. Here, each component that is also present in an RPLC is subscripted with an R. In this figure, the components are as follows: X and Y are the input signals (sensors) and the output signals (actuators), respectively. I and Q are the images of the input and output, respectively, C contains the controller code, and M is the data memory of C. For each of these, there exists a regular variant and a safety variant. D_R and D_S are data buffers for the communication from the regular program to the safety program and vice versa, respectively. Variables in D_R can be written by C_R and read by C_S, and vice versa for D_S. As an example, D_R can be used by C_R to request C_S to switch on an actuator, C_S then determines whether it is safe to do so.

Fig. 3

SPLC component architecture

The arrows indicate the direction of data flows, e.g., C_S reads data from I_R, I_S, M_S, and D_R, and writes data to M_S, D_S, Q_R, and Q_S. It is important to note that C_R cannot write to Q_S, which ensures that all safety outputs are controlled by C_S. Secondly, C_S may not read from Q_S and Q_R, as determining safety should be derived from the sensors entirely (PLCopen 2018).

An SPLC scan cycle consists of an execution of the safety part, followed by an execution of the regular part. Each execution is preceded by its associated get action and succeeded by its associated put action. The get action copies the values of the input signals to the input image and the put action copies the values of the output image to the output signals. Here, it is assumed that the safety part and the regular part are executed alternately, as shown in Fig. 4¹.

Fig. 4

An SPLC scan cycle

Within C_S, three parts can be distinguished: signal preprocessing, safety logic, and signal postprocessing. Preprocessing verifies the validity of the input signals, for example by one-out-of-two diagnostics. Postprocessing acts as a feedback loop that checks whether the output signals have been received by the actuator. When a discrepancy is detected in either the preprocessing or the postprocessing, the actuator signals are set to a predefined safe state. The safety logic encompasses the controller code. In general, the controller code of C_S can be programmed using either ladder diagrams or function block diagrams. In this paper, the focus is on the safety logic. The reason for this is that preprocessing and postprocessing are often embedded in SPLCs by the manufacturers, and otherwise standardized function blocks can be used, as defined in PLCopen (2018).

3 Preliminaries

In this section, modelling, synthesis, and implementation of supervisors is discussed. Firstly, it is shown how EFAs are used to model the components of the plant. Secondly, using event conditions to model requirements is discussed. Lastly, synthesis and implementation of supervisors is explained.

3.1 Modelling discrete-event systems with EFAs

In Cheng and Krishnakumar (1996), Chen and Lin (2000), and Sköldstam et al. (2007), extended finite-state automata are introduced for modeling systems. EFAs are finite-state automata parameterized by bounded discrete variables. Compared to regular finite-state automata, EFAs result in more compact and elegant models. For modeling large-scale systems, the use of EFAs is essential. In Reijnen et al. (2018), an example is shown where a finite-state automaton needs 2.8 ⋅ 10¹¹ locations to express a requirement that can be expressed in a simple guard, using an EFA. Moreover, EFAs are more suitable to model signal-based systems such as PLCs

A model consists of several interacting EFAs, called an EFA system, $\mathcal {E} = \{E_{1}, \ldots , E_{m}\}$ together with a set of variables $X_{\mathcal {E}} = \{x_{1}, \ldots , x_{n}\}$. Transitions in an EFA may contain guards (i.e., logical conditions) over the variables, and updates (i.e., assignments) to the variables.

With each variable x, a finite discrete domain is associated, dom(x). A valuation v ∈ V is a function $v: X_{\mathcal {E}} \rightarrow \bigcup _{x\in X_{\mathcal {E}}} \text {dom}(x)$, for which v(x) ∈dom(x) for every $x\in X_{\mathcal {E}}$. The set of all valuations is V, the initial valuation is v⁰ ∈ V.

Formally, an EFA is defined as $E = (L, X, {{\varSigma }}, \rightarrow , l^{0}, L^{\text {m}})$, where L is the set of locations, $X \subseteq X_{\mathcal {E}}$ the set of local variables, Σ the set of events, → is the transition relation, l⁰ ∈ L the initial location, and $L^{\text {m}} \subseteq L$ the set of marked locations. The transition relation is defined as $\rightarrow \subseteq L \times G \times {{\varSigma }} \times U \times L$, with G the set of guards and U the set of updates. We assume that each variable in the EFA system is local to exactly one EFA in the EFA system. To this variable, values may only be assigned by that EFA. However, any other EFA may read its value.

The event set can be partitioned into controllable events Σ_c and uncontrollable events Σ_u, which denote actions that can and cannot be disabled by the supervisor, respectively.

A guard is a function, $g: V \rightarrow \{\textbf {T}, \textbf {F}\}$, where T and F are the Boolean literals. For clarity, v⊧g is used instead of g(v). In the models, guards are written as propositional formulas over the variables in the EFA system (including the variables that are not local to that EFA). It is assumed that each EFA implicitly contains a variable that represents the current location, called the location pointer LP, with dom(LP) = L. As a result, locations of other EFAs can be used in the guards. An example of a guard is x > 5 ∧E.On, where E.On means that EFA E is in location On. This guard evaluates to T for some v ∈ V if v(x) > 5 and v(LP_E) = On.

An update is a function $u: V \rightarrow V$. Only the values of the local variables of an EFA can be updated, i.e., v(x) = u(v)(x) for all $x\in X_{\mathcal {E}} \setminus X$. In the models, updates are written as (conditional) assignments. An example of an update is x := x + 3, which increases the value of x by 3. An example of a conditional update is x := if(x < 5) : x + 1 else : x, which increases the value of x by 1 as long as the value of x is less than 5. Only deterministic updates are considered, e.g., x + y := 7 is not considered. An assignment of a value outside of the variable’s domain is undefined.

Two EFAs in an EFA system can be combined by using the synchronous product. Let $E_{k} = (L_{k}, X_{k}, {{\varSigma }}_{k}, \rightarrow _{k}, {l_{k}^{0}}, L^{\text {m}}_{k})$, with k = 1,2, be EFAs. The synchronous product of E₁ and E₂ is

$$ E_{1} \parallel E_{2} = (L_{1} \times L_{2}, X_{1} \cup X_{2}, {{\varSigma}}_{1} \cup {{\varSigma}}_{2}, \rightarrow, ({l^{0}_{1}}, {l^{0}_{2}}), L^{\text{m}}_{1} \times L^{\text{m}}_{2}) $$

where the transition relation → is defined by:

• if σ ∈Σ₁ ∩Σ₂, then $((l_{1}, l_{2}),g_{1} \wedge g_{2}, \sigma , u_{1}\oplus u_{2}, (l_{1}^{\prime }, l_{2}^{\prime })) \in \rightarrow$,

  for all $(l_{1}, g_{1}, \sigma , u_{1}, l_{1}^{\prime }) \in \rightarrow _{1}$ and $(l_{2}, g_{2}, \sigma , u_{2}, l_{2}^{\prime }) \in \rightarrow _{2}$.

• if σ ∈Σ₁ ∖Σ₂, then $((l_{1}, l_{2}), g_{1}, \sigma , u_{1}, (l_{1}^{\prime }, l_{2})) \in \rightarrow$,

  for all $(l_{1}, g_{1}, \sigma , u_{1}, l_{1}^{\prime }) \in \rightarrow _{1}$ and l₂ ∈ L₂.

• if σ ∈Σ₂ ∖Σ₁, then $((l_{1}, l_{2}), g_{2}, \sigma , u_{2}, (l_{1}, l_{2}^{\prime })) \in \rightarrow$,

  for all $(l_{2}, g_{2}, \sigma , u_{2}, l_{2}^{\prime }) \in \rightarrow _{2}$ and l₁ ∈ L₁.

In the definition above, g₁ ∧ g₂ evaluates to T for some v ∈ V if v⊧g₁ and v⊧g₂. The update u₁ ⊕ u₂ denotes that the valuations of the variables from X₁ and X₂ are updated according to u₁ and u₂, respectively. This is well-defined, as X₁ and X₂ are disjoint. If a guard contains a location l ∈ L₁ ∪ L₂, the location is substituted by T if for that transition l = l₁ or l = l₂, and by F otherwise.

An example of synchronizing EFAs is shown in Fig. 5. The EFA system is $\mathcal {E}=\{\texttt {Switch}, \texttt {Lamp}\}$, and $X_{\mathcal {E}} =\{\texttt {Q}\}$, where Q is a Boolean variable. In the graphical representation, edges labeled with controllable and uncontrollable events are depicted with solid arrows and dashed arrows, respectively. The keywords when and do are used to denote guards and updates, respectively. For the local variables, the initial value is denoted near the initial-location arrow. Filled circles denote marked locations. To differentiate between location names and event names, the former are written with a capital initial letter. In this example, the events on and off are only enabled when EFA Switch is in location Active and in location Inactive, respectively. When events on or off occur, the value of Q is negated. The synchronous product is shown in Fig. 6. Transitions with a guard that always evaluates to F are not displayed.

Fig. 5

Graphical representation of EFAs

Fig. 6

Synchronous product of EFAs Switch and Lamp

3.2 Modeling of requirements

For supervisor synthesis, the desired behavior of a system is given by a requirement model. A requirement model can be defined, just like the plant model, using a collection of EFAs. EFAs are especially useful when the order of events is important. Typically, other requirements, such as safety requirements, can be formulated more concisely using event conditions, introduced in Ma and Wonham (2006) and extended in Markovski et al. (2010).

Event conditions provide conditions for an event to be enabled. For event e and condition c, e when c defines that e may only occur whenever c evaluates to T. Conditions are defined similar to guards used in the extended transition relation. An event condition can also be represented as an EFA, such that the synchronous product with another EFA can be computed. The EFA representation of an event condition is shown in Fig. 7.

Fig. 7

EFA representation of an event condition e when c

Based on Ouedraogo et al. (2011), the behavior of a collection $\mathcal {E}$ of EFAs with respect to an associated requirement set $\mathcal {R}$ is defined as the pair of languages, the closed behavior T and the marked behavior T_m, of the finite state automaton equivalent to the synchronous product of the $\mathcal {E}$ elements refined by strengthening the event guards using the associated conditions from $\mathcal {R}$. This refined synchronous product is denoted by $\mathcal {E}_{\parallel }$ and defined by $(L, X, {{\varSigma }}, \rightarrow , l^{0}, L^{\text {m}})$.

Definition 1

Closed behavior $T(\mathcal {E}, \mathcal {R})$ is defined as the set of event sequences t = σ₁…σ_n, n ≥ 0, for which there is a run $(l_{1},v_{1})\overset {\sigma _{1}}{\rightarrow } (l_{2},v_{2}) \ldots \overset {\sigma _{n}}{\rightarrow } (l_{n+1},v_{n+1})$ in $\mathcal {E}_{\parallel }$ such that (l₁,v₁) = (l⁰,v⁰) and in every state (l_i,v_i), i ≤ n, for the associated event (l_i,g_i,σ_i,u_i,l_i+ 1) holds that g_i evaluates to T.

Definition 2

Marked behavior $T_{m}(\mathcal {E}, \mathcal {R})$ is defined as the set of event sequences t = σ₁…σ_n, n ≥ 0, for which there is a run $(l_{1},v_{1})\overset {\sigma _{1}}{\rightarrow } (l_{2},v_{2}) \ldots \overset {\sigma _{n}}{\rightarrow } (l_{n+1},v_{n+1})$ in $\mathcal {E}_{\parallel }$ such that (l₁,v₁) = (l⁰,v⁰), l_n+ 1 ∈ L^m, and in every state (l_i,v_i), i ≤ n, for the associated event (l_i,g_i,σ_i,u_i,l_i+ 1) holds that g_i evaluates to T.

3.3 Supervisor synthesis

Supervisory control theory, initiated by Ramadge and Wonham (1987), provides a method to derive a supervisor for a system. Given a model of the plant and a model of the requirements, a supervisor can be synthesized automatically. The supervisor restricts the behavior of the system (together called the supervised system), such that 1) the requirements are always met, 2) it is controllable, 3) it is nonblocking, and 4) it is maximally permissive (see e.g., Cassandras and Lafortune (2009) or Wonham and Cai (2019)). For synthesizing a supervisor for an EFA system, the algorithm proposed in Ouedraogo et al. (2011) is used.

Using the method of Miremadi et al. (2008), the synthesis result is represented as additional event conditions. The supervisor is the collection of the component models, the requirement model, and the additional event conditions. Without loss of generality, in the remainder of this paper we assume that the plant and the requirements together satisfy the properties listed above and synthesis does not generate additional event conditions. This is justified by the fact that whenever synthesis does generate additional event conditions, they can be included as requirements.

3.4 Supervisor implementation

From the model, controller code can be generated for a PLC. To prevent state-space explosion, the synchronous product of the models is not calculated. Instead, the linearization procedure given in Swartjes et al. (2014) is used.

For connecting the variables in the input image of the PLC to the supervisor, a mapping $\mathcal {I}: I \rightarrow X_{\mathcal {E}}$ is defined, where I is the set of input-image variables, and $X_{\mathcal {E}}$ the set of variables in the model. For example, consider EFA Switch, shown in Fig. 5 and Boolean input-image variable I_B. A mapping can be defined such that Switch is in location Inactive when I_B = F and in location Active when I_B = T. This implies that when the value of I_B changes from F to T or from T to F, event activate or event deactivate occurs, respectively.

For connecting the variables in the output image of the PLC to the supervisor, a mapping $\mathcal {Q}: Q \rightarrow X_{\mathcal {E}}$ is defined, where Q is the set of output-image variables. This implies that for every q ∈ Q there should be a corresponding variable in the model. For example, consider EFA Lamp, shown in Fig. 5, and Boolean output-image variable Q_L. A mapping can be defined such that Q_L equals the value of Q. This implies that when event on or off occurs, the value of Q_L changes to T or F, respectively.

It should be noted that the supervisor is implemented as a supervisory controller. In Malik (2003) and Reijnen et al. (2019) solutions are proposed to handle subtle differences between a supervisory controller and a supervisor obtained via synthesis.

A supervisor can only forbid events, whereas a supervisory controller can force some events (typically, the controllable events). Methods exist to transform a supervisor into a supervisory controller (i.e., PLC code) automatically, see, e.g., Fabian and Hellgren (1998), Zaytoon and Riera (2017), Balemi et al. (1993), Malik (2003). In essence, what is done is to keep forcing controllable events among the enabled events of the supervisor, until no more controllable events are enabled. Under certain conditions (see below), the state that is eventually reached is always the same, independent of which enabled event is forced. When the values of the outputs are only based on the current state, the choice between enabled events can be made arbitrarily. In the new state, the supervisory controller waits for a new plant input (e.g., a sensor that switches on).

For this method, the supervisor needs to satisfy additional properties not guaranteed by synthesis. These properties are finite response, confluence, and nonblocking under control, as described in, e.g., Malik (2003), Reijnen et al. (2019). Finite response ensures that always eventually a state is reached where no controllable events are enabled. Confluence ensures that each time the supervisory controller can choose between multiple controllable events, the choice can be made arbitrarily. Nonblocking under control requires that a marked state can be reached without being dependent on events that happen only in rare situations. When the supervisor does not adhere to these properties, the requirements should be altered.

In the literature (e.g., Fabian and Hellgren (1998), Zaytoon and Riera (2017)), differences are described between the execution of a supervisory-controller model and a PLC implementation. These differences originate from the real-time execution of the code. The PLC executes a repeating cycle, as explained in Section 2. As a result, when a sensor signal changes, this is only noticed during the next input reading. This delay can lead to a situation where an undetected change in a sensor invalidates the choice of the action made by the supervisory controller, referred to as inexact synchronization. A delay can also lead to a situation where between successive PLC scan cycles two or more events occur. If this happens, the supervisory controller is unable to recognize the exact order of the events, referred to as simultaneity. In general, when the process time of the system is much higher than the cycle time (the time it takes the PLC to finish the scan cycle), the above situations are never encountered, as demonstrated by Malik (2003) and Forschelen et al. (2012).

4 Modeling

This section introduces the component-based modeling method that is used for modeling. When component-based modeling is used, the plant is modeled as many small EFAs that do not share events (loosely coupled). The requirement model the desired interactions. The splitting method, shown in Section 5 works particularly well with such models.

Component-based modeling is a modeling paradigm that uses the fact that large systems can be obtained by assembling smaller components. Each component can be modeled separately. This way of modeling has proven to be useful for modeling the plant for supervisor synthesis, as shown in Kovács et al. (2012), Huang et al. (2015), and Reijnen et al. (2020b). In Goorden et al. (2019), modeling guidelines are proposed that help in obtaining the necessary models. Two guidelines that help in achieving a favorable SPLC splitting are given below.

Guideline 1

Model independent plant components as asynchronous component models.

This entails that component models do not share events or refer to variables local to other EFAs. For infrastructural systems, it has been shown in Reijnen et al. (2020b) that a realistic plant model can be created by composing asynchronous component models consisting of 2 to 4 states each.

For splitting the supervisor, having many small component models is advantageous as for each model it can be determined whether it should be included in the safety part. By having smaller models, no excess model parts have to be included in the safety part.

Guideline 2

Use the abstraction level of the inputs and outputs of the control hardware for the plant model.

This entails that each sensor and actuator in the plant is modeled with a separate component EFA. With this perspective, events relate to the change of signal value sent to actuators or received from sensors. Furthermore, all events related to actuators are controllable and all events related to sensors are uncontrollable. The way of modeling is similar to the input-output perspective introduced in Balemi et al. (1993).

In the rest of this paper, we call an automaton a sensor EFA if its event set contains only uncontrollable events, i.e., Σ = Σ_u, and an actuator EFA if its event set contains only controllable events, i.e., Σ = Σ_c.

Using the input-output perspective offers two advantages. Firstly, textual control requirements formulated by engineers can be more easily translated into event-condition models, as the states of actuators and sensors are directly available in the plant model (as demonstrated in Reijnen et al. (2020b). Secondly, for implementation the component models can easily be coupled to the available sensors and actuators as there exist dedicated component models for these.

For splitting the supervisor, a third advantage is observed. For SPLCs it is necessary to split the sensors and actuators into the safety or regular category. When these are available as component models, we can split these component models. From that split, we can derive which sensors and actuators should be put into the safety category.

5 Splitting

In this section, the method is described that can be used to split a supervisor for the implementation on an SPLC. The method is similar to the method described in Reijnen et al. (2020a). Equations have been adapted such that the method is applicable to EFA models.

The general idea is as follows. First, a plant model $\mathcal {P}$ consisting of automata representations of system components and a requirement set $\mathcal {R}$ are defined (and if needed extended with additional requirements following the synthesis step, as explained in Section 3.3) that together form the supervisor. Some of the variables and locations in the supervisor will be connected to the input image I of the PLC and some other to the output image Q of the PLC. These are defined via mappings $\mathcal {I}$ and $\mathcal {Q}$, respectively (see Section 3.4). The goal is to distribute the elements of these sets over the regular part and safety part. The distribution is derived from a (manual) partitioning of the requirements into disjoint sets of safety requirements $\mathcal {R}_{\text {S}}^{\prime }$ and regular requirements $\mathcal {R}_{\text {R}}^{\prime }$. Based on this, the plant model, the requirement model, the input image, and the output image are split and the necessary data communication between the parts is derived, as shown in Fig. 8.

Fig. 8

Desired result after splitting

In the figure, $\mathcal {P}_{\text {R}}$ and $\mathcal {P}_{\text {S}}$ denote the set of plant components that belong in the regular part and in the safety part, respectively. Similarly, $\mathcal {R}_{\text {R}}$ and $\mathcal {R}_{\text {S}}$ denote the set of requirements that belong in the regular part and in the safety part, respectively. $\mathcal {P}_{\text {R}}$ and $\mathcal {R}_{\text {R}}$ form the regular supervisor and $\mathcal {P}_{\text {S}}$ and $\mathcal {R}_{\text {S}}$ form the safety supervisor. I_R, I_S, Q_R, Q_S are the regular and safety input and output image variables, respectively. Lastly, D_R and D_S are the sets of variables communicated via the data buffers.

Notice that $\mathcal {R}_{\text {S}}^{\prime }$ and $\mathcal {R}_{\text {R}}^{\prime }$ may differ from $\mathcal {R}_{\text {S}}$ and $\mathcal {R}_{\text {R}}$, where the latter denote the requirements in the safety part and the requirements in the regular part, respectively. By definition, $\mathcal {R}_{\text {S}}^{\prime }$ should be included in $\mathcal {R}_{\text {S}}$. However, some requirements from $\mathcal {R}_{\text {R}}^{\prime }$ may also be included in $\mathcal {R}_{\text {S}}$.

For describing the splitting procedure, some additional notations are introduced. For all conditions c, the functions comps(c) and var(c) are defined that return the set of EFAs that are referenced and the set of variables that are used. An EFA is referenced if either its location is used or a local variable is used in c. Given a set of EFAs $\mathcal {E}$, $\textit {sens}(\mathcal {E})$ and $\textit {act}(\mathcal {E})$ return the sets of sensors and actuators, respectively. Given an EFA E, evt(E) and var(E) return the event set of E and the set of local variables of E, respectively. Given a variable x, comp(x) denotes the component where x is local to.

The rules that the splitting has to adhere to are given in Section 5.1. An illustrative example is provided in Section 5.2. The proposed splitting procedure is given in Section 5.3. In Section 5.4, it is proven that splitting does not influence the behavior of the supervisor.

5.1 Objectives of the splitting

For splitting, it is assumed that each condition for a requirement in $\mathcal {R}_{\text {S}}^{\prime }$ is derived entirely from sensors. This is necessary, as in PLCopen (2018) it is defined that the actuators have to be monitored by sensors directly (instead of actuators (see also Fig. 3) or internal variables). This means that:

$$ \forall(\sigma, c) \in \mathcal{R}_{\text{S}}^{\prime}: \textit{comps}(c) = \textit{sens}(\textit{comps}(c)) $$

(1)

In PLCopen (2018), rules are defined for the safety program. These rules lead to a clear separation between the safety functionalities and the non-safety functionalities. Moreover, by following these rules, the relevant aspects of the IEC 62061 standard are also met. These are translated in the following six rules used for splitting. First of all, by definition:

• (r1) Each safety requirement has to be included in the safety part.

Secondly, sensors that are used in the condition part of safety requirements, have to be included in the safety part. To this end, the EFAs that model these sensors have to be included in the safety part.

• (r2) Each sensor EFA that is used in a condition of a safety requirement has to be included in the safety part.

Thirdly, actuators that are subjected to safety requirements, have to be included in the safety part. To this end, the EFAs that model these actuators have to be included in the safety part.

• (r3) Each actuator EFA that has an event which is subjected to a safety requirement has to be included in the safety part.

Finally, because the safety program should be as small as possible (e.g., for fast execution and to obtain a clear separation between the safety part and the non-safety part), the following should hold:

• (r4) $\mathcal {P}_{\text {S}}$ and $\mathcal {R}_{\text {S}}$ should be as small as possible.

• (r5) D_S and D_R should be as small as possible.

• (r6) I_S and Q_S should be as small as possible.

These restrictions state that only the strictly necessary elements should be included in the safety part. When only looking at r4 through r6, a solution would seem to put everything in the regular part, but it is not due to r1 through r3. The other way around, when only looking at r1 through r3, a solution would seem to put everything in the safety part, but it is not due to r4 through r6.

5.2 An illustrative example

Consider two switches, Switch1 and Switch2, a lamp, and a motor. The plant component models are shown in Fig. 9.

Fig. 9

Plant component models for two switches, a lamp, and a motor

Assume there are two regular requirements ($\mathcal {R}_{\text {R}}^{\prime }$) and one safety requirement ($\mathcal {R}_{\text {S}}^{\prime }$):

reg1:	Lamp.on when Switch1.Active
reg2:	Motor.on when Switch1.Active
safe1:	Motor.on when Switch2.Active

These requirements state that if switch 1 is active, the lamp switches on. Whenever both switches are active the motor switches on. It is a safety requirement that switch 2 has to be active for the motor to switch on.

From this information, the following can be concluded regarding the partitioning of the plant components and the requirements. By definition, requirement safe1 must be part of the safety part. Secondly, since this requirement depends on information received from Switch2, Switch2 has to be a safety component. Thirdly, since this requirement restricts the behavior of Motor, Motor has to be a safety component.

Since Lamp and Switch1 are not related to any safety requirement, they are regular components. Moreover, reg1 and reg2 are regular requirements. Finally, the data buffer D_R must be used to communicate whether reg2 is satisfied, as this is needed to determine whether Lamp.on may be enabled.

Subsequently, assume the following mappings $\mathcal {I} = \{I_{1}: \texttt {Switch1.Active},\\ I_{2}: \texttt {Switch2.Active} \}$ and $\mathcal {Q} = \{Q_{1}: \texttt {Lamp.On}, Q_{2}: \texttt {Motor.On} \}$. Since Switch1 and Lamp are regular components, I₁ and Q₁ are regular inputs and outputs, respectively. Because Switch2 and Motor are safety components, I₂ and Q₂ are safety inputs and outputs, respectively.

5.3 Splitting

In this subsection, a splitting procedure is proposed that satisfies the rules defined in the previous subsection.

It is assumed that the plant model is a product system, which means that the event sets of component models are pairwise disjoint and only local variables are used in guards. If the plant is not a product system, it can be obtained by performing the procedure described in de Queiroz and Cury (2000). In that procedure, if two component models share events or use a variable from another EFA, they are replaced by their synchronous product. Moreover, we assume that the input-image variables are coupled to sensor EFAs (and vice versa) and output-image variables are coupled to actuator EFAs (and vice versa). When component-based modeling is used, both assumptions should be satisfied.

From (r2) and (r6), definitions for the safety-sensor components, safety input-image variables and the regular input-images variables are derived:

$$ \textit{sens}(\mathcal{P}_{\text{S}}) = \{E \in \mathcal{P} \mid \exists (\sigma, c) \in \mathcal{R}_{\text{S}}^{\prime}, E \in \textit{sens}(\textit{comps}(c))\} $$

(2)

$$ I_{\text{S}} = \{i \in I \mid comp(\mathcal{I}(i)) \in sens(\mathcal{P}_{\text{S}}) \} $$

(3)

$$ I_{\text{R}} = I \setminus I_{\text{S}} $$

(4)

From (r3) and (r6), definitions for the safety-actuator components, safety output-image variables and regular output-image variables are derived:

$$ \textit{act}(\mathcal{P}_{\text{S}}) = \{E \in \mathcal{P} \mid \exists (\sigma, c) \in \mathcal{R}_{\text{S}}^{\prime}, \sigma \in \textit{evt}(E)\} $$

(5)

$$ Q_{\text{S}} = \{q \in Q \mid \textit{comp}(\mathcal{Q}(q)) \in \textit{act}(\mathcal{P}_{\text{S}}) \} $$

(6)

$$ Q_{\text{R}} = Q \setminus Q_{\text{S}} $$

(7)

From (r2) and (r3), it follows that the safety-sensor components and safety-actuator components belong in the safety part. From (r4) it follows that the other components belong in the regular part.

$$ \mathcal{P}_{\text{S}} = \textit{sens}(\mathcal{P}_{\text{S}}) \cup \textit{act}(\mathcal{P}_{\text{S}}) $$

(8)

$$ \mathcal{P}_{\text{R}} = \mathcal{P} \setminus \mathcal{P}_{\text{S}} $$

(9)

From the previous two equations, the disjoint set of variables in the safety part and in the regular part can be derived.

$$ X_{\text{S}} = \{x | \exists P \in \mathcal{P}_{\text{S}}, x \in \textit{var}(P)\} $$

(10)

$$ X_{\text{R}} = \{x | \exists P \in \mathcal{P}_{\text{R}}, x \in \textit{var}(P)\} $$

(11)

Due to the product system assumption, two disjoint event sets for the safety and regular parts can be derived.

$$ {{\varSigma}}_{\text{S}} = \{\sigma \mid \exists P \in \mathcal{P}_{\text{S}},\ \sigma \in \textit{evt}(P) \} $$

(12)

$$ {{\varSigma}}_{\text{R}} = \{\sigma \mid \exists P \in \mathcal{P}_{\text{R}},\ \sigma \in \textit{evt}(P) \} $$

(13)

From Eqs. 5, 8, and 12, it follows that all events that are subjected to safety requirements belong to Σ_S. The regular requirements can be formulated for events in Σ_S and Σ_R. Hence, $\mathcal {R}_{\text {R}}^{\prime }$ can be split into regular requirements for Σ_S and regular requirements for Σ_R.

$$ \mathcal{R}_{\text{R}}^{\text{S}} = \{(\sigma, c) \in \mathcal{R}_{\text{R}}^{\prime} \mid \sigma \in {{\varSigma}}_{\text{S}}\} $$

(14)

$$ \mathcal{R}_{\text{R}}^{\text{R}} = \{(\sigma, c) \in \mathcal{R}_{\text{R}}^{\prime} \mid \sigma \in {{\varSigma}}_{\text{R}}\} $$

(15)

Because of (r4), requirements in $\mathcal {R}_{\text {R}}^{\text {S}}$ should be included in the regular program, whenever possible. This is only possible if the evaluation result of the requirement’s condition does not change during the safety cycle (otherwise the splitting can influence the behavior of the supervisor). This can be violated when, e.g., the value of a variable of a component in $\mathcal {P}_{\text {S}}$ is used to evaluate a condition and this value changes in the safety part. Therefore, the regular requirements which evaluations can change during the safety program cycle have to be included in the safety part. Formally, these requirements are

$$ \begin{array}{l} \mathcal{R}_{\text{R}}^{\text{SS}} = \{(\sigma, c) \in \mathcal{R}_{\text{R}}^{\text{S}} \mid \textit{comps}(c) \cap \mathcal{P}_{\text{S}} \neq \emptyset\} \end{array} $$

(16)

The other requirements in $\mathcal {R}_{\text {R}}^{\text {S}}$ can be included in the regular part.

$$ \mathcal{R}_{\text{R}}^{\text{SR}} = \mathcal{R}_{\text{R}}^{\text{S}} \setminus \mathcal{R}_{\text{R}}^{\text{SS}} $$

(17)

The event conditions in $\mathcal {R}_{\text {R}}^{\text {SR}}$ can be evaluated in the regular part and then the evaluation result can be communicated to the safety part via the data buffer D_R. To this end, conditions for the same events are combined by putting them into conjunction, as defined in Eq. 18. This ensures that each event has exactly one condition evaluation that has to be communicated (r4, r5).

$$ \forall \sigma \in {{\varSigma}}_{\text{S}}, c_{\sigma} = \bigwedge_{(\sigma, c) \in \mathcal{R}_{\text{R}}^{\text{SR}}}c $$

(18)

Given a valuation v for the variables, we define v_σ = v⊧c_σ. Practically, v_σ acts as a signal from the regular part to the safety part, indicating that all regular requirements are satisfied. As a result, event σ may be enabled whenever it is safe to do so. In the example in Section 5.2, v_σ is the result of the second requirement.

The following requirements are added to replace $\mathcal {R}_{\text {R}}^{\text {SR}}$. These requirements state that for event σ, all regular requirements must be satisfied (i.e., v_σ = T).

$$ \mathcal{R}_{D} = \{(\sigma, v_{\sigma}) \mid\sigma \in {{\varSigma}}_{\text{S}}\} $$

(19)

The requirements in the safety program and the regular program are

$$ \mathcal{R}_{\text{S}} = \mathcal{R}_{\text{S}}^{\prime} \cup \mathcal{R}_{\text{R}}^{\text{SS}} \cup \mathcal{R}_{D} $$

(20)

$$ \mathcal{R}_{\text{R}} = \mathcal{R}_{\text{R}}^{\text{R}} $$

(21)

It should be noted that $\mathcal {R}_{\text {R}}^{\text {SR}}$ is effectively replaced by $\mathcal {R}_{D}$.

Finally, the programs cannot access variables from the other program part, as these are saved in M_R or M_S (see Fig. 3). Therefore, some variables have to be communicated via D_R and D_S. From Eqs. 1 and 2, it follows that variables used in conditions of $\mathcal {R}_{\text {S}}^{\prime }$ are always contained in the safety part. Similarly, because of Eqs. 16, 17, and 18, it follows that v_σ can be calculated with the variables contained in the regular part.

From the regular part to the safety part, the v_σ variables have to be communicated. Secondly, the regular variables used in conditions of $\mathcal {R}_{\text {R}}^{\text {SS}}$ have to be communicated. From the safety part to the regular part, references to safety variables used in conditions of $\mathcal {R}^{\text {R}}_{\text {R}}$ have to be communicated. To be precise, the variables contained within D_R and D_S are given in Eqs. 22 and 23.

$$ D_{\text{R}} = \{v_{\sigma} \mid\exists(\sigma, v_{\sigma})\in \mathcal{R}_{D}\} \cup \{x \mid\exists (\sigma,c)\in\mathcal{R}_{\text{R}}^{\text{SS}}, x\in \textit{var}(c) \cap X_{\text{R}}\} $$

(22)

$$ D_{\text{S}} = \{x \mid \exists(\sigma, c) \in \mathcal{R}_{\text{R}}^{\text{R}}, x\in\textit{var}(c) \cap X_{\text{S}}\} $$

(23)

Above, all sets shown in Fig. 8 are defined.

5.4 Proof of equal behavior

The result is that the supervisors before and after the splitting have equal behavior. In Reijnen et al. (2020a), this proof has already been given for FAs. The proof is similar for EFAs, but has been included for completeness. For the proof, first notions of equal restrictiveness are defined.

Definition 3

Two requirements R₁ = (σ,c₁) and R₂ = (σ,c₂) are said to be equally restrictive iff c₁ and c₂ are logically equivalent.

Definition 4

Two sets of requirements $\mathcal {R}_{1}$ and $\mathcal {R}_{2}$ over the same event set are said to be equally restrictive iff for each event σ, $(\sigma , \bigwedge _{(\sigma , c)\in \mathcal {R}_{1}} c)$ is equally restrictive to $(\sigma , \bigwedge _{(\sigma , c)\in \mathcal {R}_{2}} c)$.

Definition 5

Let $\mathcal {P}$ be a plant and $\mathcal {R}_{1}$ and $\mathcal {R}_{2}$ be sets of requirements. The behavior of $\mathcal {P}$ together with $\mathcal {R}_{1}$ is equal to the behavior of $\mathcal {P}$ together with $\mathcal {R}_{2}$ if $T(\mathcal {P},\mathcal {R}_{1}) = T(\mathcal {P},\mathcal {R}_{2})$ and $T_{m}(\mathcal {P},\mathcal {R}_{1}) = T_{m}(\mathcal {P},\mathcal {R}_{2})$.

Using these definitions, it can be proven that the behavior of the supervisor before the split is equal to the behavior of the supervisors after the split.

Proposition 1

Let S₁ be $(\mathcal {P}, \mathcal {R})$ and S₂ be $(\mathcal {P}_{\text {R}} \cup \mathcal {P}_{\text {S}}, \mathcal {R}_{\text {R}} \cup \mathcal {R}_{\text {S}})$, as defined in Section 5.3. Assuming that each c_σ is evaluated when its value is needed, such that v_σ in Eq. 19 can be substituted by c_σ, then, S₁ and S₂ have equal behavior.

Proof

To prove this proposition, it is shown that the plant models of S₁ and S₂ are equal and that the requirements of S₁ and S₂ are equally restrictive. It follows from Eqs. 8 and 9 that $\mathcal {P} = \mathcal {P}_{\text {R}}\cup \mathcal {P}_{\text {S}}$. Hence, the plant models are equal. As defined in Section 5.3, $\mathcal {R} = \mathcal {R}_{\text {R}}^{\prime } \cup \mathcal {R}_{\text {S}}^{\prime }$. From this and Eqs. 14, 15, 16, and 17, it follows that the requirements of S₁ are $\mathcal {R}_{1} = \mathcal {R}_{\text {R}}^{\text {R}} \cup \mathcal {R}_{\text {R}}^{\text {SS}} \cup \mathcal {R}_{\text {R}}^{\text {SR}} \cup \mathcal {R}_{\text {S}}^{\prime }$. From Eqs. 20 and 21, it follows that the requirements for S₂ are $\mathcal {R}_{2} = \mathcal {R}_{\text {R}}^{\text {R}} \cup \mathcal {R}_{\text {S}}^{\prime } \cup \mathcal {R}_{\text {R}}^{\text {SS}} \cup \mathcal {R}_{\text {D}}$. From Definition 4, it follows that $\mathcal {R}_{1}$ is equally restrictive to $\mathcal {R}_{2}$ if $\mathcal {R}_{D}$ is equally restrictive to $\mathcal {R}_{\text {R}}^{\text {SR}}$. So now it remains to be proven that $\mathcal {R}_{D}$ is equally restrictive to $\mathcal {R}_{\text {R}}^{\text {SR}}$. Equations 14 and 17 assure that all requirements in $\mathcal {R}_{\text {R}}^{\text {SR}}$ apply to events in Σ_S. In combination with Eqs. 18 and 19, Definition 4, and the assumption that v_σ can be substituted by c_σ, this shows that $\mathcal {R}_{D}$ is equally restrictive to $\mathcal {R}_{\text {R}}^{\text {SR}}$. Therefore, $\mathcal {R}_{1}$ is equally restrictive to $\mathcal {R}_{2}$.

Subsequently, it is proven that for all event sequences t:

$$t \in T(\mathcal{P},\mathcal{R}_{1}) \Leftrightarrow t \in T(\mathcal{P},\mathcal{R}_{2})$$

and

$$t \in T_{m}(\mathcal{P},\mathcal{R}_{1}) \Leftrightarrow t \in T_{m}(\mathcal{P},\mathcal{R}_{2}).$$

This evidently holds for t = 𝜖. Assume t = σ₁…σ_n, for some n ≥ 1, belongs to $T(\mathcal {P},\mathcal {R}_{1})$. According to Definition 1, this means that there is a run $(l_{1},v_{1})\overset {\sigma _{1}}{\rightarrow } (l_{2},v_{2}) \ldots \overset {\sigma _{n}}{\rightarrow } (l_{n+1},v_{n+1})$ in the synchronous product of EFAs in $\mathcal {P}$ refined w.r.t. R₁ for which (l₁,v₁) = (l⁰,v⁰) and in every state (l_i,v_i), for i ≤ n, event (l_i,g_i,σ_i,u_i,l_i+ 1) is such that g_i evaluates to T. Since $\mathcal {R}_{1}$ is equally restrictive to $\mathcal {R}_{2}$, in the synchronous product of EFAs in $\mathcal {P}$ refined w.r.t. R₂ there is a corresponding run where in every state (l_i,v_i), for i ≤ n, event $(l_{i}, g^{\prime }_{i}, \sigma _{i},u_{i},l_{i+1})$ is such that $g^{\prime }_{i}$ evaluates to T. Hence, $t \in T(\mathcal {P},\mathcal {R}_{2})$. Similar reasoning can be applied to prove the implication the other way around and, using Definition 2, for equality of $T_{m}(\mathcal {P},\mathcal {R}_{1})$ and $T_{m}(\mathcal {P},\mathcal {R}_{2})$. Hence, according to Definition 5, S₁ and S₂ have equal behavior. □

To investigate how the SPLC scan cycle (shown in Fig. 4) influences the behavior of the supervisor on the SPLC, the execution of the SPLC is modeled. This is similar to the method suggested in Roussel and Giua (2005), where the scan cycle of the RPLC has been modeled. The model of the SPLC is shown in Fig. 10. The location S denotes the execution of the safety part, whereas R denotes the execution of the regular part. Events in Σ_S and Σ_R can only be executed in their respective part, as denoted by the self loops. The event regular denotes a switch to the regular part. When this event occurs, the values of the variables in D_S are updated. Similarly, the event safe denotes a switch to the safety part. When this event occurs, the values of the variables in D_R are updated.

Fig. 10

Model of the execution of an SPLC

The variables in D_S and D_R are only updated when events regular and safe occur, respectively. Therefore, for variables in D_S and D_R, it has to be shown that their value cannot change in locations R and S, respectively.

It follows from Eq. 23 that D_S contains references to variables local to components in $\mathcal {P}_{\text {S}}$ only. Figure 10 shows that the values of these variables cannot change in location R, as Σ_S is not enabled here. Hence, the value of the variables in D_S cannot change in location R.

It follows from Eq. 22 that D_R contains variables local to components in $\mathcal {P}_{\text {R}}$. Figure 10 shows that the values of these variables cannot change in location S, as Σ_R is not enabled here. For the v_σ variables in D_R, it follows from Eqs. 16, 17, and 18 that their values are calculated from variables local to components in $\mathcal {P}_{\text {R}}$. These values remain unchanged in location S. As a result, the values of v_σ variables cannot change in location S. Hence, the value of the variables in D_R cannot change in location S.

Because of the results from Proposition 1 and the above reasoning, it is concluded that the splitting and data communication do not influence the behavior of the supervisor.

6 Case study

To demonstrate the practical applicability of the proposed method, a case study on the Oisterwijksebaan bridge (OBB) has been performed. The OBB, shown in Fig. 11, is a rotating bridge that provides a way for land traffic to cross the canal when closed and a way for waterborne vessels to pass when open (rotated 90 degrees). The bridge deck consists of a two-way vehicle lane and two pedestrian lanes. The bridge is operated and maintained by Rijkswaterstaat.

Fig. 11

The Oisterwijksebaan bridge

In Section 6.1, the way of working of the OBB is described. Modeling of the components is discussed in Section 6.2. How the safety requirements and regular requirements are formalized is shown in Subsections 6.3 and 6.4, respectively. The results of splitting the models are given in Section 6.5. How the results are validated is explained in Section 6.6.

6.1 Way of working

A schematic overview of the bridge is shown in Fig. 13. On both sides of the bridge, stop signs are located (SS1 - SS5), which warn the land traffic to stop before the boom barriers are lowered. These boom barriers (BB1 - BB2) are placed on both sides of the bridge, to provide a safe situation before the bridge is opened. The vessels on the Wilhelmina Canal are informed via red-green-red vessel traffic lights (VTL1 - VTL8). A VTL can show four different sign aspects, see Fig. 12. The double-red aspect indicates that the lock is out-of-service. The red and red-green aspects indicate that approaching the bridge not allowed and allowed, respectively. The green aspect indicates that a vessel may pass the bridge. The bridge deck (BD) consists of a locking mechanism, a brake, and a rotating mechanism. To unlock the bridge, a hydraulic pump is used to lower the bridge into its bearings. The bridge is raised out of its bearings to lock it. Whenever the brake is applied, rotation is not possible. For rotation, an electric motor is used. The direction (open or close) and speed of this motor can be controlled.

Fig. 12

Sign aspects of a VTL: double red, red, red-green, and green

Fig. 13

A schematic overview of the Oisterwijksebaan bridge

An operator controls the bridge via a graphical user interface (GUI). The GUI has two purposes: providing information to the operator about the system’s state, such as the displayed sign aspects, and acting as a control panel to provide a way for the operator to give commands. The commands that can be given are, e.g., stopping land traffic, rotating the bridge, and switching sign aspects. In total, the bridge is controlled by 39 actuators, based on the inputs of 51 sensors and 26 control commands.

The desired controlled behavior (Fig. 13) is as follows. When a vessel wants to pass the bridge, the operator initiates the open bridge procedure. Then, all stop signs switch on, and the two boom barriers close. Then, the bridge is lowered into its bearings, the brake is released, and the electric motor is started. The bridge rotates at a constant speed until it is almost open, then the bridge decelerates. When the bridge is fully open, the brake is applied. During the bridge rotation, the operator switches the VTLs to a red-green aspect, indicating a vessel can approach the bridge. Once the bridge is fully open, a green aspect may be shown. The close bridge procedure is similar to the procedure described above. When the bridge is not being operated, both red lamps of a VTL are enabled to indicate this.

6.2 Components

For the plant model, the component-based modeling method is used. In this method, every component (actuator, sensor, or operator command) is modeled as a separate EFA. These automata typically consist of a small number (2-5) of locations and do not share events with other EFAs. An overview of the component models is shown in Fig. 14. In this figure, the number of component EFAs is denoted. The model can be partitioned into two parts: the physical part representing all ‘real’ components and the GUI part representing the symbols available on a GUI to give commands.

Fig. 14

Plant model decomposition of the OBB

For the Oisterwijksebaan bridge, 27 actuator component models, 48 sensor component models, and 7 command models are needed. One component model can represent multiple inputs or multiple outputs. For example, one VTL actuator EFA represents the outputs for the top two lamps. As an illustration, the model of that actuator is shown in Fig. 15. The model consists of three locations (circles), representing the legal aspects that can be shown.

Fig. 15

Component model of the vessel traffic light actuator

6.3 Safety requirements

Due to the human-machine interaction, the bridge has to adhere to strict standards to guarantee human safety. Rijkswaterstaat uses a risk assessment procedure (Smith and Simpson 2020) that calculates the safety integrity level (SIL-level) for certain situations based on four criteria: severity, frequency, probability of incident, and probability of avoidance. From that, dangerous situations are identified (e.g., a person stands on the bridge when the bridge rotates), and requirements are defined to avoid these situations. For this case study, 22 textual requirements were already available, given below.

• 1. A stop sign will only turn off when the barriers are open.

• 2. A barrier will only close when the stop signs are on.

• 3. A barrier will only open when the bridge is closed.

• 4. A barrier will only open when the bridge is locked.

• 5. The bridge will only unlock when the barriers are closed.

• 6. The bridge will only lock when the VTLs show a red aspect.

• 7. The brake will only be released when the barriers are closed.

• 8. The brake will only be released when the VTLs show a red aspect.

• 9. The motor will only start on when the barriers are closed.

• 10. The motor will only start when the VTLs show a red aspect.

• 11. A VTL will only show a green aspect when the brake is applied.

• 12. A VTL will only show a green aspect when the bridge is open.

• 13. A VTL will only show a green aspect when the opposite VTLs show a red aspect.

• 14. A VTL will only show a red-green aspect when the opposite VTLs do not show a red-green aspect.

• 15. A barrier will only close when the emergency stop is not pressed.

• 16. A barrier will only open when the emergency stop is not pressed.

• 17. The bridge will only unlock when the emergency stop is not pressed.

• 18. The bridge will only lock when the emergency stop is not pressed.

• 19. The brake will only be released when the emergency stop is not pressed.

• 20. The motor will only start on when the emergency stop is not pressed.

• 21. A VTL will only show a green aspect when the emergency stop is not pressed.

• 22. A VTL will only show a red-green aspect when the emergency stop is not pressed.

These requirements are formalized using event-condition models. The first part of the requirement is always an actuator action (i.e., a stop sign will only turn off when…) and the second part of the requirements is always an condition (i.e., … when the barriers are open). For example, Requirement 1 is modeled as:

$$ \texttt{SS.A.c\_off} \text{ when } \texttt{BB1.Open.On} \text{ and } \texttt{BB2.Open.On}, $$

In the expression, SS.A.c_off is the c_off event of the stop signs actuator component. BB1.Open.On and BB2.Open.On are the On locations of the components that represent the sensor that measures the open position of barrier 1 and 2, respectively.

In total, 48 event conditions are used to model the safety requirements. Notice that for some requirements, multiple event conditions are used. For example, requirements 22 refers to ‘A VTL’, whereas there are eight VTLs and thus eight event conditions.

6.4 Regular requirements

To achieve the desired functionality, additional (non-safety) requirements are necessary. For the bridge, the following regular requirements are encountered.

• 1. Actuators will only start when an operator gives the corresponding command.

• 2. VTL aspects will only switch when an operator gives the corresponding command.

• 3. Actuators will stop when they reach their end position.

• 4. Actuators will only start when they have not reached their end position.

• 5. When the locking procedure starts, the hydraulic valves will open.

• 6. The position of the hydraulic valves will only be set when the unlock-bridge procedure or lock-bridge procedure starts.

• 7. The rotation direction will only be set when the close-bridge procedure or open-bridge procedure starts.

• 8. The rotation speed will only be set when the close-bridge procedure or open-bridge procedure starts.

Similar to the safety requirements, all these requirements are modeled using event conditions. In total, 118 event conditions are used to model the regular requirements.

6.5 Splitting results

The results of splitting the model are shown in Table 1. To obtain these results, the splitting method has been implemented in CIF.² The results show that after splitting there are 60 requirements in the regular part and 99 requirements in the safety part. These numbers can be explained as follows. Of the regular requirements, 58 contain safety events, of which 51 unique events, which explains the 51 data buffers. The resulting number of $\mathcal {R}_{\text {R}}^{\text {R}}$ requirements is then 60 (118 − 58). The number of safety requirements is 48 $\mathcal {R}_{\text {S}}^{\prime }$ and 51 $\mathcal {R}_{\text {D}}$ requirements. Note that 58 $\mathcal {R}_{\text {R}}$ requirements are replaced by 51 $\mathcal {R}_{\text {D}}$ requirements, which explains the total number of requirements (166 before the split, and 159 after the split).

Table 1 Results of partitioning the model

The 24 safety actuators are related to the stop signs, the barriers, the locking mechanism, the brake, the rotating mechanism, the top red VTL lamps, and the green VTL lamps. The 15 regular actuators are related to the barrier lights, the hydraulic valves, the rotation direction of the bridge, the rotation speed of the bridge, and the bottom red VTL lamps.

The 22 safety sensors are related to the state of the stop signs, the end position of the barriers, the end positions of the bridge, the state of the top red VTL lamps, and the state of the green VTL lamps. The 29 regular sensors are related to the non-end position of the barriers, the non-end positions of the bridge, and the bottom red VTL lamps. The EFAs modelling the GUI are not shown in the table. These are all included in the regular part.

6.6 Validation of the results

The results achieved by applying the proposed method of splitting the supervisor are validated in two ways.

First, the input image and output image partitioning is compared to the manually defined input image and output image partitioning. The manually defined partitioning is the one currently used to control the bridge. The results for the splitting of I and Q are as shown in Table 2. The off-diagonal elements in this table denote differences between the automatic and manual splitting. As can be seen in the table, almost all variables are partitioned in the same manner as was chosen manually (the main-diagonal elements). For the outputs, the partitioning was identical. For the inputs, only four variables differ. Here, four of the safety inputs in the manual split were determined to be regular according to the presented method. Upon closer inspection of the controller code, none of these inputs were used in the safety part. Therefore, there was no reason to make them safety sensors. After discussing this with the engineers, it was concluded that they should have been implemented as regular inputs. In that case, exactly the same result is obtained. It is concluded that the method achieves the desired partitioning for the OBB.

Table 2 I and Q partitioning comparison

Second, the split supervisor is used to generate controller code (for a Siemens SIMATIC S7-300 CPU315F-2 PN/DP SPLC) that has been implemented on the real bridge. Function block diagrams (FBDs) are used to implement the safety supervisor and structured text is used to implement the regular supervisor. For generating FBDs, the method as shown in Reijnen et al. (2020a) is used. The size of the generated code is around 100 KB, which is only a small part of the available memory on the PLC (2 MB).

To realize a system test, the OBB was closed for traffic for one night. During this period, the original controller code has been replaced by the generated code. During the system test, the bridge was operated by professional bridge operators. The operators did not experience differences between the generated controller and the original controller.

To validate the behavior, existing site acceptance tests (SATs) have been performed. A SAT protocol describes how the system should react under a specific circumstance. The performed tests are categorized into two groups: 1) does the supervisory controller restrict unsafe behavior (i.e., are all safety requirements satisfied) and 2) does the supervisory controller perform required behavior (i.e., the way of working). Of course, the supervisory control satisfied all safety requirements and did not reach blocking situations, as that is guaranteed by the synthesis algorithm. During the tests no anomalies were observed and all tests were successfully performed.

Problems related to the differences between a supervisor and a supervisory controller, as described in Subsection 3.4, were negligible in this case study, as the control hardware is much faster than the process to be controlled.

7 Concluding remarks

This paper generalizes the supervisor splitting method of Reijnen et al. (2020a) by extending it to extended finite-state automata and event-condition requirements. Two modelling guidelines are given that help in obtaining a model which, subsequently, results in a favorable splitting. The splitting method is based on the partitioning of the requirement model into safety requirements and regular requirements. The splitting as proposed allows for a supervisor to be implemented on an SPLC.

It is proven that the behavior of the supervisor before the split is equal to the behavior of the supervisors after the split. This ensures that the properties guaranteed by supervisor synthesis still hold. Comparing a supervisor obtained via this method to a manually designed supervisor shows that a similar partitioning can be obtained. The advantage of the proposed method is that the partitioning of the input and output images is done in a systematic manner which can be automated. Finally, implementing the supervisor on a real bridge shows a proof of concept for practical applicability of this way of working.

While the use of synthesis techniques has not yet been widespread in industry, this case study shows that they are mature enough to be applicable in practice and can be embedded in an engineering process delivering a ready to use implementation. In case safety standards have to be met, the presented method can be used to generate controller code for SPLCs from the synthesis result.