Modeling in real-time systems

Modeling in real-time systems

107 Modeling in Real-Time Systems Maarten B O A S S O N Hollandse Signaalapparaten BV, Afd. SEAT, Postbus 42, 7550 GD Hengelo, The Netherlands Comp...

706KB Sizes 0 Downloads 47 Views

107

Modeling in Real-Time Systems Maarten B O A S S O N

Hollandse Signaalapparaten BV, Afd. SEAT, Postbus 42, 7550 GD Hengelo, The Netherlands

Computer systems dealing with events in their environment must be able to interpret signals from that environment. Such an interpretation can best be understood as the (relevant sub) set of parameters that defines a special instance of (theorems from) a general theory. In that respect, signal interpretation is almost synonymous with model building, or deciding that a given model is adequate. The other aspect of a system's interaction with the environment is the generation and execution of plans of action. For this activity there also is the need for a model that adequately captures the state of the environment. There is usually the extra requirement that the model can be used to simulate the effects of actions.

Kevwords: Modehng, Real-time Learning, Interpretation, Control.

After his formal training in mathematics, Main'ten Boasson has worked in a variety of fields in computer science research, ranging from language design and implementation to artificial intelligence. His current research centers around the problem of using symbolic processing techniques in real-time systems.

North-Holland Computer Standards & Interfaces 6 (1987) 107-114

1. Introduction Ever since machines have been used to deal with situations and events in the real world - as opposed to the closed world of a machine that only accepts stimuli of strictly defined syntactic structure and semantic content - the relevant part of that world needed to be modeled. In most (early) cases this modeling consisted in defining relations between expected events and possible actions. This led to systems that simply performed some, possibly very complex, operations on the signals extracted and converted from the environment. The results from these transformations were subsequently used to control various effectors for influencing the environment in accordance with the system's tasks. Examples of such simple systems are: Speed control mechanism in steam engines. The underlying model is that steam pressure is (roughly) proportional to engine speed. Furthermore, use is made of the general theory of mechanics (centrifugal force, etc). The result is a mechanism that transforms engine speed to valve settings. N o t e that in the design of this mechanism extensive use is made of modeling (although it was p r o b a b l y not recognized at the time), but that in the machine itself there is nothing left of any of the models used for the design. Simple object tracking devices, like early radar systems. The measured positions of the object are directly translated to a set of control values for positioning the radar antenna. The formulae used for this translation are derived from the assumption that the object moves in a straight line, without acceleration. This simple model of the object's behaviour is used extensively to determine the transformation equations but is not in any visible way present in the system. Typically this type of system is computationally very efficient, but lacks flexibility that would allow it adequately to handle situations that even differ only slightly from those postulated in the model(s) used in their design. The availability of tremendous amounts of computing power has led to significant changes in the way systems are built. Simple generalizations

0920-5489/87/$3.50 © 1987, Elsevier Science Publishers B.V. (North-Holland)

108

M. Boasson / Modeling

of the above-mentioned scheme were implemented almost immediately after the introduction of digital computers in real-time systems. Currently there is a trend towards the use of more and more explicit models, to the extent that time itself has become a parameter in what essentially is a simulation of the environment, rather than a (large) set of equations to deal with observations from that environment. This paper will, in the remaining sections, discuss the following topics: (1) Using (static) models for interpretation of data and generation of plans; (2) Dynamically generating model modifications if a model is found to be inadequate for dealing with situations occurring (and observed) in the environment. Note that whereas the use of models is well established, the dynamic modification and generation of such models is currently beyond the possibilities of actual systems. No attempt is made at providing solutions for problems in building real-time systems. The sole purpose of the paper is to indicate directions in which developments are likely to go.

