# Decision Support and Expert Systems

## Technical Report

 Programme name: ESPRIT Domain: HPCN Project acronym: HITERM Contract number: 22723 Project title: High-Performance Computing and Networking for Technological and Environmental Risk Management Project Deliverable: D06.2 Related Work Package: WP 6 Type of Deliverable: Technical Report Dissemination level: project internal Document Author: Kurt Fedra, ESS Edited by: Kurt Fedra, ESS Document Version: 1.2 First Availability: 1998 04 01 Last Modification: 1999 12 28

# EXECUTIVE SUMMARY

HITERM is designed to provide HPCN-based decision support for technological risk analysis, including both risk assessment and risk management aspects. It uses HPCN technologies to:
• generate decision relevant information fast and reliably
• and deliver it to the user fast and in a directly usable format.

Two different, but completely integrated Expert Systems are used in this implementation:

• a backwards chaining rule-based expert system linked to the simulation models, used for estimation and classification;
• a real-time forward chaining rule-based expert system providing guidance for the operator.

The Technical Report on DSS and Expert Systems describes the underlying KnowledgeBase syntax, and the corresponding inference strategies for backwards and forward chaining inference engines, respectively.

The main components of the hybrid expert systems are:

• Descriptors, defining the variables that are used in the inference; they are linked closely to HOT, the Hierarchical Object Tool, that provides the data for the instantiations of the Descriptors.
• Backward-chaining Rules used by the backward chaining part of the hybrid expert system;
• forward-chaining Rules, used by the forward chaining real-time part of the expert system;
• ACTIONS , the core element of the forward chaining expert system.

### The Knowledge Base syntax

#### ACTIONS

• ACTION syntax
• Embedded hypertext
• Built-in functions

The RTXPS
Slideshow
with tutorial
and draft
documentation

# The Knowledge Base syntax

The Knowledge Base of HITERM consists of a number of plain text files, located in the directory: ./data/KB (the default location) or any directory the system default *rtxps.kb.path: ./data/KB refers to.

The files that are loaded from this directory are enumerated in a configuration file KBconfig. An example of a KBconfig file is given below:

###########################################
####### Config file for RiskWare KB
#######
DESCRIPTOR-FILES
Descriptors
Descriptors.test
objects
ChemDBDescriptors
PlantDescriptors
BlastDescriptors
FloodDescriptors
EarthquakeDescriptors
END-DESCRIPTOR-FILES

RULE-FILES
Rules
BlastRules
END-RULE-FILES

RTRULE-FILES
Rules.test
END-RTRULE-FILES

ACTION-FILES
ACTIONS.test
END-ACTION-FILES

#TABLE-FILES
#Tables
#END-TABLE-FILES


Please note that the optional TABLE construct (a short notation for groups of Rules with two antecedent conditions, formatted as a decision table) is commented out in this example.

The files are loaded in the sequence referenced; in case of duplicate definitions, a later one will overload an earlier one. Diagnostics of error encountered in the initial parsing and loading of the Knowledge base are written to the file: ./logs/XPSlog-<user-name>. This is a scratch file that will be overwritten whenever the same user starts up the system again.

## Descriptors

The primary element of the Knowledge Base is the Descriptor. It is the basic variable used in the inference, and provides the link between the expert system and other components of the application such as the models or data bases. Descriptors are shared between the backward-chaining and the forward-chaining parts of the expert system.

Descriptors are characterized by:

• a name, possibly with a synonym; the latter can be used to provide a reliable connection to built-in functions or data base queries, while the primary (display) name can be translated into alternative languages.
• a type declaration; currently the types S for symbolic and variable for dynamically defined values (see below) are supported.
• a unit of measurement (primarily for display and editing purposes)
• a range of legal values
• a set of methods used to obtain a value for the Descriptor upon instantiation.
• context dependent definition of alternative properties
• layout and formatting information

The syntax of a Descriptor definition is as follows:

       DESCRIPTOR
