Systems Engineering Group Department of Mechanical Engineering Eindhoven University of Technology PO Box 513 5600 MB Eindhoven The Netherlands http://se.wtb.tue.nl/

SE Report: Nr. 2009-06

Specifying State-Based Supervisory Control Requirements K.G.M. Jacobs, J. Markovski, D.A. van Beek, J.E. Rooda and L.J.A.M. Somers (Oc´e)

ISSN: 1872-1567

SE Report: Nr. 2009-06 Eindhoven, November 2009 SE Reports are available via http://se.wtb.tue.nl/sereports This work has been carried out as part of the Coordination for Control (C4C) project in cooperation with Oc´e Technologies B.V. C4C is a FP7 European project on networked embedded and control systems - control of large-scale complex distributed systems, see http://www.c4c-project.eu/.

Abstract We use state-based supervisory control theory to synthesize control software for highly complex machines. We translate intuitive, informal state-based requirements into formal state-based requirement expressions. We have identified three formal forms of expressions, which naturally follow from the informal requirements. These forms are not compatible with the current tooling for supervisory controller synthesis. A conversion algorithm is derived and implemented in a tool. The tool is a preprocessing step for the existing tooling for supervisory controller synthesis. We applied the tool in a case study regarding complex printing systems for Oc´e Technologies B.V. The proposed 50 state-based requirement expressions in our framework translated to 200+ input expressions for the existing state-based supervisory controller tooling.

2

Contents 1

Introduction

2

Preliminaries and Notation 1 Predicates and Operators . . . . . . . . . . . . . . . . . 2 Plant Model by Means of Automata . . . . . . . . . . . 3 Ma/Wonham Tooling Input . . . . . . . . . . . . . . . . 4 Proposed Types of State-Based Requirement Expressions 5 Propositional Logic . . . . . . . . . . . . . . . . . . . . 6 Resolving a Negation of a State Predicate . . . . . . . .

3 4

5

6

7

3

5 . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Model-Based Engineering Framework for Supervisory Controller Synthesis Illustrative Example 1 Controlled System . . . . . . . . . . . 2 Plant Model . . . . . . . . . . . . . . . 3 Requirements Model . . . . . . . . . . 4 Proposal: Generalized Forms of State-Based Requirement Expressions

9 9 10 11 13 14 17 19

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22 22 24

. . . . . . . . . . . . . . . . . . . . . .

25

Conversion Algorithms 1 Generalized State-Formula to Mutual State Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Generalized State-Transition Exclusion to State-Transition Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Generalized Transition-State Formula to State-Transition Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 28 30

Tooling: Implementation of Conversion Algorithms 1 Tool Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Model-Based Engineering Tool-Chain . . . . . . . . . . . . . . . . . . . . . . .

31 31 33 33

Conclusion

35

Bibliography

37

A Illustrative Example: STS-file

39

Contents

4

Contents

Chapter 1

Introduction Designing complex manufacturing machines is a time consuming and iterative process. In the last few decades, control software has taken a more central role, replacing control in hardware. Typically, the requirements for the control software are formulated informally and software engineers translate them into control software manually. This is a time consuming and an error prone process, since control requirements are often ambiguous. This gave rise to supervisory control theory [Ram87, Won08, Ma05b], where high level controllers are synthesized automatically based upon formal models of the hardware and control requirements. Still, formal models have to be made manually from the informal requirements. This shifts the process of control software design from writing and debugging code into formulating the right models. As a result, errors are reduced and the design is more flexible. In this report we focus on specifying formal, state-based requirement for state-based supervisory control theory [Ma05b]. Complex manufacturing machines consist of physical components (hardware) and control software, see Figure 1.1(a). The physical components, typically sensors, actuators, and main structure, provide the means of the machine. The interactions between the physical components result in the so-called uncontrolled behavior of the machine. The control system interacts with the sensors and actuators to employ the means of the machine, which results in the controlled behavior of the machine. The controlled behavior should be such that the machine fulfills some functions, i.e., meets its pre-defined requirements. The control system can be divided into two layers: resource control and supervisory control. The resource control system operates in a continuous-time driven domain. The supervisory control system operates in a discrete, event-driven domain. An interface between these two layers provides an abstraction of the continuous to the discrete domain. We focus on the supervisory controller system and, therefore, we abstract the control architecture even further, see Figure 1.1(b). In this feedback control loop, the supervisor observes occurring events in the plant (which consists of both the user and the interface/resource control). Based on an off-line synthesized decision maker, the supervisor enables or disables certain events. Two types of events are distinguished, namely controllable events and uncontrollable events. The supervisor can influence the execution of controllable events, whereas the occurrence of uncontrollable events goes beyond the control power of the supervisor. As already described above, deriving formal models from an ambiguous informal description 5

Enabled events

Occurring events

User

Discrete, event driven

Enabled events

Occurring events

Supervisor

control system

Interface

Resource Control

Continuous, time driven

Hardware

(a) Complete control system. Controlled behavior (S/P)

Occurring events

Plant (P)

Supervisor (S)

Enabled controllable events

(b) Abstracted control system.

Figure 1.1: General control architecture complex manufacturing machines. is the most difficult, time consuming, and error prone part of control software design using supervisory control theory. In order to improve this process, in [Sch09a, Sch09b] a model-based engineering framework (and tool-chain) for supervisory controller synthesis is designed. The framework defines design steps and provides structure to the design process. During a case study for Oc´e technologies B.V. we noticed that the allowed input expressions of the tooling for state-based supervisory control theory is quite restrictive [Ma05a]. Intuitive requirements were not easily converted into the allowed forms of requirement expressions. To give an intuition of this statement, we give the following example: Example 1.1. We consider the process of opening and closing a car door. The car is either driving, stopping, standing still, or starting. The door is either opened or closed. A supervisor has only one task, namely to make sure that the door is only open when the car is standing still. The model of the plant consists of two components, namely the status of the car and the status of the door. We model the plant by means of automata. An automaton gives the relation between a (finite) set of states from the plant model. A set of (parallel) automata gives the entire plant model. Each automaton can always be found in exactly one state. Note that the state of the plant is defined by the set of current states. In Figure 1.2(a), a visualization of 6

Introduction

Car Standing Still _StandingStill

StartDriving

Car Stopping

Car Starting

_Driving

StopDriving

_DoorClosed Door Closed

Car Driving (a) Status of the car

OpenDoor

Door Open

(b) Status of the door

Figure 1.2: Plant model of a car and its door. an automaton is depicted. States are denoted by vertices, initial states are indicated by an unconnected incoming arrow, and marked states (i.e., states in which the system is allowed to end) by an unconnected outgoing arrow. Controllable and uncontrollable events are drawn with solid and dashed edges, respectively. Multiple events on an edge represent an edge for each event. In the remainder of this report, states are printed bold, events are printed italic, uncontrollable events are prefixed by an underscore whereas controllable events never start with an underscore. See [Cas04, Won08] for background information on the use of automata in supervisory control theory. The automaton depicted in Figure1.2(a) models the status of a car and the automaton depicted in Figure1.2(b) models the door. The states follow from the possible activities, as described earlier. The event names are chosen such that they speak for themselves. Note that the supervisor can disallow the car to start or stop driving. With respect to the door, the supervisor can disallow the door to open, closing goes beyond the power of the supervisor. As described before, the supervisor must assure that the door can be open only when the car is standing still. This requirement is informally stated as: • If the door is open, then the car must be standing still. In a logical sentence we can formulate this as: • Plant in state: Door Open IMPLIES Plant in state: Car Standing Still For the existing state-based supervisory controller synthesis tool we cannot use this as input, but instead we can use the following equivalent input: • The following logical expression must always be satisfied: NOT NOT NOT