2. The Use of Models in Real-Time Every system that is part of a dynamic environment must be able to observe the relevant aspects of that environment in order to play its part satisfactorily. Therefore, sensing devices must be present that provide a (distorted) view of what is happening in the outside world. It is not a trivial problem how to optimally use the sensors: e.g. an optical sensor "looking" in an easterly direction will fail to observe the important events to the west. There is a simple solution to this problem: mount the sensor on a rotating platform and it will be able to see events in all directions. However, the apparent simplicity of this solution is misleading! The simple fact that the device is now rotating means at the very least that its sensitivity in a particular direction will have been reduced; also, for phenomena that occur rapidly with respect to the rotation of the device, nothing has been solved yet. Moreover, the sensor will undoubtedly register a larger number of pseudo events, which are really nothing but noise and will have to be recognized as such.

The problem already mentioned of the distortion of the observation by the sensing device itself is another cause of great trouble in handling the gathered information. It is in general next to impossible to distinguish distortions caused by the device from events occurring in the physical, real, world. And yet, the difference is essential for the correct interpretation of the observations. The approach to solving these problems is to incorporate an explicit model of the environment in the system. Such a model can best be understood as a set of algorithms that, when executed with suitably instantiated parameters, will generate simulated events that bear a close resemblance to the actual observations made in the real environment. A system thus built is significantly more complex than the sort of system alluded to in the Introduction. There are two aspects to this increase in complexity: it is more difficult to design and it requires more processing power during execution of the system. Since both aspects are potential causes of problems it must be made clear that the performance improvement of such a system warrants the extra efforts and, possibly, equipment (unfortunately, the design of complex systems is still very much an art rather than an engineering discipline; the processing requirements are more often than not already difficult to meet in traditionally built systems). There are essentially two ways in which an explicit model of (part of) the environment can be used. The simpler technique is to control the system's activity by the real observations from the outside world, whereas the more difficult, but at the same time more powerful, technique is to base all system activities on pseudo observations derived from the model. We shall describe both techniques in more detail.

3. Data-Driven Approach to System Operation Rather than modeling the environment as a whole, a system built in this style uses a variety of models, each of which describes the events in the outside world that cause a particular set of data to be received through the system's sensors. Models of this kind are passive in the sense that a model is only activated if the corresponding types of signals are received - and detected.

M. Boasson / Modeling

Once it is decided that signals do represent an activity of interest to the system (which can be done on the basis of physical properties, like e.g. signal-to-noise ratio) an appropriate model is selected and the data are filtered according to that model. The filter in fact represents (some) properties of the signals that, assuming that the model selected is correct, should have been observed in the absence of distortions. Thus, the filter used in processing the signals aims at retrieving the " t r u e " signals that would be observed if no distortion would occur anywhere (all observations that can ever be made in the real world will always be distorted, both by the path through the transmission medium and by the sensing device). These true signals are needed for a variety of reasons: (a) The models used in this style generally are parameterized generic models. That means that, in order for the model to be useful at all, the relevant parameters must be estimated as accurately as possible. This is generally achieved through statistical parameter estimation, which can, but need not, be integrated with the filtering process. This estimation process ranges from simple selection from a set of predefined values to very complex algorithms, e.g. recurrent filters (Kalman, etc.). (b) Many systems need to take actions, the effects of which will only become apparent at some time in the future. In order to plan such actions correctly, a system must know what the environment, or at least the relevant part of it, will look like at that moment in the future. Thus, on the basis of the knowledge gathered about the environment, the system must predict its future state. The only way in which that can be done, either by a human being or by a machine, is to extrapolate with respect to the current parameterization of the model used for processing the signals (extrapolation must be taken in a very broad sense here). The accuracy of the prediction obviously depends critically on the correctness of both the model and its parameters. (c) Model selection is not as trivial as was suggested above. In practice there are almost always a number of models that could reasonably well describe the received inputs from the outer world. The acuteness with which signals can be separated from noise determines how discriminating a system can be in selecting a model. Some noise elimination can normally be achieved inde-

109

