RiskWare  On-line Reference Manual

Release Level 1.9
Release Date 2000 06

Revision Level 1.1

The Real-time Expert System

This constitutes the top layer of control, on top of the current simulation model layer (representing primarily the planning component) that drives the real-time Accident Management part in RiskWare with a real-time, forward-chaining expert system (RTXPS) as the driving engine.

The implementation in RiskWare is based on a set of ACTIONS similar to XPS Descriptors and forward chaining Rules.

ACTIONS are triggered by the Rules using the status of other ACTIONS and EMERGENCY PARAMETERS, data including externally obtained information and Descriptors, which can be derived through model runs, the expert system, or from data base queries. The EMERGENCY PARAMETERS define dynamic context describing the evolving emergency.

An ACTION can have four different status values:

  • ready
  • pending
  • ignored
  • failed
  • done

For the status pending a timer interval (to avoid being asked about a pending request in too short intervals) can be set in the ACTION declaration.;

An ACTION declaration looks like:

A alias_name
T Auto
V  ready / pending / ignored / done /
P 180   # timer set to 180 seconds
Q For a \value{accident_type} you have 
Q to specify the total mass or spill volume involved;
Q you can enter this directly, or refer to the
Q plant and container database of \value{accident_site}:
F get_descriptor_value(spill_volume)
OUT: spill_volume
LOG: spill_volume

ACTION declarations are stored in the file Actions in the systems KnowledgeBase (by default located in the directory $datapath/KB

The declaration of an ACTION object is blocked between the ACTION and ENDACTION keywords.

The ACTION keyword record is followed by the unique name of the ACTION (Some_Actions), which may be followed by an optional alias after the A keyword.

The T keyword introduces a type declaration: types are Interative (the default) and Automatic. In the Interactive Case, the ACTION requires the user to start and confirm its execution explicitly; in the Automatic case, the required Function is triggered directly, its completion is equvalent with pressing the DONE button.

The V keyword introduces the array of legal values or states.

P denotes the timer for pending requests in seconds.

Q recods contain the textual (hypertext syntax) part of the ACTIONS REQUEST. Please note that the

function can be embedded in the text of the ACTION REQUEST. This will automatically insert the current value of the respective Descriptor in the text.

The block between FUNCTION and ENDFUNCTION enumerate functions that the action will trigger automatically, and in sequence, when the user preses the DO IT button the ACTION REQUEST DIALOGUE window, or if the ACTION Type is Automatic. A FUNCTION declaration includes the following records:

  • F   the function name
  • IN:   a list of Descriptors the function requires as input variables;
  • OUT:   a list of Descriptors the function sets or returns;
  • LOG:   a (subset) list of OUT: descriptors the Action will log as Emergency Parameters.

The associated Rule would look like:

IF   DESCRIPTOR(accident_type) == chemical_spill
AND  [Descriptor] [operator] [value]
OR   [Descriptor] [operator] [value]
AND  [ACTION]     [operator] [value]
OR   [ACTION]     [operator] [value]
THEN Some_Action => ready

where depending on the value of some descriptors AND/OR the status of some ACTIONs, the status of the ACTION Some_Action is set to ready and thus displayed to the operator.

To simplify parsing and improve readbility of RULES, the syntax uses DESCRIPTOR(Descriptor_Name) and ACTION(Action_Name) to identify the type of variable referred to.

The general syntax of ACTIONs and Rules is similar to the Rules and Descriptors of the Knowledge Base and inference engine in the embedded XPS (backward-chaining) expert system. The main difference is that the THEN part of the Rule can only trigger (SET TO ready) an ACTION and NOT assign values.


The operating sequence is started by entering the module, where an ACTION Zero_Action (its default status is ready is displayed; it requests the user to press a START button that starts and possibly sets, the Accident-Time clock, running in tandem with the real time clock.

Marking the Zero_Action as DONE will trigger the first round of Rule pre-processing (selection) and forward chaining through the rule-base;

THEN first_action => ready
first_action could then for example:
  • require the operator to call a specific phone number,
  • press the red alarm button, or
  • define the type of the emergency.

Once the user has completed the ACTION REQUEST, and verified its results, he marks it as DONE in the ACTION DIALOGUE, which will also mark all Rules that can trigger the ACTION as done.

The next pre-processor run will then select only the subset of Rules that are active (excluding any Rules referring to ACTIONS marked done or ignored.

A special case is the ACTION status of pending, where the time-stamp set when PENDING was selected by a user in the ACTION DIALOGUE must be compared before including or excluding a Rule in the current run.

An example for the usefulness for this feature would be a phone call that should be made, but can not because of a busy connection - it can be deferred without interrupting the continuing operation of the system. The period for which this ACTION should be deferred until the next trial is defined in the ACTION declaration in the P field in seconds.

All status changes of ACTIONSs are entered in an ACTION LOG together with the time stamp of their status change to provide a complete log of the sequential operations of the system.

ACTIONS may request activities of the operator that may or may not involve the system directly. They may include:

  • external activities may, for example, communication by phone or fax with other institutions etc. or obtaining relevant information (EMERGENCY PARAMETERS) from external sources;
  • internal activities will involve the use of the system such as entering information or using specific tools such as models to determine more EMERGENCY PARAMETERS.
For internal activities the ACTION DIALOGUE may offer the option to DO IT; this button will then trigger the appropriate function with the necessary parameters automatically, for example, opening an editor dialogue box to enter a value (an EMERGENCY PARAMETER, starting an inference chain (backward chaining ...) to estimate such a value, or start a model.

Upon successful return from this operation, the user then marks the ACTION as done, which will trigger a new run of Rule filtering and evaluation, leading the user through the successive steps of the emergency management procedure as defined by the rules, and influenced by the changing context of the EMERGENCY PARAMETERS.

The procedure ends when either:

  • LAST_ACTION is triggered by a Rule, (this would require the operator to verify return to normal conditions) or
  • when there are no more applicable ACTIONS that are ready.

At this point, the ACTION LOG provides a complete and chronological record of the entire sequence of events for printing and a post-mortem analysis.

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.

© Copyright 1995-2019 by:   ESS   Environmental Software and Services GmbH AUSTRIA | print page