Project On-line Deliverables: D06.2
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.
Table of Contents
The Knowledge Base syntax
Descriptors
Rules (backward chaining)
ACTIONS
- ACTION syntax
- Embedded hypertext
- Built-in functions
ActionRules (forward chaining)
Inference engines and strategy
Integration with Objects and Models
User Interface and Dialogue
Knowledge Engineering
A hybrid expert system, GIS and simulation modeling
for environmental and technological risk management
(on-line research paper).
|
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
Reading descriptor: Fire_Prob
Reading descriptor: Explosion_Prob
Reading descriptor: Max_Evap_Mass
.........
------------------------
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
|
