REX: An Object Oriented Asynchronous Real Time Expert System ...

REX: An Object Oriented Asynchronous Real Time Expert System Shell for Aerospace Applications B.E. Prasad, T.Siva Perraju, G.Uma, P. Umarani Arti cial Intelligence Laboratory, Department of Computer and Information Sciences, University of Hyderabad, Hyderabad 500 134 INDIA e-mail:[email protected] July 31, 1996

1 Introduction An aerospace vehicle is a tightly coupled complex physical system. Ground control operations during its launch involve examining continually arriving system data, taking decisions and initiating actions to eect a successful launch. Software embedded in ground control computers presents raw system data to the operator and triggers alarms when xed thresholds are crossed. Due to the tight coupling of the subsystems, if alarms occur they occur in large numbers. Operators overwhelmed by the information deluge, neglect relevant information and react slowly. Situations like this tend to be perfect settings for panic reaction by operator and eventual failures. Knowledge based systems are capable of digesting the glut of information, and can help operators arrive at correct decisions - a prerequisite for reliable fail safe launch. But they cannot be deployed in their current form. The conventional expert system shells fail to meet the actual work loads in real time environments. Their inferencing speeds are slow by several orders of magnitude. The unbounded nature of the inference process coupled with its uninterruptability preclude guaranteed response within reasonable time limits. Current intelligent system paradigms need to be augmented to meet this requirement. The system should assimilate the data and asynchronous events, and present the operator its reasoned opinion. The need to react to asynchronous events mandates us to build a reactive interruptible intelligent system. Expert systems with higher speeds of execution are being designed to address the response time requirements of real time domains [1]. But speed alone is not sucient, and the way the system handles time and temporal events, characterises its real time behaviour. Current expert system shells do not provide facilities for representation of time and temporal data, encoding of temporal knowledge and management of temporal reasoning. A real time expert system shell needs to unite all these aspects through the mechanisms it adopts. Lockheed Expert System Shell (LES) [2] provides for representation and storage of temporally varying data. It facilitates integration of this

representation into the inference process. However, no facility for encoding of knowledge about temporal events like delays, and relationships among temporal events is provided. We propose two rule types viz. Clock synchronised and Spanning rules for encoding temporal knowledge. The match and ring of these rules is handled in a manner dierent from that of traditional rules. This semantically rich temporal representation facility for both data and knowledge is the distinguishing feature of REX. In object oriented expert system shells, rules operate on top of objects and are treated dierently from objects. In REX, rules are objects themselves and are stored, retrieved and managed in a way identical to data objects. Simultaneous occurrence of disjoint events is another key characteristic of real time domains. Expert systems with the concept of single state change in an inference cycle cannot attend this problem. A multiple rule ring model is adopted in REX to handle disjoint simultaneous events.

2 Design Philosophy The objective of the proposed expert system shell is to enable development of expert system which can be embedded in the present ground control systems, accept sensor data and reason using the same.

2.1 Requirements Before we took up the design of the shell, we identi ed the following essential features of the physical system that aect the design [3]. They are

 sporadic events: events like alarms which occur sporadically and cannot be anticipated.  continuous operation: the ground control operation is continuous and is spread over hours or even days depending on the complexity of the launch vehicle.

 delayed feedbacks and transients: the very physical nature of the systems inherently introduces delays in the feedback networks and also transients in the system as a whole.

 multiple and propagated faults: the tight coupling of the dierent subsystems causes seem-

ingly independent faults to occur almost simultaneously and also causes fault propagation from one subsystem to another.

 inaccurate and incomplete data due to sensor failures: the sensor being yet another physical

system in the loop, is prone to its own degradation and failures,which re ects in the quality of data acquired. This is normally alleviated by employing redundant sensors.

 operator control: the launch vehicle being a complex tightly coupled system, operators manning these stations would like to retain manual control to respond to wholly unanticipated emergencies.

The expert system in order to meet the above demands should possess the following capabilities.

 asynchronous event handling: system should accept data when it arrives rather than expecting data at designated times

 reactive response behaviour: system should initiate reasoning in response to changes in the environment

 guaranteed reactive and response time: as the system is working in a dynamic environment, it should be able to provide response to events in the environment within reasonable time limits and ensure that the expert system is in step with the changes in the environment.

 temporal data and knowledge representation: expert system should be capable of explicitly representing temporal data and knowledge

 handle multiple and propagated faults: expert system should reason about simultaneously

