Modeling

When modeling a given process it is of great benefit to use Petri nets, though care must be taken so that the nets are bounded. Petri nets tend to give a more compact description of the process, where the individual process components are easily identified. In fact, the physical modularization of the process in identifiable components can be used to modularize the process model, the plant, both to fight the state-space explosion and to give a more comprehensible and naturally structured model.

Modularization and Synchronization

Exploiting the physical structure of the process requires identification of the involved components and building sub-modules of those. For instance, a manufacturing cell may consist of a number of machining resources together with transporting devices. Each of these can be modeled by its own Petri net, and a model of the entire plant can then be composed from these. This can simplify the modeling effort significantly. In many cases, generic (Petri net) models can be used to compose the plant, see Adlemo (1998). Then, the models of the individual resources can be instantiated from a library of already tested models. Instantiation requires defining the transition labels according to some well-defined structure, so that the composed model will behave as expected. Even this can in many cases be automated. The well-defined structure governing the transition labeling comes then from the specification. That is, the specification determines which resources will interact and how. Usually, this requires composition operations a little more elaborate than the synchronous composition we have defined (see Arnold (1994)), but in some cases, synchronizing is exactly what we want.

Modular Modeling

A manufacturing cell consists of two machines M1 and M2 plus a robot R, see the outline above. Work-pieces arrive to the cell on an input-conveyor C1 and exit the cell on the output-conveyor C2. In-between the two machines there is a buffer B with the capacity to hold four work-pieces. The robot can transport the work-pieces between any of the other recourses in the cell.

A Petri net describing the cell is conveniently built from Petri nets describing each resource. Naturally, several equally “correct” models can be proposed for this cell. In this case we can disregard the input and output conveyors, since they (apparently) have of unlimited capacity. This is typical. An input-conveyor gets its work-pieces from some outer “agent” which can be regarded as always able to “produce” a work-piece. Likewise, an output-conveyor is emptied by some outside entity and can thus be regarded as an infinite resource. However, there still has to be events present modeling the getting from and putting to the conveyors. These are the c1 and c2 events of the robot, respectively.

The robot, the machines and the buffer need to be modeled explicitly, though. Each can be described by its own net as shown below. Here, care has been taken so that the transition labels match up consistently. As we can see, the robot acts as the “spider of the web”. The machining resources and the buffer are connected through the transitions of the robot. Therobot can get work-pieces from either resource, including the input-conveyor, and it can load either resource with work-pieces. Note that no predefined order of work-piece transportation is included in the model. That we regard as specification.

 

The synchronous composition, though much to large to depict here, is a model for the entire cell.

Assumptions about the Plant

Since we model the process, we have a great degree of freedom in choosing the model. This, even considering that for the most part the plant has to be related to the specification. Even so, some design patterns are very unreasonable, which allows us to make the following assumptions about the plant[1].

1.    It is non-marking.

2.    It is non-forbidden.

3.    It is trim.

4.    Its alphabet contains only executable events.

The plant can always be assumed non-marked. Marking specifies significant tasks or sub-tasks, and what is significant is highly dependent on what we aim to use the model for, that is, the specification. Thus, we regard marking solely as a specification issue. For a given plant, it seems unreasonable to require certain tasks to be significant. For instance, frequently the Idle state of a machining resource is a marked plant-state. This is taken to signify that a processing cycle is a significant sub-task. However, this also means that any processing cycle is equally significant. This means that there would be no way to express the significance of executing a certain number of processing cycles (unless the specification is allowed to remove plant-markings, which it is not in the “standard” theory of control of DESs). Specifying the processing of ten products, say, would still allow the closed-loop system to halt after three.

Of course, allowing the plant to include forbidden states adds no amount of generality. We choose the model, and adding states that are immediately marked as forbidden does not seem to be significant enough to validate the extra complexity. Simply not specifying those states is a much simpler way to “forbid” them.

If we agree that marking is specification, assuming the plant to be trim is simply another way of saying that it is accessible. Again, there seems to be no additional generality in allowing the specification of non-reachable states. There is also no loss of generality.

