A real time expert system environment for process control
Descrição do Produto
Copyright0 IFAC Atificial Intelligencein Real-Time Contd, California,USA, 1991
Lihat lebih banyak...
A REAL TIME EXPERT SYSTEM ENVIRONMENT FOR PROCESS CONTROL A. Crespo, J.L. Navarro, R. Viv6, A. Garcia and A. Espinosa Grupo de Automkica e Informdtica Industrial, Universidod Politknica de Valencia, Apdo 22012,
E-46071 Valencia, Spain
Abstract Process control of complex systems is one of the most interesting frameworks to apply new developments of expert systems. Intelligent tasks working together with traditional control tasks under real time contraints will permit the perfect marriage of both fields. However most of the techniques needed for this purpe are not ready: parallel inference, fast and efficient temporal representation and reasoning, guaranteed response time in an inference process, etc. In this paper a real time expert system for process control, called RIGAS, is described. The system is baaed in a set of tasks, described in the QUISAP language, a scheduler with intelligent policies, an agenda where instantaneous, delayed and periodic events are managed, and two sets of objects: application and control. Application objects are temporal objects mapping the real objects, while control objects are entities offering classical ot‘ rule-based regulators. A first prototype of the system written in Smalltalk a8 well as an application to the control of a cement kiln are detailed in the paper.
both views. However the engineer should select the most adequate temporal operations in the tasks taking into account the time constraints of each one. In the control of complex system where human experts
Real Time and expert systems provide a general framework to solve a great number of problems not completely solved by
have been doing this activity, the exact numeric value of variables has not a relevant meaning, instead of this, words like high, normal, low, etc., play an important role in the expert vocabulary. Fuzzy logic techniques [ZADEH88] provide an excellent framework for apply this interpretation. In this paper a real time expert system, called FUGAS, that incorporates most of the features above described is presented. In the first part we will explain the proposed architecture and its main characteristics: real time system, temporal objects, expert modules, etc. In the second part the concrete implementation of the system will be described. Finally, an application of this system to a rotary cement kiln will be discussed.
means of traditional approaches. One of the most interesting fields to apply these techniques is the control of complex systems. There is a significant number of topics in research related with this subject. Some of them are: real-time scheduling, temporal representation and reasoning, guaranteed response time, uncertainty management, efficient inference, etc. (LAFFEY881 From the real-time point of view, when inteNigent tasks are incorporated into traditional systems, problems come up due to the task scheduling in order to guarantee the deadline of tasks. Task resources should be analyzed (I priori and known by the scheduling algorithm. Real time tasks can have a periodic or sporadic behavior and a set of timing One issue to be considered is how to express constraints. the system reaction. In this paper a model called QUISAP [GARCIASO] based on [JAHSG] is used to define the system reaction. Tasks in a real time system can be associated to a set of timing constraints. When these tasks have an inteNigent behavior and the predictability of this computation can not be guaranteed, timing constraints should be associated mainly to the reasoning process. When it is not possible reasoning process could be defined in a separate task with explicit timing constraints. The scheduler will be responsible of starting the tasks at the appropriated time. Some architectures have
for real time
pert system [DODHISS], [HAYESSO], [RAUF89], etc. Most of them enlarge the features of expert systems to real time environments. However, this approach has some problems due to the the differences between expert and real time systems. Our proposal starts from the real time point of view adding some rule-based features in order to include expert capabilities to the system. The main components in the architecture (fig. 1) are:
been defined for real time expert systems [JAGA89]. Most of them are defined improving some features of traditional expert systems in order to have fast response, continuous operation, access to external devices, etc. In this paper a new architecture will be presented.
of the tasks
executed according to a scheduling algorithm taking into account deadlines, resources, time constraints, etc.
The consideration of temporal information is basic in Several models for temporal repthe control of systems. resentation and reasoning have been defined [ALLEN84], [DEAN87], [BARBER89]. Real time systems require a fast and efficient model, while temporal rules require high expressiveness and powerful. A temporal model must cover
2. Event-Management: to instantaneous,
maintains the information delayed and periodic events.
This work has been partially supported by the Comision de Investigacion Cientifica y Tecnica (CICYT), proyect No. ROB89-0442.
Define the methods to control output vari-
add to periodic behavior an exter-
nal or internal event instead of clock depending event, and time constraints related to the nature of the events. Timing constraints are completed with the separation, and the timeout as minimum and maximum time between two consecutive occurrences of an event, respectively. When some timing constraint is violated the associated
ables. Some regulators can be experts defining rulebased algorithms. Each expert regulator provides an inference engine in order to be independent. TemporaLObjectDataBase: contains the application objects. These objects are instances of predefined classes in the system with temporal features.
exception handler is executed. Actions in the handler should be restricted to user and error messages or condition changes. The computation model is based on active and passive
Manmachinelnterface: represents the interface between the expert system and the user. The MM1 shows graphical values, buttons to select options, pan-
objects. In an object oriented approach, actions specify an active object defining a set of messages that are sent to pasive (application) objects in order to perform some activity. Actions are sequential or parallel operations. Parallel actions define activities where the partial temporal ordering of them is not relevant to the final result. The scheduler will decide which actions will execute first taking into account the objects used by the actions.
els explaining the inference, set points modification, etc. Moreover, object, rule, and requirement editors are incorporated in this module. Communicationlnterface: performs the external communication between the expert system and the data acquisition systems implementing protocols to guarantee a reliable and fast communication. The global model is based on events.
Events are emit-
Tasks have a set of timing constraints
ted from several sources: hardware, tasks, rules, and objects. Events are collected in the agenda in order to manage periodic, instantaneous or delayed behaviors. When an event have to be known in the system, the agenda informs to the scheduler about this fact. The scheduler selects the associated tasks to the event, verifies some timing constraints and schedules them. Each task in the system is a thread of execution sending messages to the system objects (regulators, application objects, MM1 or communication module).
1. As result of an event occurrence (due to the clock or an event) the task or tasks related to the event are selected (added to a list of ready processes). 2. The most urgent tasks (shortest ready processes list is selected. (a) If the resources cess are needed them as input executed first. execution.
The requirements define the global reaction of the system. There are two predefined kinds of requirements: periodic and sporadic. The requirements are based on the eventaction model [JAH86]. A requirement specifies the response to the system to a single event, represented by some simple or composite ac-
the more appropriate
are tasks or processes in the exeof these require-
do: ectiona with deadline: time exception deadlinefailure:
subtask to be executed.
points of time in the relation
system with the environment. They can be produced by means of external or internal actions and can have a periodic or sporadic behavior. The event management is performed in the agenda that collects the events emitted from objects or external actions
requirement: name mode: modrld
requirement: name mode: msd.Id
(object) used in the current proby the selected task and both use information, the selected task is If not the current task follows its
Tasks without timing constraints are considered as non urgent tasks and are scheduled using a round-robin algorithm if they do not share resources. Parallel actions are considered as several subtasks (internally represented by a graph) with the same event or period and the same time constraints. As all of them have the same delivery time, the scheduler will consider, at each moment,
and the use of this model to control the execution of a control
The general structure
delivery time) in the
(b) If none resource is shared between selected current tasks, the selected task is executed.
tions. The response can be dependent on some condition and a set of temporal constraints for the required actions specified, as part of the requirement. Some previous works have been done by the research team related to rapid prototyping of real time system from a specification written in QUISAP [GARCIASO] generating Ada code and Petri Nets in order to verify the specification,
cution environment. ments is:
that should be guar-
anteed. In order to do this, a scheduling policy based on the most urgent task and available resources is implemented [GARCIASl]. The scheduler performs the following actions:
Real Time Requirements
system [CRESP089]. Real time requirements
do: aclisnr with deadline: time separation: time timeout: lime exception deadlinehilure: actiona separetion_faiIure: action* timeouthilure: action*
(communication, MMI) through the operating system, and send them to the scheduler. Three kinds of events are considered: instantaneous, periodic and delayed. While instantaneous and delayed events are external (named by the user), periodic events are internal as result of periodic tasks definition. The periodic behavior could be considered not only with respect to the time but to other signals (revolutions of a motor, number of alarms, etc.). In this case, a signal handler should be related to the signal management in the agenda. For instance, each time that a cement kiln complete a revolution some actions have to be performed. In this case we define a periodic requirement related with the revolutions,
Periodic requirements specify the actions to be taken periodically with a maximum time for its completion (deadline). If this maximum time is violated the actions, as defined in the exception handler, are executed. The mode and when attributes determine in which conditions (status of the system and conditions in a mode) actions are executed.
and in the agenda a mechanism to detect the period taking into account the signal produced at each revolution.
Several temporal models have been proposed as [ALLEN84], ~DEAN87], [BARBER39] based on time intervals or time points. In order to have a simple and efficient model for the reasoning process when applied to real-time systems, a simplification of the model defined in [BARBER891 is assumed.
The knowledge-based components are called Intelligent Regulators (IR) with reference to the classical regulators in process control. Each IR, as shown in figure 2, defines a set of problem solvers (rule-based or algorithmic) in order to provide solution to a concrete subsystem. The normal configuration 1. Fast Use the this
The implemented model is based on absolute time-points, being all the time point referenced with respect to an absolute clock. Only an attribute associated to the objects values is considered as temporal. This criteria implies a class hierarchy design other than having several temporal attributes with different temporal characteristics. The now time is always referenced with respect to the
of an IR is:
instantaneous clock value. In the assumed object oriented model, each temporal object maintain its own temporal information, being responsible of remove the obsolete information. An information is obsolete when its time is out of the temporal window associated to the object (memory attribute). A second temporal attribute, separation, is attached to the object with two possible meanings:
rule-based solver: of reduced set of variables, and simple functions in rules. A predicted time of execution is related to solver.
2. Complete rule-based solver: Use of all the variables and relations between them, as well as complex functions in rules (temporal reasoning) . As in the above solver, a predicted time is associated
1. Minimum time between two consecutive temporal values. This is equivalent to the minimum sampling time.
to the solver.
2. Maximum duration or validity time of a value.
3. .Algorithmic solver: Classical regulator (PID, dead-beat, adaptive, etc.) could be defined in order to supply alternative results when no solution is reached by the above solvers. As many levels could be defined reasoning process Moreover, the IR
Methods to read a value restricted to its separation time or the last value are provided in the temporal class. Figure 3 shows the internal structure of the temporal objects.
of rule- based solvers as the designer decide in the IR. Each level adds depth in the with respect to the applied previous one. has defined an inference engine in order to
The attributes l
evaluate the solution using the appropriate solver taking into account its response time. After each evaluation the average time to apply a rule set is updated. Each regulator has information about the objects used in the rule sets as input or output. The object lists are read by the scheduler in order to know the needed resources by the
Each IR works in the following way: .
2. The IR evaluate the control algorithm,
Defines the obsolescence
time of the infor-
Separation: Specifies the minimum time between two consecutive values. Could be used as duration of a temporal value. Active_value:
Defines a method that should be exe-
All the values are filtered through an object of
the deadline, starts with
Fuzzy-set: values corresponding with process ables are interpreted using this functions. Reference:
reference value of the process variable.
4. When the reasoning process finish, the IR decides if the next level have to be fired considering the remaining
value in the object
Values: temporal map of the values taken. Only the information corresponding to the real and fuzzy value is stored.
time. 5. The process follows until all level are considered or a deadline message is received.
6. If the timeout message arrives before an answer is reached as result of the applicationof any rule set, the algorithmic result or nil is answered.
object are the following:
cuted when a new value is added.
1. A message for starting a reasoning process arrives with a maximum time to give an answer.
3. The IR taking into account the first (faster) level.
of an application
Temporal class provides primitive methods for build relations between temporal objects. The relations l
Temporal_Object_Data_Base contains the application objects grouped by classes. All objects can be accessed by any component in the system: requirements and regulators. Access control mechanisms are not considered in the common storage because the scheduling takes care of them. Objects are instances of predefined application classes Tempe~tu~, Flow, Pressure, Rpm, etc.. All the application classes are subclasses of a temporal class that defines the common behavior (temporal behavior) of all the application objects.
could be: after, before, at.
quantitative: last trend, trend in an interval of time, time between two limits, times a value is greater or less than a value, etc.
Qualitative relations permits know if a temporal facts occurs at, before, after another temporal fact. For instance, the temperature ums greater than 48 at the pressun was rn~d~~m then . . . if
In this case the time
a Large number of classes giving access to the operating system, user interface, and other program design components.
looks for this case in the
complete temporal representation of the objects or an interval that could be attached to the premise. For instance, in the lost $0 nainutes if the temper&m was grater than 30 the MW frow was medium then . . .
a Multitasking after
The second group of relations is used to know quantitative information about the evolution of the object values. In order to evaluate the trends, an attribute of the temporal objects (filter) is defined. This method defines how to evaluate the trends of a set of values. For instance,
in an upper
a search in the temporal map have a greater cost and should be used
Smalltalk is not the environment real time systems.
code is worse than
level of rule sets.
Our intention is to obtain a high level environment for real time expert systems in order to analyze the proposed architecture correctly and, in the next the future, to improve temporal representation and reasoning, reason maintenance
When we combine process~control with expert systems techniques and we try to apply them with real time constraints, some criteria have to be applied in order to guarantee the response time of the system. In the proposed system, the guaranteed response time is obtained at different levels:
system, inference methods and scheduling policies. Some of these improvements are now incorporated in the prototype meanwhile others techniques are under integration.
and the used resources
task not defined in Smalltalk, a class RTProcess as a subclass of the Smalltalk Process, as well as methods for its
creation, deadline been defined:
to be ex-
Tools facilitating classes.
by seven levels of
Quisap subclass: #Event instaacsVariableIlames:
Quisap subclass: #Requirement instaacaVasiablsUames: ‘name deadline block guard mode dsadlineExcaption specification ’
A first prototype of the system is implemented in Smalltalk/V under OS2 operating system [SMALLSO]. The main advantages to select this language were: through
Quisap subclass: fcondition inatancsVariabl&ames: ‘name initValue value mutex spscificatim
defines a process
in the attached queue. Real time requirements
Additional improvements can be reached using efficient and fast methods for temporal reasoning, real-time pattern matching, methods to access to objects, etc. Although these characteristics do not guarantee the response time by themselves, they facilitate to the above mechanisms.
read the deadline,
priority. The ProcessScheduler class has been modified in order to define a level of priority with the described algorithm above, and the methods to add an instance of RTProcess
4, Real time requirements tells to the inference engine to apply or solve a problem with a maximum time. The inference engine use the best set of rules with the specified time.
Pure object oriented complete environment.
Process subclass: #RTProcess instanceVariableWames: ‘deadline’ classVariableflamea: I’ poolDictionaries: ”
of knowledge (deep knowledge); several sets of rules cooperate in a problem (rule-based regulator). The inference engine knows which rules should be applied and the time they required.
Classes for real-time requirements
Requirements are implemented as Smalltalk processes with some modifications. In order to implement a new real time
1. Requirements: specify the deadline, and other timing constraints related to the global behavior of the system,
Object methods send messages to other objects, and so on. This process finish when primitive methods are called. The number of calls is, in most cases, very large and it is very complex to evaluate an object invocation.
functions implying could
can be pointed
Dynamic object creation and deletion is done by the memory management and it is hidden to the developer. From the real time point of view, some operation with objects in memory can be correctly evaluated. Garbage collection ca,n be configurable but not always.
Some of the time primitives (those refering to a concrete time without search) have a reduced cost and could be used in the rule sets of lower level of deepening. Another mainly
by fully compiled languages (C++, Ada, etc.), due to the incremental code compilation and the dynamic behavior of the environment.
in the last hour if the trend of the fuel was high then . . .
of the objects
Requirement subclass: #Periodic instanceVz.riablaIiames: ‘periods periodefimer state ending mutex
Requiroasnt subclass: #Sporadic instancaVariablsliames: ‘went separation timeout state mutex currentEv*atValus timeoutException sepaxationlxception ’
and use of the new
Puisap subclass:#Specification inrtaaceVariablaliaes: 'IU.ra mode event conditionrequirementrunning Quisap subclass:#Agenda instaaceVariablelames: 'timerIdtime timercnt watchDog signal signal&.ndlers' classVaxiablePames: 'AllTimersNextTimer AllSignals YertSignal' Where all the classes are subclasses of the Quisap defined as main class without attributes,
objects or regulators is achieved by means of specific requirements that works in all modes. A set of classes in order to produce the MM1 more suitable to user needs is provided. The system is defined by means of the object, rule and requirement editors. Each editor allows to the user to specify all the characteristics of each component. The compilable parts of each component (active-method in objects, rules, and actions) are written in a Smalltalklike syntax in order to use the Compiler class provided in the Smalltalk environment and to produce the corresponding code. Using the same compiler as Smalltalk does, the prototype is fully integrated in the environment with all the facilities and drawbacks.
size of temporal objects within limits. Each component in the finite list is an instance of the TemporalFact class with the above defined attributes. Methods in TemporalData class define the messages accepted by temporal objects in order to provide temporal
previousValue: anlnleger previousValue: aTime
Man Machine Interface
TemporalData class models temporal information, independently of the application environment. The values attribute is a FiniteList instance in order to maintain the
Group 1 actualValue
Object subclass:#TemporalFact 'realvaluefuzzyValuetime' instanceVariablelsames:
if no answer is reached in the requested time. Each regulator has an instance of InferenceEngine class in order to be independent of others regulators. When a regulator is fired, a working copy of variables is done, being restored if the level of the rule sets is exhausted. The inference mechanism is
TemporalDatasubclass:#ApplicationData instanc.eVariableUames: 'filterfuzzySet reference initialValue'
Where the input and output attributes refer to application objects, ruleSets is an ordered coliection of RuleSet instances, and method specifies the algorithm to be applied
Object subclass: #TemporalData instamceVariableUames: 'separationmemory actirs!fathod values'
Object subclass:#RuleSet instaaceVa.riablellaes: 'name rules maximumTime'
Temporal objects are modeled by means of a hierarchy classes, each one adding a more specific behavior. Figure 4 shows the defined classes for the example scribed at the end of the paper:
and time points.
given by the filter associated
Object subclairs: #Regulator instaaceVaxiableXames: 'namemode inputs outputs ruleSets method inierence!&gj
mode, change conditions, collect events, etc. All the other classes provide methods to create, set values, get values, etc.
The Regulator Class defines the expert components system. The class definition is the following:
The Specification class defines the common behavior of all its instances. Each one defines the set of conditions, events and requirements (tasks) associated t,o an operation mode. As many instances as modes should be defined. When a mode is defined an instantiation of all the components is automat,ically done. Specification class provides methods to handle the requirements RTProcess instances: start, stop, change a
group works with trends object.
The communication between the system and external devices or other software processes is done through special classes in the system implemented as DLLs Dynamic Link Library provided by the operating system. The environment is able to send or receive messages to or from other software. Messages can be converted in recognized events in order to perform the response to the external stimulus.
are: Group 2
1greater:al/duein: anlnferd equal: a Value at: aTme less: a value before: a Z’zme equal: DI/a/w after: aTme
The developed system has been used to control a rotary cement kiln in a cement factory. The kiln process heats the inlet flow of raw material (time, sand, pyrite, dine) until the clinker is obtained. The process is formed by three step: the preheater, where the material is heated using the residual heat of the combustion fumes; the kiln, a rotary large cylinder where the clinker is formed; and the cooler, where the clinker interchanges its heat with the combustion air. Some of the characteristics of this process are:
The first group of primitives answers a temporal fact instance which can be used in rules to be related with other temporal facts using the relations before, after, or atSameTime. TemporalFact class provides methods to manage the attributes: real, fuzzy, time of all temporal facts. The second group of primitives are predicates giving an answer about the values that an object has taken in an interval. The third group answers interval(s) where an object took a set of values. A logic about intervals is supplied in the Interval class in order to perform the known primitives, ei-
. The system l
High number of variables sures(9), temperatures(l4), oratory
(between 40 and 50): gas concentration(6),
Large time delay in some variables dition.
Only few people operators).
of a model
due to the kiln con-
due to the process
know how the system
V. Botti, F. Barber, A. Crespo. Reason Maintenance in Real-Time Systems. IASTED Symposium. USA. December 1990. 78-82.
A. Crespo, P. Albertos, F. Morant, J.L. Navarro. Supervisor Control in a waste-water treatment pilot plant. IFAC Symposium on Adaptive Systems in Control and Signal Processing. Glasgow. Apri1.1989.
Dean T. and McDermott D. Temporal Data Base Management Articial Intelligence, 32, 1987
R. Dodhiawala, N. Sridaran, and C. Pickering. A Real-Time Blackboard Architecture. Proceedings of IJCAI 1989.
complexity. works (expert
Conclusions and future work
To date, most, of the work in this project has been devoted to the design and implementation of an architecture for real time expert, system applied to process control. In this paper the global architecture and its main components have been described. The proposed system allows the execution of parallel tasks where some of them can have an intelligent behavior. This is due to the scheduling policy and the internal structure of the regulator IR that perform the inference process. The real time tasks are modeled as requimments in the QUISAP language. Two classes of objects have been defined in the system: Application objects, temporal objects representing the process variables with a fuzzy interpretation, and Control objects, classical or rule-base regulators that perform the
[Garci&OO] A. Garcia, A. Espinosa, A. Crespo, J.A. de la Puente QUISAP: an environment for Rapid Prototyping of Real- Time Systems. rael May 1990.
control activities. The proposed system has been applied in a cement factory to control the kiln process. A first prototype of the system has been working in open loop mode. Most of the time the operator follows the values proposed by the system. The results are very satisfactory from the control point of view. Although the system reachs in time the main goals, it is necessary to incorporate new features. The following items showg the main points in research to be applied in our sys-
B. Hayes-Roth Architectural Foundations for Real-Time Performance in Intelligent Agents. Real Time Systems. Vol2, 1,2,
Acknowledgments We would like to thanks to the control team and the Compania Valenciana de Cementos for its comments and suggestions. Our special thanks to Prof. Pedro Albertos whose comments enhanced the quality of this work.
References a geneml Theory of Action Intelligence, 23, 1984.
Allen J.F. Towards and Time. Artificial
F. Barber, V. Botti, A. Crespo Temporal Ezpert System: Application to a Planning Environment. IASTED Symposium. USA. December 1990. 7882.
of liming Trans. on
Toward a Blackboard Architecture for interactions with Dynamic Systems.. of IJCAI
J.A. Stankovic and K. Ramamritham. Predictability for real Time Systems.
What is Real Time
Systems. Vo12, 4, 247,254
Using the previous work [GARCIASO], to add new tools in order to select appropriated schedulers and analyze them using Petri nets.
P. Raufles Real-Time Proceedings
to take in to the re-
AI Magazine. Spring.
To study how a reason maintenance system can be incorporated to the system without loss of efficiency.
complex and critical such as C++.
A.K. Mok Safety analysis in real-time systems IEEE
[LaffeydS] T.J. Laffey, P.A. Cox, J.L. Schmidt, S.M. Kao and J.Y. Read Real-Time Knowledge-Based Systems.
To study a more complete and efficient temporal model with symbolic relations, and incorporate a time map manager.
To implements the more a more efficient language,
. To improve the scheduling policy in order account all the time constraints associated quirements
R. Dodhiawala and L. Braun. Blackboard Architectures and Applications. Academic Press. 1990. properties
[Rauf89] real time pattern
tem: . Efficient
L. A. Zadeh Fuzzy Logic Computer, 4, April 1988.
F’igore 1. GlobalArchitecture