(Plant in state: Door Open AND Plant in state: Car Starting) AND (Plant in state: Door Open AND Plant in state: Car Stopping) AND (Plant in state: Door Open AND Plant in state: Car Driving)

For a detailed explanation on the input restrictions we refer the reader to [Ma05b]. In this report, we will only state the prescribed forms of input for the tool and hint on the reasoning behind it.  7

Example 1.1 brings us to the objective of this report. Deriving the expressions suitable to use for the tool is an error prone, and not to mention meticulous, process, especially for big and complex systems. Therefore our objectives are: 1. Identify forms of state-based requirement expressions that naturally follow from intuitive, informal specifications. 2. Find algorithms to convert the identified forms of requirement expressions into equivalent expressions suitable as input for the existing tooling for supervisory controller synthesis. 3. Implement the derived algorithms in a tool and place it in the existing framework for modelbased engineering. The rest of the report is structured as follows. First, in Chapter 2 preliminaries are given. In Chapter 3 the existing model-based engineering framework for supervisory controller synthesis is described. Next, an illstration of the proposed forms of state-based requirement expressions is given in Chapter 4. Given the proposed forms of requirement expressions and the necessary preliminaries, in Chapter 5 we derive conversion algorithms. The algorithms are implemented in a tool, which is discussed in combination with the existing tool-chain for model-based engineering in Chapter 6. Finally, in Chapter 7 the conclusions are presented.

8

Introduction

Chapter 2

Preliminaries and Notation In Section 1, we define predicates and operators we use to describe state-based requirements. In Section 2 we give our assumptions with respect to a plant model. In Section 3 we define the statebased requirement expression that are suitable as input for the existing supervisory controller synthesis tooling and interpret them using our predicates. Also, we give the syntax of the input of the existing tooling. In Section 4 we define three types of generalized requirement expressions we propose in this report. Next, in Section 5, we state equivalences and normal forms we use in the conversion algorithm in Chapter 6. Finally, we explain how we can resolve a negation of state predicates from a requirement expression in Section 6.

1 Predicates and Operators In this report, we use logical expressions to describe state-based requirements. The logical predicates and operators we use are described in this section. We use the following standard logical operators: the conjunction (∧), disjunction (∨), negation (¬), implication (⇒), and equivalence (⇐⇒). For V ease of notation, we denote the conjunction over an indexed set of predicates xi W as follows: i∈I xi . Similarly, the disjunction over an indexed set of predicates is given by: i∈I xi . A summary of these operators and its derivatives is given in Table 2.1(a), for background information see [B¨un99]. We use {TRUE, FALSE} to indicate the truth values of propositional logic. We introduce two predicates. The first predicate, indicated by s↓, is true if and only if the plant under supervision is in state s. We refer to this as state predicate. The second predicate, indicated by → e, is true if and only if event e is enabled by the supervisor. We refer to this as event predicate. For the ease of notation and modeling, we introduce the following derived predicates. By 9 e we denote that event e is disabled by the supervisor, i.e., 9 e , ¬ → e. As a convention, in the remainder of this report we denote a set of events by an upper case symbol and one single event by a lower

9

Predicates and Operators

case symbol. We define: →E

,

_

→ e,

(2.1)

9 e.

(2.2)

e∈E

9E

,

^ e∈E

Note that ¬ → E ⇐⇒ 9 E. A summary of these predicates and its derivatives is given in Table 2.1(b). Table 2.1: Operators and predicates and its derivatives. (a) Operators

(b) Predicates

Operator Description ∧ Logical conjunction V Logical conjunction over ini∈I dexed set xi , i ∈ I ∨ Logical disjunction W Logical disjunction over ini∈I dexed set xi , i ∈ I ¬ Logical negation Logical implication ⇒ ⇐⇒ Logical equivalence

Predicate Description s↓ True if and only if the plant under supervision is in state ’s’. True if and only if event e is →e enabled by the supervisor. True if and only if event e is 9e disabled by the supervisor. →E True if and only if at least one of the events in the set of events E is enabled by the supervisor. 9E True if and only if each event in the the set of events E is disabled by the supervisor.