<descriptor_name>
A  <alias_for_descriptor_name>
T  <descriptor_type>
U  <unit>
V  <range> / <range> / <range> / ...
R  <rule#> / <rule#> / ...
TB <table#> / <table#> / ...
F  <function>
IF <interface function>
G  <gis_function> <gis_overlay>
Q  <question>
MODEL
<model_name>
T <model_type>
I <input_descriptor> / <input_descriptor> /
O <output_descriptor> / <output_descriptor> /
ENDMODEL
ALTERNATIVE
<alternative>
<alternative defs>
ENDALTERNATIVE
LAYOUT
X <window x-coordinate>
Y <window y-coordinate>
WIDTH <window width>
HEIGHT <window height>
BGCOLOR <window bgcolor>
BORDER_WIDTH <window borderwidth>
BORDER_COLOR <window bordercolor>
FORMAT <value selector format_string>
DELTA <value selector increment>
HYPER_INFO <hyperinfo path>
HYPER_X <hyperinfo x-coordinate>
HYPER_Y <hyperinfo x-coordinate>
HYPER_WIDTH <hyperinfo width>
HYPER_HEIGHT <hyperinfo height>
HYPER_TWIDTH <hyperinfo backgroundwin width>
HYPER_THEIGHT <hyperinfo backgroundwin height>
HYPER_FGCOLOR <hyperinfo foreground color>
HYPER_BGCOLOR <hyperinfo background color>
HYPER_KEYCOLOR <hyperinfo keyword color>
HYPER_HIKEYCOLOR <hyperinfo highlight color>
HYPER_SWBORDERC <hyperinfo BORDER="1" color>
ENDLAYOUT
ENDDESCRIPTOR


For a complete definition of all terms and functions, please refer to the HITERM on-line Reference Manual.

##### Range of legal values

Descriptors of type S (symbolic or hybrid) have a pre-defined range of legal values. This range is defined by either

• a list of symbols (e.g., small, medium, large)
• a list of symbols with associated numerical values.

For the editing, both symbols or the associated numerical values can be used. A symbols is represented internally as either the (optionally defined) mean value of the associated range, or the entire range, depending on the type of operation (comparison, computation) that it is used in. A concrete example used for one of the Descriptors (Volume) is given below:

DESCRIPTOR
Volume
A VOLUME
T S
U m3
### applies to storage containers
V  very_small[   1.0,  5.0,    8.]
V  small     [   8.0, 10.0,  20.0]
V  medium    [  20.0, 50.0, 100,0]
V  large     [ 100.0, 500., 800.0]
V  very_large[ 800.0,1000.,2000.0]
Q What is the current volume of the container or vessel ?
ENDDESCRIPTOR


## Rules (backward chaining)

The Rules of the backward chaining expert system follow a first-order logic, and are encoded in near natural language, which makes them easy to code and understand.

The general syntax of a Rule is defined below:

IF   <condition>
THEN <action>
<condition> := <condition <logical operator> <condition>
:= descriptor <comparative operator> <operand>
:= descriptor <singular operator>
:= TRUE
<action>    := descriptor = <assigned value>
:= descriptor <meta operator> <constant>
<assigned value> := <operand> <arithmetic operator> <assigned v
alue>
:= descriptor
:= <constant>
<logical operator>     := AND | OR
<comparative operator> :=  < | > | <= | >= | == | !=
<singular operator>    := EXISTS | NOT_EXISTS
<arithmetic operator>  := [ | ] | * | / | + | -
<meta operator>        := INCREASES_BY | DECREASES_BY
:= BECOMES
<operand>   := descriptor
:= <constant>
<constant>  := string
:= number


Rules can result in the absolute assignment of descriptor values, their relative, incremental modification, or they can be used to control the inference strategy depending on context. Rules can also include simple formulas; more complex functions can be used through the generic model interface, see the description of the inference strategy below.

Examples of typical Rule constructs are given below:

RULE 2004
IF      emergency_type      == toxic_spill
AND     exposed_population  == few
AND     [  toxicty  == none
OR toxicity == moderate ]
THEN    Health_impact  =  no_effect
ENDRULE

RULE 3003
IF   vehicle_state == undamaged
THEN total_mass     = 0.05 * max_amount
ENDRULE


