3. Networks of automata

Transcription

1 3. Networks of automata Suppose that we need to model a traffic light system consisting of n traffic lights and a controller that has the obligation to guarantee that the complete system behaves safely (as long as drivers and automobiles behave as prescribed by the traffic lights). The state of the system can be characterized as a combination of the states of the contained traffic lights. For a traffic light with k different states (usually k equals two or three) this results in k n locations! When applying a model-based systems engineering approach to the development of supervisory controllers for high-tech systems, a similar situation is encountered. Often the system that needs to be controlled consists of a large number of subsystems or components. As an example consider bagage handling systems as described in [Swa17] that consist of hundreds of conveyor belts and other components. It is much more convenient (and desirable) to provide separate models for each of these constituent parts of the system than to attempt to provide a single automaton model for the combination of all of these parts. To ease the modelling of such a system we introduce networks of automata. A network of automata consists of a finite collection of automata. These automata may share events and variables. The automata in a network execute simultaneously. They interact with each other by synchronizing on shared events and by the shared use of variables. These forms of interaction will be discussed in more detail in the first two sections. 3.1 Synchronization of events Events that are used in multiple automata, must synchronize. That is, if one of those automata performs a transition for that event, the other automata must also participate by performing a transition for that same event. If one of the automata that uses the event cannot perform a transition in its current state, the network as a whole cannot perform a transition for that event. To illustrate this, consider the following example. Example 3.1 The automaton in the left of Figure 3.1 represents a producer of products, to be consumed by a consumer. The producer automaton starts in its producing location, in which it produces a product. Once the product has been produced, indicated by the produce event, the automaton will be in its idle location, where it waits until it can provide the produced product to the consumer (the event provide is used for modelling this). Once it has provided the product to the consumer, it will once again be producing another product.

2 38 Chapter 3. Networks of automata produce provide Producing Idle Idle Consuming provide consume Figure 3.1: Automata that synchronize on events. The event provide is shared between the automata and therefore will only be executed when both automata allow this. Consider also the automaton for the consumer given in the right of Figure 3.1. This second automaton represents a consumer that consumes products. The consumer is initially idle, waiting for a product from the producer. Once the producer has provided a product, the consumer will be consuming. Once it has consumed the product, as indicated by the occurrence of the consume event, it will become idle again. The specification has three events: the produce and provide events are used in the producer automaton, and the provide and consume events are used in the consumer automaton. The automata share the provide event. Now, let us take a closer look at the behavior of the network consisting of the producer and consumer automata. Initially, the producer automaton is in its producing location, and the consumer automaton is in its idle location. Since the producer is the only automaton that uses the produce event, and there is an (outgoing) edge in its current location for that event, the producer can go to its idle location by means of that event. Both the producer and consumer use the provide event. Initially, the producer has no edge with that event in its producing location, while the consumer does have an edge for that event in its idle location. Since events must synchronize, and the producer cannot participate, the event cannot occur at this time. This is what we expect, as the producer has not yet produced a product, and can thus not yet provide it to the consumer. The consumer will have to remain idle until the producer has produced a product and is ready to provide it to the consumer. The producer blocks the provide event in this case, and is said to disable the event. The event is not blocked by the consumer, and is thus said to be enabled in the consumer automaton. In the entire network, the event is disabled as well, as it is disabled by at least one of the automata of the network, and all automata must enable the event for it to become enabled in the network. The only behavior that is possible, is for the producer to produce a product, and go to its idle location. The consumer does not participate and remains in its idle location. Both automata are then in their idle location, and both have an edge that enables the provide event. As such, the provide event is enabled in the network. As this is the only possible behavior, a transition for the provide event is performed. This results in the producer going back to its producing location, while at the same time the consumer goes to its consuming location. In its producing location, the producer can produce a product. Furthermore, in its consuming location, the consumer can consume a product. Two transitions are possible; either one can be performed. No assumptions should be made either way. In other words, both transitions represent valid behavior, as described by this specification. Since only one transition can be taken at a time, there are two possibilities. Either the producer starts to produce the product first, and the consumer starts to consume after that, or the other way around. Once both transitions have been taken, we are essentially in the same situation as we were after the producer produced a product the first time, as both automata will be in their idle locations again. The behavior of the network then continues to repeat forever. However, for each repetition different choices in the order of production and consumption can be made.

