A state is usually defined as a memory encompassing all information necessary to predict the future behavior given that the future input can be observed. Memory-latches can be implemented by (at least) three ladder-diagram structures. These are shown in Figure 34. Whether to use set- or reset-dominant latches is mainly a matter of taste, but basically the reset-dominant versions seem to be “safest”. When S and R are both true we probably do not want to set the output. Note that in the case of set/reset-latches this means that the reset-latch should come after the corresponding set-latch; the sequential execution then guarantees that the output is reset when both S and R are active.
Figure 34. Variants of memory latches.
The a) and b) variants of Figure 34 are basically equivalent, while the c) construct is not entirely equivalent to the other variants. For instance, depending on the order of the rungs, a set- or reset-dominant structure will arise. Also, several set/reset-latch rungs can have the same output.
The straightforward way to implement a state machine in LD is to represent each state by a memory-latch and each event with an internal boolean variable, and let the transitions be represented by a boolean AND between the state variable and the event variable, see Figure 35. See also Brandin (1996). When the transition occurs, the next state is set and the previous state is reset. The latched coils are ideal for this. Note that this is generally the same way that SFCs are converted into LD.
Figure 35. A simple state machine (left) and its straightforward LD implementation (right).
The ladder-diagram must be such that the initial state is immediately set when the power is turned on. Again, there are several ways to implement this; there may exist certain memory-positions (i.e. memory bits) that are active (true) during the very first scan-cycle only. The most portable way, though, is to use the fact that a memory position is initialized to 0 (false) before execution begins. This can be used to initialize the initial state, as shown in Figure 36. Note that a non-retentive (that is, one that does not keep its value during power-offs) memory-position has to be used for FalseAtStart, otherwise there’s no guarantee that it actually is false at start.
Figure 36. Initializing the initial state.
As the state-machine executes the ladder-diagram should evolve so that the new state is set when the event occurs, and simultaneously the previous state should be reset. The easiest way to code this is with the set/reset-latches, since this only requires regarding the current state, the event and the next state in each rung. Self-hold, and SR function blocks requires, in addition, the previous state, as is shown in Figure 37. Note that the two rungs of Figure 37 are not equivalent. The a) rung will actually have both the Previous and the Current states active during one scan-cycle. Though a scan-cycle is often very short compared to the time-constants of the process, it may cause problems. However, this is unavoidable unless set/reset-latches are used. In the b) rung the Previous state being active together with the Event occurring both activates the Current state and deactivates the Previous state simultaneously. Thus, the Previous and Current states will never be active at the same time.
Figure 37. Two ways to implement a state-transition from the Previous state on the Event to the Current state.
These are the basic steps involved in coding a state-machine as a ladder-diagram. Note that as given above an event is not an event in the normal sense, but rather a boolean valued signal. The event would represent the rising (or falling) edge of that signal. There is usually some edge-detection mechanism available in the ladder-language of the specific PLC.
When the state-machine is a Sequential Function Chart (SFC, GRAFCET) rather than a “normal” state-machine, the following constructs may occur. Some of these pertain also to ordinary state-machines.
Figure 38. Alternative. If both transition-conditions (events) are true at the same time, the left path will be taken. This is governed by the order of the rungs in the ladder-diagram.
Figure 39. Initial state and loop. Note that the initial state is both activated at power-on via FalseAtStart, and by S2 and e1.
An SFC may contain sub-sequences running in parallel. Such sub-sequences are activated through a single transition-condition, and normally execute until they synchronize again. Synchronization is effected by the sequences waiting for each other and then executing a mutual event (usually the trivial always-true transition-condition). This could (perhaps) be generalized to implement synchronous composition of state-machines.
Figure 40. Parallel (sub-)sequences. When S1 is active and e1 is true, both S10 and S20 are activated and S1 is deactivated. When S100 and S200 are both active, and only then, and when e2 is true both the active places (states) are reset and s2 is activated.
Normally, the places of an SFC include actions that are performed when the corresponding place is active, and only then. These actions can be qualified to be Set or Reset, Delayed by a certain time or Limited to a specified time. Unqualified actions (qualified by the qualifier N for none) are executed/performed “continuously” (actually, cyclically, once each scan-cycle) as long as the place/state is active. Actions can be implemented in ladder-diagrams as follows.
Figure 41. Actions. TON is a timer function-block that counts down a specified amount of time as long as its input is true, and sets its output true when it has reached zero. The timer-output goes false again when the timer-input goes false. If the input goes false before the time-out, the output remains false.
Automata evolve on the occurrence of events, whereas a PLC handles boolean valued signals. Signals always exist but with different values, whereas events only exist momentarily. Intuitively the events could be associated with the rising and falling edges of the signals. Rising edges are detected by comparing the signal between two consecutive scan cycles; if the signal was low the previous scan cycle and is now high, then a rising edge has been detected.
However, when associating events with rising and falling edges of signals, care must be taken not to introduce the avalanche effect into the implementation. This effect makes the program skip over an arbitrary number of states during the same scan cycle. The avalanche effect is a consequence of the sequential evaluation of the boolean expressions within the PLC.
Figure 42 illustrates the avalanche effect. The state machine transits on the a event from state q0 to q1, where it is supposed to transit on the occurrence of a new a event to q2 or, if a b occurs before another a, to q3. The LD implementation to the right in Figure 42, does not exhibit this behavior. Instead, the avalanche effect introduces a direct transition from q0 to q2 on the same rising edge of the a signal. Thus, even if the b event (the rising edge of the b signal) occurred, it would have no effect on the evolution of the LD.
Clearly, this is unsatisfactory.
Figure 42. The state machine (left) represents two strings aa and ab, whereas the LD implementation (right) represents only the occurrence of a single a.
Note that the avalanche effect could in this case not be remedied by exchanging the positions of the rungs 2 and 3 of Figure 42. The problem would persist, as it is a consequence of not requiring that the a signal performs a falling edge before the transition from the states q1 to q2. A point that also indicates a solution.
To guarantee that a falling edge occurred between the two top rungs of Error! Reference source not found., right, we would have to introduce an intermediate state q’ from which we would transit to q1 on the falling edge of a. Note that a transition on b to q3 must be possible both from q1 and q’, otherwise the rising edge of b may be missed.
One way to guarantee that a falling edge occurs before the transition from q1 to q2 takes place, is to arrange the rungs in reverse order. Exchanging the order of rungs 1 and 2 of Figure 42 will guarantee that the avalanche is avoided. Assume that q0 is set and a positive edge is detected on a. When rung 2 is scanned before rung 1, then q2 is not set since q1 is false. On the other hand, when rung 1 is scanned (after rung 2) q0 is set so that q1 will be set and q0 reset. This effectuates the transition from q0 to q1. During the next scan cycle, q1 is set but now there is no positive edge on a, so that the transition from q1 to q2 cannot occur. Not until a negative edge has been detected on a can a positive edge be seen again, which means that at least two scan cycles must pass before the transition to q2 can occur.
Note that, placing rung 3 of Figure 42 before rungs 2 and 1 in the execution order will cause no harm. On the contrary, it would guarantee that the supervisor occupied each state at least during one scan cycle. This is important if the event generation is placed last in the execution order, as mentioned below. Consequently, the PLC implementation of state machines benefit from sorting the rungs in reverse order, whenever this is well defined. In other cases, the loops have to be broken at “intelligent” places. What this actually means is still an open question. Of course, the sorting order greatly influences the execution times.
Another problem when moving from an event-based into signal-based world is simultaneity. Events are typically assumed not to occur simultaneously with other events. Signals, on the other hand can perfectly well overlap in time. Associating events with signal edges would allow us to still assume the non-overlapping of events, provided we could guarantee the detection of the rising edge when it occurred. This is, however, not possible due to the cyclic execution of the PLC.
Regard for instance the state machine of Figure 43, which attempts to distinguish between the interleaving of the a1 and a2 events; if a1 occurs before a2 a b1 is required, and if a2 occurs before a1 a b2 is required. A problem arises if the rising edges of the a1 and a2 signals occur between the same scan cycles. Then, the PLC will detect two simultaneous rising edges, two simultaneously occurring events.
Figure 43. A state machine (left) that attempts to distinguish between the interleaving of the a1 and a2 events. If the signals rising edges occurred between two scan cycles (right), the PLC program would have no knowledge whatsoever about which event occurred before the other. In the right figure RI stands for “read input”, EP stands for “execute program”.
This problem cannot be remedied at all by clever programming, as it is a consequence of the synchronous nature of the PLC execution, whereas the state machine implies an asynchronous execution. To remove the problem the supervisor, would have to be such that the control decision does not depend on different interleavings of the same events. This is captured by the following definition.
Definition 1. Interleave insensitivity.
A supervisor S is interleave insensitive
with respect to a plant P and a sub-alphabet if for
and
. (1)
This definition captures the requirement
that after any interleaving of the traces s1and s2
the “control decision” (whatever that is, see below) is the same. We can note
that equation (1) trivially holds when either of the traces (or both) is the
empty trace. Note also that the converse is obvious, since .
Typically, represents events generated
by the supervisor (see Chapter 4) and
represents the events generated
by the plant. Then, interleave insensitivity may have benefits with regard to
the size of the supervisor. Since all interleavings of two strings of plant-generated
events are required to result in the same control decision (same supervisor-generated
events), only one of those interleavings need to be present in the supervisor.
This may greatly reduce the number of supervisor states.
In general, the specification (and hence the supervisor) is not interleave insensitive, though. For instance, it would make perfect sense to require certain work-parts in a flexible production system not to be allowed to visit certain resources before other work-parts; in milk processing, for instance, we can allow fresh milk ahead of sour milk, but not the other way around.
The SCT originally regarded the plant as generating all events, with the supervisor a passive device merely observing the event generation and disabling certain events in certain states. Balemi (1992) observed the fact that for most real systems the plant events are not generated spontaneously, but only as responses to given commands. This led Balemi (1992) to take an input/output perspective on control of discrete event systems. In this interpretation the supervisor (now called a controller) generates some events, the commands, and the plant generates other events, the responses. Balemi (1992) further took the standpoint that the commands were the controllable events, while the responses were the uncontrollable events. Then, just as the supervisor cannot prevent the generation of the responses, the plant cannot prevent the generation of the commands. Thus, the supervisor must be such that it never generates any command that the plant cannot follow. This is the dual to controllability, and Balemi (1992) defines the notion of a well-posed connection between the supervisor and the controller.
We can also note that by disabling events the supervisor requires the plant to generate one among the enabled ones. Since the supervisor must always be controllable, it ill only disable controllable events and let uncontrollable events be freely generated. In this sense, a supervisor will only require controllable events. However, when the supervisor is a PLC, the notion of “disabling” events that the SCT assumes does not exist. The only way for the PLC to “require” a specific event is to generate it itself. Thus, all events that are “required” must be regarded as controllable events. This again is a motivation for the input/output perspective of Balemi (1992).
When controlled by a PLC, the plant and the controlling PLC interact through boolean valued signals. These signals have to be actively set and reset, and this is done either by the controller or by the plant. Thus, the input/output perspective seems a natural approach. At first glance, it would seem to definitely answer the question of causality; “who generates what”? However, the behavior of the controller may change radically with different implementational decisions.
Assume for instance that we have the supervisor shown in Figure 44.
In Figure 44 the supervisor (to the left) generates b after a1, either before or after a2. The PLC implementation, though, always generates b directly after a1, when the transition to q1 has been effectuated. This, it does regardless of whether a2 has occurred or not. Therefore, rung 1 is unnecessary, and removing all such unnecessary rungs may significantly reduce the size of the implemented supervisor. Note though, that the generation of b in q1 invalidates the reception of a2, which may lead to another problem, described below.
Figure 44. A supervisor (left) and its PLC implementation (right). The b event is controllable, depicted by the small “handle”.
Balemi (1992)
equates the controllable events with the commands generated by the supervisor,
, and the uncontrollable
events with the responses,
. However, some uncontrollable
events do not have intuitive “response” interpretations. Uncontrollable events
are, in general, simply a matter of saying “do your control, but don’t touch
these”. Then, since events have
to be generated somewhere, uncontrollable events may have to be generated by
the PLC.
In the following we will therefore denote by the events generated
by the supervisor and by
the events generated by
the plant. Note that the observation above means that it is not necessarily
so that
and
.
Hmmm... vad är det egentligen för skillnad på bilden ovan och bilderna nedan? Kausalitet – någon måste generera, Val – den som genererar måste välja, Ej exakt synkronisering – medan den som ska generera väljer kan något hända som gör valet ogiltigt.
Hur exemplifierar vi detta på ett entydiga sätt? Nu tycks det som om dessa tre är samma sak?!
Note that, if the order of rungs 2 and 3 in Error! Reference source not found. is exchanged so that rung 3 is evaluated before rung 2, then the PLC will still always generate the b event after it has seen a1 regardless of whether a2 has occurred or not. But, if a2 has occurred “simultaneously” with a1. This as to do with the problem of exact synchronization, discussed in Section 0.
The supervisor generated by the SCT is generally required to be minimally restrictive; that is, it allows the plant the greatest possible freedom while still upholding the specification. Of course, this means that there may occur alternatives in the supervisor, alternatives that the plant is assumed to resolve by generating one of the events. However, when the controller generates some events only one of the possible events must be generated. Generating several may be contradictory and catastrophic.
In Figure 45 is shown a supervisor with two alternative implementations. This example is a small part of the supervisor presented by Brandin (1996) (Fig. 13, p. 8). Assume that q4 is active and that a positive edge on b2 is detected. Then the implementation of Figure 45 (middle) transits to q8 in rung 3. This sets q8 which, in rungs 4 and 5, sets (that is, generates) r2 and s1, both. This is certainly not the intended behavior. It may even be that generating one invalidates the generation of the other! (This is fortunately not the case in the example of Brandin (1996)). Furthermore, in the next scan cycle the implementation performs the transition to q1, thereby disabling q8. Thus, it behaves as if only the r2 event was generated. This behavior may even be more catastrophic, since the plant may have ignored the r2 event altogether when both r2 and s1 was set, and behaved as if only the s1 event had been generated. In that case, the supervisor and the plant are entirely out of synch and there is no longer any guarantees that the supervisor, as implemented, can control the system satisfactorily.
Figure 45. Example of supervisor (left) and (middle) an implementation that generates both events, but transits only on one of them, the first in execution order. To the right is an implementation that resolves this by choosing and transiting simultaneously. The generated events are r2 and s1, as depicted by the small “handles” on the transitions (left).
To resolve this problem the implementation must simultaneously choose and transit; and only a single event must be chosen. This can be done by implementing exactly as stated in the previous sentence, and as shown to the right in Figure 45. Now, after the transition to q8 has been made, the PLC in the next scan evaluates rung 1; sets q1, resets q8 and sets r2. This effectively performs the transition from q8 to q1 while generating r2. In rung 2 q8 is reset and no transition to q9 nor generation of s1 will take place. We have coded the event generation as a positive transition sensing coil, that generates a one scan cycle wide pulse as it senses q8’s rising edge.
Note that rung 2 in the right implementation of Figure 45 is in fact superfluous, it will never have any effect on the execution since, when it is executed q8 has already been reset. Thus, the choice is made at “compile-time”, when the implementation is hard-coded. It seems very difficult to implement in LD the “non-determinism” represented by the supervisor of Figure 45, left. In particular, if the implementor does not explicitly make the choice, the PLC itself will make the choice, determined by the ordering of the rungs.
The “best” choice is a complicated problem that is solved with scheduling principles, see for instance Liljenvall (1998), and is beyond the scope of this paper.
In some cases, there may be a “choice” as to whether generate an output event or follow an input event from the same state. Obviously, in those cases it is essential that the ordering of the rungs is such that the “uncontrollable” input event is followed. Otherwise, the state of the supervisor does not replicate the state of the plant; they become out of synch. Thus, the rung that transits on the input event must be executed before the rung that generates the output event. This works well when the input event is seen at the right time. However, this is not guaranteed, which may lead to the problem of inexact synchronization.
While the PLC executes the program, no observing of the plant takes place. The scan cycle is supposed to be short in relation to the time constants of the plant, but there is no guarantee that the two are in phase. A signal-change may occur in the plant while the program is executed. The problem here is that the changed signal may invalidate the choice made by the program. The supervisor can only have knowledge about the commands and responses issued so far.
Figure 46. A supervisor that may become out of synch with the plant if the a2 is generated while the user program is executed.
Consider the supervisor shown in Figure 46. Assume we start in q0 and a rising edge is detected on a1. Then, rungs 1 and 2 do nothing since q1 is not set. Rung 3 on the other hand resets q0 and sets q1. In the case that a rising edge is detected on a2 in the next scan cycle, rung 1 performs the transition to q2. Otherwise, b is generated in rung 2 with the transition to q3. However, while the PLC executes the program, the plant may generate a2, which invalidates the generation of b. That is, the plant cannot accept b after it has generated a2. Thus, in the case that the rising edge of a2 is detected in the scan cycle after the supervisor has generated b, the plant and the supervisor are out of synch.
This problem can be modeled as a communication delay, as was noted by Balemi (1992), who therefore introduced the notion of delay insensitive languages.
Definition 2. Delay insensitive language (Balemi (1992))
A language K is said to be delay insensitive
if, for
.
As above, denotes the events generated
by the supervisor while
are the events generated
by the plant.
The definition of delay insensitivity means that for the supervisor in the example above to be delay insensitive, it would have to be able to generate b in q2 as well as be able to accept a2 in q3.
Two things can be noted about the above definition. First, it captures delays in one direction only; from the plant to the supervisor. Balemi’s motivation for this is that we can always control the plant so that only a single command is generated between the responses. The supervisor generates the command, and then waits for the responses. With a PLC implementation, this is natural, since the delay is due to the cyclic execution of the PLC. In the direction from the PLC to the plant, there are typically no delays, since all communication is achieved through digital I/O.
The second thing to note is that the definition concerns only delays of length one. This is assumed by Balemi (1992) in order to simplify the problem. However, again this is inherent in the communication between plant and supervisor. The delay is due to something happening in the plant while the PLC is executing its program and not updating its inputs. The next scan cycle, though, starts with an update of the signals, and thus, the event is seen, assuming that the scan cycle time is short compared with the time constants of the plant.
Note though, that the definition of delay insensitivity does not capture the “simultaneous events” problem described above. Thus, interleave insensitivity is not a “sub-problem” of delay insensitivity, though at first glance this may seem so. The two problems are distinct; interleave insensitivity stems from the problem of not being able to distinguish between the order of two (or more) input events, whereas delay insensitivity resolves the problem of not observing while choosing. Interleave insensitivity concerns the order of two input events, while delay insensitivity concerns the order of an input and an output event. Obviously, these two definitions could be captured by a single definition.
When implementing supervisory control in a PLC-based control system, a number of problems may occur. We have described them and suggested implementational details to solve the problems.
First, there is the problem of moving from an asynchronous event-based state-machine world into the synchronous signal-based PLC-universe. There are, in fact, two main problems associated with this, avoiding the avalanche effect and handling the simultaneous event problem. The avalanche effect occurs when several states are directly stepped through on the same event, although the intent was to count the occurring events. This can be solved by sorting the ladder diagram rungs in an “intelligent” order. Exact details how to do this is still an open research matter.
The other main problem associated with signals and events, is the problem of simultaneous events. Due to the cyclic execution of the PLC, with a read inputs – execute program – write outputs, scan cycle, events in the plant can appear to occur simultaneously. Thus, if the supervisor is supposed to determine its control action on the order of those events, this will not be possible. The notion of an interleave insensitive supervisor captures the requirement that the control decision is not dependent on the order of “simultaneously” occurrable events. Again, deeper investigation is necessary.
Apart from these problems, three related problems have been discussed.
Causality – someone must generate the events that are not naturally generated by the plant, and that someone can only be the PLC. Thus, the PLC implementation must include the event generation, and be such that several events are not generated simultaneously.
Choice – the generator must choose. To guarantee that only one choice is made, the choice, that is the generation of the event, must be made simultaneously with the transition. In LD however, the chosen transition will always be the same in a particular state according to the ordering of the rungs.
Inexact synchronization – while the generator chooses, something may occur that invalidates the choice. This problem was addressed by Balemi (1992) and resolved by the introduction of delay insensitive languages. The supervisor is delay insensitive if the choice is not invalidated by a plant event that occurs during the time of making the decision.
There is a strong indication that a correct PLC-implementation of a supervisor can exist if and only if the supervisor has a delay and interleave insensitive language. This we aim to prove in the final version of this paper.