occurring multiple faults and respond to each of the faults while recognising propagated faults.

To facilitate the development of this kind of expert systems,the core requirements of the expert system shell are facilities to represent time, temporal data and knowledge, interruptible inference engine and bounded inference process.

2.2 REX Architecture REX is an object oriented real time expert system shell with an asynchronous forward chaining inference engine [4]. Some of the important features which make REX a powerful tool for the class of applications like ground control are mechanisms for handling external input, asynchronous rule ring, polynomially bound match, ability to focus on important system events, object oriented store for data and rules, and semantics of representation suitable for easy veri cation and maintenance [4, 5]. A knowledge based system developed in REX can consist of multiple number of expert systems. An expert system in REX is called an agent. The architecture of a REX agent is shown in Figure 1. A REX agent consists of an object store, a rule base, a work area, an asynchronous inference engine and an external input update task. The object store is a repository for storing system facts and beliefs. It has the necessary facilities for storage and retrieval of time varying data. The rule base is an object oriented store for the domain knowledge. The asynchronous engine provides the necessary intelligence capabilities to meet the domain requirements. The external input update task provides the interface to the environment. Execution of a REX agent is initiated by posting default facts and beliefs about the environment from the object store to the work area. The default facts and beliefs contain information such as system con guration, default expected values of system sensor data etc. Reasoning is initiated when the external input update task posts sensor data on the work area. The inference engine is not a single monolithic process, rather it is composed of independent threads viz. match, interference analysis and multiple rule ring threads.The inference engine initiates the match thread when triggered by updates to the work area. The match thread matches

 

?


 

Object Box

6

'

?


Rule Box

?

#

Match

$

! > "  ' ? & %  $  6  Interference  $ ?  Analysis & % - Work Area   @  @@R % iPPP #+ . . . . # P Rule P Rule

Knowledge Manager

'

External Input Update &

Firing

"

!

Firing

"

!

Figure 1: Architecture of REX agent the updates against the antecedents of the rules and produces a set of rules with matching antecedents. This set is called matched rule set or MRS. To speed up inference, match is an incremental process, i.e. instead of matching all the WME's with the rules, only those WME's that have changed are matched. The inference engine of REX also diers from other engines in its rule selection and ring strategy. The data in the work area represents the status of the process system and its integrity is of paramount importance. Therefore, the ring of multiple rules, must not lead to loss of integrity. To achieve these twin requirements of speed and integrity maintenance, REX selects a maximal subset of MRS called the eligible rule set (ERS) to be red asynchronously after performing interference analysis. The inference engine then creates threads to execute the rule rings asynchronously. This property of asynchronous multiple rule ring allows REX agents to respond to simultaneously occurring multiple faults or events in the environment. External input is obtained by preempting any of the running inference threads. The external input updates to work area are not allowed when match is in progress. This is because match task requires a static snapshot of the work area. In this case the external input update task stores input in a buer and updates work area soon after the match thread runs to completion. Combinatorial match tasks are the norm in expert systems. However in REX, the combinatorics associated with match are eliminated and match completes in bounded time as will be explained later. This allows synchronisation of external input update task without loosing the reactive nature of REX agents. The bounded nature of the match task coupled with the asynchronous multiple rule ring make REX an ideal environment for developing reactive expert systems.

3 Data and Knowledge Subsystem The concept of building system models in diagnosis is an accepted engineering practice. Models readily capture the abstractions, components, hierarchies and their interactions in a complex physical system. Further a single model cannot capture all the features of a physical system. It is common to employ more than one model to study a system in all its dimensions. In REX we provide two archetypes to model the domain knowledge viz. object representation and rule representation. The former is intended to model the static and structural aspects of the physical system, while the latter is employed to model the dynamic interactions and dependencies of the system.