3 3.1 Synchronization of events 39 Exercise 3.1 Guided by your intuition, provide a single automaton that expresses the same behaviour as the network of automata from the previous example. R As we will see later, in Section 3.4, for any network of automata, we can give a single automaton that defines the same behaviour in the sense of (marked) language equivalence. By using multiple automata, the producer and consumer were modeled independently, allowing for separation of concerns. This is an important concept, especially when modeling larger systems. In general, the large system is decomposed into parts, usually corresponding to physical entities. Each of the parts of the system can then be modeled in isolation, with little regard for the other parts. Note that it is of course very important to make proper decisions on which events are to be shared between the automata! By using synchronizing events, the different automata that model different parts of a system, can interact. This allows for modeling of the connection between the different parts of the system, ensuring that together they represent the behavior of the entire system. Exercise 3.2 Provide a network of automata for the two traffic light system discussed before in Exercise 2.7, where each traffic light and the controller are modelled by means of a separate automaton. Exercise 3.3 Consider a system consisting of two users, U 1 and U 2, and two shared resources, R 1 and R 2. User U i needs both resources to perform a task (represented by a i,b i ). After the task completion, the resources are released (represented by r i ). Provide an automaton for each of the users and each of the resources. Exercise 3.4 Recall Exercise 2.9 about the dining philosophers. Develop a model of the system where each philosopher and each fork is modelled as a separate automaton. As we have seen in Exercise 2.46 there is a deadlock in this system. Add an automaton that prevents the deadlock from occurring while maintaining all other behaviour of the system. Later in Exercise 3.29 you will use CIF to simulate the model in order to establish if you have succeeded in removing the deadlock situation(s). Exercise 3.5 Pump-valve-controller system, adapted from [CL99, Example 2.25]. Consider a heating system consisting of a pump, a valve, and a controller. In Figure 3.2 the models of the pump and the valve are shown. The model for the valve contains states VC and VO representing the situations that the valve is closed and open, respectively. Additionally, the states SO and SC represent that the valve is stuck when open or closed. The events are easily understood by their names. The model for the pump should be straightforward. Develop a model of a controller that may use the events open_valve, close_valve, start_pump, and stop_pump and that prevents that the pump is operating while the valve is closed. Exercise 3.6 For the pump-valve-controller system of the previous exercise, model a valve flow sensor. It may be assumed that the sensor is discretized to two possible values, namely flow and no_flow. First, establish under what conditions the valve flow sensor should report a flow event and in which circumstances it must report a no_flow event. Exercise 3.7 The wolf, the goat, and the cabbage. A man once had to travel with a wolf, a goat and a cabbage. He had to take good care of them, since the wolf would like to taste a piece of goat if he would get the chance, while the goat appeared to long for a tasty cabbage. After some traveling, he

4 40 Chapter 3. Networks of automata close_valve stop_pump VC stuck_closed SC Poff open_valve stuck_open stuck_closed stop_pump start_pump close_valve SO stuck_open VO Pon open_valve start_pump Figure 3.2: Automata for the valve and the pump. suddenly stood before a river. This river could only be crossed using the small boat laying nearby at a shore. The boat was only good enough to take himself and one of his loads across the river. The other two subjects/objects he had to leave on their own. How must the man row across the river back and forth, to take himself as well as his luggage safe to the other side of the river, without having one eating another? Provide a model that allows all safe behaviour! Now etend the model to deal also with two additional pieces of luggage - a stick and fire! In addition to the restrictions mentioned before, if the stick and the wolf are left on their own, the stick will beat the wolf! If the fire and the stick are left on their own, the fire will burn the stick! Exercise 3.8 Consider a lift moving products in a warehouse to the next floor. An electric motor is used to control the lift. The motor can move the lift upwards with event move_up, move the lift downwards with event move_down, or stop the lift with stop. The position of the lift is measured with two sensors L and H. L is located at the lowest position of the lift and H is located at the highest position. The sensors will turn on with events L_on and H_on when the lift is at the location of the corresponding sensor, and turn off with events L_off and H_off when the lift is not at the sensor. Provide an automaton model for the actuator and each sensor. Furthermore, include the sensor events in the actuator model to restrict the behavior to only physically possible behavior of the sensors. Exercise 3.9 A workcell consists of two machines M 1 and M 2, and robot arm RA. Machine M 1 receives workpieces from an input bin (event in). After processing, the robot arm takes the workpiece from M 1 (event pick 1 ), moves to M 2 (event move 12 ), delivers the workpiece to M 2 (event drop 2 ) and moves back (event move 21 ). After processing, machine M 2 sends workpieces to an output bin (event out). For both machines holds that if a new workpiece is delivered while they are busy, this workpiece is rejected (events reject 1 and reject 2 ). Define corresponding automata models.