2 Plant Model by Means of Automata In this section we give the assumptions we make on the plant model. The plant model captures the possible sequences of events that can occur in the uncontrolled plant. An automaton gives the event relation between a (finite) set of states from the plant model. We assume that the possible sequences of events in a plant are modeled by means of a set of automata {Ai | i ∈ I}, see [Cas04] for background information on modeling a plant by means of automata. The state set and event set of an automaton Ai is given by Qi and Σi , respectively. Each state name is unique, i.e., Qi ∩ Qj = ∅, i 6= j, i, j ∈ I. For ease of notation, we define Q and Σ as the set of all states in the plant and events in the plant, respectively: [ Q = Qi , i∈I

Σ

=

[

Σi ,

i∈I

Moreover, we assume that the automaton Ai is in exactly one state at a time, i.e., _ q↓ ⇐⇒ TRUE,

(2.3)

q∈Qi for some i∈I

j↓ ∧ s↓ 10

Introduction

⇐⇒

FALSE if j 6= s and {j, s} ∈ Q.

(2.4)

3 Ma/Wonham Tooling Input In this section we discuss the input for the the tooling for state-based supervisory controller synthesis. The state-based requirement expressions are interpreted as logical expressions using the predicates and operators introduced in Section 1. At the end of this section, the syntax of the input of the Ma/Wonham tooling is given and related our interpretation. The synthesis of a state-based supervisory controller is implemented in a tool we refer to as the the Ma/Wonham tool [Ma05a]. The input of the Ma/Wonham tooling consists of a sts-file and a spec-file. The sts-file contains the plant structure and the event-based requirements. The spec-file contains the state-based requirements. The output is a control function for each controllable event, in the form of a binary decision diagram. Each control function defines in which (combination of) states the event is enabled. For a detailed description on synthesis and tooling see [Ma05b, Ma05a]. First we discuss the input of the plant model briefly. Then we go into more detail on the input of the state-based requirement specifications. Plant Model We use automata to describe the plant model, see Section 2, whereas [Ma05b] uses state-tree structures. This means that we use a fixed form of state tree structure, that consists of an AND superstate root state, with only OR superstate child states, each of which is only has simple child states. Each OR superstate represents one automaton and the simple states represent the states of the automata. The transition relation between simple states within an OR superstate in a state tree structure is described by holons. In [Ma05b] is already remarked that a holon can be seen as a generalized automaton. Requirement Specifications In state-based supervisory control theory, both event-based and state-based requirements are allowed. Event-based requirements define sequences of events that are allowed and are modeled using automata. State-based requirements suitable for the Ma/Wonham tool, either define a combination of states from different plant automata, which the plant under supervision is not allowed to enter, or an event that must be disabled by the supervisor in case the plant is in a certain combination of states. We refer to these types of requirements as mutual state exclusion and state-transition exclusion, respectively. In this report we focus on state-based requirements, therefore we discuss them into detail in the following. An example of mutual state exclusion is already presented in Example 1.1. The plant under supervision is not allowed to enter a combination of states in which the logical expression (1.1) is not satisfied. Note that in this specific example, the plant under supervision is not allowed to enter the following three combinations of states: Door Open and Car Starting, Door Open and Car Stopping, and Door Open and Car Driving. Using the logical operators and predicates as defined in Section 1, we can rewrite this as the following logical expression: ¬ ( Door Open↓ ∧ Car Starting↓ ) ∧ ¬ ( Door Open↓ ∧ Car Stopping↓ ) ∧ ¬ ( Door Open↓ ∧ Car Driving↓ ) The general form of this type of requirement expression is given by the following definition: Definition 2.1. Mutual state exclusion We write the set of mutual state exclusion expressions as the following logical expression   ^ ^ ¬ sij↓ , i∈I

11

Ma/Wonham Tooling Input

j∈Ji

where sij ∈ Q.

A combination of states that a plant under supervision may not enter is interpreted as negation over a conjunction of state predicates indexed by j for j ∈ Ji . The complete set of mutual state exclusion expressions is a conjunction over each combination indexed by i for i ∈ I. State-transition exclusion states that if the plant is in a combination of states, an event must be disabled by the supervisor. For example, using the plant automata of Example 1.1, imagine that the event Open Door must be disabled by the supervisor in states Car Starting, Car Driving, and Car Stopping. Using the logical operators and predicates as defined in Section 1, we can rewrite them in the following form: Car Starting↓ ⇒ 9 OpenDoor Car Driving↓ ⇒ 9 OpenDoor Car Stopping↓ ⇒ 9 OpenDoor

∧ ∧

The general form of this type of requirement expression is given by the following definition: Definition 2.2. State-transition exclusion We write the set of state-transition exclusion expressions as the following logical expression  ^

 ^

 i∈I

sij↓ ⇒ 9 ei  ,

j∈Ji

where sij ∈ Q and ei ∈ Σ.

A combination of states of a plant under supervision which implies that an event must be disabled by the supervisor, is interpreted as a conjunction of state predicates indexed by j for j ∈ Ji . Each combination implies that if it becomes correct, an event, indexed by i for i ∈ I, is disabled by the supervisor. The complete set of state-transition exclusion expressions is a conjunction over each implication, also indexed by i for i ∈ I. To finalize this section, we give the syntax of the STS-file, which is the input for the Ma/Wonham tool. The STS-file has the following form: 1 2 3 4 5 6 7 8 9 10 11 12

{ { state_11_1, { state_21_2, ... { state_n1_n, } { ({state_11_1, ({state_21_2, ... ({state_o1_o, }

state_12_1, ..., state_1m_1 }, state_22_2, ..., state_2m_2 }, state_n2_n, ..., state_nm_n }

state_12_1, ..., state_1p_1}, event_1), state_22_2, ..., state_2p_2}, event_2), state_o2_o, ..., state_op_o}, event_o),

A conjunction over a set is enclosed in curly brackets, whereas a pair is enclosed by round brackets. Lines 1–6 give the set of mutual state exclusion expressions, as given by Definition 2.1 with i = 1...n and j = 1...m. Lines 7–12 give the set of state-transition exclusion expressions, as given by Definition 2.2 withv i = 1...o and j = 1...p. 12

Introduction

4 Proposed Types of State-Based Requirement Expressions In this section we identify three types of state-based requirement expressions. In Chapter 4 a motivation for these forms is given. These forms are generalized versions of the forms that can be used as input for the Ma/Wonham tool. In Chapter 5 we derive a conversion algorithm from the generalized forms to the input forms. The first type of generalized state-based expression we propose is ‘state-formula’. A stateformula is given by the following definition: Definition 2.3. State-formula Let Op be either conjunction, disjunction, or implication and P r a state predicate, then we define a state-formula, SF , as follows: Op ::= P r ::= SF ::=

∧ | ∨ | ⇒, s↓, P r | ¬ SF | SF Op SF,

where s∈ Q. The plant under supervision must always be in a combination of states that satisfies the stateformula. This allows us to formulate any logical expression of state predicates (using the operators defined in Section 1), that must be satisfied by the plant under supervision. Note that this is a generalized form of a mutual state exclusion expression. In the rest of the report, we refer to state-formula as generalized state-formula in the context of a generalized form of mutual state exclusion expression. The second form of expression we propose is a generalized version of state-transition exclusion expressions, as defined in Definition 2.2: Definition 2.4. Generalized state-transition exclusion Let a generalized state-transition exclusion requirement expression, GST , be GST ::= (SF ⇒9 E) , where SF state-formula is of type state-formula and E ⊆ Σ. This generalized requirement expression allows us to formulate any logical expression over state predicates (using the operators defined in Section 1) to imply that a set of events must be disabled by the supervisor if the plant under supervision is in a state in which it is correct. The third form of expression we propose is not a generalized form of the original input, although we will show in Chapter 5 that an equivalent set of state-transition exclusion expressions always exists. We use the plant introduced in Example 1.1 to give an intuition. Imagine we want to formulate the following informal requirement: ’Event OpenDoor may only be enabled by the supervisor, i.e., may only occur in the plant under supervision, if the plant is in state Car Standing Still’. In a logical formula: → OpenDoor ⇒ Standing Still↓ We define the generalized version of such an expression as follows: Definition 2.5. Generalized transition-state formula Let a generalized transition-state formula requirement expression, GT S, be GT S ::= (→ E ⇒ SF ) , 13

Proposed Types of State-Based Requirement Expressions

where SF state-formula is of type state-formula and E ⊆ Σ. This definitions states that if at least one of the events a set E is enabled implies that a stateformula SF must be correct. For the ease of modeling and notation, we combine the three proposed types of generalized statebased requirement expressions in one definition: Definition 2.6. Generalized state-based requirement expressions We define the set of generalized state-based requirement expressions, combining SF (Definition 2.3), GT S (Definition 2.4), and GST (Definition 2.5), as follows: Generalized-Requirements ::= | | |

SF, GST, GT S, Generalized-Requirements ∧ Generalized-Requirements.

5 Propositional Logic In Chapter 5 conversion algorithms from the generalized expressions into the restricted Ma/Wonham tool input expressions is presented. In this section, we state the equivalences and normal forms that we use for these algorithms. Equivalences The equivalences used in the conversion algorithm are stated in Table 2.2. Since these equivalences are basic laws of propositional logic, no description is given. For background information we refer the reader to [B¨un99].

Table 2.2: Logic equivalences. Definition (P ∨ Q) ∨ R ⇐⇒ P ∨ (Q ∨ R) (P ∧ Q) ∧ R ⇐⇒ P ∧ (Q ∧ R) Commutativity (P ∨ Q) ⇐⇒ (Q ∨ P ) (P ∧ Q) ⇐⇒ (Q ∧ P ) Distributivity P ∨ (Q ∧ R) ⇐⇒ (P ∨ Q) ∧ (P ∨ R) P ∧ (Q ∨ R) ⇐⇒ (P ∧ Q) ∨ (P ∧ R) (P ∨ P ) ⇐⇒ P Idempotency (P ∧ P ) ⇐⇒ P Double negation law ¬¬ Q ⇐⇒ Q De Morgan’s laws ¬(P ∨ Q) ⇐⇒ ¬P ∧ ¬Q ¬(P ∧ Q) ⇐⇒ ¬P ∨ ¬Q Implication (P ⇒ Q) ⇐⇒ (¬P ∨ Q) Law of implication reversal (P ⇒ Q) ⇐⇒ (¬Q ⇒ ¬P ) Equivalence (P ⇐⇒ Q) ⇐⇒ (P ⇒ Q) ∧ (Q ⇒ P ) Law Associativity

We give the generalized equivalences of the distributivity laws presented in Table 2.2: 14

Introduction

Proposition 2.7. 

 _

^ 

i∈I

t∈Qi

 ^

_

tj ∈Qj for j∈I

i∈I

_

^

tj ∈Qj for j∈I

i∈I

ti

 _

 i∈I

t ⇐⇒

! ^

t ⇐⇒

t∈Qi

! ti

We discuss only the first rule, as the discussion for the second one is analogous due to the symme W V try of the distributive laws. In the original formula, on the left-hand side we have i∈I t . t∈Qi Here, the conjunction ranges over the elements of the set Qi for every i ∈ I. There are in total |I| of these conjunctions, connected by disjunction. When applying the distributive law, we have to form conjunctions of disjunctions of elements of Qi . These disjunctions are formed from |I| arbitrary chosen elements, each one from a different set Qi for i ∈ I, i.e., one has to make all possible in Qi for i ∈ I. For that purpose, on the right-hand side we
V combinationsWof elements have tj ∈Qj for j∈I However, when forming i∈I ti , where tj is arbitrary in Qj for j ∈ I. W the disjunctions one must take an element from each set, leading to i∈I ti , where ti has been previously arbitrarily chosen from Qi for i ∈ I. The total number of disjunctions in this case is Q i∈I |Qi | as we make all possible combinations of elements from Qi . To finalize the equivalences, we give two propositions on moving dis- or conjunction outside an implication: Proposition 2.8. P ⇒ (Q ∧ R) ⇐⇒ (P ⇒ Q) ∧ (P ⇒ R). Proof. We have the following computation: P ⇒ (Q ∧ R) ⇐⇒ ¬P ∨ (Q ∧ R) ⇐⇒ (¬P ∨ Q) ∧ (¬P ∨ R) ⇐⇒ (P ⇒ Q) ∧ (P ⇒ R) , which concludes the proof. In the proof we first use the definition of implication, then we use distributivity, and finally the definition of implication again. Proposition 2.9. (P ∨ Q) ⇒ R ⇐⇒ (P ⇒ R) ∧ (Q ⇒ R). Proof. We have the following computation: (P ∨ Q) ⇒ R ¬ (P ∨ Q) ∨ R ¬P ∧ ¬Q ∨ R (¬P ∨ R) ∧ (¬Q ∨ R) (P ⇒ R) ∧ (Q ⇒ R) ,

⇐⇒ ⇐⇒ ⇐⇒ ⇐⇒

which concludes the proof. In the proof we first use the definition of implication, then De Morgan’s law, subsequently distributivity, and finally the definition of implication again. 15

Propositional Logic

Normal Forms The conversion algorithm presented in Chapter 5 starts from normal forms, either from conjunctive normal form or from disjunctive normal form. Any arbitrary propositional expression can be converted into both forms. In this section we give the definition of these forms and informally describe the conversion algorithm from any logical expression to these forms. For background information we refer the interested reader to [B¨un99], where the proofs to the propositions can be found. In conjunctive normal form, a formula is a conjunction of clauses, where a clause is a disjunction of literals. A literal is a predicate (positive literal) or a negation of a predicate (negative literal). A conjunctive normal form over state predicates is defined as follows: Proposition 2.10. Conjunctive normal form of state predicates Every state-formula, SF , can be rewritten in an equivalent conjunctive normal form:   ^ _ _  ¬ sik↓ , SF ⇐⇒ sij↓ ∨ i∈I

j∈Ji

(2.5)

k∈Ki

where sij , sik ∈ Q. Every propositional expression can be converted to conjunctive normal form in the following steps, using the laws stated in Table 2.2: 1. Eliminate the ⇐⇒ connective using the equivalence; 2. Eliminate the ⇒ connective using the equivalence; 3. Move negation symbols inward, using the ‘De Morgan’s laws’ and the ‘double negation law’, both stated; 4. Use distributive law to convert to conjunctive normal form, i.e., move conjunction over disjunction. For example, (P ∧ Q) ∨ R becomes (P ∨ R) ∧ (Q ∨ R) 5. Flatten nested conjunctions and disjunctions. For example, (P ∨ Q) ∨ R becomes P ∨ Q ∨ R In disjunctive normal form, a formula is a disjunction of clauses, where a clause is a conjunction of literals. A conjunctive normal form over state predicates is defined as follows: Proposition 2.11. Disjunctive normal form of state predicates Every state-formula, SF , can be rewritten in an equivalent disjunctive normal form:   _ ^ ^  SF ⇐⇒ sij↓ ∧ ¬ sik↓ , i∈I

j∈Ji

(2.6)

k∈Ki

where sij , sik ∈ Q. Every propositional expression can be converted to disjunctive normal form in the same steps as it can be converted into conjunctive normal form, with the only difference that at step four disjunction is moved over conjunction. 16

Introduction

6 Resolving a Negation of a State Predicate In this section we show how to resolve negations of state predicates. Resolving of negations over state predicates is possible since automata have a finite state-set. To give an intuition on how to resolve a negation of a state predicate, consider the plant automaton of the status of the car from Example 1.1, depicted in Figure 1.2(a). Say we have the following negation ¬Car Standing Still↓. Instead of writing that we are not in state Car Standing Still↓, we can also write that we are either in Car Starting↓, Car Driving↓, or Car Stopping↓, i.e., Car Starting↓ ∨ Car Driving↓ ∨ Car Stopping↓. This is possible since the automaton must occupy exactly one state of a finite set of states. This is generalized by the following proposition, which proof is straightforward: Proposition 2.12. Resolving a negation of a state predicate We can resolve a negation of a state predicate using the following equivalence _ ¬s↓ ⇐⇒ t↓,

(2.7)

t6=s,t∈Qi for some i∈I

where s∈ Qi for some i ∈ I. This proposition states that a negation over a state predicate can be resolved by taking the disjunction of state predicates over all states from the automaton in question, apart from the (negative) state predicate we are resolving.

17

Resolving a Negation of a State Predicate

18

Introduction

Chapter 3

Model-Based Engineering Framework for Supervisory Controller Synthesis Supervisory control theory is a study on how to automatically synthesize a supervisor, based on formal models of the plant and the requirements. However, modeling cannot be automated. In order to structure the modeling process, in [Sch09a] a framework for supervisory controller design has been developed. In this chapter, we give a brief introduction to this framework. In [Sch09b] a tool-chain for this framework is presented. The conversion tool we present in Chapters 5 and 6 fits in this framework. An overview of the model-based engineering framework for supervisory controller design is dedenotes docpicted in Figure 3.1. In the figure, the following conventions are used: icon uments, denotes models, and denotes realizations. From requirements of the controlled system (RS/P ), a design of the controlled system (DS/P ) is made and decomposed into a plant (P ) and a supervisory controller (S). Requirements of the supervisor (RS ) are formally modeled resulting in a model of the control requirements (MRS ). From plant requirements (RP ), a design (DP ) and one or more models (MP ) are made, each with a different level of detail. For instance, a discrete-event model of the plant can be made that serves as input for the supervisory controller synthesis, while a more detailed (possibly hybrid) model can be developed to study the dynamic behavior of the plant by means of simulation. In this way, simulation of the hybrid plant model and the model of the supervisor can reveal invalid assumptions in the models that are used for

define define

Requirements Controlled System RS/P

define

Design Controlled System DS/P

Requirements Supervisor RS

model

Model Requirements Supervisor MRs

synthesize

Model Supervisor MS

realize

integrate

integrate

Interface integrate

define

Requirements Plant RP

design

Design Plant DP

model

Model Plant MP

integrate

realize

Figure 3.1: Model-based engineering supervisory controller design framework 19

Realization Supervisor ZS

Realization Plant

ZP

the supervisor synthesis. Using the supervisory control synthesis tool, which takes as input the discrete-event model of the plant and the model of the control requirements for the supervisor, the model of the supervisory controller (MS ) is synthesized. Using this model and the model(s) of the plant, the analysis techniques provided by the model based engineering paradigm can be used. Finally, by means of, for instance, code-generation, a realization of the supervisor can be made. In the case study for Oc´e, the requirements and design of the controlled system and the requirements and design of the plant are given. As a result, we can only make design choices on the model of the plant. We choose a discrete-event model of the plant. The requirements of the supervisor follow from the requirements of the controlled system and the requirements of the plant. An example is presented in the next chapter.

20

Model-Based Engineering Framework

for Supervisory Controller Synthesis

Chapter 4

Illustrative Example In this chapter we present an example to illustrate which types of generalized state-based requirement expressions we propose in this report. The proposed forms of expressions follow more naturally from intuitive, informal requirements. The example is inspired by a case study on the printing process part of an Oc´e printer. An external view of such an Oc´e printer is depicted in Figure 4.1. The paper input is where blank papers are stored. The paper transport mechanism

2a 3

2b

1 2a 2

Figure 4.1: External view of an Oc´e printer. 1. Paper input. 2. Print Engine. 2a. Paper Path. 2b. Print Process. 3. Finisher.

transports paper from the paper input, through the printing process to the finisher. The finisher sorts the paper, staples them, etc. The printing process is where the toner images are formed and transferred to the paper. Our example concerns the printing process. In Section 1 we describe the controlled system. Given the controlled system we decompose it into a plant and requirements in Sections 2 and 3. Using the requirements, we give an intuition on why we propose the new forms of requirement expressions in Section 4. 21

1 Controlled System Due to confidentiality and for illustrative reasons, we consider a simplified part of the printing process in this example. The supervisor is part of the distributed control depicted in Figure 4.2 and acts as a coordinator. A user sends print jobs and the distributed control actuates the hardware to realize the jobs. The supervisor we are considering, coordinates the print status and a maintenance procedure. The hardware can be in the following two print statuses: • Down, i.e., not ready to print pages, minimal consumption of energy, and ready to perform maintenance procedures; • Up, i.e., ready to print pages. The supervisor receives a desired status and information on the scheduling of the maintenance procedure. If no maintenance procedure is requested by the scheduling, then the supervisor must follow the desired status. If a maintenance procedure is requested by the scheduling, this has priority over the desired status since it concerns the quality of the prints. In this case, the supervisor must bring the print status to status Down and perform the maintenance procedure. In the following two sections, we divide the controlled system into a plant and control requirements.

2 Plant Model In this section we give a informal description of the plant model followed by a formal model using automata. The print status of the hardware is controlled by a part of the software named ‘Print Status’, see Figure 4.2. The print status can be Down, i.e., not ready to print pages, Up, i.e., ready to print pages, Starting, i.e., transitioning between Down and Up, and Stopping, i.e., transitioning between Up and Down. The supervisor can order a change in status with signals Down2Up and Up2Down. When a status is reached, the supervisor receives events InUp or InDown from the print status. This can be modeled using an automaton as depicted in Figure 4.3. Each state corresponds to a status and each event corresponds to a communication signal. Outgoing signals are controllable and incoming signals are uncontrollable. Initially the plant is in status Down and this is also the status in which it should end up. Therefore, Down is a initial and marked, or final, state. The user desired status is given by a part of the software named ‘Desired Status’, see Figure 4.2. The desired status is either Up or Down. An update of the desired status can be received by the supervisor at any moment in time with the signals GoToUp and GoToDown. This can be modeled using an automaton as depicted in Figure 4.3. The desired status Up is represented by state GoToUp, and Down by GoToDown. Both events are incoming, thus uncontrollable. It is assumed that initially and finally the desired status is GoToDown. The execution of the maintenance procedure by the hardware is controlled by a part of the software named ‘Maintenance A’, see Figure 4.2. The procedure is either idle, state A Idle↓, or in progress, state A Progress↓. The supervisor can send a signal A Start to initiate the procedure 22

Illustrative Example

User

Interface + Control

Desired Status _Desired_Up

Scheduling A

_Desired_Down

_A_Now

Distributed Control

_A_Finish

Supervisor Down2Up Up2Down

_InUp _InDown

A_Start

Print Status

_A_Finish

Maintenance A

Hardware

Figure 4.2: Distributed control scheme of a fictive case of the printing process, with one maintenance procedure

Desired Status

Scheduling A

_DesiredUp

_A_Now GoTo Up

GoTo Down _DesiredDown

A_Now

A_Not _A_Finish

_DesiredUp

_DesiredDown

Print Status

Maintenance A

Down

_InDown

Down2Up

A_Start Startin g

Stoppi ng

A_Pro gress

A_Idle _A_Finish

_InUp

Up2Down Up

Figure 4.3: Plant Automata.

and when it is finished a signal A Finish is received. Again the signals correspond to the signals 23

Plant Model

and controllability by the direction. It is assumed that initially and finally the procedure is idle. This results in the automaton depicted in Figure 4.3. The part of the software that determines whether a maintenance procedure is required is named ‘Scheduling’, see Figure 4.2. The scheduling can be in two statuses, namely the procedure A is not required: A Not, and the procedure A is required: A Now. The supervisor receives the signal A Now at the moment the procedure is required. Whenever the procedure is finished, the scheduling is reset. The resulting automaton is presented in Figure 4.3. Note that the event A Finish (printed red in Figure 4.3) synchronizes with the Maintenance A automaton, since the procedure is scheduled until it is finished. Until that moment, the scheduling will not schedule a next procedure.

3 Requirements Model Given a plant model, the next step is to formulate the requirements. The supervisor has the task to coordinate the printing process, i.e., to order the print status to follow the desired status, unless the scheduling gives an order to perform the maintenance procedure. This has priority over the desired status, since it concerns the quality of the prints. If an order to perform a maintenance procedure is received, the supervisor must bring the print status to down and execute the procedure. Afterwards, the desired status must be followed again. This results in the following four informal (state-based) requirements: 1. Maintenance A may only be in progress, if the Print Status is Down: A Progress↓ ⇒ Down↓; 2. Print Status may only go from Down to Up, if Desired Status is Up and the Scheduling A does not require a procedure: → Down2U p ⇒ ( GoToUp↓ ∧ ¬ A Now↓ ); 3. Print Status may only go from Up to Down, if the Desired Status is Down or if the Scheduling A requires a procedure: → U p2Down ⇒ ( GoToDown↓ ∨ A Now↓ ); 4. Maintenance may only start, if the Scheduling A requires a procedure: → A Start ⇒ A Now↓. These expressions follow from the intuitive, informal (state-based) requirements. Though these do not fit in the input for the Ma/Wonham tooling, these can be translated into an equivalent expressions that do, using the equivalences given in Chapter 2. We state the equivalent forms below and in Chapter 5 we derive an algorithm which automates these transformations:

24

Progress↓ ⇒ Down↓ ⇐⇒ ( Starting↓ ∧ A Prog↓ ) ∧ ( Up↓ ∧ A Prog↓ ) ∧ ( Stopping↓ ∧ A Prog↓ )

1.

A ¬ ¬ ¬

2.

→ Down2U p ⇒ ( GoToUp↓ ∧ ¬A Now↓ ) GoToDown↓ ⇒ 9 Down2U p ∧ A Now↓ ⇒ 9 Down2U p

3.

→ U p2Down ⇒ ( GoToDown↓ ∨ A Now↓ ) A Not↓ ∧ GoToUp↓ ⇒ 9 U p2Down

Illustrative Example

⇐⇒

⇐⇒

4.

→ A Start ⇒ A Now↓ A Not↓ ⇒ 9 A Start

⇐⇒

4 Proposal: Generalized Forms of State-Based Requirement Expressions This example shows that for certain models intuitive requirement expressions do not fit the input for the Ma/Wonham tool. We identified three forms of state-based requirement expressions that would make an addition to the Ma/Wonham expressions. The first two forms are generalizations of the Ma/Wonham expressions. The generalization is in the fact that instead of allowing only a combination (conjunction) of state predicates, we allow a state-formula (Definition 2.3). Generalizing the Ma/Wonham expressions mutual state exclusion (Definition 2.1) and state-transition exclusion (Definition 2.2) with a state formula results in: • Generalized state-formula (Definition 2.3); • Generalized state-transition exclusion (Definition 2.4). Note that we allow a set of events in a general state-transition exclusion expression instead of a single event. The third and last generalized form we distinguish is a • Generalized transition-state formula (Definition 2.5). This form is used when one wants to specify a possibility of occurrence of an event. The most convenient way of modeling these forms is to have the freedom to use these three forms in any random order, which is given by Definition 2.6. We note that there might be other forms of state-based requirements. One such form is given by the expression SF ⇒ → E, where SF is of type state-formula and E ∈ Σ. The interpretation of this expression is that if SF is valid, then an event in E is enabled. However, it is not needed to add this form to the input for the synthesis tool, since if an event is not disabled by any expression, by definition it is enabled. Still, for verification that an event in E had not been disabled by mistake, one can extend the tool to use such an expression. Moreover, note that the introduced predicates allow us to formulate expressions which do have a physical meaning, but are not implemented in the tooling, such as: → E ⇒ → B, where E 6= B, and E, B ∈ Σ. This expression states that if an event in E is enabled by the supervisor, then an event in B must be enabled. Future work might be to investigate whether these forms are desired as input. In the next chapter we derive an algorithm to convert the proposed forms into either one of the forms that can be used for the state-based Ma/Wonham tooling.

25

Proposal: Generalized Forms

of State-Based Requirement Expressions

26

Illustrative Example

Chapter 5

Conversion Algorithms Following the guidelines of the example presented in the previous chapter, in this chapter we derive conversion algorithms. We start from generalized state-based expressions, that follow from intuitive, informal requirements, and convert them into a form such that they can be used as input for the Ma/Wonham tool. These algorithms are implemented in a tool in Chapter 6. In Section 1, a conversion is presented that starts from a generalized state-formula expression (Definition 2.3) and converts it into an equivalent set of mutual state exclusion expressions (Definition 2.1). In Section 2, a conversion is presented that starts from a generalized state-transition exclusion expression (Definition 2.4) and converts it into an equivalent set of state-transition exclusion expressions (Definition 2.2). Finally, in Section 3, a conversion is presented that starts from a generalized transition-state formula (Definition 2.5) and converts it into an equivalent set of generalized state-transition exclusion expressions (Definition 2.2).

1 Generalized State-Formula to Mutual State Exclusion In this section, we derive a conversion algorithm which starts with a generalized state-formula expression, given by Definition 2.3, and converts it into an equivalent set of mutual state exclusion expressions, given by Definition 2.1. The correctness of the algorithm is given by the following theorem: Theorem 5.1. Generalized state-formula to mutual state Exclusion Given a generalized state-formula, SF , there exists a set of mutual state exclusion expressions, M S, such that SF ⇐⇒ M S.

Proof. Let SF be a state-formula. Then we can convert SF into conjunctive normal form, i.e., 27

Generalized State-Formula

to Mutual State Exclusion

 SF ⇐⇒

^

 _

 i∈I

sij↓ ∨

j∈Ji

_

¬sik↓, where sij , sik ∈ Q. We have the following computation:

k∈Ki

SF 

⇐⇒

¬sik↓

⇐⇒

 ^

_ 

i∈I

sij↓ ∨

_

j∈Ji

k∈Ki

_

_



 ^

¬¬ 

i∈I

sij↓ ∨

j∈Ji

¬sik↓

 ^  ^

¬

i∈I

 ^

¬

i∈I

¬sij↓ ∧

j∈Ji

t↓ ∧



^

i∈I

sik↓

⇐⇒

 

  ¬ 

⇐⇒

k∈Ki

t ∈ Qij , t 6= sij

 ^

sik↓ 

 _

j∈Ji

^ k∈Ki

 ^

⇐⇒

k∈Ki

_

 ^

 tm ∈ Qim , tm 6= sim for m ∈ Ji

tj↓ ∧

j∈Ji

^ k∈Ki

 ^ tm

i∈I : ∈ Qim , tm 6= sim for m ∈ Ji

¬

  sik↓ 

⇐⇒

 ^

j∈Ji

tj↓ ∧

^

sik↓

=

M S,

k∈Ki

where Qij and Qim are state sets of automata Aij and Aim , respectively, which concludes the proof. In the proof, first we convert the state-formula into conjunctive normal form using Proposition 2.10. Next, we use the double negation law and move one of the double negations inwards. This gives us a negation of a conjunction of state predicates. The conjunction still contains negations of state predicates, these are resolved using Proposition 2.12. Subsequently, we apply distributivity using Proposition 2.7. In the final step we apply Morgan’s law moving the disjunction over the negation. This gives us a set of mutual state exclusion expressions, which is suitable as input for the Ma/Wonham tool. Note that in the fifth step, the number of expressions grows exponentially with respect to the sizes of Qij for j ∈ J, as we make all possible combinations of Qij , see discussion of Proposition 2.7. The resulting set of expressions might contain several states from the same automaton. If this is the case, using (2.4) we can identify illegal expressions which can be removed. Otherwise, using idempotency the expressions can be simplified.

2 Generalized State-Transition Exclusion to State-Transition Exclusion In this section we derive a conversion algorithm using the preliminaries presented in Chapter 2. We start with a generalized state-transition exclusion expression, given by Definition 2.4, and and 28

Conversion Algorithms

convert it into an equivalent set of state-transition exclusion expressions, given by Definition 2.2. The correctness of the algorithm is given by the following theorem: Theorem 5.2. Generalized state-transition exclusion to state-transition exclusion Given a generalized state-transition exclusion expression, GST , there exists a set of state-transition exclusion expressions, ST , such that GST ⇐⇒ ST . Proof. Let GST be SF ⇒ 9 E, where SF is of type state-formula and E ⊆ Σ is a set of events. Then we can convert SF into disjunctive normal form, i.e., SF ⇒ 9 E ⇐⇒   _ ^ ^  sik↓ ∧ ¬sij↓ ⇒ 9 E, where sik , sij ∈ Q. We have the following computation: i∈I

GST

j∈Ji

k∈Ki

SF ⇒9E

⇐⇒

¬sij↓ ⇒ 9 E

⇐⇒

=  _

^

i∈I

j∈Ji

k∈Ki







_ ^   ^  sik↓ ∧    

i∈I

^

sik↓ ∧



_

j∈Ji

k∈Ki

t ∈ Qij t 6= sij

  t↓ ⇒ 9 E 



 

_  ^ sik↓ ∧  

i∈I

k∈Ki

_

 ^

 j∈Ji

tm ∈ Qim , tm 6= sim for m ∈ Ji

  tj↓ ⇒ 9 E 

 ^ 

^

sik↓ ∧

tj↓ ⇒ 9 E





^

^ 

^

sik↓ ∧

tj↓⇒ 9 E 





^

^ 

i∈I : ∈ Qim , tm 6= sim for m ∈ Ji

sik↓ ∧

^

tj↓⇒

j∈Ji

k∈Ki

9 el 

⇐⇒

 ^

 i ∈ I, l ∈ Li : ∈ Qim , tm 6= sim for m ∈ Ji

^ l∈Li

 ^ tm

⇐⇒

j∈Ji

k∈Ki

i∈I : tm ∈ Qim , tm 6= sim for m ∈ Ji

⇐⇒

j∈Ji

k∈Ki

i∈I : tm ∈ Qim , tm 6= sim for m ∈ Ji

⇐⇒



_

tm

⇐⇒

k∈Ki

sik↓ ∧

^

tj↓⇒9 el 

=

ST,

j∈Ji

where Qij and Qim are the state sets of automata Ail and Aim , respectively, which concludes the proof. In the proof, first we convert the state-formula into disjunctive normal form using Proposition 2.11. Next, we resolve negation of state predicates using Proposition 2.12. Subsequently, we apply distributivity using Proposition 2.7. In the following step, we move the disjunction outwards. Next, we apply Proposition 2.7 to move the disjunction outside the implication resulting in a conjunction. In the before last step, we replace each set of events Ei by the conjunction over each event in the set, see (2.2). In the last step, we move this conjunction outside, see Proposition 2.8. This gives us a set of mutual state exclusion expressions, which is suitable as input for the Ma/Wonham tool. 29

Generalized State-Transition Exclusion

to State-Transition Exclusion

Note that in the third step, the number of expressions grows exponentially with respect to the sizes of Qij for j ∈ J, as we make all possible combinations of Qij , see discussion of Proposition 2.7. Similar as in the previous section, the resulting set of expressions might contain several states from the same automaton. If this is the case, using (2.4) we can identify illegal expressions which can be removed. Otherwise, using idempotency the expressions can be simplified.

3 Generalized Transition-State Formula to State-Transition Exclusion In this section, we derive a conversion algorithm using the preliminaries presented in Chapter 2. We start with a generalized transition-state formula expression, given by Definition 2.5 and convert it into an equivalent set of state-transition exclusion expressions, given by Definition 2.2. The correctness of the algorithm is given by the following corollary, which is a direct consequence of Theorem 5.2: Corollary 5.3. Generalized transition-state formula to state-transition exclusion Given a generalized transition-state exclusion formula, GT S, there exists a set of state-transition exclusion expressions, ST , such that GT S ⇐⇒ ST . Proof. Let GT S be → E ⇒ SF , where SF is of type state-formula and E ⊆ Σ is a set of events. We have the following computation: GT S

=

→ E ⇒ SF ¬SF ⇒ ¬ → E ¬SF ⇒9 E

⇐⇒ ⇐⇒ =

GST,

from Theorem 5.2 follows: GST ⇐⇒ ST, which concludes the proof. In the proof, we use the law of implication reversal. The final result is identical to the definition of generalized state-transition exclusion, given in Definition 2.4, except for the negation in front of the state-formula. This is not a problem, since a negation of a state-formula is also a stateformula, see Definition 2.3. Given the set of generalized state-transition exclusion expressions, we can convert it into a set of state-transition exclusion expressions using Theorem 5.2, which is suitable as input for the Ma/Wonham tool.

30

Conversion Algorithms

Chapter 6

Tooling: Implementation of Conversion Algorithms Given the conversion algorithms described in the previous chapter, in this chapter we present a tool which implements these algorithms. We describe its functionality in Section 1. To illustrate this, in Section 2 the example from Chapter 4 is continued. To finalize this chapter we describe how the tool fits in the model-based engineering framework for supervisory controller synthesis in Section 3, which is presented in Chapter 3.

1 Tool Description In this section we describe the input and the output of the tool, which is implemented in the CIF toolset see [Sys08]. We refer to the tool as logexpr2spec-tool. An overview of the input and output is depicted in Figure 6.1. In the figure the same conventions are used as in Figure 3.1 depicting the model-based engineering framework. The input consists of a model of the plant (MP ) and a model of the requirements of the supervisor (MRS ). The output is a converted version of the model of the requirements of the supervisor (MRS ), which is given as input. The output model of the requirements of the supervisor is in the form of a spec-file (MRS .spec) and the input model of the plant is a sts-file (MP .sts), which are both input for the Ma/Wonham tool, see [Ma05a] for background information. For the input of the model of the requirements of the supervisor we introduce a new format: MRS .logexpr. In our new format, the three proposed forms of state-based requirement expressions are allowed, as given by Definition 2.6. Moreover, it is allowed to introduce a new names which represent either a state formula or a set of events, which can be used in other expressions. We discuss the syntax in detail in the remainder of this section.

31

The syntax of the logexpr-file is described below. The following conventions are used: • A comment line starts with #. • A set is indicated with curly brackets: { set }. • ∧ is entered as: &. • ∨ is entered as: |. • ¬ is entered as: ∼. • ⇒ is entered as: =>. Tool Description

Model Plant MP.sts

logexpr2spec [Sys08] Model Requirements Supervisor MRs.logexpr

Model Requirements Supervisor MRs.spec

Figure 6.1: Overview of the input and output for the logexpr2spec-tool. • state↓ is entered as: state. • → E is entered as: E, where E is a set of events. For example, → E with E = {e1, e2} is entered as { e1, e2 }. • → e is entered as: {e}, where e is an event. • 9 E is entered as: ∼E, where E is a set of events. For example, 9 E with E = {e1, e2} is entered as ∼{ e1, e2 }. • 9 e is entered as: ∼{e}, where e is an event. With the syntax, one can construct arbitrary logical expressions of state names and event sets. However, the program can convert only three forms, where S is a logical expression of nonterminal ’formula’ containing only state identifiers and operators, and E is an event set following the syntax of non-terminal ’names’: 1. A formula S, as given by Definition 2.3. 2. A formula S => ∼E, as given by Definition 2.4. 3. A formula E => S, as given by Definition 2.5. In addition, it is possible to introduce new names to make modeling simpler. The formula new name = S introduces a new name, new name, for state-formula S. The formula new name = E introduces a new name, new name, for event set E. Such names can be used in other formulas. Note that we write new names of type state-formula bold and new names of type event set italic. For example, • if we want to introduce a new name, name1, for state-formula ( state1↓ ∨ state2↓ ) ∧ state3↓, we enter: name1 = (state1 | state2) & state3; • if we want to introduce a new name, name2, for event set { event1, event2 }, we enter: name2 = { event1, event2}; • if we want to use the new names introduced in the previous two bullets to construct a stateformula, which states that whenever state-formula name1 is valid, the set of events name2 must be disabled, i.e., name1↓⇒9 name2, we enter: name1 => ∼name2. A conjunction of formulas F 1 & F 2 & F 3 & ... & F n, where each F i is of type formula, is entered as: (F 1, F 2, F 3 ..., F n). This allows the user to enter the set of generalized expressions as given by Definition 2.6 and the introduced names. Given the above described input, the following checks are performed before the three conversion algorithms, given in Theorem 5.1 and 5.2 and Corollary 5.3, are executed: • A syntax check on the sts-file. This includes a if the state tree structure (plant model) is well formed, for details see [Ma05a]; 32

Conversion Algorithms

• A check that all state and event names used in the specifications and mappings exist in the plant model; • A syntax check on the logexpr2spec-file. These checks are also an improvement to the Ma/Wonham original tooling, since these are not implemented in the Ma/Wonham tooling. In many cases a supervisor is calculated by the Ma/Wonham tool, even when the input contains mistakes. This might lead to undesired behavior of the plant under supervision.

2 Example In this section we use the tool to convert the expressions from the example presented in Chapter 4. The logexpr-file has the following form: 1 2 3 4 5 6 7 8

# 1 A_Progress # 2 {Down2Up} # 3 {Up2Down} # 4 {A_Start}

=> Down, => (GoToUp & ˜A_Now), => (GoToDown | A_Now), => A_Now

We refer to Appendix A for the corresponding sts-file which is needed as input for our tool. Running the tool gives the following spec-file as output (see Section 3 for the syntax): 1 2 3 4 5 6 7 8 9 10 11

{ {Up,A_Progress} {Starting,A_Progress} {Stopping,A_Progress} } { ({GoToDown},Down2Up) ({A_Now},Down2Up) ({A_Not,GoToUp},Up2Down) ({A_Not},A_Start) }

This matches the expected output presented in Chapter 4.

3 Model-Based Engineering Tool-Chain The logexpr2spec-tool described in the previous section fits in the tool-chain for modelbased engineering framework for supervisory controller synthesis [Sch09b]. In the remainder of this section we describe the tool-chain, updated with our tool. Figure 6.2 shows the tool-chain for model-based engineering framework for supervisory controller synthesis to support state-based supervisory controller design. In the figure, the following conventions are used: icon denotes documents, denotes models, and denotes tools. The (file) extension ‘.sts’ refers to a state-tree structure, and extension ‘.spec’ refers to the specification of the control requirements, both specified using the input language for the controller 33

Model-Based Engineering Tool-Chain

Requirements Supervisor RS Requirements Controlled System RS/P

Model Requirements Supervisor MRs.logexpr

Model Requirements Supervisor MRs.spec

logexpr2spec [Sys08]

NBC [Ma05a]

Model Supervisor MS.bdd

STS2CIF [Sys08]

Model MP.cif

BDD2CIF [Sys08]

Model Supervisor MS.cif

Design Controlled System DS/P Requirements Plant RP

Requirements Plant DP

Model Plant MP.sts

MERGECIF [Sys08]

SIMULATOR [Sys08]

Model Controlled System MS/P.cif)

Figure 6.2: Model-based engineering for supervisory controller synthesis tool-chain synthesis software package NBC, see [Ma05a]; extension ‘.logexpr’ refers to our input file for the above described tool; extension ‘.bdd’ refers to the Binary-Decision-Diagrams, see [Ma05b], one for each controllable event; extension ‘.CIF’ refers to the CIF language, see [Sys08]. In the state-based tool framework, the same five documents (RS/P , DS/P , RS , RP , and DP ) are distinguished as in the framework described in Chapter 3. The model of the requirements of the supervisor, MRS , is first modeled in a logexpr-file, MRS .logexpr, as described in the first part of this section. Using the logexpr2spec-tool, MRS .logexpr is translated into a spec-file, MRS .spec. The resulting MRS .spec is the equivalent of MRS .logexpr that can be used as input for the Ma/Wonham tooling. The model of the plant, MP , is modeled in a sts-file, MP .sts. MP .sts can be used as input for the Ma/Wonham tooling. The model is translated to an equivalent CIF, see [Sys08], model, MP .cif . Using the Ma/Wonham tooling, NBC, the model of the supervisor, MS .bdd, can be synthesized. This model is respectively translated, with the tool BDD2CIF, to an equivalent CIF model, MS .cif . These models of the supervisor relate to MS in the MBE-SCT framework. Given the plant model, MP .cif , and the supervisor model, MS .cif , the tool MERGECIF generates a discrete-event model of the plant controlled by the supervisor, MP/S .cif . This model can be used as input for the CIF simulator, SIMULATOR, to analyze the behavior of the plant with respect to the control requirements. Finally, these models can be used to make an implementation of a software controller.

34

Conversion Algorithms

Chapter 7

Conclusion In this report we formulated three generalized forms of requirements expressions, that would make an addition to state-based supervisory controller synthesis toolset from Ma and Wonham [Ma05b, Ma05a]. Depending on the system, these are more naturally derived from informal state-based requirements. The forms of requirements expressions that can be used as input for the Ma/Wonham tooling are a subset of the generalized forms. Therefore, the generalized forms are an addition. Given the generalized forms, we derived a conversion algorithms, from the generalized forms into the forms for the Ma/Wonham tooling. The algorithms are implemented in a tool, which also performs checks on the input. The tool fits within the existing guidelines (and tool chain) of the model-based engineering for supervisor controller synthesis paradigm [Sch09a, Sch09b]. The generalized expressions are used to solve an industrial case. The plant consists of 15 automata (2–17 states) and 50 generalized requirements. The conversion algorithm gives 200+ Ma/Wonham input expressions. Due to confidentiality, we cannot present additional details in this report.

35

36

Conclusion

Bibliography [B¨un99] H.K. B¨uning and T. Lettmann. Propositional logic: deduction and algorithms. Cambridge Univ Pr, 1999. [Cas04] C. Cassandras and S. Lafortune. Introduction to discrete event systems. Kluwer Academic Publishers, 2004. [Ma05a] C. Ma and W.M. Wonham. Ma/Wonham Tool. Can be downloaded from: http: //se.wtb.tue.nl/sewiki/_media/wonham/sts.tgz, 2005. [Ma05b] C. Ma and W.M. Wonham. Nonblocking Supervisory Control of State Tree Structures. PhD Thesis, University of Toronto, 2005. [Ram87] P.J. Ramage and W.M. Wonham. Supervisory control of a class of discrete event processes. SIAM Journal on Control and Optimization, 25:206–230, 1987. [Sch09a] R. R. H. Schiffelers, R. J. M. Theunissen, D. A. van Beek, and J. E. Rooda. Modelbased engineering of supervisory controllers using cif. In Workshop on Multi Paradigm Modeling, ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, United States, 2009. [Sch09b] R.R.H. Schiffelers, D. Hendriks, R.J.M. Theunisesen, and J.E. Rooda D.A.van Beek. Integrating Model-Based Engineering and State-Based Supervisory Controller Synthesis. Technical report, Eindhoven University of Technology, Systems Engineering Group, 2009. [Sys08] Systems Engineering Group TU/e. CIF toolset. http://se.wtb.tue.nl/sewiki/cif, 2008. [Won08] W.M. Wonham. Supervisory control of discrete-event systems. Technical report, Systems Control Group, Department of Electrical & Computer Engineering, 2008.

37

38

Bibliography

Appendix A

Illustrative Example: STS-file In this appendix we give the input sts-file which is used in Chapter 6 applying our tool to the illustrative example presented in Chapter 4. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

39

root = plant { plant Status Maintenance_A Schedule_A DesiredStatus }

= = = = =

AND OR OR OR OR

{ { { { {

Status, Maintenance_A, Schedule_A, DesiredStatus } Down, Starting, Up, Stopping } A_Idle, A_Prog } A_Not, A_Now } GoToDown, GoToUp }

Status { Down2Up Up2Down } { _InUp, _InDown } { [ Down Down2Up Starting ] [ Starting _InUp Up ] [ Up Up2Down Stopping ] [ Stopping _InDown Down ] } Maintenance_A { A_Start } { _A_Finish } { [ A_Idle A_Start A_Prog ] [ A_Prog _A_Finish A_Idle ] } Schedule_A {} { _A_Now _A_Finish } { [ A_Not _A_Now A_Now ] [ A_Now _A_Finish A_Not ] } DesiredStatus

37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

40

{ { { [ [ [ [ }

} _DesiredDown _DesiredUp } GoToDown GoToDown GoToUp GoToUp

_DesiredDown GoToDown ] _DesiredUp GoToUp ] _DesiredDown GoToDown ] _DesiredUp GoToUp]

{ Down, A_Idle, A_Not, GoToDown

}

{ { Down, A_Idle, A_Not, GoToDown } } {

}

Illustrative Example: STS-file