Project On-line Deliverables: D07.0

Systems Architecture

Systems Architecture 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:	D07.0
Related Work Package:	WP 7
Type of Deliverable:	Technical Report
Dissemination level:	project internal
Document Author:	Kurt Fedra, ESS
Edited by:	Kurt Fedra, ESS
Document Version:	1.4
First Availability:	1998 01 10
Last Modification:	1999 12 31

EXECUTIVE SUMMARY

The HITERM system architecture is presented at two levels:

• a conceptual level, that describes the logical relationship of the elements (objects) used to represent, and manage, an emergency situation as a decision support system; this is based on an object-oriented design;

• a physical implementation level, that provides the actual operational hardware and software environment for running the decision support system; this is based on a client-server architecture that includes high-performance computing elements, remote data acquisition, and wireless mobile clients.

The logical communication architecture and protocol between the system's components is based on TCP/IP and http. The high-level communication structure can then be implemented on a wide variety of physical and logical communication infrastructures, including the support of mobile, wireless clients and a range of LAN and WAN technologies. The technical details and specifications of the communication aspects are covered in Deliverable D03, Communication Architecture.

Table of Contents

Systems Architecture

The Conceptual Level

• The DSS framework
• Modes of Operation: Assessment vs Management
• Data Structures: the Object Classes
  • Emergency Scenarios
  • Risk Objects plants, regional elements, resource objects
  • RTXPS objects: ACTIONS, Descriptors, Rules
  • Methods of instantiations: external information sources, rule-based inference, simulation modeling

The Physical Implementation

• The Main HITERM server
• HPCN Resources: Compute Servers
• HPCN Resources: Real-time data acquisition
• Display Clients

Implementation Considerations

Systems Architecture

The HITERM system architecture is presented at two levels:

• The conceptual level, that describes the logical relationship of the elements (objects) used to represent, and manage, an emergency situation as a decision support system; this is based on an object-oriented design.

  The object-oriented design (OOD) approach followed is based primarily, but not exclusively, on Booch 1991 and Rumbaugh OMT (1991). The design methodology is both relevant for the system architecture as well as for the development and implementation strategy, i.e., rapid prototyping.

• The physical implementation level, that provides the actual operational hardware and software environment for running the decision support system; this is based on a client-server architecture that includes high-performance computing elements, remote data acquisition, and wireless mobile clients.

  The implementation uses a modular approach; the core of the system is represented by the main Server, that, in principle, can provide a self-contained and fully operational implementation even on a single processor system. To realize the required better-than-real-time and fully interactive nature of the system, high-performance versions of the basic models are available as an optional extension, that in turn requires high-performance computing facilities and a fast network connection.

  However, the main feature achieved with the system architecture is excellent scalability: a broad range of performance characteristics can be supported with the same software system, implemented on increasingly more powerful hardware.

The Conceptual Level

At the conceptual level, the system architecture is based on an object-oriented design. The main real-world elements of technological risk assessment and management are represented by classes of objects and associated methods.

The basic object classes used for representing an emergency are:

• emergency scenarios: an emergency scenario is a dynamically evolving collection of emergency parameters, which are collected by methods including the expert system, and the high-performance parallel simulation models.

  Emergency scenarios can be linked to types of emergencies such as toxic spill, chemical fire, explosion, etc. Alternatively, they can be linked to specific risk objects (see below) such as a particular chemical plants.

  Emergency scenarios can be dynamic, in the context of risk management, or static, in the context of risk assessment, where they represent the set of assumptions describing a plausible accident as defined by the Seveso Directive (96/82/EEC).

• Risk objects: they provide the basic vocabulary and attributes of a emergency scenario; risk objects cover several classes of objects, including:

  • sources of risk: examples are chemicals plants, production units, containers, warehouses, vehicles with hazardous cargo, etc;

  • components exposed to risk: examples are communities (at various levels of geographical and administrative organization) and their population, including population centers such as schools, shopping malls, churches, etc., but also environmental targets such as water bodies;

  • risk management resources: they include, for example, hospitals, fire fighters and their equipment, police, ambulance services, civil defense forces, etc.

• ACTIONS are the central component of the decision support system, selected and shaped by the expert system, based on the evolving context provided by the emergency scenario.

  The concepts of the decision support system are described in more detail below.

In addition to these basic groups, the object oriented paradigm is also used to represent other elements of the system: hazardous chemicals; external information sources such as meteorological stations, infra-structural components such as road segments, and "internal" information resources such as the simulation models.

Systems Modules

The HITERM system is, in principle, and open framework that can integrate any number of analytical or communication modules in its open client-server architecture.

The basic elements or classes of modules are:

Data Layer

• data bases, including:
  • hazardous chemical data base
  • risk objects (chemical plants, transportation vehicles)
  • target objects (communities, sensitive areas)
• GIS containing background data and spatial model input such as the digital terrain model or the rail network, and population distributioni (gridded)
• Knowledge Base including Descriptors, Rules, and ACTION declarations;
• configuration files such as the defaults, templates for communication (fax),

Expert System

the real-rime forward chaining system (RTXSP) which is the overall driver for the Emergency management branch,
• and the backward chaining system that support all editing functions;

Embedded Models