pendently of any model of the event that generates the signals. There must be a model, however, of signal distortion in general (of a particular kind, in a particular transmission medium). This transmission model can be used for signals that originate from different sources in the same environment, and is therefore often kept separate from models that describe the environmental activities. Some examples of models used in this fashion are: Consider a system that must raise alarm when two aircraft are on an impact course. The system will need to be able to gather data about all aircraft in the region it is supervising. Assume that a traditional radar is used as the sensing device. Data coming from the radar system indicate reflecting spots in space (within the boundaries of the radar coverage). The accuracy of these positions in three-dimensional space is limited mainly by the discrete nature of the measuring method of the radar system. Thus the so-called plots only approximately represent the true situation. In order to estimate the actual positions and speed vectors of the aircraft, the system assumes that the planes either fly along a straight line or make a circular curve (note that this is an over simplification for the sake of the example). The radius of a curve is a function of the type of aircraft (a Boeing 747 typically makes larger turns than a Fokker F27). The type can be inferred from the strength of the received signal relative to the background noise: large airframes better reflect radar energy than small ones. Thus the system must choose between either a straight line trajectory or a circle of the correct curvature. In order to make a choice the system may try to estimate parameters for all possible models and after some time select the one that best corresponds with the measurements. A complication is that reflections do not always correspond with aircraft: birds, metal objects and noise generated in the equipment may produce results very much like true echos. Obviously the correct choice of a model is essential for the safe flying in areas with much traffic, as in the neighbourhood of airfields. The civilian case is relatively simple in the sense that all (most, at least) aircraft comply with well defined procedures. The military equivalent problem is much more difficult as unfriendly planes are, by definition, non-cooperative.

110

M. Boasson / Modeling

In order to control a chemical plant it is necessary to know which factors are important for the behaviour of all (chemical) processes. Moreover, it must be known what the acceptable limits of e.g. temperature, pressure and concentration are for stable operation of the plant. Finally, the relation between controlling factors and critical attributes must be known. Some of this knowledge may result from understanding all the details of the various reactions, while other knowledge can be shallow, learned from experience. In both cases, models will have to be built that permit the system to interpret measurements of critical attributes as indications of the reactions proceeding in order, o r approaching critical values. The models will allow the system to generate control values for the various controls in order to prevent the reaction from getting out of hand. The difference between deep-knowledge models and those merely based on experience is the system's ability to deal with new, not yet experienced, emergencies in the case of deep models. From the examples given, it is clear that a real-time system not only has to deal with interpretation of signals, but also, and equally important, must be able to generate plans of actions that will, when executed, "guarantee" the environment to behave in a controlled (desired) way. This planning aspect is generally handled in an implicit way, i.e. the system does not specifically address the problem of how to sequence basic actions for optimal results. The possible actions like in the case of the chemical plant controller, the control over valve settings - are predetermined and closely linked to deviations from the model-generated expectations in the observed environment parameters. There is good reason for this approach: actions by the system are needed only when the environment departs from the state the system is built to maintain. But when such a deviation is observed it is very often important to act immediately, lest the system lose control entirely. Thus, speed in reacting to observed anomalies is the determining factor in designing these systems. Unfortunately, due to a lack of precision both in the models used (clearly, models are abstractions as well as simplifications of the real world) and in the observed phenomena, signals are occasionally interpreted wrongly. When an action is then triggered automatically as a result of such an

interpretation, it may be totally adverse to the systems's intention, and consequently create disaster, rather than prevent it.

4. Model-Driven Approach to System Operation Instead of directly relating a system's activities to observations of events in the outside world, a model-driven system is centered around execution of the model. Typically, a model in such a system describes the complete environment (as far as it is of relevance to the system's task). Such completeness can in general only be approached through a hierarchy of sub-models, each of which covers a particular aspect of the environment. These systems in a way use the model to simulate the world. The pseudo observations that are extracted from this simulation are then compared with the real observations. If the two "match", i.e. if there is no reason to conclude that the simulation is significantly different from what is going on in the real world, then the received signals are simply discarded. If, however, there are differences, then the model inadequately describes the external world, and action is needed to bring the model up to date with the events in the environment. Such action is limited to what the model can handle in terms of events and their dynamics. However complete a model (note that we will not bother always to distinguish between model and sub-model), it of necessity is but a simplification of the system's environment, and therefore sooner or later will generate pseudo observations that differ from the real ones. The case in which observations are made in the world that indicate a new event, i.e. one that could not conceivably be connected to an existing model by assuming small errors in parameterization of that model, is handled in the following way: a world model would preferably contain generic sub-models for those phenomena that can appear and disappear at unpredictable times. Each time a signal is received that is not explained by the current state of the model, a number of such generic sub-models is instantiated in order to find the sub-model and its parameters that best describes the observations. That sub-model will subsequently be part of the total model, and each successfully interpreted signal - attributed to the real counterpart of the sub-model - will strengthen the belief in the