3.1 Object Structure and Management An entity in the external world is best described as a collection of its properties (both static and dynamic). Object oriented representation oers facilities to capture these properties in an elegant manner which is not the case with contemporary models like relational data model. Object oriented model oers two facilities not available in other models viz. composite attributes and methods. Composite attributes themselves being objects enable us to capture system subsystem relationships (like has-part). Methods oer ways of capturing dynamic behaviour of the modelled entity. Data obtained in real time systems possess two temporal properties which distinguish them from static data obtained in other application domains. They are: time at which the data are obtained and timeout i.e. the life span of the data. Every data value in the environment has a birth and a life span. For example in a dynamically changing system the fact that a certain pressure is 300 Ksc has little or no meaning. But the fact that the pressure at time 500 sec is 300 Ksc is meaningful and has immense value to the agent. Timeout of a data value represents the useful life span of the data reading obtained. For example if the timeout (i.e. life span) of the pressure is given as 10 sec, it means that the pressure value 300 Ksc has no meaning after 510 sec unless it is updated by the sensor. So it is essential to represent the time of obtaining a data value in addition to the value. Thus data in a real time system is a triple , where v is the data value and t is the time at which the value is obtained and to is the timeout of the data item. Object oriented models do not provide for explicit representation of temporal behaviour of data (like time out). We augmented the object oriented model by de ning a timeout property for every attribute of the object. All object classes in REX are derived from the base class OBJECT. The base class OBJECT provides the clock service which is so essential to the real time system. In addition, OBJECT provides generic function implementation for access to members of the classes. The structure of OBJECT is class OBJECT f time;

g

An object class is created in the REX object base by a call to create(classname). The attributes

of the class are de ned by repeated calls to addattr(classname, attrname,type, timeout). If we de ne a class named Pressure with attributes line pressure and accumulator pressure whose timeout are 2 sec and 4 sec respectively. The class de nition would be class Pressure f line pressure; time@line pressure; accumulator pressure; time@accumulator pressure;

g

The addattr calls de nes the timeout of the attributes as private class members invisible to the user. Two new parameters are created by REX when the class Pressure is de ned viz. time@line pressure and time@accumulator pressure. The parameter time@line pressure indicates the valid life time of the attribute line pressure. It is the time after which the value of line pressure is no longer valid. Another policy adopted in REX which is similar to many OODB implementations is that any update to the attributes results in the creation of a new instance. All references to objects of a given class refer to the latest instance created unless explicitly speci ed otherwise. This is because in a real time reasoning system a new data value from the sensor invalidates the old data value. Hence references to the latest data values alone suce. In REX object base the latest instance of the class, contains the latest available values of the class variables. However for calculating trends, earlier values are also available. The update behaviour of objects in REX is brought out in the following example. Let there be an object of class Pressure with object-id 1 at time 0. If the attribute line pressure is updated time 1 to value 450 a new object with a dierent object identi er 2 is created. The two objects would be as shown below. object-id :1 f time : 0 line pressure : 200 time@line pressure : 2 accumulator pressure : 5000 time@accumulator pressure : 4

g

object-id :2 f time : 1 line pressure : 450 time@line pressure : 3 accumulator pressure : 5000 time@accumulator pressure : 4

g

It is observed that the parameter time@accumulator pressure remains unchanged since the value of accumulator pressure is obtained at time t0. Any references to the object of class Pressure are directed to the object with object-id 2. Whenever the value for accumulator pressure

is requested the value 5000 is returned only if

currenttime  Pressure:time@accumulator pressure: In this way retrieval is allowed only for attributes which still have a valid life span. The REX knowledge manager also manages the secondary storage facility. A xed number of instances of all classes are maintained in the main memory for access by rules. If instances beyond the limit are created the manager shifts old instances to secondary store retaining new instances in main memory. Old object instances are temporarily brought to main memory if required for trend calculations. Lockheed Expert system shell (LES) [2] provides for storage of temporally varying attribute values within its frame structure. However LES provides for storing a xed number of data values in contrast to REX.

