A real time expert system environment for process control

July 14, 2017 | Autor: Alfons Crespo | Categoria: Process Control, expert System, Real Time
Share Embed


Descrição do Produto

Copyright0 IFAC Atificial Intelligencein Real-Time Contd, California,USA, 1991

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.

1

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

INTRODUCTION

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

2

Global Architecture

Several

architectures

have been

proposed

for real time

ex-

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.

1. Scheduler:

performs

the selection

of the tasks

to be

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.

related

This work has been partially supported by the Comision de Investigacion Cientifica y Tecnica (CICYT), proyect No. ROB89-0442.

19

Regulators:

Sporadic requirements

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.

2.2

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

2.1

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-

sporadic requirement

when: every:

when:

condition

00:

Lime

do: ectiona with deadline: time exception deadlinefailure:

aefionr

and

subtask to be executed.

2.3

Event Management

Events

are significant

points of time in the relation

of the

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

Scheduler

condition event

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.

20

and in the agenda a mechanism to detect the period taking into account the signal produced at each revolution.

3

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.

Regulators

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

l

.

IR.

.

Each IR works in the following way: .

2. The IR evaluate the control algorithm,

.

Memory: mation.

identifier.

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:

Filter:

Defines a method that should be exe-

All the values are filtered through an object of

the IWer

if exists.

the deadline, starts with

class.

Fuzzy-set: values corresponding with process ables are interpreted using this functions. Reference:

vari-

reference value of the process variable.

Initial-value:

4. When the reasoning process finish, the IR decides if the next level have to be fired considering the remaining

value in the object

initialization.

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.

3.2

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.

3.1

Object

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.

Name:

of an application

Temporal

Reasoning

Temporal class provides primitive methods for build relations between temporal objects. The relations l

Temporal_ObjectData-Base

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.

qualitative:

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

21

In this case the time

manager

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

However

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

3.3

a search in the temporal map have a greater cost and should be used

Smalltalk is not the environment real time systems.

more appropriate

The execution

that

code is worse than

other

for

generated

level of rule sets.

Guaranteed

Response

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

Time

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.

4.1

2. Scheduler:

selects

the best

deadline ecuted.

specifica.tion

3. Knowledge

Base:

task

with

respect

and the used resources

Rules

are defined

task not defined in Smalltalk, a class RTProcess as a subclass of the Smalltalk Process, as well as methods for its

to the

creation, deadline been defined:

to be ex-

at different

Smalltalk

the following

Smalltalk

code compilation

Tools facilitating classes.

through

the development

the Compiler

etc., have

by seven levels of

have been

defined

by means

of

classes:

Quisap subclass: #Event instaacsVariableIlames:

‘name value





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

table formed

Quisap subclass: fcondition inatancsVariabl&ames: ‘name initValue value mutex spscificatim

at ion

provided

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.

language

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.

assignement,

Process subclass: #RTProcess instanceVariableWames: ‘deadline’ classVariableflamea: I’ poolDictionaries: ”

levels

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.

Implement

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,

4

out:

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

quantitative

some drawbacks

facilities.

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

and scheduling

Requirement subclass: #Periodic instanceVz.riablaIiames: ‘periods periodefimer state ending mutex

an



Requiroasnt subclass: #Sporadic instancaVariablsliames: ‘went separation timeout state mutex currentEv*atValus timeoutException sepaxationlxception ’

class.

and use of the new

22

ther between

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,

4.3

Objects

The Smalltalk

definitions

interruptible

4.4

are:

lastvalue

shows

results

in Smalltalk.

through

a man-machine

The protocol

between

interface

the MM1

and

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

The system

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

and restartable.

dewritten

methods

in the

of

Object subclass:#TemporalFact 'realvaluefuzzyValuetime' instanceVariablelsames:

of these

Class

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'

A subset

to the

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'

reasoning.

The four

Object subclass:#RuleSet instaaceVa.riablellaes: 'name rules maximumTime'

Definition

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:

Regulator

and time points.

given by the filter associated

Object subclairs: #Regulator instaaceVaxiableXames: 'namemode inputs outputs ruleSets method inierence!&gj

class

mode, change conditions, collect events, etc. All the other classes provide methods to create, set values, get values, etc.

Temporal

or intervals

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

4.2

intervals

group works with trends object.

4.5

External Communication

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

5

Application

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-

l

Distributed

. The system l

can operate

High number of variables sures(9), temperatures(l4), oratory

23

process

analysis,

etc.

in several

different

situations.

(between 40 and 50): gas concentration(6),

preslab-

l

Large time delay in some variables dition.

l

Absence

l

Only few people operators).

of a model

due to the kiln con-

due to the process

know how the system

[BottiSO]

V. Botti, F. Barber, A. Crespo. Reason Maintenance in Real-Time Systems. IASTED Symposium. USA. December 1990. 78-82.

[Crespo89]

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.

[Dean871

Dean T. and McDermott D. Temporal Data Base Management Articial Intelligence, 32, 1987

[DodhidO]

R. Dodhiawala, N. Sridaran, and C. Pickering. A Real-Time Blackboard Architecture. Proceedings of IJCAI 1989.

complexity. works (expert

Conclusions and future work

6

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,

[Jaga

V. Jagannathsn,

[Stank901

[Zadeh88]

in

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

[Barber901

F. Barber, V. Botti, A. Crespo Temporal Ezpert System: Application to a Planning Environment. IASTED Symposium. USA. December 1990. 7882.

SE12,

of liming Trans. on

9, 1986

1988.

Toward a Blackboard Architecture for interactions with Dynamic Systems.. of IJCAI

1989.

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.

[Allen841

P. Raufles Real-Time Proceedings

to take in to the re-

parts

Engineering.

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,

F. Jahanian;

Software

matching.

. 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

Is-

[Hayes901

[J&86]

tem: . Efficient

EuroComp’90.

24

L. A. Zadeh Fuzzy Logic Computer, 4, April 1988.

Vol12,

Num

F’igore 1. GlobalArchitecture

Figure

3. Temporal

Objects

Structure

Regulator

Figure

2. Regulator

structure

Figure

25

4. Temporal

Class Hierarchy

Lihat lebih banyak...

Comentários

Copyright © 2017 DADOSPDF Inc.