## ACTIONS

ACTIONs are the core components of the real-time forward chaining emergency management expert system; the decision support consists in a sequence of ACTIONS, offered to the operator, which include:

textual advise (in a hypertext format, see below) that includes instructions for ACTIONS to be performed by the operator.
These ACTIONS can be:
• requests for external actions: an example would be the instruction to place a phone call to some of the actors involved in emergency management; the hypertext system will display the request for ACTION< but also any auxiliary information (e.g., name and number of the person to be called) deemed useful for the operator;

• request for external information: the user has to answer specific questions, posed through the dialog of the backward chaining expert system, that also can provide assistance in finding and appropriate answer through its rule-based inference;

• requests for internal functions: the operator is requested to use some of the systems functions, e.g., run a simulation model, to obtain more information (e.g., a forecast) on the likeley evolution of the emergency;

• display of information: information that is deemed relevant for the operator is shown, for example, first aid instructions for a specific chemical once it has been identified as involved in the emergency.

ACTIONS are triggered by the Rules of the forward-chaining inference engine; their selection and sequence, but also contents of the hypertext displayed, are context sensitive and thus can be tailored to address a very wide range of possible situations flexibly.

ACTION can also include (and trigger) specific built-in functions can can be started automatically, or interactively, depending on the ACTION declaration.

In any case, the operator has the option to ignore or override any or all of the ACTIONs and their requests and suggestions.

ACTIONS as well as all their information input and output are time stamped and logged by the system for a post mortem analysis.

#### ACTION syntax

An ACTION declaration consists of a series of records between an ACTION and ENDACTION pair of delimiters; The internal ACTION name is followed by a longer, more explanatory display name, followed by the (optional) type declaration: ACTIONs of type Auto will execute their built-in functions automatically. ACTIONS (following the syntax of a Descriptor) also have a range of legal values that the Rules of the expert system can set and check.