3.2 Augmented Rule Structure and Taxonomy Real time knowledge based process monitoring system tracks process variables intelligently so as to detect faults and perform malfunction diagnosis. Unfortunately a majority of the process applications are characterised by large data sets and equally large malfunction hypotheses space. Ground control of launch operations is an example of one such application. Ground control operators are usually provided with operator manuals which de ne alarms and procedures to isolate and repair faults causing the faults. These manuals are organised on the basis of symptom - cause relationships. The procedures in the operator's manuals represent the compiled knowledge about the system behaviour. Real time knowledge based systems should make use of this compiled knowledge. Structured representation of knowledge become sine qua non for ecient search in large domain knowledge space. Some of the well known structured techniques are frames, rules, causal models and case based indexing systems. Rules oer a easy and ecient way of representing symptom-cause relationships and associated compiled knowledge. Since REX is a shell intended for real time process monitoring applications, rules are chosen as the basic knowledge representation formalism. However as stated earlier, current rule systems lack facilities to represent the semantics of the application and temporal information. We augment the rule structure to represent knowledge about temporal properties and behaviour. Further in consonance with the aim of building an object oriented knowledge based system and treat all entities as objects, we treat rules also as objects derived from the base class OBJECT with a specialisation hierarchy. There are three types of rules in REX. They are Autonomous rules, Clock synchronised rules and Spanning rules. The clock synchronised rules and spanning rules are specialisations of the autonomous rules. Spanning rules are further categorised as Event spanning rules and Time spanning rules. Autonomous rules are generic rules in REX. All other rule types are derived from this base rule type. Firing of autonomous rules is unattached to any trigger events or enabling conditions, hence the name. If the work area contents match the premises of autonomous rule, the rule is scheduled for ring. The structure of an Autonomous rule is

Priority Premises Actions Hold

The priority of the rule indicates the importance of the rule in the total rule set. This information is used for scheduling rule rings. The premises is a conjunction of a set of conditions. The satisfaction of the premises makes the rule eligible for ring. The actions are the consequents of the rule. Actions assert new beliefs on the system state and these assertions are entered in the work area. For example, Rule A1: Premise: Pressure.accumulator pressure > 1000 Ksc Action: Hydraulic system.status = OK. Real time monitoring systems track the process variables to ascertain the normal behaviour of the system under investigation and carry out fault detection by dierentiating between normal and abnormal conditions. The Hold slot in the rule structure asserts a fault state of the system under investigation. In REX, Hold is an action which asserts a system malfunction and could possibly terminate a reasoning thread. Rules with non empty Hold slots have empty Action slots and vice-versa. An example of a rule with a non empty Hold slot is Rule A2: Premise: Pressure.line pressure < 100 Ksc and Yaw fb > 15o Hold: [message System controllability is negative.] Physical systems do not react instantaneously to inputs but do so with a certain time lag. For example in an aerospace vehicle the reaction of the ns to the auto pilot control is not immediate but occurs after a de nite time lag. The auto pilot running the vehicle, will expect the ns to follow the commands with this time lag. If the expected action of the ns fails to take place, a warning is signalled to the ground control immediately for possible remedial action. Systems monitoring such physical processes should conduct their investigation of the process by anticipating these time delays. Autonomous rules clearly do not cater to these requirements. We propose a specialisation of autonomous rules called clock synchronised rules to model physical phenomena like the example above. The structure of the clock synchronised rules is Event Time limit Time operator Priority Premises Actions Hold Clock synchronised rules have three attributes in addition to the attributes inherited from the Autonomous rule type. They are Event, Time limit and Time operator. The Event is a trigger condition which enables the match or ring of the rule based on the value of Time operator. The Time operator can take as values either AFTER or BEFORE.

