Control systems consist of a controller
K that observes and influences a dynamic process G so that the
closed-loop system, say, behaves according to a
predefined specification. Let P represent a model of the dynamic process
with possibilities to observe and influence the dynamics. The, so called, design
problem, of control engineering concerns, using P and a given specification
for the desired closed-loop behavior, designing a controller such that the closed-loop
system behaves within the specification “as well as possible”. Solving this
problem requires a number of “tools” that facilitates for us to perform a number
of steps. First, we need to find the (mathematical) model P. Next,
we may have to transform the (often informally and incompletely given) specification
so that it relates to P. Third, we need to generate (preferably
automatically, that is, synthesize) the controller and finally to implement
it. In some cases, we may also want to verify that the generated controller
is correct. This is especially important in the cases that the controller is
not synthesized according to some formal mathematical procedure proven to result
in a correct solution.
In this course, we will be concerned with those controller-design steps for a specific class of dynamic systems, namely discrete event systems. We will be treating:
·
Modeling, , P is a model of the real
process G.
·
Specifying, , Sp is a function of P
and the specification for the real system.
·
Synthesis, , the controller is derived from P
and Sp.
·
Implementing, , the physical controller K
implements S.
·
Verification, , the model of the closed-loop system
fulfils the specification.
Not all dynamic phenomena can be meaningfully represented by real-valued mathematical expressions. Especially man-made, non-physical systems containing information-handling parts, such as manufacturing systems, operative systems, communication protocols and telephony systems are profitably modeled as discrete event systems (DESs). These are systems that at any time-instant occupies a unique state of being, out of a (finite) set of such states. The states are symbolic-valued in contrast to the numeric-valued variables we normally deal with, and represent a configuration or situation during which certain physical laws, policies and rules apply. For example, a manufacturing resource can be in any of the states Idle, Working, Finished or Broken; a communication protocol can occupy the states Sending or Receiving; a telephony system can be Busy, Off-hook etc. Other examples include traffic control systems, digital switching circuits and the like.
The discrete event system performs transitions between the states, transitions that are associated with the occurrence of events, occurring asynchronously at discrete points in time. In this way the behavior of the system is described (or observed) as sequences of the occurring events, traces, and sequences of the states visited as a result of these traces.
The complexity of the typical discrete event systems has, thanks to (or perhaps because of) the rapid computer evolution increased significantly (just think of modern telephone switches!). This makes formal methods almost a necessity for handling the complexity of all but the smallest systems. However, the development of methods and theories to handle the complexity has somewhat slipped behind the increasing technical advancements. Not until quite recently has useful methods evolved. Some of these will be presented in this course.
Methods and theories to manage continuos systems, such as differential and matrix algebra, have evolved during hundreds of years and been refined to a very high degree. These tools have also been integrated usefully into the everyday engineering practices as well as into engineering education. A large number of computer-tools supporting the manipulation of these types of objects exist also, particularly in the form of numerical analysis.
For DESs, on the other hand, very few
standards and tools exist, and few (if any) of these are integrated into the
everyday practice of engineers or engineering education. There are several reasons
for this. One of the reasons being that for DESs there does not exist any laws
of preservation similar to the ones for physical systems. Models cannot (more
or less uniquely) be derived from the principles of the conservation of energy,
mass balances or equilibria of momentum. The state-space of a continuos system
is a dense subset of ,
while the state-space of a DES is a discrete set of symbols. This means, of
course, that other methods must be used for the analysis and computation of
DESs. Such methods we find, particularly, within the realm of discrete mathematics;
set theory, boolean algebra, formal languages, automata theory, etc. are the
type of mathematics behind manipulations of DESs.
“Abstraction, (the result of) a thinking that disregards certain (temporary) aspects of an object while emphasizing other (important) characteristics” (Bra Böcker, Lexikon 2000 ).
A model is an abstraction that tries
to capture the, for the user, important or relevant characteristics of an object.
We write to denote
that P is a model of G. With P we try to express
those aspects of G that are of importance to us. What these are depends
entirely on our intention for the model P. It is essential to realize
that (the real) object G has, just as any other (real) object, an infinite
number of attributes, of which the model can only ever capture a finite number.
It is therefore imperative that P really captures exactly the relevant
characteristics of G. Otherwise it cannot be used for our intended purposes.
However, it is equally important that P captures only those aspects
that we deem relevant, and no more. Letting P encompass redundant and
unnecessary information complicates our mental view of G and may complicate
the manipulation of P and its derivatives.
In this course our models will be DESs, more exactly automata (in different guises). However, this does not mean that there necessarily exists a single unique model of a given G. On the contrary. As mentioned above, the absence of fundamental physical modeling principles and the absence of globally agreed modeling standards, means that unique models seldom exist. This complicates the modeling, since it interweaves the modeling intimately with the use of the model, that is, the specification. Two different models of the same G can bring forth radically different specifications, in the same way as specifications of different complexity can give rise to different models of the same G.
Thus, the question “which model is the correct one?” can only be answered by “it depends on the specification” (that is, the intended use).
We will not investigate questions of congruence (that is, whether the model captures enough) and similar questions in any formal way, but we will see different models of the same G and discuss their suitability.
The specification is given (by the “client”) in relation to the real system G and often stated in a highly informal way. The typical case in this course (as well as in practice) is a textual description of the desired behavior of the closed-loop system. This results in two problems.
1. The specification does not relate to the model P.
2. The specification is not complete.
These problems are real, that is, they turn up even in the daily work of the engineer. They are not specific for the simplified here’s-the-problem-hand-me-the-solution form present in engineering education. On the contrary, in the industrial “real world” the problems are much more accentuated.
That the specification does not relate to the model means that we need to transform it so that what the specification expresses coincides with what the model expresses. We need to formalize the informal specification, translate it to a format we can manipulate together with our model. Typically (for our case), this implies that the specification is expressed as forbidden and/or desired states and traces.
The incompleteness of the specification means that it does not express everything. This can be accidental or by purpose. One characteristic of the formal specification, though, is that it must express the entire desired and allowed behavior. This in turn requires us to make certain choices where the informal specification is incomplete. These choices must, of course, be relevant and well-motivated (something which is of the greatest importance at exam time J)
One way to make the specification complete is to “compose” it with the plant model. This is especially useful when the incompleteness is intentional. Then the intent is that the process (or rather the model) should handle the non-specified parts as it pleases. However, this does not always lead to a reasonable complete specification. Most notably in the cases where the incompleteness was unintentional.
We write to express that the formal specification
Sp is a function of the model P and the informal specification
spec (which relates to G). At the same time, we said above that
the model is dependent on our intended use, that is, the specification. This
“duality” between specification and process (model) both complicates and simplifies
things for us. It complicates matters since the distinction between specification
and model is not always entirely clear. On the other hand, it simplifies matters
since we need not always make that distinction; Sp is (under some conditions)
a model of the closed-loop system.
Given the formal specification Sp
and the process model P a controller S is to be generated. This
controller should be such that as it observes and influences P the closed-loop
system should
fulfil the specification “as well as possible”. Two things can be immediately
noticed.
1. S
cannot guarantee anything other than that fulfils the specification.
2. “As well as possible” is not well defined.
The first point means S promises
us nothing about the real closed-loop system , nor the fictitious system
. Assuming
that P really captures the relevant parts of G in sufficient detail
and that Sp really expresses what we want, we may assume that
really tells us something about
the behavior of
. However, there are many sources
of error on the way. That K is a correct implementation of S is
of course crucial, for one thing. We cannot do much about this problem, other
than try to formulate as relevant models and specifications as necessary and
possible. This is something that is learned by experience.
“As well as possible” may mean many things and could be considered a (meta) specification in itself. It can mean as fast/cheap/safe/robust/… as possible. In this course, we will take it to mean “with as little influence as possible” (with a few exceptions). We will talk about a “minimally restrictive” controller and mean a controller that allows the process the greatest possible amount of freedom. An underlying assumption being that the process can choose for itself what to do among the actions the controller allows it. In this way a controller can be seen as a “safety device”, a supervisor, that restricts the process from doing things that would break the specification. While the process behaves within the legal realm it can do whatever it wants. Obviously, in practice there must be choices made, but deciding the “best” choice is a very complex computational problem rather than a control problem. Thus, we will not treat that problem (the scheduling problem) in this course. Not even in the case where we design a controller that actually commands the process to take specific transitions will we touch upon the choosing difficulty.
The controller S is a function
of both the model P and its corresponding formal specification Sp,
and we write. Here
we can note that P and Sp are composed by the same operator as
we use to model the interaction in the closed-loop system
. Thus, Sp
observes and influences P in the same way as S does. This is natural;
Sp expresses a restriction of the behavior of P and this restriction
is introduced by the
operator. S is then a
further restriction of the behavior of
. The controller S is then
the least necessary restriction guaranteeing that the closed-loop system
fulfils
the specification. Hence, S is the least restrictive controller that
exists, given that model and that specification. S is such that
, that
is, the controller is a model of the controlled system.
Note that, the last restriction may not
always be necessary. Under certain conditions, S will actually be equal
to Sp and thus Sp can be directly used as a controller. This has
the important implication that for certain systems the formal approach may not
be necessary. However, such specific examples, though they may be many, should
not be taken as a reason to assume that a formal approach is never necessary.
On the contrary, the formal approach can explain to us exactly why and
exactly when the approach is not needed. This is a great feat in itself
and a strength of the formal methods approach. For instance, in the case that
Sp is not directly usable as a controller, this fact will be revealed
in the composition (if not sooner).
The synthesis results in a controller of an abstract form, an automaton. The implementation of that automaton we call K. Typically, S is implemented in a computer and specifically for manufacturing systems S is implemented in a programmable logic controller, a PLC. These are programmed in specific programming languages, ladder diagrams (LDs) and/or sequential function charts (SFCs). For these programming languages there exists an international standard (IEC 1131) and the course will devote a number of lectures to these “languages”, which are basically graphical.
However, there are a number of problems associated with implementing the resulting controller in a computer in general and a PLC in specific.
1. The asynchronous nature of automata is not easily implemented in a computer.
2. Assumptions about the interaction between P and S do not hold between G and K.
The first problem concerns moving from the asynchronous event-based automata world into a signal-based PLC-universe. Regarding the rising and falling edges of the signals as the events is the intuitive approach. However, this does not necessarily solve all problems; it may even introduce some new ones. The solution is to sort the transitions in the “correct” order; the problem is that “correct” is not always well-defined.
The second problem is actually a communication-delay problem. The PLC (and most computer implementation) observes the process periodically (samples it), reading all inputs at once and holding that information while acting upon it. However, while an action is computed no observation of the process takes place. When generating the controller, on the other hand, exact synchronization is assumed between the controller and the process. When an event occurs in the process, that event is immediately observed by the controller (if observed at all). This discrepancy between what we assume and what we actually have has the consequence that in certain situations the implemented controller and may get out of synch with the process. Then, the computed action may not be what is required to keep the closed-loop system within the specification. Sufficient requirements exist on S such that this problem does not turn up in the implementation. However, these requirements are (as yet) quite strong.
One may ask why we insist on using a theory that we know does not model reality in enough detail. The answer is that the current theory is all we have and the problems can be overcome. The benefits of using formal methods are greater than the drawbacks of implementing the result.
By verification, we mean the process of ascertaining whether a system fulfils a given specification or not. When verifying we do not (usually) distinguish between (a model of) the controlled process and (a model of) the controller. Rather, the closed-loop system is taken as a whole and questions such as “can this happen?” are asked. Hopefully, the verification tool answers “no” (assuming it is an undesired property), but in the cases that the answer is “yes”, typically some indication of what causes the problem is given. Naturally, this information can be used to change the closed-loop system (that is, the controller) so that the undesired behavior is avoided. From a control engineering perspective, this seems a backward way of working, though. Since we generate the controller from the specification and the process model, using a procedure that is mathematically proven to give a correct result, we know that none of the non-specified behavior will be exhibited. The specification is guaranteed not to be broken. Obviously, this holds only if the process model and specification is correct, which may seem as an argument in favor of verification. However, the same problem turns up there. It is the models that are verified, not reality. If the verification models are incorrect, then no guarantees can be given about the real system.
One verification aspect that may be useful even from a control engineering perspective is the verification of the specification. Given the specification we assume that it specifies the entire desired and allowed behavior. However, mistakes may have been made. Asking and answering questions about the specification can thus be very useful.
It should be noted that synthesis is generally a more complex problem than verification, especially considering the specification. For synthesis, the entire desired and allowed behavior must be expressed, whereas separate characteristics can often be verified separately. It is very hard to give a complete specification, particularly for a system under development.
Traditionally, verification has treated timing aspects, which lie outside the logical correctness that our synthesis guarantees. This is very important, in particular for time critical (embedded) systems, a very important class of systems where formal methods are practically imperative. For logical systems, timing aspects can be treated separately and will always restrict the logically correct solution.
An area close to verification is simulation. When simulating, the models are exposed to different types of inputs and disturbances and their outputs are (computer) generated. The simulation models can often be made more complex and thus closer to reality than the models used for synthesis. Thus, simulation can reveal “incorrectness” in the controller (say) due to the synthesis model not capturing enough of the relevant details. Note though that simulation can never prove the absence of errors, only the presence