M. Boasson / Modeling

sub-model as a description of part of the world. The alternative is an observation that is "almost" explained by the set of models. Then the system must decide whether to adapt the relevant sub-model by adjusting its parameters (in which case it must ensure that the new set of parameters is consistent with previous observations) or to discard the sub-model describing the relevant part of the environment and from then on use another model. In practice, a system will instantiate a number of generic models while at the same time continuing the old one until it is clear which model best describes the current behaviour of whatever the cause of the observed signals may be. Note that in instantiating a number of models the system can use the attributes of the model that up to now was found to be adequate. As a simple example take the flight control system mentioned before. The world model will in general contain a (possibly large) number of rather simple models of aircraft flying along well defined flight paths. Such models typically embody knowledge about flight dynamics, about established procedures in flight control areas, etc. Every time a new radar echo is detected, one that cannot belong to any of the known, and thus modeled, flights, the system creates a new model, probably taking into account expectations about incoming flights derived from the filed flight plans. Flights that terminate cease to generate signals that can be matched against simulated signals, and the system will have to decide what to do with the models that predict signals that no longer occur in reality. The more difficult case is the flight that for some .unknown, and certainly unexpected reason, departs from the routine (the model relies on). The above-mentioned approach is to initiate a number of models, one of which may be a valid description of what is happening. It is very difficult in practice, however, to automatically deal with such situations. The number of possible models can be prohibitively large, requiring unlimited processing capacity, and therefore the system is always controlled by expert operators, and in fact mainly used as a practical information-gathering and display tool. Not only does the potential benefit of greater modeling flexibility direct system designers towards a model-based approach, but the explicit use of time in the models greatly enhances the possibilities for adequate planning of actions.

111

Planning means deciding at a given moment which activities will have to take place at some time in the future. Thus, it is essential for planning to have as good an idea as possible what the situation in the environment (in which the plan will be carried out) will be for the duration of the plan. Such predictions about the state of the environment can very elegantly be obtained from the model by executing the various algorithms with simulated time that runs ahead of real time. If the model is sufficiently complete to allow effects of actions to be simulated (this being a major reason for using a model-driven approach, it is likely to be at least partially possible), the consequences of a plan can be studied well in advance of its effectuation. Note that in order to continue interpretation of observations, and consequently adapting the environment model if so needed, there must be two copies of the entire model: one that is executed with time synchronized with the environment, the other with time running as fast as possible, in order to quickly investigate the future. In practice, for a system controlling a variety of devices, there may be many copies of (parts of) the model. For each device a separate copy of the relevant parts of the model may be needed to determine how best to handle the device in view of the current, and predicted, state of the world, because different devices may require different prediction periods. This approach obviously requires vast amounts of processing capacity. It seems unlikely that a single processor can be programmed to deal with all the aspects of using the model sufficiently fast to allow the system still to respond to events in real time. Therefore, distribution of processing is a necessary condition for building systems of this kind. However, the design of distributed systems requires more than the design of a hardware mechanism that is capable of transferring data (e.g. messages) between processors. Attempts at writing a program for a distributed system as if the system were a very powerful single processor will either fail completely, or make less than optimal use of the potentially available processing capacity. It is essential in the design of (real-time) distributed systems to think in terms of parallel, (semi) autonomous activities. No available programming language or program design method

112

M. Boasson / Modefing