Though it could be argued that allowing non-executable events in the plant alphabet is useful, we will not do this. The usefulness arises when a plant is composed (by synchronization) from several sub-plants. Then, non-executable events in one sub-plant alphabet will prohibit the event from occurring in any sub-plant module. This could perhaps be valuable in some applications, however, we will find no use for it. The benefit of assumption 4 is that we do not have to specify the alphabet explicitly for a plant. Its transition function defines the alphabet (as well as the state-space, according to assumption 3). Note though, that this is not necessarily the case for a specification. A specification can, and often will, include non-executable events in its alphabet. The intent is that the event should never be executed in the closed-loop system.

Examples

A description of a process may be given in textual as well as graphical form, as for instance, in the following. For real systems, the description is much more substantial, sometimes comprising entire shelves of design documents. Needless to say, extracting a useful model from such an immense amount of information is not easy. However, breaking the problem down into smaller sub-problems can alleviate the problem. Using formal descriptions to begin with during the design process would further simplify things.

The Tank Process

We have a process consisting of a liquid tank with a heater, an input flow and an output flow with valves, and sensors for low and high liquid levels and high temperature, see Figure 3. The tank can be filled from the input by opening the input-valve and it can be drained by opening the output-valve. Opening both valves simultaneously will result in undefined behavior; that is, we cannot say whether this will result in a filling or draining. This depends on the dynamics of the tank, of which we purposely have very limited knowledge (none, in fact). Opening only the input-valve, though, will result in an increase of the liquid level. This increase is observed by the low-level sensor emitting an event, followed eventually by an event from the high-level sensor. Similarly, when draining a filled tank, the high-level sensor will emit an event eventually followed by an event from the low-level sensor.

The heater can be turned on and off and when the heater is turned on the temperature sensor will eventually signal that a certain set point has been reached. If the heater is turned on with no liquid in the tank we, again, have no idea (and do not care!) what will happen. Probably, the heater will burn up, but since there seems to be no way for us to observe that, we avoid modeling it.

Figure 3. Simple tank process to model.

What significant modules and events can be deduced from this simple description?

First, there are three sensors, A, B, T, representing the high-level, low-level and temperature sensors, respectively. Second, there are the input and output valves and the heater, V1, V2, and E, respectively. Obviously, the heater E and the temperature sensor T interact to form a “heating module” of the process. This module is independent of the “flow module” formed by the other devices. We can turn the heater on and off and measure the temperature irrespective of whether the tank is filled or drained (though the result may not be what we want). In the same way the flow module is independent of the heating module; filling and draining can take place whether the heat is on or not. Note that the specification will tie these independent modules together.

The temperature sensor can be in one of two states; either high when the temperature is above the set-point or low when the temperature is below. The switching between these will be associated with the events t0 and t1. Thus, T can be described by the automaton (drawn as a Petri net) to the left in Figure 4. Likewise, the heater can be either on or off and transiting between these states on the E0 and E1 events. However, there exists an interaction between the heater and the temperature sensor; the temperature can only rise, and hence the sensor transit from low to high, if the heater is on. This interaction can be modeled by synchronizing the models of the respective components. This requires that the heater includes the “generation” of the transition events of T, though. This can be done as in the heater model E of Figure 4. Synchronizing E and T results in a Petri net that describes the “heater module” , see Figure 6.

Note that we have assumed that we can distinguish between the events associated with the transition from low to high and high to low, respectively. Since the system description seems to imply that the sensors really emit signals, this seems reasonable. The events are then merely the rising and falling flanks of the temperature signal. However, this is not always necessarily so. Modern “intelligent sensors” can send messages over a network instead of raising and lowering signals. This would make the event based model more appropriate, but it also introduces a hazard of message corruption. When the message arrives, we may not be able to tell whether it was a transition from low to high, or high to low. We could actually ignore that distinction, merely assume that there was a t event signifying either transition, and thus making the model and hence controller more robust. In this case, though, it does not seem to be very useful. On the other hand, for the “flow module” it will be very useful.

Figure 4. The components of the "heater module" of the tank process.