5 3.2 Shared variables 41 Exercise 3.10 Workcell with a test unit. Consider a workcell consisting of two machines M 1 and M 2, buffer B and test unit TU, schematically represented below. M 1 B M 2 TU Machine M 1 receives workpieces from an input bin (event start_m 1 ). After processing, machine M 1 sends a workpiece to buffer B (event end_m 1 ). Two-place buffer B receives a workpiece either from M 1 or from the test unit TU (event to_b). From the buffer, workpieces are transferred to M 2 (event start_m 2 ). After processing, machine M 2 sends workpieces to the test unit TU (event end_m 2 ). From the test unit, workpieces are transferred either to the buffer (event to_b) or to an output conveyor (event to_c). Model the four workcell components as automata. Exercise 3.11 Transmitters. System T to be controlled consists of two transmitters T 1 and T 2 modelled over alphabet Σ i = {a i,s i,t i,r i }, for i = 1,2. Events: a i denotes arrival of a message to be transmitted s i denotes the start of message transmission t i denotes timeout in case the transmitted message is not acknowledged r i denotes reset for transmission of a subsequent message An unacknowledged message is retransmitted after timeout. New messages that arrive while a previous message is being processed are ignored. First, provide a model for each transmitter. Are there any shared events in these automata? Now add a model of a shared medium. That is, it is assumed that both transmitters use the same medium for transmitting their messages. In case a transmitter is willing to start a ransmission while the medium is occupied it will wait until the medium is available. The medium has a capacity of one message only. Exercise 3.12 Three servers. Can you improve on your model for the three server system from Exercise 2.12 by modeling it as a network of automata (without variables)? 3.2 Shared variables As mentioned in the introduction of this chapter, variables can be shared between the automata involved in a network of automata. In the type of networks we consider, a variable is local to one automaton. This means that the variable may only be assigned (given a value, written) by that automaton. All variables may however be inspected (read) by all automata in the network. Consider the following example. Example 3.2 Supermarket. We model some aspects of a supermarket checkout, namely the arrival of customers and their queueing behaviour with respect to two queues. Customers arrive and enter either of the queues. Eventually customers leave the queue. For modelling this system three automata are considered, one for each queue and one for the customer arrival process. Both queues (automata queue1 and queue2) are identical, except for their names and the names of the events

6 42 Chapter 3. Networks of automata used in those automata 1. Each queue maintains a variable count, which represents the number of customers in the queue. Note that these are different variables! A queue is full if it contains two customers. Customers can thus only enter a queue if less than two customers are present. Similarly, it is only possible for a customer to leave a queue if there is a customer in the queue. Customers decide to which queue they go, based on the number of customers already present in those queues. A customer only enters the first queue if that queue has less than or the same number of customers as the second queue. Similarly, a customer only enters the second queue if that queue has less than or the same number of customers as the first queue. If the queues have the same number of customers, the customer can choose either queue. The three automata are given in Figure 3.3. The event q1enter is used in automata queue1 and customer. The event is thus only possible (enabled) if both automata can participate. Both automata restrict the occurrence of the event using a guard. The event is thus only enabled if both guards hold. That is, a customer never enters the first queue if it is full, but it also never enters that queue if it has more customers than the second queue. The customer automaton uses the values of the variables of the queue automata, and thus reads variables of other automata. This is allowed, due to the global read concept. This concept allows for guards, that directly and intuitively represent the condition under which an event may take place. In the guard the variable count of automaton queue1 is referred to by prefixing the variable name with the automaton name, i.e., queue1.count refers to variable count of automaton queue1. count < 2 q1enter count := count + 1 count < 2 q2enter count := count + 1 queue1.count queue2.count q1enter count = 0 count = 0 count > 0 q1leave count := count 1 count > 0 q2leave count := count 1 queue2.count queue1.count q2enter Figure 3.3: Network of automata for the supermarket. From left to right these automata are named queue1, queue2, and customer. The global read concept should only be used when it is intuitive. In the supermarket example, the customer can physically see how many customers are in the queues. It is therefore intuitive to directly refer to the count variables of the queue automata. If however the customer would not be able to physically observe the queues, then the customer would not be able to directly base its decision of which queue to join on that information. In that latter case, it may not be a good idea to model the guard in such way. The local write concept means that a variable can only be written by the automaton in which it is declared. It is not allowed for the automata customer and queue2 to write (change the value of) the variable count of the automaton queue1. Only automaton queue1 may write that variable. The local write concept prevents that multiple automata write to the same variable, as part of a synchronizing event, potentially causing conflicting values to be assigned to that variable. This leads to several benefits, most notably simpler semantics. 1 CIF offers features for reuse and parameterization of automata. However these are beyond the scope of this course. The online language tutorial contains all the relevant information:

7 3.2 Shared variables 43 R In the tool Supremica ( variables are used that are declared globally and may be written and read in every automaton. From the perspective of modelling discrete-event systems and synthesizing supervisory controllers, Supremica may be considered an interesting alternative for CIF. In theory, each and every variable needs to be declared explicitly. However, it will turn out te be very convenient to be able to check whether or not another automaton is in a particular state in guards. Therefore, we assume the presence of Boolean variables that indicate whether an automaton is in a specific location. More concretely, for any automaton with name A and location l within that automaton we assume the existence of a Boolean variable A.l that is true if automaton A is in location l, and false otherwise. These location variables are never explicitly updated in the automata. Example 3.3 Consider the two automata given in Example 3.1. Suppose we want to adapt the condition of the event produce from the provider automaton in order to prevent it from being taken in cases where the consumer automaton is not yet in location Idle. With the location variables just introduced this amounts to adding the guard consumer.idle to the produce event. Exercise 3.13 For the pump-valve-controller system, as discussed in Exercise 3.6, model a valve flow sensor. This time collect the resulting value in a variable flow. Figure 3.4: Schematic representation of the ATM and bank system. Exercise 3.14 Exam 2014/10/28. Model a system consisting of an ATM and a bank. In Figure 3.4 the events that are used to describe interactions between these systems are depicted. No other events may be used! Provide one automaton for the ATM and one for the bank. It is not needed to model the user. Your model of the ATM should be able to repeatedly handle the interactions with the user in the same order as depicted in the picture from top to bottom. Model the exchange of the bank card just as the occurrence of an event bank_card. Upon receipt of a request, the ATM may inspect a variable User.request_amount to obtain the amount that the user wants to withdraw from his account. The ATM asks the bank for permission. The bank uses the same variable from the user to get to know the amount of money the user wants to withdraw and checks with respect to the users balance (stored in variable balance) if this is still possible without ending up with a negative balance. The bank replies to the ATM with either OK or not_ok. The ATM returns the bank card and provides the cash (by means of the event cash). There is no need to model the amount of cash in the ATM or in the possession of the user. Exercise 3.15 Traffic system [CL99, Exercise 3.28]. Consider the traffic system shown in Figure 3.5. There are two vehicles, denoted by a and b, that must go from the origin to the destination. The road is divided into four sections, numbered 1-4. There are traffic lights at the entrances of sections 1 and 4. There are vehicle detectors at the entrances of sections 1, 3, and 4 and at the destination. Let events x i (for x = a,b and i = 1,...,5) denote that vehicle x enters section i, where section 5 is the destination. Develop a model for a controller that guarantees that (i) the two vehicles must reach

8 44 Chapter 3. Networks of automata Figure 3.5: Traffic system; schematic representation. the destination, and (ii) only one vehicle can be in a road section at any given time (in order to avoid collisions). You may assume that vehicle x (for x = a,b) can only perform the sequence of events x 1 x 2 x 3 x 4 x 5 (for x = a,b). The controller may only use the events x 1, x 3, x 4 and x 5 (for x = a,b). Take care that your controller does not prevent the events a 3 and b 3 from happening since there is no traffic light at the start of section 3. Is your controller more restrictive than necessary? Exercise 3.16 Three servers. Can you improve on your model for the three server system from Exercise 2.12 by modeling it as a network of automata using variables? Exercise 3.17 Manufacturing system [Oue+11]. Consider a system consisting of three machines M 1, M 2, and M 3, working on parts stored in two buffers B 1 and B 2 of size 16 and 8, respectively. Parts are supplied through an input buffer IN (of infinite size) and stored after being processed in two output buffers OUT 1 and OUT 2 (of infinite size). The system operates as follows: M 1 supplies B 1 with parts taken from the input buffer IN; M 2 takes a part from B 2 and after processing puts it either in OUT 1 or in B 1 ; and M 3 takes a part from B 1 and after processing puts it either in OUT 2 or in B 2. Provide a network of automata that models all possible movement of parts between these subsystems. There is no need to discriminate between parts. Exercise 3.18 Manufacturing system [MMF13]. Model the following manufacturing system that consists of four machines M 1, M 2, M 3, and M 4, linked by three buffers B 1, B 2, and B 3. Workpieces are processed by M 1 (event s 1 ) and then placed into B 1 ( f 1 ), then they go to M 2 (s 2 ) and are placed into B 2 ( f 2 ). From B 2, the workpieces go to M 3 for final processing (s 3 ) and then M 3 outputs them from the system ( f 3 ). Additionally, M 4 takes workpieces from outside the system (s 4 ), processes them and sends them either to M 2 or M 3 through B 1 (event re) and B 3 (events f 3 for transport to the buffer and s 34 for transport from buffer to machine), respectively. Provide a network of automata that models all possible movement of parts between these subsystems. There is no need to discriminate between parts. Exercise 3.19 A customer C orders a product at a plant P. The plant passes the order to the manufacturer M. The manufacturer makes the product and gives it to the transporter T. The transporter delivers the product to the customer, unless something goes wrong in transport. If this occurs, this is reported to P, who will take care of the production of a new product. Provide a model for this system. How many products can be in production in this system? How should the specification be changed to increase this number of products in production?

9 3.3 Open automata 45 Exercise 3.20 Manufacturing process [CL99, Exercise 2.39]. A simple manufacturing process involves two machines, M 1 and M 2, and a buffer B in between. There is an infinite supply of parts to M 1. When a part has finished processing at M 1, it is placed in B, which has a capacity of one part only. The part is subsequently processed by M 2. Each machine has three states I (Idle), P (Processing), and D (Down). Each machine has four transitions: see Figure 3.6 for the automata. Explain why the two machines use different event names! Give a separate controller for each of the following requirements: M 1 can only begin processing if the buffer is empty; M 2 can only begin processing if the buffer is full; M 1 cannot begin processing if M 2 is down; If both machines are down, then M 2 gets repaired first. Can you establish whether the system consisting of all these automata has deadlock? start_m 1 breakdown_m 1 start_m 2 breakdown_m 2 I P D end_m 1 repair_m 1 I P D end_m 2 repair_m 2 end_m 1 E F start_m 2 Figure 3.6: Network of automata for the simple manufacturing system consisting of automata for two machines and one buffer. Exercise 3.21 Extended Workcell with a test unit. Adopt your model from Exercise 4.5 to allow for multiple workpieces in each machine, and in the buffer. Assume that the capacities of the machines are given by some constant C 1 and C 2 and that the buffer may contain C B workpieces. 3.3 Open automata As mentioned in the previous section we will use automata that allow two types of variables: local variables that may only be assigned by that automaton, and external variables that may be read by the automaton. We thus need to adapt Definition of automata. As we have seen before in Example 3.2 different automata may use the same local variable name. Both the automata queue1 and queue2 use a local variable count. To differentiate between these in mathematical representations we will always prefix local variables with the name of the automaton they are local to. Thus, for the purpose of mathematical description we would first transform the automata for the queues from Figure 3.3 into the following automata: Definition Open automaton. An open automaton is a 8-tuple (L,V,X,E,,L m,l,v) where L is a finite set of locations; V is a finite set of local variables; X is a finite set of variables (V X);

10 46 Chapter 3. Networks of automata queue1.count < 2 q1enter queue1.count := queue1.count + 1 queue2.count < 2 q2enter queue2.count := queue2.count + 1 queue1.count = 0 queue2.count = 0 queue1.count > 0 q1leave queue1.count := queue1.count 1 queue2.count > 0 q2leave queue2.count := queue2.count 1 Figure 3.7: Transformed versions of automata queue1 and queue2 from Figure 3.3. E is a finite set of events; L G(X) E U(V, X) L is the transition relation; L m L is a set of marked states; l L is the initial location; v : V Λ is the initial valuation of the local variables. The notation U(V,X) represents the set of all updates of variables from the set V where variables from X may be used in the right-hand sides of the updates. The set of variables X \V is referred to as the (set of) external variables. Observe that an open automaton where X = V is just an automaton in the style of Definition Definition Network of automata. Let I be an arbitrary index set. A network of automata is a collection of open automata M i =(L i,v i,x i,e i, i,l mi,l i,v i ) for i I, with pairwise disjoint sets of local variables V i such that V i = X i, i.e., each global / external variable of an open automaton is local to exactly one of the contained open automata. i I i I Example 3.4 Consider the (transformed) network of automata for the supermarket from Figures 3.3 and 3.7. The automaton queue1 has set of local variables {queue1.count} and automaton queue2 has set of local variables {queue2.count}. Both of these automata have no additional variables. The automaton customer has no local variables and has set of variables {queue1.count,queue2.count}. The specification of the other components of the 8-tuples representing the automata follows the same lines as before with the difference that also there the full names of the variables are used. R Our graphical representations usually only show the local and external variables that actually occur in guards and updates. It may be the case that a local variable is declared in some automaton and not used in any of the guards or updates. In such cases this will be mentioned explicitly. We thus assume that the sets of local variables and variables are always the sets of variables mentioned in the guards and updates, unless stated otherwise. 3.4 Synchronous composition of automata Networks of automata were motivated from the point of view that describing larger systems with a single automaton is inconvenient. In principle, nevertheless, a single automaton is represented by such a network of

11 3.4 Synchronous composition of automata 47 automata. In this section we define how to obtain a single automaton representing a network of automata. Thereto, first the synchronous product of two open automata is defined. Definition Synchronous product. Given two open automata M 1 =(L 1,V 1,X 1,E 1, 1,L m1,l 1,v 1 ) and M 2 =(L 2,V 2,X 2,E 2, 2,L m2,l 2,v 2 ), the synchronous product of these, denoted by M 1 M 2, is given by the open automaton (L,V,X,E,,L m,l,v) where L = L 1 L 2 V = V 1 V 2 X = X 1 X 2 E = E 1 E 2 is defined as the smallest relation that is defined by the following deduction rules: if σ E 1 E 2, then ((s 1,s 2 ),g 1 g 2,σ,u 1 u 2,(t 1,t 2 )) for each (s 1,g 1,σ,u 1,t 1 ) 1 and (s 2,g 2,σ,u 2,t 2 ) 2 such that u 1 (x)=u 2 (x) for all x dom(v 1 ) dom(v 2 ) if σ E 1 \ E 2, then ((s 1,s 2 ),g 1,σ,u 1,(t 1,s 2 )) for each (s 1,g 1,σ,u 1,t 1 ) 1 if σ E 2 \ E 1, then ((s 1,s 2 ),g 2,σ,u 2,(s 1,t 2 )) for each (s 2,g 2,σ,u 2,t 2 ) 2 L m = L m1 L m2 l =(l 1,l 2 ) { v 1 (x), for x dom(v 1 ) v : V Λ is defined as follows: v(x)= v 2 (x) otherwise R Note that in order to respect our naming convention for the variables, we need to replace all prefixes of the local variables of the involved automata with the name of the resulting automaton. Note that v is well-defined since the sets of local variables of the automata, i.e., V 1 and V 2, are disjoint. This is a consequence of our naming convention for variables! For updates u 1 and u 2 in the above definition the following notation has been used: u 1 u 2 denotes the update with domain dom(u 1 ) dom(u 2 ) that is defined as follows: { u 1 (x), if x dom(u 1 ) (u 1 u 2 )(x)= u 2 (x), otherwise. Note that in our graphical representations the combination of two updates just means that the updates are both put on the edge! Example 3.5 Consider the two automata given in Example 3.1. The synchronous product of these two automata is given graphically by Producing Idle produce Idle Idle consume provide consume Producing Consuming produce Idle Consuming

12 48 Chapter 3. Networks of automata The locations of this resulting automaton are formally represented by the set {(Producing,Idle), (Idle,Idle), (Producing,Consuming), (Idle,Consuming)}. Graphically we just listed the two original location names in the location. Example 3.6 Consider the automata queue1 and customer from Example 3.2. The synchronous product of these automata results in the following automaton. queue1.count < 2 queue1.count queue2.count q1enter queue1.count := queue1.count + 1 queue1.count > 0 q1leave queue1.count := queue1.count 1 queue1.count = 0 queue2.count queue1.count q2enter queue2.count := queue2.count + 1 Exercise 3.22 Consider the following automaton, named Sem. get 1 2 put Compute the synchronous product of automaton Sem with itself, i.e., Sem Sem. Based on the result of the previous exercise you may be tempted to believe that for any automaton M we have that the synchronous product of M with itself is very similar to M itself. The next exercise challenges you to prove that this is not the case. Exercise 3.23 Provide an automaton M for which the marked languages of M and M M are different. Exercise 3.24 The first buffer has capacity C 1 and the second buffer has capacity C 2. Items arrive in the first buffer using the event in1 and leave this buffer via event out1in2. Similarly, items arrive in the second buffer using the event out1in2 and leave this buffer via event out2. Provide automata models for two buffers. Conmpute the synchronous product of the two buffers. Exercise 3.25 Compute the synchronous product of the automata used for the ATM and the bank from Exercise In Chapter 2 the meaning of an automaton was presented in terms of the (marked) language accepted by that automaton. The meaning of a network of automata is also defined to be a set of strings. The (marked) language of a network of automata is the (marked) language of the automaton that results from computing the synchronous product of all involved open automata. Sometimes, we simply call the automaton that results from the computation of this synchronous product the semantics of the network. Example 3.7 Consider the network of automata from Example 3.2. The synchronous product of these

13 3.5 Tool support for networks of automata in CIF 49 three automata results in the following automaton. Note how the guards of the shared event q1enter from the two automata are combined. queue1.count < 2 queue1.count queue2.count q1enter queue1.count := queue1.count + 1 queue1.count > 0 q1leave queue1.count := queue1.count 1 queue1.count = 0 queue2.count = 0 queue2.count < 2 queue2.count queue1.count q2enter queue2.count := queue2.count + 1 queue2.count > 0 q2leave queue2.count := queue2.count 1 Exercise 3.26 Compute the synchronous product of the machine and buffer automata from Exercise Exercise 3.27 Consider the four automata from your answer of Exercise 3.3. Compute the synchronous product of these automata. Establish if the system has deadlock. Can you provide an additional automaton (that only uses the events for claiming the resources) that, when composed with the computed synchronous product, prevents all deadlock situations and still allows the users to make use of the resources. Exercise 3.28 Provide a single automaton model for the supermarket from Example Tool support for networks of automata in CIF A network of automata is just modelled in CIF by putting all the involved automata in a single CIF model. Example 3.8 The CIF model representing the network of automata for the supermarket checkout from Example 3.2 is as follows: 1 event q1enter, q1leave, q2enter, q2leave; 2 3 automaton queue1: 4 disc int count = 0; 5 location l0: 6 initial; 7 edge q1enter when count < 2 do count := count + 1; 8 edge q1leave when count > 0 do count := count - 1; 9 end automaton queue2: 12 disc int count = 0; 13 location l0: 14 initial; 15 edge q2enter when count < 2 do count := count + 1; 16 edge q2leave when count > 0 do count := count - 1; 17 end automaton customer: 20 location l0:

14 50 Chapter 3. Networks of automata 21 initial; 22 edge q1enter when queue1.count <= queue2.count; 23 edge q2enter when queue2.count <= queue1.count; 24 end For computing the synchronous product of automata without variables CIF has the option Apply synchronous product... (again the keyword event may not be used and should be replaced by controllable or uncontrollable). The CIF tool set has two functions for replacing a network of automata with a single automaton. Neither of these computes the synchronous product as defined in this chapter. Exercise 3.29 Use CIF to simulate the model from Exercise 3.4 in order to establish if you have succeeded in removing the deadlock situation(s). Exercise 3.30 Pump-valve-controller system, adapted from [CL99, Example 2.25]. Consider a heating system consisting of a pump, a valve, and a controller as modelled in Exercise 3.5. Simulate your model to gain confidence in your solution. 3.6 Additional modelling exercises Exercise 3.31 Tic tac toe. Team up with one of your fellow students for this exercise in which you will need to provide a model for the game of tic tac toe. 1. First develop a model in which each possible placement of cross and circle is present. 2. Divide the roles of cross-player and circle-player. Develop an automaton for the player that is assigned to you. 3. Combine the automaton or automata representing the board with the player automata and play the game. 4. Provide a separate automaton that controls the turns, i.e., that guarantees that players take their turns in a fair way. 5. Provide an (observer) automaton that terminates the game when one of the players has won, or in case no more turns are possible. Exercise puzzle. Imagine a 15-puzzle. Provide a model of the 15-puzzle in CIF. It should be possible to simulate all legal moves. The game ends as soon as the final configuration is reached. Simulate the game!

15 3.6 Additional modelling exercises Control of a reconfigurable machine tool In this subsection, inspired by [Sch15], we discuss the modelling approach presented in this chapter on a somewhat larger example of a reconfigurable machine tool. Reconfigurable manufacturing systems are designed to allow rapid adjustment of production capacity and functionality in response to new or changed circumstances, by adapting the functionality of their machine devices, by reconfiguring the arrangement of their machines, and even by modifying the building structure of the manufacturing system. We consider the model-based development of a controller for a reconfigurable machine tool. The reconfigurable machine tool (RMT) that we consider can perform three different operations: drilling, milling, and polishing. The tool consists of six components: a conveyor, a machine stand, a machine head, a drill, a mill, and a polishing tool. Products can enter and leave the RMT from the conveyor. The machine head of the RMT can move to three different positions for drilling, milling, and polishing (see Figure 3.8). The machine stand enables the vertical movement of the machine head to an upper and a lower position. Figure 3.8: Schematic of the example RMT with the configurations D (drilling), M (milling), and P (polishing) Exercise 3.33 Uncontrolled plant for RMT. Model the components of the RMT by automata. It is not necessary to model the movements exactly, it suffices to model the relevant positions of the components and the moves between these positions.

16 52 Chapter 3. Networks of automata The uncontrolled plant consists of these six components. Hence the model of the uncontrolled plant is the network of hybrid automata that consists of the models of the components. Is there any interaction between these models (so far)? Validate your model of the uncontrolled plant by simulating it and interpreting what happens. When modelling and simulating the uncontrolled plant, it should become clear that the uncontrolled plant may behave in several undesired ways. To prevent (some of) this undesired behaviour, we wish to control the behaviour of the plant to respect the following requirements: 1. the machine tools should only operate if the machine head is in the lower position, and 2. the machine stand is only allowed to move down if a product is present in the system. In the following exercises you are asked to develop a controller for these requirements. Exercise 3.34 Controller. Develop a model of a controller that forces the plant to behave in such a way that the aforementioned requirements are respected. Use simulation to validate if the controlled plant, i.e., the uncontrolled plant in combination with the controller, indeed satisfies the requirements. The requirements mentioned above do not disallow to operate the different machine tools if the machine head is not in the right position. Therefore, we add the following requirement: 3. the different machine tools should only operate if the machine head is turned to the correct position. Exercise 3.35 Adapt controller. Adapt your controller in such a way that the controlled system satisfies all three requirements. Use simulation to validate if the controlled plant satisfies the requirements. Exercise 3.36 Cancel a requirement. Adapt your controller in such a way that the controlled system satisfies only the first and the third requirement. Use simulation to validate if the controlled plant satisfies the requirements. In adapting the controller as asked for in the previous two exercises you may have experienced that it is not always immediately clear which constructions in your controller are present for which reason. Exercise 3.37 Split your controller in one controller for each requirement. Use simulation to validate if the controlled plant satisfies the requirements.

17 Bibliography [Bae+11] [Bee+14] [CW10] [CL99] [CL08] [FW06] [Flo+07] [For+12] J.C.M. Baeten et al. A Process-Theoretic Approach to Supervisory Control Theory. In: Proceedings of ACC. IEEE, 2011, pages (cited on page 86). D. A. van Beek et al. CIF 3: Model-Based Engineering of Supervisory Controllers. In: Tools and Algorithms for the Construction and Analysis of Systems - 20th International Conference, TACAS 2014, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2014, Grenoble, France, April 5-13, Proceedings. Edited by Erika Ábrahám and Klaus Havelund. Volume Lecture Notes in Computer Science. Springer, 2014, pages (cited on page 32). K. Cai and W.M. Wonham. Supervisor Localization: A Top-Down Approach to Distributed Control of Discrete-Event Systems. In: IEEE Transactions on Automatic Control 55.3 (2010), pages (cited on page 86). C. G. Cassandras and S. Lafortune. Introduction to Discrete Event Systems. International Series on Discrete Event Dynamic Systems. Springer-Verlag, 1999 (cited on pages 15, 16, 39, 43, 44, 50). C.G. Cassandras and S. Lafortune. Introduction to Discrete Event Systems. Springer, 2008 (cited on page 9). L. Feng and W.M. Wonham. Computationally efficient supervisor design: abstraction and modularity. In: Proceedings of WODES. 2006, pages 3 8 (cited on page 86). H. Flordal et al. Compositional synthesis of maximally permissive supervisors using supervisor equivalence. In: Discrete Event Dynamic Systems 17.4 (2007), pages (cited on page 86). S.T.J. Forschelen et al. Application of supervisory control theory to theme park vehicles. In: Discrete Event Dynamic Systems 22.4 (2012), pages (cited on page 83).

18 54 Chapter 3. Networks of automata [Gla90] [Gla93] [HTL08] [LLW05] [LA14] [MW06] [MF08] [Mar+10] [MMF13] [Oue+11] [Pnu77] [QC00] [RW87a] [RW87b] Rob J. van Glabbeek. The Linear Time-Branching Time Spectrum (Extended Abstract). In: CONCUR 90, Theories of Concurrency: Unification and Extension, Amsterdam, The Netherlands, August 27-30, 1990, Proceedings. 1990, pages DOI: /BFb URL: (cited on page 29). Rob J. van Glabbeek. The Linear Time - Branching Time Spectrum II. In: CONCUR 93, 4th International Conference on Concurrency Theory, Hildesheim, Germany, August 23-26, 1993, Proceedings. 1993, pages DOI: / _6. URL: (cited on page 29). R.C. Hill, D.M. Tilbury, and S. Lafortune. Modular supervisory control with equivalencebased conflict resolution. In: Proceedings of ACC. 2008, pages (cited on page 86). R.J. Leduc, M. Lawford, and W.M. Wonham. Hierarchical interface-based supervisory control-part II: parallel case. In: IEEE Transactions on Automatic Control 50.9 (2005), pages (cited on page 86). Hai Lin and Panos J. Antsaklis. Hybrid dynamical systems: An introduction to control and verification. Now Publishers Inc., 2014 (cited on page 13). C. Ma and W.M. Wonham. Nonblocking supervisory control of state tree structures. In: IEEE Transactions on Automatic Control 51.5 (2006), pages (cited on page 86). R. Malik and H. Flordal. Yet another approach to compositional synthesis of discrete event systems. In: Proceedings of WODES. 2008, pages (cited on page 86). J. Markovski et al. Coordination of resources using generalized state-based requirements. In: Proceedings of WODES. 2010, pages (cited on page 72). Sahar Mohajerani, Robi Malik, and Martin Fabian. Compositional nonblocking verification for extended finite-state automata using partial unfolding. In: 2013 IEEE International Conference on Automation Science and Engineering, CASE 2013, Madison, WI, USA, August 17-20, , pages DOI: /CoASE URL: (cited on page 44). Lucien Ouedraogo et al. Nonblocking and Safe Control of Discrete-Event Systems Modeled as Extended Finite Automata. In: IEEE Trans. Automation Science and Engineering 8.3 (2011), pages DOI: /TASE URL: (cited on pages 44, 66). Amir Pnueli. The temporal logic of programs. In: Proceedings of the 18th IEEE Symposium on the Foundations of Computer Science (FOCS-77). Providence, Rhode Island: IEEE Computer Society Press, 1977, pages (cited on page 109). M.H. de Queiroz and J.E.R. Cury. Modular supervisory control of composed systems. In: Proceedings of ACC. 2000, pages (cited on page 86). P.J. Ramadge and W.M. Wonham. Supervisory control of a class of discrete event processes. In: SIAM Journal on Control and Optimization 25.1 (1987), pages (cited on page 57). P.J. Ramadge and W.M. Wonham. Supervisory control of a class of discrete event processes. In: SIAM J. Control and Optimization 25.1 (1987), pages (cited on page 86).

19 3.6 Additional modelling exercises 55 [Ric08] [Sch15] [Sha01] [SSR09] [SSR10] [SSR12] [ST06] [Swa17] [WW96] [Won10] Elaine Rich. Automata, Computability, and Complexity: Theory and Applications. Pearson Prentice Hall, 2008 (cited on pages 22, 23, 32). K. W. Schmidt. Computation of supervisors for reconfigurable machine tools. In: Discrete Event Dynamic Systems 25 (2015), pages (cited on page 51). A.C. Shaw. Real-Time Systems and Software. John Wiley & Sons, Inc., 2001 (cited on page 71). R. Su, J. van Schuppen, and J. Rooda. Synthesize nonblocking distributed supervisors with coordinators. In: Proceedings of the 17th Mediterranean Conference on Control and Automation. 2009, pages (cited on page 86). R. Su, J.H. van Schuppen, and J.E. Rooda. Aggregative synthesis of distributed supervisors based on automaton abstraction. In: IEEE Transactions on Automatic Control 55.7 (2010), pages (cited on page 86). R. Su, J.H. van Schuppen, and J.E. Rooda. The Synthesis of Time Optimal Supervisors by Using Heaps-of-Pieces. In: IEEE Transactions on Automatic Control 57.1 (2012), pages (cited on page 86). R. Su and J.G. Thistle. A distributed supervisor synthesis approach based on weak bisimulation. In: Proceedings of WODES. 2006, pages (cited on page 86). Lennart Swartjes. PhD thesis. Eindhoven, The Netherlands: Department of Mechanical Engineering, Eindhoven University of Technology, 2017 (cited on page 37). K.C. Wong and W.M. Wonham. Hierarchical control of discrete-event systems. In: Discrete Event Dynamic Systems: Theory and Applications 6.3 (1996), pages (cited on page 86). W.M. Wonham. Supervisory control of discrete-event systems. Technical report. University of Toronto, 2010 (cited on page 60).