Introduction

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.

1-1. Discrete Event Systems

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.

Modeling

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.

Specifying

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.

Synthesis 

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).

Implementing

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.

Verification

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