• a source model (spill characteristics, pool evaporation, soil infiltration, probabilities of fire and explosion)
• dispersion model (multi-puff)
• explosion models: TNT and TNO
• probabilistic soil infiltration model

Client-Server Models

• Spill (pool evaporation) model (with Monte-Carlo implementation)
• Diagnostic wind field model
• Lagrangian dispersion model

External data sources

• on-line weather data
• train information (CIS of the SBB).

LC: local client	MC: mobile client	DB: data bases	HOT: HOT objects
KB: knowledge base	Ch: Chemicals	GIS: map data	Meteo: weather station
CIS: train information	RTXPS: Chemicals	XPS: forward chaining expert system	Meteo: backward chaining expert system
S: source model	P: multi-puff	B1: explosion (TNT)	B2: explosiuon (TNO)
GW: groundwater model	W: wind model	S: spill model	L: Lagrangian

The DSS framework

HITERM is designed as a decision support system; its distinguishing feature is the integration of HPCN components to support decisions in a complex domain (technological risk management) with the help of complex state-of-the-art analytical tools with better-than-real-time performance, including the possibility to obtain probabilistic solutions to complex, dynamic 3D scenario simulations.

While the domain of decision support is rather broad and inclusive, there are two distinct aspects implemented in the system:

• risk assessment and planning, which is based on the comparative evaluation of scenario analysis, based in turn on accident simulation;

• operational risk management, i.e., a real-time risk management expert system that provides direct advise to an operator or a command center during an emergency situation, or a training exercise.

A more detailed description of the Decision Support Aspects is given in
Deliverable D06.1 and D06.2, Decision Support and Expert Systems

Modes of Operation: Assessment vs Management

• risk assessment and planning:
  
  scenario analysis;
• training for emergency management:
  
  scenario analysis or real-time expert system;
• operational emergency management:
  
  real- time expert system.

The system offer two entry levels through its interactive interface:

• directly to the scenario analysis and modeling; here the emergency scenario parameters are pre-defined in the scenario objects, and can be interactively modified by the user to represent s specific case; this case is simulates, and evaluated (in terms of area and population exposed)

• through the real-time emergency management expert system; the expert system advises the operator in a dialog to compile relevant information on the emergency. This context-sensitive dialog builds the emergency scenario information step by step. It also suggest, in real time and as the emergency develops, specific management actions to the operator.

  The scenario analysis is an integrated part of the emergency management approach; the main difference exists in the fact that the emergency parameters are collected within the framework of a dynamically developing emergency situation, and are used to provide operational guidance and advice on emergency management actions.

Data Structures: The Object Classes

Objects and object classes are used to represent relevant real-world concepts and elements of an emergency situation. In general terms, an object (class) consists of:

• a header used for identification;

• meta information, primarily describing the sources of the information contained with the object;

• georeference information where applicable (in HITERM, all objects with the exception of hazardous chemicals are spatial objects);

• a set of attributes with their associated methods; the methods provide the actual values of the attributes in a given context;

• a list of children: these are object that logically relate to the parent object as components (e.g., containers in a container group, communities within a province) any or all of their attributes may be aggregated into a parent object's attribute.

• a list of siblings: these are objects at the same level of logical relationships, i.e., they share a parent object with the current object.

The objects in HITERM are based on HOT the hierarchical object tool, which describes the details of the technical implementation. For details of HOT, its architecture, implementation, and component object classes, please refer to the HITERM on-line manual.

Emergency Scenarios

The emergency scenario is the core object in HITERM. Depending on the chosen operational mode (assessment or management) it is a static object (with a complete pre-defined structure and list of attributes) in the case of scenario analysis and risk assessment;

and a dynamic object in the case of the emergency management mode, with a context dependent structure and list of attributes.

For scenario analysis and assessment, the emergency scenario is instantiated based on a TEMPLATE; the TEMPLATE is selected based on the primary scenario attribute, emergency type. The emergency type is the first descriptor the user has to define; on the basis of its value, one of a set of predefined defaults scenarios (the TEMPLATES) is loaded. The TEMPLATES are associated with emergency types in a configuration file, ./data/objects/scenarios/CONFIG:

###########################################################
##### CONFIG file for emergency type SCENARIO TEMPLATES
##### contains one record for each legal - and supported - 
##### emergency type, defined in Descriptors

toxic_spill    TEMPLATE.1
earthquake     TEMPLATE.2
explosion      TEMPLATE.3
chemical_fire  TEMPLATE.4
flood          TEMPLATE.5
forest_fire    TEMPLATE.6

Each TEMPLATE defines the basic attributes, which includes the characteristics of the emergency and the input data for the associated simulation models. The TEMPLATE ensures that a complete set of default data is available so that the model-based analysis can be run immediately. The user can, however, edit and overload any or all of the scenario attributes with the notable exception of the emergency type.

A TEMPLATE example contains, inter alia, the following:

NA  toxic_spill # corresponds to the emergency_type value
ID  TEMPLATE.1
ME  Meta Information 1                 # meta information 1
ME  Meta Information 2                 # ...
ME  Meta Information n                 # meta information n
AU  kurt Sun Oct 25 12:45:55 1998   # automatically inserted