The main hypertext block is indicated by a series of Q records (equivalent to the Question method block of the standard descriptor.

The hypertext block is followed by an optional list of built-in functions (between FUNCTION and ENDFUNCTION delimiter pairs.

An ACTION declaration example looks like:

ACTION
get_source
TI Define_the_Source
T Auto
V ready / pending / ignored / failed / done /
Q \vspace{20pt}
Q Please define the \font{bm} source type \font{nm} for this emergency:
Q \newline Does it involve \newline
Q \hspace{30pt} a \font{bb}fixed installation \font{nb}or  \newline
Q \hspace{30pt} a \font{bb}transportation accident \font{nb} ?
Q \bigpara
Q \picture{plant_sm.gif}
Q \picture{truck_sm.gif}
Q \picture{rail2_sm.gif}
FUNCTION
get_descriptor_value(source_type)
OUT: source_type /
LOG: source_type /
ENDFUNCTION
ENDACTION


#### Embedded hypertext

The hypertext of the ACTION (the Q records use the same syntax as normal hypertext in the ACA ToolKit functions. For a complete Description of the basic syntax, please refer to the on-line Manual pages for hypertext.

This includes a range of positioning commands (vspace, hspace), font and color setting (font, color), embedded imagery (pictureGIF format), hyperlinks through text strings (key or window, or images icon, and variable text (the current string or numerical value of a Descriptor: value{DESCRIPTOR(descriptor_name)}).

#### Built-in functions

ACTIONs have a range of built-in functions available. These are executed automatically if the ACTION type is set to Auto.

The syntax of a function is:

FUNCTION
function_name[(arguments)]
LOG: descriptor / descriptor /
OUT: descriptor
ENDFUNCTION

get_descriptor_value(substance_name)
This will pop-up an XPS Ask-box; depending on the type of the Descriptor : this can be:
• a symbolic selection (with out without rule-based inference)
• a hybrid selection (with or without rule-based inference)
• a string entry for Descriptors of the type: variable
display_chemical(substance_name)
displays a Chemical data base entry for the chemical name held by the Descriptor substance_name; please note that this descriptor is initialized at start-up from the file: ChemDB
display_msds(substance_name,file_number)
displays an individual hypertext file section from a chemical MSDS; the path is defined in the defaults: *msds.path: explain/Chemicals
display_object
displays a Risk Object from data/objects based on its name (TITLE field of the object declaration) based on the current value of the Descriptor risk_object Please note that this Descriptor is initialized at start-up in an analogous way to the Chemicals.
set_wind_dir
generates an editor tool with a compass to set the wind direction in an analog graphical way
start_assessment()
start the assessment branch from the RTXPS branch; the scenario data and available models are controlled by the scenario type (defined in ./data/objects/scenarios) where individual scenario templates are associated with the values of the Descriptor emergency_type in the file: CONFIG system(shell_command)
executes a system command with the argument: shell_command
shell(script)
executes a C-shell with the argument script; the path to script is defined by the defaults: *rtxps.bin.dir: ./bin
export(Descriptor)
writes the current value of Descriptor in a file with the name (first 14 characters) of the descriptor; the file is located in a subdirectory of the log directory ./logs defined by the default: *rtxps.fax.dir: fax preview(file)
generates a full screen hypertext version of the file: file the file is located in a subdirectory of the log directory ./logs defined by the default: *rtxps.fax.dir: fax and can be generated with any external script triggered by the function: shell(script) (see above).

## ActionRules (forward chaining)

The associated Rule would look like:
RULE RULE_ID
IF   accident_type == chemical_spill
AND  [Descriptor] [operator] [value]
OR   [Descriptor] [operator] [value]
AND  [ACTION]     [operator] [value]
OR   [ACTION]     [operator] [value]
THEN Some_Action => ready
ENDRULE


## Inference engines and strategy

The hybrid expert systems combines two basically different inference strategies:

• forward chaining: here the Rule set is processed in sequence, the first Rule that fulfills all antecedents conditions will fire;
• backward chaining: starting from a target Descriptor, the Rules are recursively examined in a dynamic tree structure designed to test all antecedent conditions efficiently.

## Integration with Objects and Models

Objects and Models (scenarios) include their data (attributes, input, output) as Descriptors. These Descriptors can be edited or updated through Rules.

In the other direction, the Knowledge Base (the current set of Descriptors and associated Rules)

## User Interface and Dialogue

#### Backward chaining

The primary interface of the backward chaining expert system is the dialog box or AskBox. The configuration of the AskBox depends on the set of METHODS declared for a Descriptor. The configuration options include:

• editing only, symbolic Descriptor (list of symbols only)
• editing only, hybrid Descriptor (list of symbols and numerical slider)
• editing only, variable Descriptor (text string entry)
• editing and rule-based inference (symbolic and hybrid Descriptors)
• editing, rule based inference, external model interface (symbolic and hybrid Descriptors)
Additional display options include:
• Rule Trace (displaying Rules before they are evaluated;
• WHY explanation function: the steps leading to a given results can be retracted with the display of Rules and Descriptors;
• KB Browser: display of Rule sets and Descriptors for a specific target Descriptor.

#### Forward chaining

The user interface consists of three main element:
• the ACTION DIALOGUE box with its four response buttons:
• DO IT (if active, this will satisfy the request by triggering one of the built in functions (like starting the expert system or a model) to obtain the requested information;
• PENDING (refers a task for later execution)
• IGNORE (actively eliminates or skips a task),
• DONE (confirms the successful completion of an ACTION REQUEST.
• the EMERGENCY PARAMETERS listing that provide the evolving summary description of the emergency; please note that the MAP WINDOW will display related (geo)graphical information);
• the ACTIONS LOG that records each status change of an ACTION REQUEST with its time step in a scrolling window.

## Knowledge Engineering

The second major interface of the Expert system is the interface to the knowledeg engineer for the development of the systems knowledge base.

Due to the complexity of the integrated forward- and backward-chaining systems, and their continuing development, no final knowledge engineering tools (specific editor for Rules, Descriptors, and ACTIONs) have yet been developed that can be used directly by an end user. This, however, fits well into the philosophy of offering services including adaptation of the Knowledge Base as part of the system exploitation.

The development of the knowledge base is a multi-phase process with feedback loops:

• definition of the basic logic, sequence of tasks (ACTIONS), definition of conditions, interdependencies (Rules) in an informal way, see, for example, the initial notes for the Swiss case study (Reusstal) as an example;

• in a subsequent stage, this informal description is converted to a SCRIPT, a formal pseudo-code language that defines the logic usung actual ACTIONs and Descriptor names;

########################################################
###
### SCRIPT    control structure documentation for RTXPS
###
###           this is intended as a possible control
###           language, alternative to the purely
###           rule-driven implementation.
###
#########################################################
BEGINSCRIPT: SCRIPT.sigric

ACTION(Zero_Action)
ACTION(ask_type)          #obtains the emergency type
IF DESCRIPTOR(emergency_type) == toxic_spill
THEN ACTION(get_source)   # identify source (fixed, rail, road)

##### this block covers all other emgerncy types, for which no
##### ACTIONS and Rules are defined at present.
ELSE IF DESCRIPTOR(emergency_type) == explosion
THEN
EXECUTE SCRIPT: SCRIPT.blast
ACTION(No_Data)
ACTION(Last_Action)
ENDSCRIPT.sigric
ELSE IF DESCRIPTOR(emergency_type) == chemical_fire)
THEN
ACTION(No_Data)
ACTION(Last_Action)
ENDSCRIPT.sigric
ELSE IF DESCRIPTOR(emergency_type) == forest_fire)
THEN
ACTION(No_Data)
ACTION(Last_Action)
ENDSCRIPT.sigric
ENDIF
####### toxic_spill, continued

###### this construct works like a SUBROUTINE
###### the SCRIPT is supposed to sit in a separate file in KB

IF DESCRIPTOR(emergency_type) == toxic_spill
THEN EXECUTE SCRIPT: SCRIPT.toxic
ENDIF

ACTION(Last_Action)
ENDSCRIPT.sigric
#########################################################


• The SCRIPT (and editor for the SCRIPT development is under development) is then converted to its final implementation in terms of the Knowldge Base files ACTION, Rules (and Tables), and Descriptors. This is done by editing the three respective files simultaneously with a standard text editor.

• As a final stage, the system then performs extensive syntax check of the Knowledge Base when it is loaded, and generates a complete log of both the loading sequence and the actual operation of the Expert system in the log file: ./logs/XPSlog-username:

Now reading Rule 0 (int. id 0)
Now reading Rule 11 (int. id 1)
Now reading Rule 1 (int. id 2)
Now reading Rule 2 (int. id 3)
Now reading Rule 21 (int. id 4)
Now reading Rule 3 (int. id 5)
Now reading Rule 4 (int. id 6)
Now reading Rule 5 (int. id 7)
Now reading Rule 6 (int. id 8)
Now reading Rule 7 (int. id 9)
Now reading Rule 1000 (int. id 10)
Now reading Rule 1001 (int. id 11)
Now reading Rule 10011 (int. id 12)
Now reading Rule 10012 (int. id 13)
Now reading Rule 10013 (int. id 14)
Now reading Rule 10020 (int. id 15)
Now reading Rule 10030 (int. id 16)
Now reading Rule 1004 (int. id 17)
Now reading Rule 1005 (int. id 18)
Now reading Rule 1006 (int. id 19)
Now reading Rule 1010 (int. id 20)
Now reading Rule 9999 (int. id 21)
........
DESCRIPTORS: ./data/KB/Descriptors
.........
------------------------
rt_engine() started ....
------------------------
rt_condition(): checking rule 2
Condition: DESCRIPTOR(emergency_type) != rail_accident not OK
rt_condition(): checking rule 21
Condition: ACTION(abort_train) == done not OK
rt_condition(): checking rule 3
Firing Rule: 3 ACTION(get_location) => ready
Action get_location set to ready
=> Action: get_location
AutoStarting Function: get_descriptor_value(accident_location)
Calling Function: get_descriptor_value(accident_location)
accident_location = Altdorf
Action get_location set to done