Module 3.1: Supervisory control loop
In supervisory control, an uncontrolled system is controlled by a supervisory controller that ensures its correct and safe operation. The uncontrolled system is also called the plant. It is the system that is to be controlled, as it is, so without the supervisory controller that controls it. The plant may therefore exhibit undesired and unsafe behavior. The supervisory controller restricts the plant's behavior, by disabling certain events in certain states, to ensure it never reaches states that are undesired or unsafe. Together the plant and the supervisory controller form the controlled system.
The plant can be seen as a map with all the possible roads that can be taken. The supervisory controller can then be seen as traffic lights at road intersections that turn red to prevent taking roads that should not be taken, because they are dangerous, lead to a dead end or don't lead to your destination. Being at a certain intersection is then analogous to the state of a discrete event system. A road between two intersection is analogous to a transition between two states. And a traffic light turning red is analogous to disabling a certain event.
The supervisory controller should thus observe the events that are possible in the plant, and should be able to prevent some of these events from occurring. This is also known as the supervisory control loop, as shown in the figure below. The plant indicates events that are enabled in its current state. The supervisor then decides for each event whether it is allowed to be executed or not. The plant then executes one of the events that are enabled in its own state and are allowed by the supervisor. The plant, from its new state, then again indicates which events are enabled, and so on.
Restricted copy of the plant state space as supervisor
So, how does this work exactly? How does the supervisor control the uncontrolled plant? The simplest form of supervisor, the traditional one, is one that is a restricted version of the plant. It has the same alphabet as the plant, but disables some of its behavior (prevents certain roads from being traveled). Such a supervisor is an automaton representing the state space of the plant, as you computed in the previous module, but then with some states and transitions removed from it. We saw an example of this in already in Module 1, where the plant of a bridge had the following behavior (but now with a marked state):
And the supervisor was a restricted version of that (now also with a marked state):
Two states of the plant state space are unsafe, and are therefore not present in the supervisor. And all transitions to these two states are not present either. The supervisor thus only contains the safe part of the plant behavior.
The plant and supervisor together form the controlled system. When the plant and supervisor automata are put together in a single model, this is a model of the controlled system. In such a model, the plant and supervisor automata synchronize on shared events. The plant can then only take an edge for an event if the supervisor can also take one, and thus the supervisor allows the event. If they can both take an edge for an event, they together perform a transition for the event.
In cases where the supervisor automaton is purely a restricted version of the plant state space, the state space of the controlled system model is equal to that of the supervisor automaton. The CIF event-based supervisor synthesis tool produces such supervisor automata.
It can also be that a supervisor automaton is derived in some other way, for instance manually. It could be that it is then not a restriction of the plant state space, but still restricts the plant behavior in some way. Still, in all cases, the plant together with the supervisor forms the controlled system.
Additional control conditions as supervisor
For very large plant state spaces, it is not very convenient to represent a supervisor as a restricted version of the plant's state space. If it has thousands, millions or even billions of states, it would be hard to see what exactly is being restricted. In such cases it is better to represent the supervisor as a smaller automaton. The most extreme case for this is to represent the supervisor only as the extra control conditions that it imposes on the plant's behavior. That is, the supervisor automaton has a single location that is initial and marked. This location has for each restricted event a self-loop edge with as guard the extra control condition. For the bridge example, such a supervisor could look like this:
To prevent going from the ClosedGreen state to the PartiallyOpenGreen state, the supervisor allows the partially_opened event only when not in the ClosedGreen state.
And to prevent going from the PartiallyOpenRed state to the PartiallyOpenGreen state, or from the OpenRed state to the OpenGreen state, the supervisor allows the to_green event only when in the ClosedRed state.
It is sufficient that the supervisor restricts going from a safe state to an unsafe one.
It does not have to prevent transitions between unsafe states, as the unsafe states can no longer be reached.
The controlled system still consists of the plant together with the supervisor. If the plant and this new supervisor are put together in a model, they still synchronize on their shared events. The supervisor thereby adds additional conditions, through the guards on the self-loop edges, to the behavior of the plant. Only if the supervisor guards allow an event, can the plant and supervisor together take a transition for the event. The events for which the supervisor does not have a self-loop edge are not in the alphabet of the supervisor. The supervisor does not restrict such events, and the plant can take transitions for them by itself.
The behavior of this alternative controlled system is the same as for the previous controlled system. That is, the state space of the plant together with this second supervisor is exactly the same as the supervisor automaton of the first supervisor. The two supervisors are thus functionally equivalent. The second supervisor however, more explicitly indicates what behavior of the plant it restricts.
Modeling plants and supervisors in CIF
When modeling for supervisory controller synthesis, the automata in a CIF model need be distinguished as being part of the plant or being a supervisor.
The automaton keyword can be replaced by plant to indicate that the automaton is a plant automaton.
The automaton keyword can also be replaced by supervisor to indicate that the automaton is a supervisor automaton.
Besides plant also plant automaton is allowed, and similarly supervisor automaton can also be used instead of supervisor.
For instance, the supervisor automaton above, the one with the additional control conditions as self loops, could be modeled in CIF as follows:
supervisor s:
location:
initial;
marked;
edge partially_opened when not ClosedGreen;
edge to_green when ClosedRed;
end
Quiz
`,
answers: [
"Yes.",
"No.",
],
correctAnswer: '2'
},
{
type: 'single-choice',
question: `
Does the following supervisor control the bridge system in the same way as the first two supervisors presented in this sub-module?
`,
answers: [
"Yes.",
"No.",
],
correctAnswer: '1'
}
]