adequately supports truly concurrent execution of program parts. Strong synchronization between concurrent activities is contrary to efficient use of processor capacity, and should therefore be avoided through careful design. Programming languages for concurrent systems (like Ada, CHILL, Modula-2, etc) were all designed as extensions to languages for sequential programs, and therefore treat concurrency as an exception rather than the normal case. It is this grafting of concurrency onto a language primarily intended for the notation of sequential programs that leads to the emphasis on synchronization. It is interesting to note that a system concept as outlined here closely resembles the " b l a c k b o a r d " concept that is rapidly gaining popularity as a paradigm in problem-solving strategies. These blackboard systems - a few have actually been built for signal interpretation tasks - are generally structured as a globally accessible memory (the blackboard) around which processes are grouped, each assigned a particular task in the entire problem-solving process (a process is said to " e m b o d y knowledge of some particular kind"). The total activity of a system like this is normally controlled by a process with specialized knowledge of how to use the available processes for "optimal" results. The decisions made by the controlling process are of the scheduling kind. It is well known e.g. that in operations on trees the choice between depth-first and breadth-first search strategies can make the difference between success and failure. A scheduling process would need very general knowledge about which strategy to use and when; obviously, in order to make such a decision the process would have to be able to distinguish between the different situations that require different strategies. This observation can be generalized in the sense that a plan can never be made without interpretation and vice versa. It is well conceivable that the processes can be made autonomous, and thus eligible for assignment to a separate processor each. Since the communication requirements can hardly be foreseen very much, if not everything, depends on the state of the total system, including its environment the possible interactions between the processes cannot be programmed in advance, and a runtime mechanism is needed, therefore, that permits very flexible communication links to be created and destroyed as the situation dictates. An architecture

of this kind can be designed which has the additional desirable property that processors can be fully dedicated to their intended task, rather than spend a significant part of their time in organizing the communication with others. It seems within our possibilities now to build systems based on a model-driven approach, thereby significantly extending the capabilities of these systems. Far more decisions can be taken automatically, and if it is still too early to accept systems like that, at least the advice given to their users can be more meaningful. If, for example, a powerful system built along these ideas had been installed for controlling electrical power generation and distribution systems, a numer of (near) accidents would have been avoided. Equally beneficial use of such systems could have been made in the chemical industry.

5. Dynamic Generation of Models All systems that rely on predetermined models, whether implicit or explicit, data-driven or model-driven, are only capable of dealing with those situations that are covered by the model. There inevitably occur events in the outside world that a fixed-model system cannot deal with adequately. It is essential that at least a system recognize such a situation in order to inform an operator, and provide him with sufficient information to decide how to handle the unforeseen event. Increasingly, systems are designed to operate unattended. This pre-empts the solution in which the decision how to handle in difficult cases is left to the operator, as indicated above. There are two obvious reasons for requiring systems to operate autonomously: - H u m a n resources are scarce, especially if highly skilled personnel are needed to operate a system that in the majority of situations is perfectly capable of handling them unattended; - The environment in which decisions must be made is progressively getting more and more complex. Events of ever greater complexity occur at frighteningly increasing frequencies. Therefore, the human operator, even the highly capable, well trained professional, cannot react to such events either with sufficient sophistication or quickly enough to redress dangerous situations.

M. Boasson / Modeling

Clearly, systems must be made more versatile, in the sense that even in unexpected circumstances some useful activity can be undertaken. There seem only two ways in which such generality can possibly be achieved: either by exhaustively covering all possible real-world situations in the model that drives the system, or by providing the system with the means and general knowledge to itself extend the model whenever a situation is encountered that is not satisfactorily described by that model. The first approach, although perhaps not in principle impossible, is at the very least impractical. It would require a great deal of imaginative analysis on the part of the model builder to foresee such exotic events as e.g. the catastrophic sudden breakdown of a nuclear reactor control mechanism. If the situation that results from such a breakdown is not built into the model according to which the reactor is controlled, there is no way in which a traditional system can cope with the ensuing problems. As is well known, human operators do not always handle such situations correctly either. In general the number of possible unpleasant situations is so much larger than the number of acceptable ones, that it is virtually impossible to enumerate them all, and thus to build them into a model. The basic technique for building models is the exploitation of analogies between the world to be modeled and some abstract theory. Clearly the well known mathematical models for such diverse worlds as space flight and chemical processes are of this kind. The general theory of differential equations in both cases provides a framework in which adequate descriptions of the phenomena of interest can be formulated. More generally, an abstract theory in terms of which a model is to be formulated must be specialized in such a way that the resulting properties can be elegantly mapped onto the world that is being modeled. Such specializations consist of selecting the theorems from the theory that have a valid interpretation and of choosing values for parameters that restrict the application of the theory to a domain of values that correspond with conditions in the real world. If e.g. a model must be developed for the behaviour of aircraft, the mathematical field of differential equations is the most likely choice of a general theory. However, only those theorems are