TABLE methods
E   icon    # this is a trigger
E   method
E   message
D   1 rail_edit none
D   2 evaporation_model none
D   3 puff_model none
D   10 wind_gen none
D   4 pop_eval none
D   8 alert Sorry._Model_not_applicable_in_given_context
END_TABLE

TABLE input_sets
E   name
E   parent
E   display_method
D   model_descriptors main descriptor_list
D   targets main descriptor_list
END_TABLE

TABLE targets
E   name
E   value
E   method
D   Health no_effect edit_descriptor
D   Damage no_effect edit_descriptor
D   Ecology no_effect edit_descriptor
END_TABLE

TABLE model_descriptors
E   name
E   value
E   method
D   Substance benzene edit_descriptor
D   Total_duration 3 edit_descriptor
D   Mass 1000 edit_descriptor
D   toxicity high edit_descriptor
D   Spill_duration 20 edit_descriptor
D   source_type unknown edit_descriptor
D   Cut_Off    60 edit_descriptor
D   Time_step 10 edit_descriptor
D   Spill_pool_depth 1 edit_descriptor
D   Air_Temperature 20 edit_descriptor
D   Stability_Class 2 edit_descriptor
D   Inversion_height 1000 edit_descriptor
D   Wind_speed 0.5 edit_descriptor
D   Wind_direction 45 edit_descriptor
D   Number_of_runs 10 edit_descriptor
D   Grid_size 200 edit_descriptor
D   Standard 20 edit_descriptor
D   boiling_point 0 edit_descriptor
D   input_uncertainty 50 edit_descriptor
END_TABLE

Risk Objects: plants, regional elements, resource objects

• Sources of risk
• Targets or recipients
• Resources for risk management
• Hazardous chemicals

Sources of Risk

Within the scope defined for the HITERM system (chemical emergencies, see: Executive Summary of the Requirements and constraints Report), this class includes both stationary chemical plants and their components, as well as vehicles used for the transportation of hazardous substances.

Chemical plants are represented by a hierarchy of objects classes, implemented in HOT. This hierarchy can include, as an example:

PROCESS PLANT
   PRODUCTION UNIT
     PRODUCTION LINE
       REACTOR
     STORAGE AREA
       CONTAINER GROUP
          CONTAINER
   WAREHOUSE
     LOADING DOCK

An example for a plant object is given below:

NA Sample Chemical Plant               # object name
ID SITE1                               # unique ID
ME  Meta Information 1                 # meta information 1
ME  Meta Information 2                 # ...
ME  Meta Information n                 # meta information n
AU  patel   Thu Feb 23 12:45:55 1995   # automatically inserted

GX 1566613          # latitude / reference X
GY 5058113          # longitude/ reference Y
EL 25.5             # masl
HY demo.exp         # hypertext explain file

TABLE
input_sets
E   method
E   data_table
E   default_prefix
D   widget              address         plant.widget
D   disp_address        address         plant.address
D   disp_list           links           plant.links
D   disp_list           Process_units   plant.p_units
D   disp_hidden_list    safety_reports  plant.scenarios
D   disp_hidden_list    safety_reports  plant.s_reports
D   disp_hidden_list    safety_reports  plant.s_equipment
D   hidden_list_values  substances      plant.substances
D   disp_map            global_map      plant.global_map
D   disp_map            local_map       plant.local_map
D   disp_map            plant_map       plant.plant_map
D   disp_properties     descriptors     plant.descr_list
D   disp_children       none                plant.children
END_TABLE

TABLE
safety_reports
E   object_name
E   path
E   layer
D   Safety_report.92        safety_reports/report.92    child
D   Safety_report.95        safety_reports/report.95    child
END_TABLE

TABLE
plant_map
E   type
E   value
D   background 172
D   x   1543200
D   y   5052300
D   extent  420
D   index   17
D   index   21
D   index   20
D   index   19
D   index   18
END_TABLE

TABLE
local_map
E   type
E   value
D   x   1543200
D   y   5052200
D   extent  1500
D   index   3
D   index   9
D   index   10
D   index   12
D   index   13
END_TABLE

TABLE
global_map
E   type
E   value
D   index   2
D   index   7
END_TABLE

TABLE
address
E   type
E   value
D   TITLE   DEMO_Plant
D   EXfile demo.exp
D   EXtitle Example
D   N1 Bayer_SpA
D   N2 Stabilimento_di_Filago
D   ST Via_delle_Industrie_9
D   TO 24040_Filago
D   PR Tel._035/990111
D   ZI Sede
D   CO Viale_Certosa_126/130
D   PE 20156_Milano
D   PH Tel._02/3978.1
D   FX 00123_456_999                  
D   EM donald.duck@working_hard.it
END_TABLE

TABLE
links
E path
E layer
D plants/new    sibling
D plants/new    independent
END_TABLE

TABLE
substances
E   name
E   value
E   method
E   derived_from_object
E   derived_from_table
E   derived_from_descriptor
D   Substance    *list* disp_chem Process_units substances Substance
D   Volume       *sum*  disp_chem Process_units substances Substance
END_TABLE

TABLE
Process_units
E path
E layer
D process_units/pu_a    child
D process_units/pu_b    child
END_TABLE