The “flow module” consists of the two level sensors, A and B, and the input and output valves, V1 and V2, respectively. The level sensors could be modeled similarly (isomorphically, in fact) to the temperature sensor T. However, there is one observation that hinders us from (easily) doing this. The level sensors have a “sequential” relationship that is not easily modeled by composing two Petri nets[2]. For the high level sensor A the transition from low to high cannot occur before the low level has transited from its low to its high state. This would be physically impossible. Thus, instead of giving a model for each level sensor, we give a Tank model describing the way the liquid level rises in the tank. This is shown in Figure 5, left. Note that the high state of the B sensor is overlaid on the low state of the A sensor. One way to interpret this model is that two quota of liquid can be contained in the tank. The exact size of those quota cannot be determined from the model and are of no interest. In fact, absence of this information allows the model to be used for processes with different levels.

Figure 5. e components of the "flow module" of the tank process.

Another design choice can be pointed out. The events of the Tank module do not explicitly distinguish between whether they come from the high-level sensor or the low-level sensor. The events merely model the fact that one quota of liquid has entered or exited the tank. Naturally, we could name each event uniquely, say like inA, inB, outA and outB, but this would require us to have two transition is each valve model, one for A and one for B.  Just as in the “heater module”, the transitions in the Tank model cannot occur unless the respective valve is open. Remember that one of our main objectives is to keep the model simple. We want to capture as little detail as possible, while still capturing as much detail as necessary. This cannot be over-emphasized. Thus, if we can do without distinguishing between exactly which sensor event occurred, we should do so. To what degree this can be done is determined by the specification. The more meticulous the specification, the more detailed the model has to be. In this case though, it would seem to be detailed enough to model as in Figure 5. The “flow module” of the tank process is now the synchronous composition of the components of Figure 5.

The model of the tank process, the plant, is summarized in Table 2 and Figure 6, where the significant events are listed and the two modules are shown as results of synchronizing the respective components. Though we try to refrain from introducing causalities in or models, it is (in this case) natural to view some events, the sensor events, as being generated by the process and the other events as being generated by the controller. Thus, we can regard the sensor events as input, or responses, from the process to the controller, while the other events are outputs, commands, from the controller to the process. The significance of this will be discussed in Chapter 3.

Responses (input) Events Commands (output) Events
A: high level; above, below in, out E: heater; off, on E0, E1
B: low level; above, below in, out V1: input valve; close, open V10, V11
T: temperature; low, high t0, t1 V2: output valve; close, open V20, V21

Figure 6.Significant events of the tank process.

A number of points deserve to be pointed out and motivated. For one thing, the plant is incapable of overflowing. After two in events, if the input valve V1 is kept open, nothing else will happen in the plant. This is, obviously, not a true view of the real process. However, since there is no way to detect that the tank has actually overflowed, this was not included in the model. Furthermore, whether we want the tank to overflow or not, can be regarded as a specification issue. It is easy for the specification to introduce a third consecutive in event that leads to a forbidden state. This would require a controller to close the input-valve when the tank is full. In the same way, and for the same reasons, we do not model what happens if the heater is turned on with no liquid in the tank. Probably the heater will burn up, surely an undesired incident. Nor does the plant model any requirement to avoid this; we do not require the tank to be filled to some level before turning the heater on. Both of these aspects, we regard as specification, and our plant should be as ignorant of the specification as possible. The plant models what can happen, the specification expresses what we want (and do not want) to happen.

As with any Petri net, the plant includes an initial marking. This initial state carries a number of implications. We assume, for instance, that the temperature of the surrounding environment and the incoming liquid is lower than the set-point of the sensor. This is a natural assumption, since otherwise the heater would hardly be necessary. However, if this is not the case, the model must be changed and it might be worthwhile to consider how. This is left as an exercise for the reader. Similarly, the tank is assumed initially empty, or at least with a liquid level below the point marked by the low-level sensor. Again, this may not be the case, and then the model would have to be altered. Again, this is worthwhile contemplating. Note that, merely changing the initial marking is not necessarily enough. It may well be that the structure of the plant needs to be changed to adequately model the “new” process in enough detail. For instance, if the incoming liquid is warmer than the temperature sensor set-point, then the t1 event can occur without the heater being turned on.