113

useful for the model that pertain to, say, second-order linear equations. (Such an approximation could be valid if observations of the real aircraft would be so imprecise that higher-order details would not be visible anyway). Furthermore, the dynamics of the aircraft being limited to accelerations that would not impair the pilot's senses, the parameters of the differential equations can be restricted to reflect this condition. This process of abstraction (from physical properties of the world) and, at the same time, specialization (of the too general theory) is still very poorly understood. The process involves at the very least the following: O Determination of which properties of the world need to be modeled for a system (relying on the model) to perform a given task. Trivial as it may be, it is not always obvious exactly what these properties are. A rather thorough understanding of the phenomena that may occur is necessary to estimate the importance of the underlying properties and their relations. It seems very unlikely that an automaton can be designed (in the next decade) that is capable of this difficult analytical task. • Given the essential properties and their relations, expressed in terms of the world in which the system must operate, an abstract formulation must be found. Again, there is more to this step than meets the eye: more often than not several abstractions will be possible, but only a few (at most) will be useful for the next steps in the modeling process. The abstraction process itself relies on the detection of similarities in, and the subsequent categorization of these world attributes. This area is more amenable to automation than the previous, but still requires extensive research, and much work, before it will be possible to automatically generate useful abstractions. Part of the problem is that there is no way of knowing, at this stage, whether an abstraction is useful for the building of models, or not. • The next step is to find a general theory that is closely related to the abstracted world of the preceding phase. Essential in this comparison of theories are the structures of both theories (note that in fact the abstracted world is a theory of that world). Only if that abstracted world theory can be subsumed in the general theory can that general, well known, theory be used to model the world. The determination of this relation between

114

M. Boasson / Modeling

theories is a difficult computational problem, but may eventually be performed algorithmically, provided there is a uniform notation in which all the relevant theories can be formulated. The degree to which this subsumption of a special theory in a general theory must be successful for the general theory to be used for modeling is an open question. • Finally, the general theory that is found to be useful for modeling must be specialized to limit its scope to those theorems that admit of useful interpretation. The process of modeling as indicated above (note that it is certainly incomplete and possibly totally useless!) consists of a number of steps that would provide a system with some capability of adapting itself to unforeseen situations in its environment. Not all steps would have to be implemented, but the order in which a system could actually use implemented steps is the reverse from the order in which they are presented here. This is hopeful, in the sense that it may in fact be possible to build such adaptive (if not learning) systems, because the later stages of modeling (as described above) seem "easier" to implement than t h e first steps.

The power of systems of this kind - if they can be built, and if so, with some efficiency in their modeling activity - can hardly be (over) estimated. From a very high-level description of both the world the system must be active in (and thus part of) and a number of general theories, the system would be able to determine which theory would provide the best basis for modeling - and thus understanding, in a somewhat narrow sense certain aspects of the world. There obviously may be any number of models to describe particular aspects; as outlined above, their relationships tie them together as a complex model of the entire environment. The concepts used in our approach to designing real-time systems are identical to those that drive research in some areas of Artificial Intelligence. In AI, these concepts form of the starting point, whereas in the observations made here, they naturally follow from the need to make systems more capable of autonomous behaviour. This indicates that there is a smooth transition from traditional programming to the use of AI methods in real systems.