TABLE
descriptors
E   name
E   value
E   method
E   derived_from_object
E   derived_from_table
E   derived_from_descriptor
D   Total_volume    *sum* none    Process_units descriptors Total_volume
D   Fire_protection none  ask_box none          none        none
END_TABLE

Storage containers

Containers, like all plant related objects with the exception of chemicals, are spatial objects, i.e., their position within the plant is known and can be used for modeling.

NA Sample Chemical Storage Container   # object name
ID SITE1                               # unique ID
ME  Meta Information 1                 # meta information 1
ME  Meta Information 2                 # ...
ME  Meta Information n                 # meta information n
AU  patel   Thu Feb 23 12:45:55 1995   # automatically inserted

GX 1566613          # latitude / reference X
GY 5058113          # longitude/ reference Y
EL 25.5             # masl
HY demo.exp

TABLE
input_sets
E   method
E   data_table
E   default_prefix
D   widget          content     container.widget
D   disp_list       links       container.links
D   disp_hypertext  content     container.htext
D   disp_properties descriptors container.descr_list
END_TABLE
 
TABLE
content
E   type
E   value
D   TITLE           Container_A
D   HYfile          one
D   HYtitle         Example
D   EXfile          demo.exp
D   EXtitle         Example
END_TABLE

TABLE
links
E path
E layer
D containers/Container_A sibling
D containers/Container_B sibling
END_TABLE

TABLE
descriptors
E   name
E   value
E   metho d
D   Substance           benzene        ask_box
D   Volume              20000          ask_box
D   Fullness            85             ask_box
D   Function            raw_materials  ask_box
D   Shape               sphaerical     ask_box
D   Material            steel          none
D   Wall_thickness      2.             ask_box
D   Diameter            20.            ask_box
D   Working_temperature ambient        ask_box
D   Working_pressure    2.5            ask_box
D   Pipe_diameter       0.10           ask_box
D   Insulation          yes            ask_box
D   Passive_control     overfilling    ask_box
D   Active_control      pressure       ask_box
D   Loss_protection     leak_detection ask_box
D   Fire_protection     none           ask_box
END_TABLE

For a detailed explanation of the interpretation of the individual data TABLES, please refer to the on-line manual description of the HOT hierarchical object tool

Targets or recipients

Targets or recipients are either related to population, or vulnerable environmental features. Examples of the former class are communities and population centers, examples of the latter water bodies or aquifers.

As in the case of the sources of risk, the target objects may be organized hierarchically. A typical example is a community or municipality as an administrative and geographical unit of organisation; its primary property is its population, linked to the location and spatial extent of the community used for population exposure estimates.

GX 1566613          # latitude / reference X
GY 5058113          # longitude/ reference Y
EL 25.5             # masl
HY municipality.exp

TABLE
input_sets
E   method
E   data_table
E   default_prefix
D   widget          content             munic.widget
D   disp_list       Populated_Places    munic.pop_pl
D   disp_list       Municipalities      munic.munic
D   disp_list       Public_Institutions munic.pub_inst
D   disp_list       Health_care         munic.health
D   disp_list       Intervention_Forces munic.int_force
D   disp_hypertext  content             munic.htext
D   disp_properties descriptors         munic.descr_list
D   disp_map        local_map           munic.map
D   disp_children   none                munic.children
D   disp_address    address             munic.address
END_TABLE
 
TABLE
content
E       type
E       value
D       TITLE   Bonate_Sotto
D       HYfile  bonate_sotto.exp
D       HYtitle Bonate_Sotto
D       EXfile  municipality.exp
D       EXtitle Municipalities
END_TABLE

TABLE
address
E       type
E       value
D       Name    Municipio_di_Bonate_Sotto
D       Street  Strada_di_Milano_115
D       City    3141_Bonate_Sotto
D       Phone   tel:_030_123_456_00
END_TABLE

TABLE
Municipalities
E path
E layer
D municipalities/Bottanuco              sibling
D municipalities/Brembate               sibling
D municipalities/Capriate_San_Gervasio  sibling
D municipalities/Chignolo_d'Isola       sibling
D municipalities/Filago                 sibling
D municipalities/Madone                 sibling
END_TABLE

TABLE
Populated_Places
E path
E layer
D places/Sotto      child
END_TABLE

TABLE
Public_Institutions
E path
E layer
D schools/SPS       child
END_TABLE

TABLE
Health_care
E path
E layer
D hospitals/HBS     child
END_TABLE

TABLE
Intervention_Forces
E path
E layer
D police/police     child
END_TABLE

TABLE
descriptors
E       name
E       value
E       method
D       Population            5067  ask_box
D       Total_area            1200  ask_box
D       Residential_area       400  ask_box
D       Residential_buildings  250  ask_box
D       Public_buildings        25  ask_box
D       High_rise_buildings      0  ask_box
D       emergency_shelters     500  ask_box
D       sirens                 none ask_box
END_TABLE

TABLE
local_map
E   type
E   value
D   background  172
D   x           1542788
D   y           5052368
D   extent      1000
D   index       14
D   index       9
D   index       10
D   symbol      hospitals/HBS
D   symbol      schools/SPS
D   scale       on
END_TABLE