Finally, do not fail to notice the exactness of the formal model compared to the “hazy” textual description.

Figure 6. The two modules of the tank process. Their synchronous composition is the plant.

The Two Users

Consider two users[3] of a single resource that cannot be used by both simultaneously. This might model, for instance, two students in a class-room “using” the single teacher in the sense that each asks a question and is answered. The two students cannot ask their questions simultaneously (although students sometimes do). During the lesson, the students sit calm until one of them wants to ask a question. When a student wants to pose a question he or she calls the teachers attention, usually by raising his or her hand, and waits to be granted access to the resource, that is, to be allowed to speak. Once having access to the resource the question is asked and the teacher answers. The answer may raise new questions, which it would be proper to immediately ask and have answered. This conversation continues until the student is satisfied, after which the resource is released, that is, the teacher continuous his teaching.

Of course, the student-teacher metaphor is just one pertaining to the mutual exclusion of a shared resource. This is a general problem in many systems with concurrently acting “agents”, such as computer networks, where printers are typical shared resources, and manufacturing systems, where work-pieces compete for machining resources.

Given the description above, we can identify three components, the two users, the students and the mutual resource, the teacher. Looking at the two users, we can observe that they behave identically. They sit idle until they request the resource. When they are granted access, they use the resource until they are satisfied. Then they release the resource and sit idle again until the next time they require the resource. Thus, the users can be modeled by identical Petri nets, consisting of three places (equal to states, in this particular case). This net is shown in Figure 7. In a system with two users we can instantiate two user models and compose them into a single plant. By “instantiation” we mean renaming the labels according to some logical pattern, normally we just index the events with the same index we give a particular user. That is, for User1 we have the events a1, b1 and c1.

The a event represents the request action; for a student this means the raising of the hand. The c event corresponds to the finish of the interaction with the resource. This action is not so well-defined in the student case, but for computers, there is typically some ready message exchanged. The b event represents the granting (by some controller) of access to the resource. Note that, in many cases, such as in the student case, the resource acts as the controller, as well. The teacher grants access to himself by letting one of students with raised arm speak.

Figure 7. User model.

Typically, both the a and c events are initiated by the user and are not under the “jurisdiction” of any controller. The teacher, for instance, cannot prevent nor force a student to raise his or her arm. Nor would a (polite) teacher cut off the communication once a student had gotten permission to ask a question. However, the access can be controlled by a controller. Only when the resource is free would the controller allow the b event to occur. Note that from this point of view the controller can merely inhibit some events from occurring, not actually force them to occur. This is different from the command-response view of the previous example, and will be discussed in Chapter 4.

The third component of this process is the resource itself. As already mentioned, in some cases the resource acts as the controller itself. In other cases, a separate controller grants access to the resource. In any case, the resource itself can be seen as a passive component of the system and so, need not be modeled.

Thus, the plant will be the synchronous composition of two instantiations of the user of Figure 7. This will be a bounded Petri net, since the user-nets are bounded, and its automata representation is shown in Figure 8. Note that this model includes a state UU where both users access the resource simultaneously. In the uncontrolled process, this can always happen, though the result may not be what is expected. The requirement that both users should not access the resource simultaneously is a specification for what we do not want to happen in the system. The controller is to guarantee this.

Figure 8. The synchronous composition of two users.

Note that if we had a classroom full of students and with a single teacher, we could easily derive a model for that classroom by instantiating and synchronizing as many users as there are students. Obviously, this model would be very large and complicated, but a valid model nonetheless.



[1] Some of these may be regarded as unconventional. In the “standard” theory of control of DESs, see Ramadge (1987), the plant P is assumed to define all the markings and forbidden states are not covered (though see also Lin (1988)).

[2] Easily, that is, with the composition we have defined for Petri nets, the synchronous composition. The sequential composition of Peterson (1981), would allow us to do this straightforwardly.

[3] This example is adapted from Ramadge (1987).