Semantics of AFTER operator Time Match Conditions Met Not met Delay Fire Ignore over rule Delay Don't not care over Table 1: Semantics of AFTER operator in Clock Synchronised Rules Semantics of BEFORE operator Time Match Conditions Met Not met Delay Don't over care Delay Fire Try not rule again over Table 2: Semantics of the BEFORE operator in Clock Synchronised Rules If the operator is AFTER, the match of the premises is initiated after an amount of time equal to Time limit has elapsed from the occurrence of the Event. The semantics of the AFTER operator are summarized in the Table 1. The type of knowledge that can be represented with a clock synchronised rule using the AFTER operator is given below. Knowledge : If the pressure valve is opened and even after 5 seconds the pressure is less than 40 Ksc then it can be concluded that the uid level in the tank is low and pump motor should be switched on. Rule: Event: Hydraulic system.Pressure valve = OPEN Time limit: 5 seconds Time operator: "AFTER" Premise: Hydraulic system.Pressure  40 Ksc Hold: [message " fluid level low - switch pump motor] In physical systems, some events are expected to happen at a given time and at a given pace. For example if an auto pilot issues a yaw command, the vehicle is expected to achieve the desired turn at a desired rate and by the end of a desired period. If the yaw rate is achieved too quickly it may induce undesirable body accelerations. These situations are modelled using the BEFORE operator. The semantics of the BEFORE operator are summarized in Table 2. Consider the following example about an aerospace vehicle's responses to it's auto pilot's commands.

Knowledge: If the auto pilot has issued a Yaw command, the Yaw feedback is to become equal to the Yaw command 2 seconds after the command is issued but before 6 seconds. Rules: C1:

Event: Yaw.cmd == +10o Time limit: 2 seconds Time operator: "BEFORE" Premise: Yaw.fb == -10o Action: Yaw.Controlstatus

= Fast

C2:

Event: Yaw.cmd == +10o Time limit: 6 seconds Time operator: "AFTER" Premise: Yaw.fb 6= ?10o Hold: Yaw.Controlstatus

= Lag

Early warnings based on historical trends are a desirable feature in reactive systems as preventive action can be contemplated before the alarm actually occurs. This requires the study of historical data before issuing warnings. Knowledge for this kind of reasoning is captured using Spanning rules in REX. Spanning rules are derived from Autonomous rules and their structure is shown below. From time Spanning premises Priority Premises Actions Hold

The additional attributes of Spanning rules are From time and Spanning premises. Spanning premises are conditions ranging over data history to calculate trends like increase, decrease and rate of change. The From time parameter indicates the time over which parameter history is to be obtained to calculate the trends. Spanning rules can be either triggered by events occurring in the system under investigation or periodically. Two specialisations of spanning rules are derived viz. event spanning rules and time spanning rules. Event spanning rules are triggered by an event. The structure of this rule is

From time Event Spanning premises Priority Premises Actions Hold

The following knowledge can be represented by an Event Spanning rule. Knowledge: if hydraulic oil level is below 3000 litres and rate of decrease of pressure is more than 10% in the last 100 seconds then a leak in the pipe system is suspected. S1:

Event: Hydraulic system.OilLevel  3000 l From Time : 100 seconds Spanning Premise: Decrease(Hydraulic system.Pressure) > 10% Hold: [message "leak in pipe system suspected, check up"]

Some important parameters of physical systems are of critical importance and their values are monitored periodically to observe trends and make conclusions about the status of the physical system. Such situations are modelled by a Time spanning rule. The Time spanning rule is derived from the Spanning rule class. The structure of these rules is From time Cycle time Spanning premises Priority Premises Actions Hold

The attribute Cycle time speci es the time period in which the rule should be red once. This rule is used for periodic monitoring as in the example below. Knowledge: If the bearing temperature of the reaction wheels has increased by 10% in the last 5 seconds then it can be concluded that the bearing lubrication is low. S2:

Cycle time: 5 seconds From Time : 10 seconds Spanning Premise: Increase(Bearing. temperature) > 10% Hold: [message "bearing lubrication low, check up"]

The four dierent rule types de ned above enable modelling of knowledge and events peculiar to real time monitoring applications like ground control. The dierent rule types in REX are de ned as classes with the taxonomy in Figure 2. Rules in the REX agent's rule base are

instances of one of the rule classes. This conceptual view of the rule taxonomy is carried to the storage level by storing rules in an object base similar to object store using the same access methods provided by the knowledge manager. Rules in REX are thus treated as rst class objects with all properties of independent objects.

3.3 Knowledge Base Veri cation The veri cation of rule bases is classi ed into two categories. They are intra rule and inter rule veri cations. In intra rule veri cation, a given rule is veri ed for completeness and freedom from contradictions. A rule in the knowledge base is de ned to be Complete if all slots in the rule objects are lled with legal entries. An autonomous rule should posses legal non empty premise slot and either a non empty action or hold slots. Autonomous rule which possesses non empty action and hold slots is declared invalid. A spanning rule should have non empty spanning premise and from time slots. The premises and actions of any rule should be free from contradictions. The contradictions fall into two categories: value contradicting and operator contradicting. Value contradicting premises have identical attributes and relation operators and dissimilar values. Operator contradicting premises possess identical attribute value pairs but have complementary operators. The complementary operator table is given below == ! =

> < >=