The municipality can include sub-locations (e.g., called Frazione in the Italian test case). Please note that the h class hierarchy that can be represented in HOT is open, i.e., an arvbitrary number of layers and elements can be represented simpy through the appropriate data declarations.

The municipality contains, either directly or through aggregation of its sub-units, specific population centers, like schools, shopping centers, churches, sports grounds etc. Again their specific properties primarily include population, but also other attributes like contact addresses that can be used by the emergency management expert systems's rules.

GX 1542085      # reference point
GY 5052152      # reference point
EL 25.5
SR school.sc    # icon for map display

TABLE              # PLEASE COMMENT/EXPLAIN
input_sets
E   method
E   data_table
E   default_prefix
D   widget          content             school.widget
D   disp_list       Public_Institutions school.health
D   disp_hypertext  content             school.htext
D   disp_properties descriptors         school.descr_list
D   disp_map        local_map           school.map
END_TABLE
 
TABLE           
content
E   type
E   value
D   TITLE       Scuole_Communali       # header
D   HYfile      scuole_communali.exp   # object specific hypertext
D   HYtitle     Scuole_Communali
D   EXfile      scuole_communali.exp     
D   EXtitle     Scuole_Communali
END_TABLE

TABLE
Public_Institutions
E path
E layer
D schools/SPS       sibling
END_TABLE

TABLE
descriptors
E       name
E       value
E       method
D       Population     2453   ask_box
D       students        255   ask_box
D       teachers         25   ask_box
END_TABLE

TABLE          
local_map
E   type
E   value
D   background  172
D   x           1542300
D   y           5052347
D   extent      650
D   index       14
D   index       9
D   index       10
D   symbol      schools/SPS
D   scale       on
END_TABLE

Resources for Risk management

Yet another group of objects describes resources available to the intervention forces and the health care services. A prototypical example is a hospital:

GX 1542554
GY 5051722
EL 25.5
HY demo.exp
SR spital.sc    

TABLE
input_sets
E   method
E   data_table
E   default_prefix
D   widget           content                hospital.widget
D   disp_list        Health_care_resources  hospital.health
D   disp_hypertext   content                hospital.htext
D   disp_properties  descriptors            hospital.descr_list
D   disp_map         local_map              hospital.map
D   disp_address     address                hospital.address
END_TABLE
 
TABLE
content
E   type
E   value
D   TITLE   St.Maria_Maggiore
D   HYfile  St.MariaMaggiore.exp    
D   HYtitle St.Maria_Maggiore   
D   EXfile  report.25
D   EXtitle Hospital_Objects
END_TABLE

TABLE
address
E       type
E       value
D       Name    St.Maria_Maggiore
D       Street  Strada_di_Milano_115
D       City    3141_Ponte_St._Pietro
D       Phone   tel:_030_123_456_00
END_TABLE

TABLE
Health_care_resources
E path
E layer
D hospitals/HBS     sibling
END_TABLE

TABLE
descriptors
E      name
E      value
E      method
D      patients(intensive_care)    35 ask_box 
D      patients(stationary)       350 ask_box
D      patients(ambulatory)        50 ask_box
D      hospital_staff              75 ask_box
D      burn_unit                    3 ask_box 
D      emergency_treatment          5 ask_box
D      operating_theaters           2 ask_box
D      helipad_type              none ask_box
END_TABLE

TABLE
local_map
E   type
E   value
D   background  172
D   x       1542300
D   y       5052347
D   extent  650
D   index   14
D   index   9
D   index   10
D   symbol  hospitals/HBS
D   scale   on
END_TABLE

The above example already indicates the complexity of the object relationship: a hospital represents both a population center that may be relevant for evacuation planning, as well as a health care resource to accept and treat casualties.

Hazardous Chemicals

Hazardous Chemicals represent a non-spatial class of objects in HITERM. The chemicals are described by:

• a set of properties (Descriptors) that can be loaded to the scenario object;
• a set of hypertext files that can be displayed together or individually by the expert systems ACTION construct.

The definition for the Hazardous Chemicals objects is given below:

###############################################################
### Chemical DataBase object
###
NA  ChemDB
ID  standard
ME  Meta Information 1                 # meta information 1
ME  Meta Information 2                 # ...
ME  Meta Information n                 # meta information n
AU  patel   Thu Feb 23 12:45:55 1995   # automatically inserted
###############################################################
TABLE ChemDB
E chemical_name           # short name for selectors
E CAS_Number     
E EC_Number
E UN_Number
E Kemler
E formula
E Seveso_II
E health_risk
E toxicity
E flammability
E reactivity
E contact
E specific_gravity
E boiling_point
E melting_point
E vapor_density
E solubility
E diffusivity
E flash_point
E flam.limit_min
E flam.limit_max
E SYMBOL_1
E SYMBOL_2
E HAZARD_1
E HAZARD_2
E HAZARD_3
E HAZARD_4
E long_name
E msds_link      
########################################################################
D gasolio        # substance short name  
  CAS000         # CAS number
  EC000          # EC number
  1202           # UN Number 
  30             # Kemler
  hydrocarbon_mixture        # formula
  *undef*        # Seveso_II
  low            # health_risk
  low            # toxicity
  medium         # flammability
  *undef*        # reactivity
  *undef*        # contact risk
  0.9            # specific gravity, relative to H2O
  294            # boiling_point
  *undef*        # melting_point
  3.4            # vapor_density
  none           # solubility
  *undef*        # diffusivity
  65             # flash_point
  1.5            # flammability, lower limit
  7.5            # flammability, upper limit
  F100.gif       # first symbol
  N100.gif       # second symbol
  0              # Hazard diamond, health
  2              # Hazard diamond, fire
  0              # Hazard diamond, reaction
  0              # Hazard diamond, special instruction
  gasolio_(Diesel_fuels)        # long name, if any
  gasolio.msds   # hypertext msds file
########################################################################
D benzene 
 71-43-2        # CAS number
 200-753-7      # EC number
 1114           # UN number
 33             # Kemler
 C6H6           # formula
 2_Toxic        # Seveso_II
 extreme        # health risk
 high           # toxicity
 severe         # flammability
 none           # reactivity
 slight         # contact risk
 0.88           # specific gravity
 80.0           # boiling point
 6.0            # melting point
 2.77           # vapor density
 none           # solubility
 *undef*        # diffusivity
 -11.0          # flash point
 0.3            # flammability, lower limit
 8.0            # flammability, upper limit
 F100.gif       # first symbol
 T100.gif       # second symbol
 3              # Hazard diamond, health
 3              # Hazard diamond, fire
 0              # Hazard diamond, reaction
 0              # Hazard diamond, special instruction
 the_very_long_version_of_the_name_benzene
 benzene.msds
################################################################

Please note that as with any other object, the list of attributes is open, i.e., it can be extended by simply adding the desired Descriptor in the above TABLE definition, and updating the data fields accordingly. It also requires that the corresponding Descriptor definition is inserted in one of the Knowledge Base Descriptor files. The display routines, and the loading of the data to the KnowledgeBase and ScenarioObject will be automatic.

RTXPS objects

Within the overall object-oriented design and implementation framework, the elements of the RTXPS real-time expert system are designed and also implemented as objects. For a more detailed description of RTXPS and its primary role in the decision support functions of HITERM, see the Deliverables on Decision Support and Expert Systems (D06.1 and D06.2).

• ACTIONS
• Descriptors
• Rules (forward chaining)

ACTIONS provide a hypertext based information and instructions to the operator. ACTIONS may include specific built-in functions (see the Technical report on Decision Support and Expert Systems) which can either be triggered automatically or manually by the operator, depending on the ACTION type declaration. An icon menu in the ACTION display header offers four options:

• done acknowledges the ACTION and confirms that its requests have been fulfilled; the ACTION will ba marked as done for the forward chaining inference;
• ignore skips the ACTION and continues the forward chaining rule processing;
• pending backgrounds the ACTION, starts a timer, continues forward chaining rule processing; the ACTION will be considered again when the timer is expired.
• do it is used to manually trigger function offered, and requested, by the ACTION;

Methods of instantiations

• external information sources
• rule-based inference
• simulation modeling

The attribute of the objects representing an emergency obtain their values by a range of methods:

• external information sources: the operator obtains the information requested by an ACTION from an external source, e.g., through a phone call, and enters this information through the expert systems editing dialog.

• external data acquisition as a special case of an external data source, automatic connection to external data bases or monitoring equipment can also provide a required data item. An example is the compilation of a meteorological scenario for dispersion modeling from a remote weather station;

• rule-based inference: the backward chaining expert system is used to help deduce or estimate the required information;

• simulation modeling:one of the systems built-in (high-performance) models is used to obtain the data;

The Physical Implementation

At the physical implementation level, HITERM is based on a client-server architecture that links an easy-to-use front end (clients) with powerful High-Performance Computing as the main server. The basic architecture of the system is organized around a central HITERM Server, that coordinates the various information resources, prominently including

• the HPCN components like parallel computers or workstation clusters for better-than-real-time simulation of demanding 3D dynamic models,
• links to monitoring equipment,
• and the user interface clients.

Since the communication of the various software components is based on the standard http protocol, a high degree of hardware independence can be achieved: any platform and operating system that supports that protocol on top of TCP/IP can be integrated within this framework.

For the hardware and software tools used for HITERM, we have to discriminate between:

• the develop platforms and the Demonstrator
• the delivery platforms for a commercial exploitation phase

The Main HITERM server

The server and clients in HITERM are primarily conceptual: the flexibility of the architecture supports implementation one a single CPU, or in a complex network of CPUs with various levels of interconnectedness, including wireless, mobile, clients. A given machine may perform logical functions of both server and client at the same time.

The main HITERM server is implemented on a UNIX or Linux machine. In its minimal configuration this can be a single CPU machine, in its most complex configuration, a network of CPUs including massive parallel machines or workstation cluster, and remote, wireless, mobile clients.

A major important feature of the architecture is the flexibility to support a wide range of possible hardware configurations to achieve a high degree of scalability.

The main HITERM server runs the basic HITERM application. This, in a minimal configuration, is operational on a single-processor system and provides a possible, but not recommended, entry-level configuration (see the discussion on entry-level and scalability in the DRAFT Exploitation Plan.

The main server runs the basic HITERM application. The server requires at least one display client which can, in fact, be the Xserver running on the basic single CPU workstation or Linux PC.

The main server also needs at least one compute server, which again can be supplied by the same CPU on the basic machine.

For an efficient implementation, the main server is connected to either

• a remote super computer or high-performance computer center
• a local computer cluster.

HPCN Resources: Compute Servers

For the necessary performance to run the simulation models better-then-realtime conditions required by the basic systems specifications

The compute servers are connected to the main server through the TCP/IP based http protocol, which requires an http server and httpd daemon to be running at least on one logical compute server; this can, in turn, manage a larger cluster configuration through PVM see: The Parallel Environment for a description of the parallel computing environment and architecture.

The apparent complication of the http protocol layer provides the necessary flexibility to connect to either local or remote computational resources, using standard public Internet or dedicated Intranet connections.

Compute services can either be provided

• by a single (but possibly multi-processor powerful super-computer;are
• by a cluster of computers linked by a high-speed network.

HPCN Resources: Real-time data acquisition

As an important feature for real-time emgerncy managemnt, the HITERM architecture supports the direct and automatic on-line integration of field data acquisition, including:

• meteorological monitoring data for the atmospheric dispersion models
• hydrological data for surface and groundwater impact models
• field measurements of air quality data (concentrations) for dysnamic model calibration
• location information (GPS) primarily for vehicle and mobile client position data.

The communication protocol used is again based on TCP/IP http; and example for the retrieval of meteorological data (driven by the real-time expert system) is shown below:

main () {
char    buf[256];
int     Nbytes;
FILE    *INFILE, *OUTFILE;
   fprintf (stdout, "Content-Type: text/html\n\n");
   /* MY request receives notification of HTML page coming */
       
   query_met_DB(WHATEVER); 
      /* query_mat_DB obtains the lastest met data,
         with error handling, of course; WHATEVER is
         the POSSIBLE (but not necessary) argument string,
         for example, the current time etc - WHATEVER you need ...  
         to make it more clear -- I HOPE -- assume that
         query_met_DB puts the results  of the data base query
         in the local file met_data  (in your format: keyword: value)
         and places the string "END" in the last record;
         of course, you can do the whole operation in meory, no
         real need for a local scratch file, 
         maybe just easier for debugging  ..... */

   /* ERROR: database query failed:   */
   if(( OUTFILE = fopen("met_data","r") == NULL) {
        printf("can't open met data file \n");
        fprintf (stdout, "Content-Length: 0 \n\n",);
        /* now we know we get NOTHING, reqeust failed */

   /* SUCCESS: there is something in the DB scratch file */
        } else {
                Nbytes = get_size(OUTFILE);  /* size of the message body */
                fprintf (stdout, "Content-Length: %i \n\n",Nbytes);
                /* now we know how many bytres to expect */
          }
    /* DATA TRANSFER: move the contents of met_data to stdout: */
        while (fgets (buf, 256, OUTFILE)) {
        fprintf(stdout,"%s", buf);
        /* whatever is written to stdout, our client request  receives:
           THIS IS HOW WE 'PICK UP'  RESULTS !!! */
        if (!(strncmp (buf, "END", 3))) break;
        /* used to signal the receiving process end of data transmission */ 
        }
}

Display Clients

HITERM currently support two types of display clients:

• X11 (servers) for the X Windows protocol;
• Java clients through http Java sockets based directly on TCP/IP;

Implementation Considerations

• a UNIX workstation for the main HITERM server, including the display client;
• a (UNIX) workstation cluster under PVM for the implementation of the HPC components.

The main specification for the client-server architecture is the communication protocol to be used between the HITERM Server and display client and the HPC Model Server.

This is based on a POST request issued by the client to the server URL:

REGION:Testdatensatz Berge
LONG:15.64
LAT:53.78
RELEASE_TYP:1
START_TIME: 12:00
DATE: 15.06.1997
SIMULATION_TIME:10800.
NX:51
NY:51
DX:100.
DY:100.
STABILITY_CLASS:3
MIXING_HEIGHT:0.
WIND_SPEED:2.
MIN_WIND_SPEED:1.
MAX_WIND_SPEED:3.3
WIND_DIRECTION:-20.
MEASUREMENT_HEIGHT:10.
GAMMA:-0.038
ROUGHNESS_LENGTH:0.5
SURFACE_TEMPERATURE:297.
MIN_SURFACE_TEMPERATURE:293.
MAX_SURFACE_TEMPERATURE:300.
TIME_STEP_MONT:30.
SPILL_DURATION:1800.
MIN_SPILL_DURATION:1600.
MAX_SPILL_DURATION:2000.
DEPTH:0.15
MIN_DEPTH:0.13
MAX_DEPTH:0.2
TOTAL_VOL:50.
MIN_TOTAL_VOL:40.
MAX_TOTAL_VOL:60.
CLOUD:10.
MIN_CLOUD:0.
MAX_CLOUD:20.
WTMOL:16.04
DAB:50.
CONLIQ:1.
BOILP:112.
VAPHT:3.1E+3
COEFF_A:8.9
COEFF_B:984.
COEFF_C:273.
RHO_LIQUID:0.3e+6
X_LOCATION:35.
Y_LOCATION:43.
Z_LOCATION:0.5
OUTPUT_LAYERS:10
LAYER_1:20.
LAYER_2:40.
LAYER_3:60.
LAYER_4:80.
LAYER_5:100.
LAYER_6:120.
LAYER_7:140.
LAYER_8:160.
LAYER_9:180.
LAYER_10:200.
OUTPUT_STEP:300.
TIME_STEP_LAGR:10.
DX_LAGR:100.
DY_LAGR:100.
SUBST:OZON
END

REGION:

name of the region of interest

LONG

LAT

mean longitude,latitude of this place if all places in the future are well defined, we can skip long,lat and put it into the constant part together with the orography

RELEASE_TYP

has currently no meaning since only evaporation is implemented

START_TIME:

the time format is HH:MM in a 24 hours scheme

DATE:

the date format is DD.MM.YYYY

SIMULATION_TIME

total time of the simulation of Monte Carlo and Lagrange, possibly results will appear for shorter time interval, if spill is exhausted and all particles carrying mass have left the domain before end of simulation is reached - but this seems to cause no problems, since the output-data-stream will be limited by finish and not by a counter of time steps. NX,NY

number of points of the computational domain for meteorology, these must match the numbers in orography input, if NY is not specified, then NY=NX

DX,DY

spatial resolution of the same in m, if DY not provided, DY=DX

STABILITY_CLASS

MIXING_HEIGHT

GAMMA

PARAMETRIZATION:
----------------
stability classes:
    class   value      description       gamma [K/m]      hmx [m]
      a      1.0      very unstable        -0.025        2500
      b      2.0        unstable           -0.020        1500
      c      3.0    slightly unstable      -0.015         800
      d      4.0         neutral           -0.010         500
      e      5.0     slightly stable       -0.005         300
      f      6.0         stable             0.000         200

if hmx<100. (assume no value for hmx is available): hmx = f (stability_class) if stability class equals 0: use gamma values, else use stability class

 
  if (stab.le.0) then
      if (hilf1.le.-0.0225) stab=1
      if ((hilf1.gt.-0.0225.and.hilf1.le.-0.0175)) stab=2
      if ((hilf1.lt.-0.0175.and.hilf1.le.-0.0125)) stab=3
      if (hilf1.eq.-0.01) stab=4
      if ((hilf1.gt.-0.01.and.hilf1.le.-0.0075)) stab=5
      if (hilf1.gt.-0.0075) stab=6
      else
      if (stab.eq.1) hilf1= -0.025
      if (stab.eq.2) hilf1=  -0.02
      if (stab.eq.3) hilf1= -0.015
      if (stab.eq.4) hilf1= -0.01
      if (stab.eq.5) hilf1= -0.005
      if (stab.eq.6) hilf1=  0.0
      endif

WIND_SPEED:

MIN_WIND_SPEED:

MAX_WIND_SPEED:

wind speed in m/s, the min/max are for variations in MC, if not specified set to the exact value

MEASUREMENT_HEIGHT

meters above ground

ROUGHNESS_LENGTH

at the site of the measurement station

SURFACE_TEMPERATURE:

MIN_SURFACE_TEMPERATURE:

MAX_SURFACE_TEMPERATURE:

same as for WIND_SPEED

TIME_STEP_MONT

internal time step and output time step for the release model in seconds

SPILL_DURATION

MIN_SPILL_DURATION

MAX_SPILL_DURATION

same as for WIND_SPEED

DEPTH

MIN_DEPTH

MAX_DEPTH

initial depth of the evaporating volume in m

TOTAL_VOL

MIN_TOTAL_VOL

MAX_TOTAL_VOL

total volume of the liquid, that will be evaporated m**3

CLOUD

MIN_CLOUD

MAX_CLOUD

cloud cover 0...100 %

WTMOL

DAB

CONLIQ

BOILP

VAPHT

COEFF_A

COEFF_B

COEFF_C

RHO_LIQUID

parameters of the material evaporated, compare evapor.f, source.f

X_LOCATION

Y_LOCATION

Z_LOCATION

localisation of the spill in terms of the meteorological grid - box numbers in x,y direction (in our notation starting at the left lower corner), vertical coordinate in meters

OUTPUT_LAYERS:10

LAYER_1:20.

LAYER_2:40.

LAYER_3:60.

LAYER_4:80.

LAYER_5:100.

LAYER_6:120.

LAYER_7:140.

LAYER_8:160.

LAYER_9:180.

LAYER_10:200.

number of output layers for the Lagrange calculation, currently limited to 12, if more are necessary, the program has to be changed; the heights representing the top of the layers do not have to be equidistant, but maximal height should be in some correlation with the MIXING_HEIGHT as given or set according to the explanation above. If it is greater the layers will be empty. OUTPUT_STEP

output step for Lagrange in s

TIME_STEP_LAGR

internal time step for Lagrange, may possibly be skipped in future

DX_LAGR

DY_LAGR

spatial resolution of the Lagrange results, may be other then DX,DY. if DY_LAGR not specified, DY_LAGR=DX_LAGR

SUBST

char*10, can be specified; please note that this should be one of the legal values of the RTXPS Descriptor substance_name.