In the LAN context, in the absence of Connection Oriented solutions,
Connection Less Technologies may be used as the primary means of transporting
information, provided that an exclusive Physical Layer is used. The
development of structured cabling and the use of Ethernet switching instead of
shared medium Ethernet, enables a very good level of reliability for a
Connection Less Ethernet solution.
The volume of information generated by large-scale 3D dynamic models - in
particular when considering more than one model solution generated in parallel
or
when the output is inherently stochastic, adding yet another dimension to the
data interpretation - is enormous and overwhelming to the human observer.
Therefor, related methods of real-time interpretation (including visualisation,
pattern recognition, classification, etc.) are required to translate the model output
into useful, decision relevant information that can be presented, in multi-media
formats, to the end user in real time.
Visualisation and extensive graphical displays are one of the User Requirements
defined in The Executive Summary of D01.1, the Requirements and Constraints
Report.
An important element is the preparation of topical maps, using local GIS data
around the accident site. Maps, as a familiar format, are an effective basis for the
communication of complex information by providing a familiar context.
On this basis, and supported by other display styles, graphs, symbolic (icon)
displays, and possibly synthesised text and audio signals, a clear picture of the
state and expected evolution of the system, including the uncertainty of the
forecasts, have to be summarised. This includes spatial interpolation, 3D
reconstruction, rendering, and animation, as well as various forms of statistical
analysis.
The main objective of visualisation is the presentation of the large volume of
data, including the representation of uncertainty, in a directly understandable,
easy to comprehend form, i.e., largely symbolic and graphical, that guarantees safe
interpretation even under the special situation of emergency management. Since
most of the graphic rendering is again compute intensive, the use of HPC can also
be helpful at this stage of the overall information processing system.
At the same time, the field application of an emergency management system will
require thin clients with rather limited local processing capabilities.
HITERM uses a dual approach to user interface design and implementation,
reflecting the distributed client-server architecture of the system:
X Windows (X 11) for clients with a high-bandwidth connection (10 Mb or
better)
HTML, JavaScript and Java for low-bandwidth or light-weight (mobile)
clients.
Examples of the final user interface and its visualisation tools
are given throughout the report,
based on screendumps from the HITERM system.
Model calibration and uncertainty analysis are two important tasks to encourage
potential users to use the developed software and to ensure a maximum level of
truthfulness. The use of state-of-the-art methods for sensitivity analysis
(Automatic Differentiation) allows the quantification of the sensitivity of a model
output with regard to its input parameters for a given input data set. This forms a
basis for a pre-selection of parameters which have a dominant influence on the
model result. The methodology is documented for a selected spill release model.
Monte Carlo simulation techniques are generally used for varying input parameter
sets of release submodules. Rather than using a single value, a time dependent
source strength probability function serves as the input for the dispersion
calculation. Usually, the evaluation of atmospheric and aquatic dispersion models is
based on large field experiments and cannot be executed within the framework of
the HITERM project. However, a comparison of test cases with observed structures
or a comparison of numerical model results with analytical solutions for simple cases
was carried out, whenever it was possible.
Model performance evaluation is realised by a comparison of the model results with the real world. In the
case of atmospheric and air pollution models, an enhanced model evaluation is quite difficult.
Data from field campaigns together with data from continuous measuring nets has to be compared with simulated
data sets.
This was not within the scope of this project. Moreover, given the possibility to compare
simulated with real data, it is hard to distinguish between real model errors and data incorrectness or
inadequateness. A model may be valid (this includes an appropriate modeling of the desired features, a proper
selection of the numerical schemes, and a careful implementation), but the outcome can be insufficient due
to a lack of appropriate input data.
A validation requires the usage of a perfect input data set to distinguish between model and
data. Additionally, there is a principle validation problem which is still the
subject of scientific investigations. The reason can be found in the different nature
of point measurements and gridded model results as well as in the stochastic behavior of
local turbulence patterns.
Most of the selected software components already have a broad range of applications, and can
therefore be considered as sufficiently evaluated within their application range. This is the case for
the wind field model which has been derived from EPA's DWM (Douglas 1990) and for the different release
models. Nevertheless, an evaluation of the system is documented.
The model evaluation methodology in the context of the HITERM project focuses on the following
features:
- demonstration of the appropriate changes of the wind field calculation for different
meteorological conditions
- flow description for complex terrain
- comparison of Lagrangian dispersion results with an analytical solution for a simple case
- analysing the dispersion calculation for different atmospheric stability parameters
- evaluation of the interplay of all submodules.
The major source of uncertainties is given by the, in general, sparse and insufficient data
structure of emergency cases. Especially the differences caused by unknown release parameters can lead to
uncertainties in the concentration calculation of up to one order of magnitude.
One of the most important input parameters for all kind of dispersion models is the time
dependent emission rate of the source.
This rate is sufficiently known in the case of a continuously operational
source, such as the stack of a power plant or an industrial estate.
In the case of an accident, this parameter is very rarely
known. Very often, a rough approximation of the total release mass is given and, in some cases,
this release mass is unknown as well. This requires the incorporation of different source-strength
models. But release and spill models for emergency management tasks suffer from a high degree of
uncertainty regarding their input parameter set. Depending on the sensitivity of the source function, this is the
reason for many unrealistic concentration patterns.
Two different methods have been used to determine the uncertainty range of the source module:
Monte Carlo Simulation and Automatic Differentiation. Monte Carlo methods are directly included in
the model system whereas Automatic Differentiation has been used in the implementation phase.
The validation of models is a central concern of Applied Mathematics. Sensitivity analysis is
carried out in order to examine the robustness of numerical results with respect to changes of the model
structure, input parameters, algorithms, machine accuracy etc. The effects of perturbations concerning data or
computations can be studied by the application of the Monte Carlo method. Accurate sets of data
are perturbed by random data corresponding in their distribution and correlation as closely as
possible to those of the real data inaccuracy (Überhuber 1995).
Within HITERM the Monte Carlo approach is used to find a source-strength probability function
with the help of measured input parameters and user specified uncertainty ranges for these parameters.
The computation of the probability function requires thousands of runs of the same code with
varying parameters. In the case of a very complex multi-parameter release module this can be very
time-consuming. Additionally, the dependencies of the individual parameters are hidden.
A more general approach is used in automatic differentiation. With automatic differentiation,
the sensitivity of the result with regard to the individual parameters can be quantitatively
specified. This is especially useful for the preselection of parameters which have to be
varied with the Monte Carlo method. If a new release
module is added, a sensitivity analysis can be executed using automatic differentiation to
filter out the most sensitive parameters for a later Monte Carlo simulation.
Additionally, the automatic differentiation approach
defines which parameters have to be determined with maximum accuracy.
To allow a more realistic determination of the release, a Monte Carlo method
is used to construct a probability function of the source-strength for
different times of the release duration. With this method, all uncertain
parameters are varied in a selected range.
The parallel implementation of the source term models uses a generalised
mask to run different types of source term models. The user must specify
the number of input parameters which are not precisely known. In addition,
an uncertainty range must be given for every parameter. This range can
vary in positive or negative direction.
Example: Monte Carlo simulation for an evaporation module
Source strength probability function
A probability function of the source-strength is constructed using
millions of runs of a deterministic
release model. The input parameters of this model are varied over the given
uncertainty range using a random generator. Figure 1 (above) shows an example of
a source-strength probability function for evaporating pool release for
a given time.
The input parameter variations for this test run were:
-
cloud cover (0 - 100 %)
-
surface wind speed (20 %)
-
ambient air temperature (-20% / +30%)
-
initial depth of the pool (20 %)
-
total release volume (10 %)
-
total release time of the liquid phase (10 %).
The results exhibits an asymmetric distribution whereas neither the source-strength
at the mean nor at the maximum of the probability function is equal to
the "exact value" (which is the deterministic outcome of the model by neglecting
the uncertainties).
If the release is a complex function of parameters (which is normally
the case), the Monte Carlo run is very useful for finding even the most
probable values for the source-strength. This is due to the fact that even
the most probable values can be considerably different from the exact one.
The mean and the emission rate at the 95th percentile of the time dependent
source term probability function are used as an input for the Lagrangian
dispersion model. The mean represents the most probable emission rate,
whereas the 95th percentile represents a worst case scenario for the emission
rate excluding a small probability of 5 percent of higher emission rates.
The Wind Field Model
The diagnostic wind field model is based on the well-established and evaluated
DWM (EPA). To allow the user a faster selection of the meteorological condition
where only sparse observational data is given, some new parametrisation
features were added.
Two examples show the typical wind flow in a hypothetical complex terrain.
The measured meteorological values at 5 m above ground parameters were:
-
wind speed 3 m/s
-
wind direction 300
-
surface temperature 290 K.
The assumed roughness length was 0.5, a quite typical average value. The
numerical grid has a horizontal resolution of 100 m x 100 m. The complex
orography is characterised by fairly steep rise to a mountain range in
the eastern parts of the domain, some isolated smoother hills and some
sharp gashes of valleys between the range. The simulation was carried out
for the same measured values but for different hypothetical stability classes.
Figure 2 (left) represents
the flow under very stable conditions, occurring quite often during the
night. The wind is forced to flow around the sides of the obstacles. Directly
upwind of the hill, some of the air is blocked and becomes nearly stagnant.
Additionally, there is a visible tendency to drainage winds (valley winds).
The underlying background color represents the orography.
In Figure 3 (right), the meteorological condition is very different. An
unstable vertical stratification in the lower atmospheric boundary layer
(happens often on hot summer days) leads to a considerably different flow
despite the same measured wind direction and speed. The wind flows over the
mountain range and exhibits its highest values at the top of the summits.
Additionally, there is a thermally generated uphill flow, the so-called
mountain winds. As demonstrated above, the diagnostic wind model is able
to describe the main features of air flow in complex terrain.
The Lagrangian Particle Model
Comparison of LPD results with a Gaussian solution for a simple case
Gaussian plume models are most commonly used for modeling point source
emissions. In case of an (inert) air pollutant and
homogeneous conditions the resulting plume represents an exact
solution. The restrictive conditions comprise a wind field with a rigid
advective wind which is constant in time and space and an even homogeneous
orography. Thus the horizontal and vertical wind fluctuations are constant
as well. The emission rate at the point source is permanent and constant.
For preconditions given as described, the concentration dispersion of
an arbitrary (inert) air pollutant at ground level is simulated by the LPD
model. It is compared to the analytical Gaussian solution calculated for the
respective conditions.
A horizontal grid size of 51 x 51
with a resolution of 100 m is given for the meteorological (input) and the
output grid. For the vertical resolution of the input the stratification
of a labil wind field is applied while for the output equidistant layers
of 10 m are chosen.
The inputs for both models are as follows:
Advective wind field:
The standard deviation of the velocity fluctuation
and the Lagrangian time-scale 
are required for the v and w component and the y, z component, respectively.
They are set to the following values:
The coordinates of the emission source are:
| coord_x |
= |
2 |
| coord_y |
= |
25 |
| coord_z |
= |
5 |
For the simulation time of 20 min the emission rate is assumed to be
constant with
In the LPD model the number of emitted particles per time step is set
to 200. Hence for a time step of 10 s each particle is associated with
a mass of 
.
For the Gaussian solution the air pollutant concentration
is calculated by:
with 
(x,y,z) the position in the three-dimensional
coordinate system and H the effective stack height.
For the test case the concentration was calculated at H= qz and
the level of z = coord_z.
The standard deviations 
in the y and z direction, respectively, are
obtained from the Taylor Theorem based on
Taylor's homogeneous diffusion theory (Taylor 1921, Yamada 1987):
is constructed analogous.
Figure 4 (above) represents the resulting dispersion of an air pollutant
at the end of the simulation time (20 min) under the described conditions
and the level of the source height. The Lagrangian dispersion in the right
figure shows a good reproduction of the Gaussian solution (left).
The quality of the Lagrangian dispersion is also displayed in the figures
below (Figures 5 and 6). The diagrams show the alteration of the concentration along an
intersecting line for the Gaussian solution and for the LPD dispersion at
identical locations.
In Figure 5 (above), a line intersecting parallel to the main wind
direction was chosen whereas in Figure 6 (below) the intersecting line
is nearly perpendicular to the main dispersion direction.
the diagram in Figure 5 proves the apparent good reproduction of the
Gaussian solution
by the Lagrangian dispersion calculation along the centerline of the
pollutant plume. The further the distance from the centerline (Figure 5)
and the emission source, the larger becomes the stochastic
error in the LPD model. The stochastic effect is due to the principle of
the Lagrangian model theory. It can be reduced by enlarging the number
of particles emitted per time step.
Comparing the LPD dispersion and the Gaussian solution, Figure 6
indicates that the error effects are relatively small.
Discussing this phenomenon, it has to be considered that the
solution of Gaussian models gives an exact analytical resolution and hence
are not subject to any stochastic influence.
Test runs with different numbers of emitted particles
Lagrangian models are based on the determination of trajectories of
individual particles.
The figures in this section show the
dispersion plume for different numbers of emitted particles per time step
- from left to right, top to bottom: 50, 100, 200 and 300 particles.
The number of particles emitted per time step influence the quality of the
output, as well as the computation time. The more particles are released
the clearer is the shape of the plume. The figures also show that with
a certain number of particles asymptotic effects appear.
These effects depend on the presently given conditions, like
meteorology, orography, etc., and the time parameters (time step,
simulation time).
A limiting factor for the number of particles emitted per time step is
the computational burden and the available memory.
To achieve reasonable results in a reasonable time - which for risk
management has to be as short as possible - a compromise has to be
made for the appropriate number of particles.
The LPD
model represents a good reproduction of the Gaussian plume under
convective conditions. It can be assumed that the modeling of pollution
dispersion by the LPD model also holds for stable meteorological conditions.
The number of particles emitted should be chosen in the range of 100
to 200 particles per time step. The default value in the LPD model
version is set to 200. The smaller the number of particles, the larger
is the effect of the stochastical error, and thus the coarser the result
(see figures). A larger number of emitted particles often
shows a nearly proportional increase in computation time.
Dispersion calculation under different meteorological conditions
For a complex orography the effect of different meteorological
conditions on the dispersion calculation by the LPD model is discussed. A
point source for the pollutant emission was chosen and the
horizontal reference layer set to the source height.
The isolines in Figure 8 (below) denote the height above sea level in m.
Equal preconditions as for the emission rates, simulation time, time
step, etc. are assumed.
|
|
|
Representative for the tests, two cases have been chosen for display.
The left part of Figure 8 shows the dispersion calculated for a slightly
unstable wind field with a mixing height of 800 m (stability class 3).
In the right of Figure 8, the dispersion in case of slightly stable
conditions with a mixing height of 300 m (stability class 5) is displayed.
For unstable meteorological conditions, the area affected by the
pollutant is much wider (left part of Figure 8) than for stable case
(right part of Figure 8) in the considered layer. The left part also
shows that high concentrations of the pollutant occur only near to the
emission source due to larger diffusion, causing, e.g., faster rising
effects in an unstable wind field.
Under the given stable conditions the pollutants rest more at the
ground/source level and perturbation across the main wind
direction is less. Therefore the region affected by the pollutant
dispersion is smaller but concentrations are higher
(right part of Figure 8).
The simulated effects are as expected (also for other than the
displayed meteorological conditions) and reproduce known observations
gained by field experiments. This implies that the LPD model provides
reasonable results for different kinds of meteorological conditions.
The conclusion can be drawn that the LPD model is appropriate
for dispersion calculation in the given context.
HITERM is designed to provide HPCN-based decision support
for technological risk analysis, including both risk assessment and
risk management aspects.
As a Decision Support System
it uses HPCN technologies to:
- generate decision relevant information fast and reliably;
- to explicitly address uncertainty as the determining feature risk
analysis;
- and deliver it to the user fast and in a directly usable format.
HITERM implements several decision support paradigms in parallel,
and integrated with each other, reflecting the complex nature of the
application domain, but also the scope of the intended applications ranging
from strategic planning (risk assessment)
to training and real-time emergency management.
The DSS paradigms applied are, basically
comparative analysis and (multi-criteria)
selection, based on scenario analysis, primarily applicable in
the planning domain;
rule-based classification, applicable to both the planning
and real-time domains;
uncertainty analysis and sensitivity analysis, that is applied
to the criteria used both in comparison and classification;
and real-time rule-based guidance, applicable to the
real-time training and emergency management domain.
These paradigms are implemented, respectively, through:
a set of tools for the direct comparison of HPCN simulation
generated options or scenarios and associated statistical analysis;
a backwards chaining rule-based expert system linked to the
simulation models;
Monte Carlo Analysis and a Direct Differentiation approach;
a real-time forward chaining rule-based expert system for
emergency management support.
The ultimate objective of a computer based decision support system
for technological and environmental risk management is
to improve planning and operational decision making processes by
providing useful and scientifically sound information to the actors
involved in these processes, including public officials, planners
and scientists, industrial operators, emergency management personnel
and civil defense forces.
This information must be:
timely in relation to the dynamics of decision problem:
this is particularly challenging in real-time decision
making situations such as in emergency management;
accurate in relation to the information requirements;
directly understandable and usable;
easily obtainable, i.e., cheap in relation to
the problems implied costs.
Decision support is a very broad concept, and involves both rather
descriptive information systems that just demonstrate alternatives,
as well as more formal normative, prescriptive optimisation approaches
that design them.
Any decision problem can be understood as revolving around
a choice between alternatives.
These alternatives are analysed and ultimately ranked according to a
number of criteria by which they can be compared;
these criteria are checked against the objectives and constraints
(our expectations), involving possible trade-offs between conflicting
objectives.
An alternative that meets the constraints and scores highest on the
objectives is then chosen. If no such alternative exists in the
choice set, the constraints have to be relaxed, criteria have to be
deleted (or possibly added), and the trade-offs redefined.
This choice process may be iterative, and at leisure, when the
decision maker(s) can experiment with criteria, objectives, and
constraints, to develop his preference structures and reduce the
set of alternatives step by step until a preferred solution is found.
Or this choice process may be a dynamic, real-time sequence of numerous
small but interrelated decisions in the form of (alternative)
actions that need to be taken under sometimes extreme pressure
of time, and under considerable uncertainty.
However,
the key to an optimal choice is in having a set of options to choose
from that does indeed contain an optimal - or at least satisfactory - solution.
Thus, the generation or design of alternatives is a most important,
if not the most important step.
In a modeling framework, this means that the generation of scenarios must
be easy so that a sufficient repertoire of choices can be drawn upon.
The selection process is then based on a comparative analysis of the
ranking and elimination of (infeasible) alternatives from this set.
For spatially distributed and usually dynamic models -- natural
resource management problems most commonly fall into this category --
this process is further complicated, since the number of dimensions
(or criteria) that can be used to describe each alternative is potentially
very large.
Since only a relatively small number of criteria can usefully be compared
at any one time (due to the limits of the human brain rather than computers),
it seems important to be able to choose almost any subset of criteria out
of this potentially very large set of criteria for further analysis, and
modify this selection if required.
While this classical approach is most applicable for planning situations
where the decision maker is at leisure to contemplate alternatives,
the management of an emergency situation in real-time does not offer
these luxuries: here efficient decisions have to be taken in a minimum of time,
under considerable psychological pressures, and often under large uncertainty.
Real-time decision support can therefore build on the above
concepts of comparative analysis, but must implement them in
an efficient and effective way that minimizes time
and effort by the decision maker (or rather operator) during an emergency.
Instead of offering, and manipulating many alternatives subject to the
decision makers preferences, here we must present a best alternative
(or a very small set of efficient alternatives with a clear ranking and clear
trade-offs), i.e., strategies, plans, or a set of actions in the form of
a rather firm guidance, but with enough context information
to allow the operator to exercise ultimate judgment and decision power.
This is based on a set of a priori defined strategies and options,
that are adapted dynamically depending on context,
i.e., the characteristics and circumstances of the evolving emergency.
In HITERM, the decision support approach chosen for the
strategic planning applications is primarily constrained
by the characteristics of the underlying system. These are:
dynamic, with a typical time resolution in the order of minutes;
spatially distributed, with spatial resolution ranging from the street
level (meters) to the regional air quality grid (100 m);
highly non-linear and involving time-delays and memory in the
cause-effect relationships, e.g., cumulative exposure.
These problem characteristics preclude any straight forward optimisation
approach.
Consequently, HITERM uses an approach centered on
- Scenario Analysis and the
- comparative evaluation of scenarios.
This can lead, eventually, and if the set of alternatives is reasonably large
and complex (i.e., of high attribute dimensionality) to
- discrete multi-criteria optimisation.
Scenario Analysis
In a DSS framework, Scenario Analysis supports the user to explore a
number of WHAT -- IF questions.
The scenario is the set of initial conditions and driving variables
(including any explicit decision variables) that completely
characterize the system behavior, which is expressed as a set of
output or performance variables.
Control or Decision Variables
The control variables or decision parameters the user
can set to define a scenario include:
- industrial site or location along one of the networks
(transportation or pipelines);
- accident conditions (e.g., spill, fire, explosion);
- receiving environment (air, soil and groundwater, surface water;
- meteorological conditions (primarily wind and temperature)
or hydrological conditions (flow);
- mitigation measures.
Editing functions
An important aspect here is the translation of the more or less technical
(and sometimes cryptic) model data requirements into concepts and terms
that are directly problem relevant and directly understandable to the user.
A general concept used is the specification of most user defined values in
relative terms and as a selection from a list of
predefined, valid and meaningful options.
The editing (and estimation of parameters)
within HITERM is supported by an embedded expert system that
can be used to ensure
- completeness
- consistency
- plausibility
of any or all user inputs.
All parameters are represented by Descriptors which are terms used
in the expert systems Knowledge Base.
Descriptors are Objects that have
several Methods available to determine or update their value in a
given context (the scenario). One such method is to ask the user through
an interactive dialog box.
The complete syntax of a Descriptor definition is described in
Deliverable D06.2, Decision Support and Expert Systems, Technical Report.
A concrete (but simple) example is the Descriptor
exposed_area, used for a storage container mass:
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 volume of the container or vessel ?
ENDDESCRIPTOR
The upper limit that can be used, is, however, constrained by the
selection of the source (e.g., a storage container or
transportation vehicle) and the maximum mass of a hazardous
substance it contains.
Performance or Impact Variables
The performance variables measure the overall behavior of the system
(in terms of a set of partly implicit and partly explicit objectives)
in an aggregate form. This is clearly necessary for simple reasons of
cognitive limitations.
Visualisation
An additional important function provided by the user interface is the
visualisation of the scenario parameters, i.e., the current status of an emergency,
and the related model results. Due to the relatively large
number of variables (spatially distributed, dynamic, multi-parameter)
graphical and symbolic representation is used to summarize numerous, and in
particular spatially distributed and dynamic data.
Details on the user interface and visualisation aspects in HITERM
are described in Deliverable D04,
Visualisation and Multi-Media.
In summary, simple scenario analysis results in a single (set of)
result(s), that is (implicitly or explicitly) compared against a set of
(absolute) objectives (expectations) and constraints such as environmental
or health standards.
Sensitivity, Uncertainty, and Robustness
The Deliverable D05
provides an overview of Model Calibration and Uncertainty
Analysis.
From the DSS point of view, uncertainty is simply another of
the (multiple) criteria that needs to be displayed and evaluated.
In any cases the uncertainty, e.g., represented by a set of
Monte Carlo solutions, can be reduced to a set of discrete scenarios
by selecting, for example, different probability levels (or risk level)
in the reconstructed probability distribution.
As an example, given a set of Monte Carlo solutions we can consider as samples,
we will obtain a frequency distribution of the number of people exposed.
Fitting an appropriate probability distribution (with an appropriate
transformation), we can select now select a value at two standard deviations
from the mean, interpreted as a 95% probability level. Thus, based on the results of
the Monte Carlo analysis, the user can select and compare
different probability levels of exceeding or staying under,
certain threshold values of key criteria.
As an alternative, the concept of expected value
can be used to characterize the probabilistic nature of the
simulation results.
Representation of Uncertainty
Explicit representation and treatment of uncertainty
is implemented at several stages in HITERM.
Examples include:
- PVM model group: Monte-Carlo implementation of the
(parallel) spill and pool-evaporation model;
the main parameters (defined by
external sensitivity analysis) are sampled in a Monte-Carlo
framework; from the resulting distribution of solutions,
the mean and 95% level are used as input to the Lagrangian model
to generate two solutions.
- SOURCE model
computes the dynamic source
term for the atmospheric dispersion models, soil infiltration,
and determines the probabilities for fire
and explosion with the respective input data values
(available mass); the user can determine the level of uncertainty for
the input parameters (expressed as a percentage around the mean,
the type of a priory distribution to be sampled, and the
number of Monte-Carlo runs. All these values are provided as
defaults, but can be modified on demand.
The results are shown in four parallel windows:
- upper left: ensemble of solution for evaporation rate against time;
- lower left: ensemble of cumulative mass evaporated
- lower right: frequency distribution of total mass
- upper right: frequency distribution of evaporation rate for a selected
class of the mass distribution.
By default, the system selects a source term for the dispersion models
from these results based on the 95% percentile range; alternatively,
the user can select an arbitrary class range from the mass distribution
for the subsequent dispersion computations.
Probability of fire and explosion
During the run, the probabilities of fire and explosion are indicated in two
separate windows. This is based on the temperature range versus the
flashpoint of the substance for fire, and the local concentration over the pool
versus the upper and lower ranges for explosivity.
These values are reported at the end of a run as a
probability for fire and explosion, depending on the
duration of fire or explosion conditions.
- GROUNDWATER
Another example of the direct representation of uncertainty
in the simulation models is implemented for the determination
of response times for soil contamination.
The simple screening model estimates the time a given
substance will need to reach the groundwater table,
based on viscosity, soil permeability, and the distance to the
groundwater table.
For the simulation, the user can again override the defaults for
the uncertainty around the input parameters, soil permeability and
viscosity.
The display shows the a priory distribution of the two main input
parameters, viscosity and soil permeability, and the frequency
distribution of results below.
The indicate:
- the deterministic solution
- a worst case 95% value
- the mean value of the frequency distribution
- the median value of the frequency distribution
of the response time (the time until the substance
reaches the groundwater table).
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 HITERM
with a real-time, forward-chaining expert system (RTXPS)
as the driving engine.
The implementation in HITERM 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
- 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:
ACTION
Some_action
A alias_name
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)
ENDACTION
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 V keyword introduced the array of legal values or states.
P denotes the timer for pending requests in seconds.
Q records contain the textual (hypertext syntax) part of the ACTIONS
REQUEST.
Please note that the
\value{descriptor_name} 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.
One or more optional F records enumerate functions that the action will
trigger automatically, and in sequence, when the user presses the DO IT
button the ACTION REQUEST DIALOGUE window.
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
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.
The general syntax of ACTIONs and Rules is similar to the
Rules and Descriptors of the current 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.
Running RTXPS in HITERM
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;
RULE RULE_ID
IF TRUE
THEN first_action => ready
ENDRULE
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 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 dialog
box to enter a value for an EMERGENCY PARAMETER, starting an
inference chain (backward chaining ...) to estimate such a value,
or starting 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 provides 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.
A generic DSS tool: Rule-based Classification
A major problem in any computer-based system is to obtain reliable and
accurate information from the user, and to translate efficiently
between the language easily understandable to the user and the
technical information requirements and formats used by the computer system.
The general logic and syntax of the backward-chaining embedded expert systems
approach in HITERM was described above under Editing functions within the
framework of Scenario Analysis. This covers the domain of user input.
A similar approach can be used, however, to classify complex systems results
(e.g., the results from a spatially distributed, dynamic, multi-parameter model)
into a simple and directly understandable statement through linguistic
classification.
In the embedded expert system, this is accomplished through the hybrid nature of the
basic concept, the Descriptor object; its possible states (legal values)
can be expressed both symbolically or numerically as the example below for
storage containers illustrates:
DESCRIPTOR
exposed_area
T S
U ha
V none [ 0, 0, 0]
V very_small [ 0, 2, 3]
V small [ 3, 5, 8]
V considerable[ 8, 10, 20]
V large [ 20, 50, 80]
V very_large [ 80,100,300]
Q What is the total area affected by this accident,
Q ie., above a no-effects threshold ?
ENDDESCRIPTOR
Synthesis of model output
Another use of the backward chaining expert system is to provide
a synthesis of large model generated data volumes. The chain of
models used to simulate an accident scenario may easily generate
data volumes in the order of GigaBytes. These should, however, be
summarised in a few simple variables such as the number of people exposed,
the level of exposure, the area contaminated, estimated material damage
and a rough classification of the accident: these classifications are
needed to trigger the appropriate responses.
Starting from the dynamic model results, specific aggregate parameters are
computed as a post-processing step or while the model is running,
updating values for maxima of threshold related parameters.
In the case of the atmospheric dispersion models, the critical parameters are
the extent of the area covered, the population exposed in this area, and time
factors such as the time until the first houses are reached by the cloud, and the
duration of the exposure.
Starting with the model result and a (default or substance specific)
concentration threshold, the system computes the area of the plume that exceeds the
threshold (shown in yellow), the populated area (shown in blue), and the
intersection (shown in red). Based on the known or estimated population density,
two key parameters, namely the area exposed and
the population exposed are computed and indicated (see above).
In addition to the model derived values (which are setting the corresponding
Descriptors in the expert system), a user-defined threshold value is used
in this evaluation. This can either be derived from a set of rules,
or from the hazardous chemicals data base (e.g., based on the Seveso II
classification).
In the simplest case, the user can directly set that threshold
value with the expert system's editing functions.
The behaviour of the editing function is data driven:
if the only Method defined for
the corresponding descriptor is the Question to the user,
a simple editing box will be used. If, however, one or more Rules
are defined in the descriptor declaration, the will be offered to
perform a rule-based inference. For a detailed description of the data formats of
the Knowledge Base files, refer to the
Technical Manual of deliverable D06.
In the next step, the expert system attempts a classification of the emergency in
terms of:
- Public health effects,
- Environmental damages, and
- Material damages.
In terms of the backward chaining inference
procedure, these three Descriptors are Target Descriptors i.e.,
the are at the top of the respective inference trees.
Each of them has a set of associated Rules that use Descriptors as their inputs.
The Descriptor values are set by the model output in the step above,
but can, in principle, be overwritten by the user interactively if he
repeats the (automatically triggered) inference procedure.
If all the necessary data (Descriptor values) to reach
a conclusion are available, the expert system will directly arrive at,
and display in a symbolic format, the results in the Accident Summary Box.
If any of the necessary input values are missing, the Dialog Box
will be used to obtain the information from the user.
This can be entered by either choosing one of the symbolic labels
and associated default numerical value;
by using the slider tool of the dialog box; of by directly typing in
the required numerical value. The default value, if defined or set,
is indicated in the blue header bar; in the above case,
it is set dynamically from an interpretation of the model output results.
The small information icon in the header leads to a hypertext page
that provides additional background information on the Descriptor in
question to assist in setting its value.
Benefits and functions
The integration of the expert systems in the HITERM framework
has several major benefits, related to the different functions
of the rule-based expert system:
Rule-based guidance: the expert system can implement
any checklist-type procedure, that guides the user through a
number of subsequent steps, like working through
the steps of an emergency manual.
This takes a major load and responsibility from the operator
and simplifies the procedure, thus making it less error prone.
Time awareness: the real-time
components are time aware, all components are context sensitive.
This means that time can be used explicitly in the rules and
any evaluation, reflecting the realities of an emergency management
situation where it is essential to know not only WHAT will happen,
but also WHEN.
Context sensitivity:
an emergency situation is characterised by a large number of
interdepedent developments; every decision has to be taken
within the context of all the information available at
that point. This context sensitivity is implemented through
the Rules of the expert system that make any conclusion and
advise conditional to any number of input variables (the context)
the designer deems relevant.
Natural language interface: The rules of the expert system
are formulated in the near natural language syntax of
production rules, and follow first order logic.
This makes the rules and their processing easy to understand and follow.
Explanation facility:
to build user confidence, but also as a major didactic element,
the expert system can explain its function and conclusions
step by step, backtracking the inference chain one rule at a time.
- Symbolic representation:
The possibility to describe systems attributes in symbolic terms,
and thus approximately, matches the information available in an
emergency situation, where detailed quantitative estimates
or measurements are simply not feasible. The symbolic classification
and the use of ranges facilitates efficient interaction in
the absence of hard and reliable data.
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 realise 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.
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 organisation) 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.
The HITERM system is, in principle, an 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
distribution (gridded)
- Knowledge Base including Descriptors,
Rules, and ACTION declarations;
- configuration files such as the defaults,
templates for communication (fax).
Expert System
consisting of two main interlinked components, namely:
- the real-time forward chaining system (RTXPS) which is the
overall driver for the Emergency management branch,
- and the backward chaining system that supports all editing functions.
Embedded Models
currently including:
- 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
implemented with PVM on external
high-performance compute-servers or clusters, including currently:
- Spill (pool evaporation) model (with Monte-Carlo implementation)
- Diagnostic wind field model
- Lagrangian dispersion model
External data sources
connection to external http servers
that provide information such as:
- 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: forward chaining expert system |
XPS: backward chaining expert system |
| S: source model |
P: multi-puff |
B1: explosion (TNT) |
B2: explosion (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
Based on the findings of Deliverables D01 (Requirements and Constraints Report),
HITERM is designed for a range of application modes:
- risk assessment and planning:
- training for emergency management:
scenario analysis or real-time expert system;
- operational emergency management:
real- time expert system.
The system offers 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 a specific case; this case is simulated 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 suggests, 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 objects 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 on 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 (
http://www.ess.co.at/HITERM/MANUAL/manual.html).
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.
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.
Risk Objects: plants, regional elements, resource objects
Risk Objects
cover a broad range of elements used in the representation of a
technological emergency; they can be grouped into
- Sources of risk
- Targets or recipients
- Resources for risk management
- Hazardous chemicals
Sources of Risk
Within the scope defined for the HITERM system
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.
Storage containers
A lower-level object within a plant would be, for example, a chemical storage
container - the most likely source of a chemical spill, as it is
the primary source of hazardous chemicals within the plant.
Containers, like all plant related objects with the exception
of chemicals, are spatial objects, ie., their position within
the plant is known and can be used for modeling.
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 organised
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.
The municipality can include sub-locations (e.g., called Frazione
in the Italian test case). Please note that the
class hierarchy that can be represented in HOT
is open, i.e., an arbitrary number of layers and elements can be
represented simply 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.
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.
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.
Since hospitals, as every other risk object, are geo-referenced,
additional tasks such as optimal routing to the nearest appropriate
hospital can easily be added as functions related to this object class.
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.
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
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 be 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.
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 organised 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 development 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 a 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 Deliverable D12, 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.
Optional components include external data acquisition
units and their database servers, as well as wireless,
mobile clients.
HPCN Resources: Compute Servers
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: Deliverable D02.2,
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;
- by a cluster of computers linked by a high-speed network.
HPCN Resources: Real-time data acquisition
As an important feature for real-time emergency management,
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 dynamic model calibration
- location information (GPS) primarily for vehicle and mobile client
position data.
The communication protocol used is again based on TCP/IP and http.
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.
The current HITERM Demonstrator is based on the X11 user interface;
for the Java components, only first test examples for the
implementation on mobile, wireless clients have been developed.
Implementation Considerations
The primary implementation platform for HITERM Demonstrators was
- 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.
The following application scenarios have been used as the basis for
the HITERM demonstrator; they provide the data and practical testing
ground in an industrial context, involving representative end users for the
evaluation of the approach.
Chemical process plants (Italy)
using the example of the Ponte S.Pietro industrial district in
Bergamo, Northern Italy, a number of accident scenarios following
the Seveso II guidelines for the plants in this area have
been formulated and simulated.
The primary objective of the Italian Demonstrator was to show
a completely integrated operational system including
the transparent integration of high-performance parallel models
(spill, wind field, Lagrangian atmospheric dispersion model) based on PVM
and a workstation cluster. |
 |
The basic scenario for stationary objects (Seveso-class process
plant or storage plant) and transportation of hazardous goods to
and from the loading docks of process and storage plants offers the
possibility for partial pre-processing (e.g., of the geographical data
of a well defined site), as well as the use of fixed data acquisition and
monitoring systems.
With the type and amount of a substance leak or spill, as well as the
meteorological conditions as the main variables, the accident consequence
simulations are performed similar to the transportation accident case to
support emergency response measures or related training exercises.
The main case study for process plant accidents, coordinated
by SYRECO, was Ponte S.Pietro near Bergamo,
Northern Italy. This area covers about
40 km2, distributed over 8 communities with about 30,000 inhabitants. 10%
of the area is under industrial land use. A number of Seveso-class chemical
process plants and so-called Level 2 installations with a total of more
than 3,000 employees operate in this area. The main hazardous substances
include Acrylate, Acrylonitrile, Butadyene, Styrol, Methyl Alcohol and
Alifatic Alcohols, Formic Aldehyde, Ethylene Oxide, Phenol, Toluene, Amine,
Flammable Solvents, Pesticides, Cyanides, LPG, etc, distributed over about
500 storage tanks from 5 to 1,500 tons of capacity and a total quantity
of around 10,000 tons of toxic and flammable substances.
In addition to their storage and use in the process industries, these dangerous
substances are transported by road, mainly through the A4 Milan-Venice highway
and other roads of provincial interest. The average daily traffic involves
16,000 vehicles. About 10% of these are trucks carrying hazardous substances:
more than 10% of these transport toxic, another 45% flammable substances
with a flash point below 65 degree Centigrade.
SYRECO has performed extensive safety audits and analyses in this area,
including process plants, storage locations, and the transportation of
hazardous substances, and compiled large amounts of recent safety related
data and the necessary environmental background information. This did
form the basis of the simulation exercises, which covered main possible
major accident scenarios as foreseen in the recent amendments (COM(94)
4) to the Seveso Directive (82/501/EEC, 87/216/EEC).
Railway transport (Switzerland)
The Swiss Demonstrator concentrates on the transport of hazardous
material by train, across the strategic North-South Alpine
corridors. The example of the Reuss valley as a steep alpine
valley with an extreme orography poses a considerable challenge
to the atmospheric dispersion models, but demonstrates
the need for advanced complex models and thus high-performance
computing to obtain realistic and reliable forecasts of the
evolution of an emergency. The case study implements the RTXPS
real-time expert system as the decision support framework
for emergency management. |
 |
The case study addressed the release of
a hazardous substance to the atmosphere or into a water body (surface or
possibly groundwater) from a train accident.
The train uses an emergency information system to broadcast
its position (GPS derived, through GSM) and freight data (substance, amount)
to a control center running the HITERM main system. From this information
the control center with (access to) the appropriate HPC resources initiates
further data collection (for example, from the nearest meteorological
station(s)
or an appropriate hazardous chemicals data base), loads the local GIS data,
and initiates the simulation of the accident consequences to guide emergency
response measures.
The consequence simulation involves complex dispersion modeling (atmosphere,
soils, water bodies), parallel (Monte Carlo) error and sensitivity analysis,
and the graphical visualisation of the accident consequences (for example,
population exposure in space and over time in the form of interactively
animated topical maps), as well as providing integrative instructions and
decision support for field personnel or in a training situation. Using
a discrete multi-criteria DSS approach to suggest optimal strategies to
the operators, the interactive interface allows people on site to introduce
their observations, constraints, and objectives. This information can be
accessed remotely (again through GSM phone links or dedicated channels)
through TCP/IP Internet protocols and IP/ISDN with simple, mobile and hand-held
terminal equipment (PC, laptop running http clients).
The case study,
under the primary responsibility
of ASIT, addressed transportation risks on railways in the
Canton of Uri, part of the Gotthard alpine transit corridor linking France
and Germany with Italy. This provides a model for several similar
North-South
alpine corridors of strategic economic and environmental importance. Detailed
geographical, environmental and transportation systems data, as well as
existing traffic telematics systems (using GPS and GSM) are already in
place.
The study involved the evaluation of the
HITERM system under the special conditions of the alpine region
(narrow valleys, long tunnels, high traffic densities).
A number of Swiss authorities,
including the National Alarm Head Office, Chemical Accidents Intervention
Forces of the Canton Uri, and the Swiss Federal Railways
Office, as well as the Association of Chemical Industries have
expressed their interest in the project.
-
Road transport (Portugal)
The Portuguese test case concentrates on a very practical case:
more than a hundred fuel trucks make the daily trip from the Aveiras fuel
depot to the Airport of Lisbon along the major North-South highway leading
into the capital. Accident scenarios for the fuel trucks include fire,
explosion, and soil and groundwater contamination. An on-board
alarm unit with GPS/GSM communication triggers the
RTXPS expert system. |
 |
The impact assessment for road accidents involving hazardous goods
involves a number of real-time communication elements:
the identification of the truck and the determination of its location,
based on GPS/GSM in an on-board unit installed in the truck, operated
by the driver or automatically in the case of an accident.
The assessment also considers dynamically updated environmental criteria
to accurately predict accident consequences, based on
time-variable local conditions such as temperature, precipitation, wind speed
and direction, surface water flow, in addition to traffic related information.
The models used (spill/evaporation, fire, explosion, atmospheric dispersion,
and infiltration/soil contamination) are all run as stochastic models
in a Monte Carlo framework.
Given a dynamically generated alarm from a vehicle in transit,
the possible impacts of the accident are determined through simulation
of accident scenarios based on the hazardous substances involved, their amount, and
the degree of damage to the vehicle, i.e., the nature of the accident.
Given the requirements of a large fleet of hundreds of vehicles, and the
inherent complexity of the risk calculations (e.g., involving heavy gas
dispersion modeling, fire and explosion models)
the need for HPCN should be obvious. An additional
complexity can arise through the inclusion of on-line sensitivity analysis,
where the robustness of the solutions is tested against increasing levels
of data and parameter uncertainty.
The vehicle fleet (tanker trucks with hazardous cargo) of PETROGAL and
its Portuguese distribution (road) network, and in particular the highway
between Lisbon (airport) and the fuel depot and loading station in
Aveiras north of Lisbon, have been used as an example.
The Petrogal fleet includes:
| |
Petrol and Diesel |
Fuels, mixtures |
Asphalts |
Chemicals |
| Vehicles |
185 |
24 |
9 |
6 |
| avg. tons |
4,163 |
455 |
191 |
127 |
in transit
annual km |
13,945,000 |
1,754,000 |
1,035,000 |
793,000 |
In addition to the three major case studies,
and a number of smaller applications, primarily designed to
test and illustrate specific features and functions of
the system have been built.
To test and validate the concepts and tools developed in HITERM,
they were applied in three regional case studies with varying emphasis:
- a chemical process plant in Italy;
- a railway transportation case in Switzerland;
- a road transportation case in Portugal.
Assessment and evaluation of the three case studies is based on
a common set of validation and evaluation criteria that
are being applied to the experiences of the Demonstrator installation, its operations,
and the feedback from potential users in a number of demonstrations of the system.
The latter part includes an analysis not only of the technical aspects
of the system such as performance, reliability, efficiency, ease of use etc.,
but also the equally important institutional and ultimately commercial aspects,
summarised in a benefits analysis for each application, that is then generalised
for the project as a whole.
The three application scenarios described above have
been used as the basis for the HITERM Demonstrator; they provide
the data and practical testing ground in an industrial context,
involving representative end users for the
evaluation of the approach.
Each of the three test cases was dedicated to a different aspect of
technological risk management, namely:
- chemical process plants;
- road transportation accidents;
- rail transportation accidents.
While all three cases share the same software framework,
their configuration and data make them very different.
At the same time, they have been selected and configured to
concentrate on, and demonstrate, different aspects of the HITERM system:
- the integration of parallel high-performance computing models;
- the integration of artificial intelligence, and in particular, real-time
expert systems functionality as a decision support tool;
- the integration of communication elements such as a GPS/GMS on-board
alarm unit, automatic downloading from external data bases, and polling
of real-time sensors.
The objective of the case study assessment and evaluation phase
was to validate the operation of the HITERM demonstrator within
the context of a variety of application domains (see above).
The validation activity took place
at the three demonstration sites: Gavirate, Bern, and Lisbon.
The assessment and evaluation process did seek to confirm that the demonstrator
implements the specified user requirements as defined in WP 01,
Requirements and Constraints Analysis. The demonstration
activity did allow a range of potential users to be exposed to the Demonstrator
in a series of presentations at each site.
This facilitated feedback on the validity
of the originally agreed requirements, their method of implementation, new
requirements and the general acceptability of the system for operational
use. It did also provide opportunities for publicising the demonstrator
as part of the dissemination activities (compare Deliverable D12.0,
Dissemination and Exploitation Plan.
Together with the local users the detailed criteria for success of the
evaluation activity have been defined. These include comparisons of the
HITERM results with historical and observation data on
accidents (where available) as well as well as results derived independently
(eg., available from literature including Safety Reports).
The same evaluation process has been applied at all three evaluation sites:
SYRECO at its offices in Gavirate; ASIT at its offices in Berne; and Petrogal,
with the support of LNEC and the FCCN was responsible for the validation
in Lisbon.
In the following the individual results (summarised in the Deliverables D08,
D09, and D10) are compared and integrated across the three sites.
The objectives of the assessment and validation include:
Technical feasibility:: validation of the technical
infrastructure, client-server setup, ease of installation,
reliability, robustness
Performance: better-than real-time simulation modeling
for complex scenarios
Accuracy: comparison of model results and
model-generated decision support with benchmark results
and expert assessment
-
Relevance: evaluation of overall performance and usefulness
and usability of the information provided by peer groups and
potential users in industry and public administration.
These criteria are compiled for each of the three Demonstrator implementations.
While some of them would, in principle, lend themselves to quantitative treatment,
the assessment has been done on a qualitative basis mainly.
Validation criteria have been defined according to the following topics
including both technical capabilities and marketing perspectives:
System should be easily implemented and HW/SF costs should not be an obstacle
for exploitation basing on the state-of-the-art
System performance should allow for better-than-real-time evaluation
On-line connection should be available and tested, integrating dynamic analysis
and field data retrieval
User comprehension and satisfaction has to be verified by demonstration to local
municipalities, industries and authorities
Interviews and reactions of potential end-users during the demonstration of the
system have been
used and systematically collected by questionnaires as validation criteria.
SYRECO has presented the system in different contexts, such as:
- National congress on Industrial risk analysis and Technological Emergency
management in
Pisa (October 1998) together with ESS, where also a paper has been presented.
- Presentation during a course for emergency managers organised by Regione Lombardia in February 1999.
- Demonstration to the Civil Protection Bureau of Regione Lombardia and its responsible in April 1999.
- Demonstration to industrial representatives and population during the SYRECO Emergency
Training Center inauguration in Filago (Ponte S.Pietro Area) in October 1999.
- Demonstration to a wide sample of majors of municipalities in Ponte S.Pietro Area to support
the proposal of an integrated Civil Protection and Emergency plan in Ponte S:Pietro area in November 1999.
-
Many other technical demos have been gived in our offices to expert groups
and individuals.
A common relevant validation criteria was the assessment of the capabilities of
the potential user
to understand what the system is doing and the usefulness of the information he
can get.
Validation Results
During the first phase of HITERM project development and test case implementation, the first two
validation objectives have been well satisfied, that is technical feasibility and performance of the system.
Validation by expert assessment, peer group and potential end-users, as far as usefulness and
usability, was part of the second phase of the Italian test case implementation,
but this could only be
partially completed, since no comparison in benchmark exercises with other system results could
be done by now, due to practical difficulties in doing this.
Applicability of HITERM to industrial emergency management demonstrate the reliability, flexibility
and robustness of the technical infrastructure and installation of the system architecture and client-
server set-up.
The system could be easily installed and re-configured, changing the initial plan to use a
powerful HPC (Parsystec) in JRC Ispra, to a simple, but still efficient (in terms of performance) cluster
of work-stations installation by connecting the partners development machines
and rented ones, caused by the fact that (although initially promised) access and use of JRC machines was not possible.
As far as performance is concerned, the application of the HITERM evaporation and Lagrangian
dispersion model to the accident scenarios, characterising the Italian case study, showed that the
main objective of better-than-real time performance could be obtained by the simple cluster configuration unsed for
the Italian demo with a reduction of a factor ten compared to normal operating resolution time.
Validation experiments
For the validation of the performance and the accuracy of the system,
the Swiss Demonstrator had been tested in detail and the results of the modeling calculations
had been exactly investigated also with the help of experts in the various topics.
The relevance had been validated by sending a questionnaire to all
important potential users of such a tool or system in industry and
administration in Switzerland.
After analysing all the incoming answers of the potential users,
presentations of the Swiss Demonstrator had been carried
out (cantonal authorities) or are still planned (Federal Office of Transport,
National Railway Company (SBB), chemical intervention forces of Zurich, etc.)
for all those, who showed a strong interest in the new system.
Results of the Validation
Adequacy (conceptual)
The feedback concerning the conceptual adequacy is very positive. Especially
from the intervention-experts we got good judgments.
Technical feasibility:
We can`t say much about the installation and possible problems
(the demonstrator has been installed by ESS).
But after the installation, the
Swiss demonstrator proved to be reliable concerning the
installation. The installation of new timely limited licenses could
be done without any problems.
Technical (implementation) reliability
In the current version of the Swiss demonstrator the technical performance is
not satisfactory enough. The presentations of the demonstrator are not very easy
because of unexpected errors, impossibility to step back in some parts of the program
to show effects of changing input parameters etc., buttons switching wrong, .....
Performance and Accuracy:
The test of the Swiss demonstrator at the ASIT
office showed very satisfactory results concerning the modeling of various
chemical accident scenarios. All the tested
scenarios and the used applications produced results which are
very realistic in the eyes of the experts (wind field in the alpine
topography, extents of various chemical accidents, etc).
Tests and model verifications - also with help of external experts -
could show that the model accuracy can be judged to be good.
Most of the modeled simulations showed realistic results.
So the Swiss Demonstrator can be considered to be a useful tool for
simulation of accident scenarios and also as an
information system for decision support for authorities.
Looking at the different (sub-)tools within the Swiss-Demonstrator,
the remark has to be made that not everything seems to be very stable in
the present version of the Swiss Demonstrator. Repeated error
messages and unexpected program break downs happen more often than desirable.
Ease of use
If the program would be more stable, it could be considered to be very easy to
handle -
also for people who are not very experienced in operating computer programs.
The GUI for our opinion is quite OK and it is clear arranged. The buttons should have a
text to describe their function, because the meaning of the icons is
sometimes not clear enough.
The data link functionalities are useful.
Institutional feasibility (integration)
Concerning the institutional feasibility we see some problems in Switzerland because of
responsibilities in case of an emergency involving dangerous goods, which
lies clearly on cantonal level. The
railway companies have the duty to prepare preventive and safety measures but in
case of an accident the emergency management is on cantonal side. On the other hand
the federal supervisory authority has to coordinate the cooperation of the cantonal
intervention forces and the railway companies.
In this situation we see the use of a HITERM-system in a computing center which is
operated according to the agreement of
- the cantonal intervention organisations and emergency management
- the railway companies and
- the federal supervisory authority (federal office of transport).
Relevance:
The analyses of the questionnaire and the first Swiss demonstrator
presentations led to a quite positive judgment.
To be more specific, the results can be summarised the following way:
Most of the interested and involved potential users consider the System as
very useful and important for the simulation of various chemical accident/incident
scenarios for risk determination, but also as an
excellent information system for emergency forces for fast and
reliable decision support. Very often mentioned was also that the system would
be a good training tool for emergency forces and
very useful for the modeling of the extents of accidents with dangerous
chemical goods, too.
About half of all who answered our questions find it also a good
tool for the evaluation of the requirements
concerning safety arrangements and a practicable instrument for planning
and strategic analyses.
A bit surprising was the fact that nobody valued the tool as useful as an
alert-system for emergency forces.
Most of the potential users who gave us a feedback can imagine to use such
a system at their office or company.
Technical/economic feasibility (cost)
None of the potential users of a system like HITERM we contacted here in
Switzerland can see a solution involving a high performing computing system
for their needs (and their financial capabilities). They all use normal
PC-platforms (or occasionally single workstations).
After our analyses, a big problem seems to be the expected costs
for the purchase of such a system. Most of the interested authorities are
currently not equipped with sufficient and suitable hardware to run such a
system, so that they would have to buy the according hardware first.
But most of the authorities do not have budgets big enough
to allow them to buy a system in the financial dimensions of HITERM.
Only few potential users made a concrete statement what they are willing to
pay for such a system. But their ideas about these costs (system,
license and yearly maintenance) are in the region of some thousands of Swiss Francs,
which we consider much too low.
The main conclusion is that
HITERM was considered to be a very good and useful tool by potential
users in industry and public administration and many
decision makers could well imagine to use it. But only if the costs were low
enough.
So one of the main problem for the atractivity of the product seems to be the
purchase price, or more correctly, the expected total cost of ownership of the system.
As far as Italian experience is concerned, the main business potential now can be seen with:
Local communities like Ponte S.Pietro (the pilot implementation to be exploited in other similar
areas in Italy), including Municipalities and Industries looking at the new requirement of the
SEVESO II directive in which public information and training is one of the most important
features.
Civil Protection organisation in Italy is now moving (following the European trend)
the competence in co-ordination and intervention for large scale, long term emergencies, typical of
natural cataclysms,
from the central institutions and organisation (like Provinces and Prefettura) to
local organisation and management responsibilities at the level of municipalities and majors.
Regione Lombardia, which is proposing a pilot project in developing integration with safety
reports analysis and management with emergency planning and land use guidelines and useful
information, to support local Municipalities and Provinces (as potential remote clients in a
client-server architecture).
The implementation of the HITERM system is expected to produce benefits that can
be divided roughly in two categories.
- Response quality
- Response time
The impact in response quality, although hard to quantify, can be easily
understood if we consider that, in the current situation, risk assessment and
emergency management is carried out based mainly on previous experience of the
individuals which happen to be in charge at the time. This leads not only to a
bigger probability of human failure, but also to a lack of consistency in the
responses to emergency situations depending on the particular individuals
involved with each emergency. Also, there is no efficient way to propagate
information to everyone involved in dealing with the situation which can lead
to further inconsistency, as different agents are operating with different
background information.
In addition, we must also consider that - no matter how big the experience of
the individuals might be - they still do not have any quantitative data or
forecasts on which to base their course of action.
The HITERM system will provide not only consistent quantitative data and
guidance in the information gathering and decision making process, but also has
a powerful communications infrastructure which will allow the timely
dissemination of that data.
The result will be a better and more consistent response to emergency
situations.
The gains in response time, also critical in damage control are even more
obvious.
The current Petrogal modus operandi relies on external entities (such as road
police or passers by) to produce the alarm. The current alarm issuing procedure
shows that the time span until the specialised Petrogal team reaches the
accident site can reach several hours.
The HITERM system will allow an alarm to be sent to Petrogal as soon as the
accident occurs. This represents a saving of 35 - 75 minutes, ie., about 45% of
the total response time.
It should be noticed that this time saving can be accomplished with little
additional investment as all Petrogal trucks already have mobile phones and
industrial computers which can be programmed to fulfil the vehicle location and
alarm issuing tasks. The additional investment needed refers to the GPS units
and possibly more sophisticated alarm situation detection devices such as
gyroscopes for tip-over detection or airbag trigger detectors.
The three demonstrators are conceptually and technically quite similar.
Not surprisingly, the assessment therefor reflects these similarities by
showing quite similar results.
While the general evaluation is positive, and the technical
issues of performance, ease of use and user interface, and
model accuracy are all evaluated positively, the specific
problems resulting from the assessment are:
- institutional integration into existing structures;
- reliability (stability) of the current prototype;
- total cost of ownership.
Benefits Analysis
The HITERM project offers the tools for a rational response to technological
risk, both at the planning stage and the emergency management stage.
It can thus, on the one hand,
- contribute to considerably reduce damage from technological emergencies -
which is an obvious benefit, but also
- help the users of the system to do their job better and more cost-effective,
which is a second level of benefit.
The latter aspects has to be seen in a comparative context, i.e.,
comparing the capabilities of HITERM with the status quo
of operations in potential user institutions and organisations
and evaluating incremental benefits.
This is described, for the example of the Italian market in some detail,
in D10.0, The Italian Case Study Report.
HITERM/RiskWare is not an off-the shelf software system; we expect,
as the current experience with marketing the systems clearly demonstrates,
to build and support a wide range of implementations for different customers,
including:
public institutions (government) including the so-called competent authorities
of the Seveso Directive (96/82/EC), responsible for external safety,
emergency management and civil defense in general;
plant operators for hazardous installation such as chemical process plants,
storage facilities, or refineries;
transportation systems operators, whether they are railway operators,
airport authorities, or road transport operator (and possibly harbor authorities).
For each of these groups, potential benefits of a decision support system based on
the HITERM results will differ, depending on their mission and current methodology.
In general terms, HITERM has potential
socio-economic impacts and benefits at several levels:
Benefits and drawbacks of HITERM have been compared with potential competitive systems for risk
analysis and emergency support and results are summarised in the following:
Real-time and on-line evaluation in emergency conditions is the most important feature of
HITERM: combined with a good comprehensive interface, reproducing the standards of the
competent authorities for emergency procedure and planning (recently established and now in
normal use) can represent the most important benefit for customisation.
A DSS concept, like in HITERM, is not yet provided by competitors for standard applications and
improvement of rules in the domain of accident scenarios identification, source terms definition,
"domino effects" evaluation, practical suggestions for prompt intervention and first safety
measures to be taken seem to be the most promising and attractive features for exploitation.
Complex and fast running models for dispersion that can take into account the characteristics
of the domain (elevation, obstacles, land-use and so on) still represent an advantage, that most
other competitive system are lacking, but the model library needs to be enlarged and
improved in order to cover all the basic potential accident scenarios: HITERM cost and
performance capabilities can be attractive only if the model library is completed and well
integrated with basic hazardous material data base.
GIS support and system integration are much better than in any other system in
operation or development at now, but public authorities are
orienting their choice towards cheaper and easily accessible system, integrating other potential
applications (mainly ArcView and ArcInfo); so cost awareness of the HITERM system could present a
difficulty in dissemination and exploitation.
Integration with MSDS and more specialised public data bases
needs to be implemented in HITERM with internal protocols completely transparent for
the users, run and integrated by DSS rules.
Competitive systems are developing routines and DSS for population behaviour and traffic
control in case of an emergency evacuation which are not taken care of in HITERM;
implementation efforts should be made in that direction.
On the one hand consequent follow-up of what has been addressed above could present a way to successful
exploitation of the system, but on the other hand cost and complexity of HITERM suggests to (first) select
a subset of the functionality to address the potential markets in industrial risk analysis and
technological emergency management represented by public authorities and significant industrial players.
Conclusions
In summary, the validation phase of the project has
been successfully completed. Technical feasibility, reliability,
and performance have met or surpassed the expectations as
formulated in the user requirements analysis.
The basic objective of demonstrating the potential of
high-performance computing for decision support in a
technically demanding domain like technological risk management
has been met. A flexible systems architecture was developed
that supports the use of high-performance computing in an
incremental, scalable way that is very cost-effective
and can adapt to growing demand efficiently.
Shortcomings of the Demonstrator are largely due to lack
of critical data (e.g., the chemical data base) or some
additional models (surface and groundwater) deemed desirable
in some applications.
These problems, however, are of a quantitative rather than
principle, qualitative nature, and there is every indication
that they can be easily solved with a reasonable
level of effort. This is foreseen in the continuing exploitation
phase, converting HITERM results into a marketable product.
HITERM is designed for two major user groups:
private industry (primarily the chemical industry,
but also the transportation sector, power generation, heavy industry, etc.)
public administrations responsible for emergency management and civil
protection including fire brigades, the national competent authorities under
Seveso II (96/82/EC).
As a commercial product, HITERM represents a bundle of
several software components that can be licensed,
together with consultancy services that can be offered
in support of, or by using, the software.
This includes performing contract studies with the system,
but also the compilation of the necessary data and technical support
for end users, including the possibility to provide
computational (high-performance computing) services to end users.
The range of exploitation options therefor includes:
- licensing of the software components to
end users or value-added distributors;
- providing consultancy services on the basis of the software;
- providing consultancy and user support for end users;
- offering computing services for the high-performance components;
- exploitation of the development components and experience gained
in related products and projects.
The HITERM exploitation plan constitutes a Deliverable
of the project; while it provides an overview of the
main concepts, plans, and strategies envisioned by the
project consortium for the exploitation of the project results,
it will not disclose any detailed financial information
or confidential business information of the partners.
Parts of the exploitation plan, and in particular the
business plan, therefor, will be expressed in qualitative or at best
semi-quantitative terms.
The markets and target user groups
HITERM is designed as a flexible system that is fully data driven.
It can, therefor, be adapted to any language and regulatory framework
with reasonably small effort.
The target market of HITERM is global.
However, for practical reasons the market introduction
will have to follow a more gradual approach:
- introduction in the case study countries Italy, Portugal, Switzerland
through the respective partners and using the case study Demonstrator
installations as reference systems;
- the second step will concentrate on the other EU countries;
- in a third step, the candidate countries will be targeted;
- and subsequent steps can then attempt expansion into
the CIS and other eastern and central European states,
and ultimately world wide.
The target user groups for the HITERM project results
can be grouped into two main types:
private industry (primarily the chemical industry,
but also the transportation sector, power generation, heavy industry, etc.):
any industrial sector that is either subject to the Seveso II Directive,
or involves major technological risks (chemical emergencies, explosion, fires,
structural failure etc.) that may require specific emergency preparedness and
management tools;
public administrations responsible for emergency management and civil
protection including fire brigades, the national competent authorities under
Seveso II (96/82/EC) in the EU, and comparable institutions in other
countries. Please note that while the HITERM project and demonstrator
concentrate of chemical emergencies as defined in the Executive
Summary version of the Requirements and Constraints Report,
the derived product can again address the entire range of technological
and environmental emergencies where the basic methodology is applicable.
The size of this market is considerable:
concentrating again on the chemical industry only,
in the US alone, about 250,000 chemical industrial
plants are subject to the latest regulations on
emergency planning and management. The European common market
is of a comparable size. Globally, this would encompass
for the chemical industry alone, a market size of 500,000
to 1,000,000 chemical plants and enterprises that are
potential users of an emergency management system like HITERM.
The number of public institutions is in the same order of
magnitude if not larger. While national and regional bodies
concerned with emergency management are in the order of thousands,
the local level, and in particular fire fighters command centers,
are again in the hundreds of thousands world wide.
Therefor, the potential market for a system like HITERM
is of a considerable size.
Competitor Analysis
For the analysis of competing products, a survey of
existing software systems for emergency
planning and management, as well as a series of ongoing EU
sponsored R&D projects was undertaken.
The current status of systems identified is summarised
in Deliverable D12, Exploitation Plan;
see also Moskowitz et al, (1995) and Bouchart et al, (1995)
for recent compilations of risk related computer codes.
Detailed information on ongoing research and development projects funded
under the Fourth Framework Programme by the European Union can be
found on the CORDIS server, http://apollo.cordis.lu, and on
the respective home pages of the various programmes such as ESPRIT,
TELEMATICS.
In summary ...
While the analysis of competing products is necessarily incomplete
and cursory, the following basic feature relevant for the positioning
of the HITERM results seem to emerge:
- most products are based on relatively old models, and concentrate
on vapor cloud dispersion
- integration with data bases, GIS, or on-line monitoring is the exception
- no expert system (other than simple decision tables) seems to be
available
- no explicit treatment of uncertainty or stochastic modeling
could be identified in emergency management applications
- graphical user interfaces are generally poor or absent
- the high degree of integration characteristic for
HITERM seems unique
- no systems that use high-performance computing other than
for pure research purposes could be identified.
The lack of the above features, at least in terms of
their integration into a single product, therefor clearly
defines the competitive advantage for HITERM.
Product packaging: software and services
As a commercial product, the results of the HITERM project
represent
- a bundle of several software components
that can be licensed together or individually
(the framework system RiskWare and its component
screening models; the parallel high-performance computing models;
the wireless communication tools);
-
together with consultancy services
that can be offered in support of, or by using, the software.
This includes performing contract studies with the system,
but also the compilation of the necessary data and technical support
for end users, including the possibility to provide
computational (high-performance computing) services to end users.
As one possible form of packaging, ESS is planning to
integrate the results of the project with its
RiskWare software system.
Other software developers (primarily GMD and LNEC for the parallel
models and wireless communication tools) will receive
license fees from any copy of their software bundled with RiskWare
for a third party client; and the consultant partners
in Portugal, Italy, and Switzerland will act as
both distributors, but also as consultants providing
local user support and technical services, with or for the
RiskWare software.
Finally, as an optional extension of the consultancy
in support of end users, the optional HPCN components of
RiskWare can be offered by the project partners, or qualified future
distribution and support partners, as a computational service.
This would allow end-users to minimize their investment, training,
and long-term maintenance efforts by outsourcing these components
to an external service provider.
While this option is conceptually very attractive,
and technically and commercially sound, there may be
issues of confidentiality that may make it difficult to
implement both in the industrial and public administration
environment.
Please note that the bundling within the RiskWare framework
is only one possibility: other partners, or ESS,
may choose to bundle any or all of
the software components in other frameworks and products,
with reciprocal licensing arrangements.
The GMD, for example, will continue to exploit the HITERM developments
in future projects, and provide continuing support and
consultancy on a case to case basis. Research oriented
but externally funded projects will try to build
on the HITERM components such as the parallel models,
sensitivity analysis, and parallel implementation
techniques together with the remote client-server
execution of models on powerful hardware, triggered by a
web-request.
Commercially oriented exploitation and continuing support
for end users is foreseen under a number of constructs,
currently under discussion, that will involve spin-off
companies that can license and then commercially exploit
GMD developed products.
Technical constraints: data, costs, infrastructure
As already discussed in the
Requirements and Constraints Analysis report
a technically demanding system like HITERM faces a number of
constraints that are important to consider in any exploitation planning.
Data
For the practical application of the HITERM system,
the availability of data may be a constraint.
This includes:
- geographical and orographic background data, climate data;
- risk related data (chemical plants, population, intervention forces);
- administrative and organisational data: rules and procedures for
intervention;
- hazardous chemicals data.
Since the compilation of some of these data may be expensive,
HITERM as a product has to:
- operate with a minimum of data
- facilitate incremental building of its data bases
- include data compilation as a bundled service.
Costs
Cost considerations are a major constraints both for
public authorities, as well as for industrial enterprises,
in particular small and medium sized enterprises.
HITERM as a product must therefor:
- offer a low-cost entry level configuration
- be easily upgrade-able if and when more performance is required.
Infrastructure
Constraints on the availability of HPCN infrastructure
(massive parallel computers, cluster with fast LAN connections,
fast external network connections) are to be expected in most
potential applications. This is both related to costs, but
also to institutional constraints that simply do not make
the introduction of "exotic" technology easy. In addition,
HITERM as a product will have to address the general
dominance of Microsoft-based PC equipment as the computing platform
of choice in the overwhelming majority of potential client sites.
Therefor, the following issues must be addressed:
- simple entry-level configurations
- flexible upgrade options through cluster solutions
- porting to Windows NT as the basic (client) platform
or further development of Java clients.
Marketing strategy
The marketing strategy for HITERM/RiskWare is based on a phased approach
(see the description of the market above).
The initial phase will concentrate on the direct exploitation of the project
and the Demonstrator cases in Italy, Portugal and Switzerland.
It will focus on the national partners in these three countries and
their existing professional contacts and clients.
Since the national partners already operate successfully in this market,
no further market studies seem necessary.
The primary mechanism for marketing will be:
- exploitation of existing business contacts of the partners;
- presentations of the Demonstrator at exhibitions, conferences, and
technology fairs;
- mailings to potential users with individual follow up;
- as accompanying measures, publications of articles, features, and
editorials describing the system in appropriate technical journals;
- continuing use of the Internet as an advertising medium.
In a second phase, the marketing will require to identify
strategic partners in various countries.
Due to the very important (and comparatively time consuming)
consultancy component, and the need for customisation to national
regulatory frameworks, institutional
structures, language, etc., building up a network
of local support partners is essential.
Business plan options
In principle, there are several options for a business strategy
for HITERM; they include:
- concentration on a small number of high-profit projects;
- building a support and distribution network capable to
support a high-volume but relatively low-cost market;
- licensing to national or regional distribution partners
or value-added resellers with a minimum direct involvement;
- seek strategic partnerships with established players in the market.
These strategies are of course not mutually exclusive but can
be combined and mixed with a geographical discretisation,
and evolve depending on market response and first experiences.
For the last point, strategic partnerships with
developers of similar systems, several initiatives have
been started:
initial contacts with DNV (developers of the SAFETI system
and related products including models like PHAST)
discussion with TEMARS (developer of SIGEMI in Italy) with the
goal of integrating the Chemical data base, accident data base, and
simple screening models from SIGEMI in RiskWare/SIGEMI for
the Italian market.
first contacts with ASSOMINERARIA (coordinator of the
SINGER project) to explore possibilities for integration,
since SINGER and RiskWare/HITERM have complementary capabilities.
Exploitation and IPR issues
The exploitation of the HITERM results is regulated by the terms
and conditions of the Consortium Agreement signed by the HITERM
partners at the beginning of the project.
The relevant conditions of the Consortium Agreement are as follows:
Ownership
Foreground shall be owned by the Contractor(s) generating it.
Access Rights
Access Rights granted for Foreground or Background shall be subject, where
appropriate, to suitable arrangements determined by the Contractor to ensure
their use only for the purpose for which they are granted and may be subject
to appropriate undertakings as to confidentiality.
Access Rights for Background shall be conditional upon the Contractor being
free to grant such rights.
Access Rights shall not, unless expressly agreed, confer any right to
sub-license.
Proprietary information which is to be treated confidentially shall be duly
marked.
Access rights for exploitation
Each Contractor shall be entitled to exploit all the Foreground, including
to procure the manufacture of products by third parties for exploitation by
the Contractor at its risk and account and shall grant each other Access
Rights for exploitation of Foreground on a royalty-free basis.
Any Contractor not normally undertaking commercial activities or unable
itself to commercialise its Foreground may grant above Access Rights on,
instead of royalty-free conditions, fair and reasonable financial or similar
conditions which have regard to the Contractor's contribution to the Project
and the commercialisation potential of the Foreground.
Any Contractor applying this paragraph shall not use the Foreground in
commercial activities.
Each Contractor shall grant Access Rights for its Background necessary
for the exploitation of Foreground to the other Contractors in this
Contract subject to major business interests, provided they do not result
in abusive restrictions to the exploitation of Foreground, under favorable
conditions.
Exploitation proceeds in two parallel
but related tracks:
- commercial exploitation by the industrial (developer) partners;
- in-house and academic exploitation (Petrogal, GMD, LNEC, FCCN).
The commercial partners (ASIT, SYRECO, ESS) are directly exploiting
HITERM by marketing RiskWare and related services. RiskWare is a
proprietary system owned and distributed by ESS.
The data sets for the three Demonstrators are owned by the
respective case study partners.
ASIT and SYRECO can distribute RiskWare as value-added
resellers in their own respective projects.
Continuing free licenses are granted to ASIT and SYRECO
for marketing purposes.
Software developed by GMD (parallel models) and LNEC (GPS/GSM integration)
constitutes optional components of RiskWare, and can be licensed from
GMD and LNEC respectively.
A proposed exploitation strategy and licensing agreement for the GMD
is available as APPENDIX 3 to this report.
-
Al-Wali K. I., Samson P. J. (1996)
-
Preliminary Sensitivity Analysis of Urban Airshed Model Simulations to
Temporal and Spatial Availability of Boundary Layer Wind Measurements.
Atmosheric Environment Vol 30, No. 12, 2027-2042
-
Allwine K.J., Whiteman C.D. (1985)
-
MELSAR: A Mesoscale Air Quality Model for Complex Terrain: Volume 1 - Overview,
Technical Description and Users Guide. Pacific Northwest Laboratory, Richland
(PNL-5460).
-
Booch, G. (1991)
- Object Oriented Design with Applications.
Benjamin/Cummings, California, USA. ISBN 0-8053-0091-0
-
Bouchart,D.C., Ambrose, R.B.Jr., Barnwell, T.O.Jr., and Disney, D.W. (1995)
- Environmental Modeling Software at the U.S. Environmental
Protection Agency's Center for Exposure Modeling.
In: G.E.G. Beroggi and W.A. Wallace [Eds.]
Computer Supported Risk Management. Kluwer Academic Publishers. Dordrecht.
The Netherlands. pp. 321-360.
-
Briggs G.A. (1984)
- Plume Rise and Buoyancy Effects, Atmospheric Science and Power Production,
D. Randerson, Editor, DOE/TIC-27601, Office of Scientific and Technical
Information, US Dep. of Energy.
-
Douglas G.S., Kessler R.C., Carr L. (1990)
-
User's Manual for the Diagnostic Wind Model. EPA-450/4-90-007C.
-
Ermak L.D. (1991)
-
User's Manual for SLAB: An Atmospheric Dispersion Model for Denser-Than-Air
Releases. National Technical Information Services (NTIS), DE91- 008443,
Springfield, VA.
-
Fedra, K. and Winkelbauer, L. (1999)
- A hybrid expert system, GIS and simulation modeling for environmental
and technological risk management. In: Environmental Decision Support
Systems and Artificial Intelligence, Technical Report WS-99-07, pp 1-7,
AAAI Press, Menlo Park, CA.
- Fedra, K. (1997)
- Integrated Risk Assessment and Management: Overview and State-of-the-Art.
p3-18. In: Ale, B.J.M, Janssen, M.P.M., and Pruppers, M.J.M [eds]
Risk 97 Book of Papers. Proceeding of the International Conference Mapping
Environmental Risks and Risk Comparison, Amsterdam, 21-24 October 1997.
RIVM, Bilthoven.
-
Garnatz Th., Haack U., Sander M., Schröder-Preikschat W. (1996)
-
Experiences made with the Design and Development of a Message-Passing Kernel
for a Dual-Processor-Node Parallel Computer. In Proceedings of the Twenty-Ninth
Annual Hawaii International Conference on System Sciences. (Maui, Hawaii,
January 3-6, 1996). IEEE Computer Society Press.
-
Geist A., Beguelin A., Dongarra J., Jiang W., Manchek R., Sunderam V. (1994)
-
PVM: Parallel Virtual Machine, A User's Guide and Tutorial for Networked
Parallel Computing. The MIT Press, Cambridge, Massachusetts.
-
Gerharz I., Lux Th., Sydow A. (1997)
-
Inclusion of Lagrangian Models in the DYMOS System. In Proceedings of the
IMACS World Congress 1997. (Berlin, Germany, August 25-29). W&T, Berlin,
6: 53-58.
-
Gerharz, I., Mieth, P., Unger, S. (2000)
- A software system for environmental
risk management - the HITERM approach, Systems Analysis Modeling
Simulation, (to be published)
-
Giloi W.K., Brüning U. (1991)
-
Architectural Trends in Parallel Supercomputers. In Proceedings of the
Second NEC International Symposium on Systems and Computer Architectures.
(Tokyo, Japan, August). Nippon Electric Corp.
-
Goodin W.R., McRae G.J., Seinfeld J.H. (1980)
-
An objective analysis technique for constructing three-dimensional urban
scale wind fields. J. Applied Meteorol., 19: 10-16.
-
Janicke L. (1991)
-
Ausbreitungsmodell Lasat. Handbuch Version 1.10. Ingenieur-Büro Dr.
Lutz Janicke, Überlingen.
-
Kawamura P. I., Mackay D. (1987)
-
J. Hazardous Materials, 15, 343-364.
-
Legg B.J., Raupach M.R. (1982)
-
Markov-Chain Simulation of Particle Dispersion in Inhomogeneous Flows:
The Mean Drift Velocity Induced by a Gradient in Eulerian Velocity Variance.
Boundary-Layer Meteorology, 24: 3-13.
-
Liu M.K., Yocke M.A. (1980)
-
Siting of wind turbine generators in complex terrain. J. Energy, 4: 10-16.
-
Moskowitz. P.D., Pardi, R.R., DePhillips, M.P. Meinhold, A.F. and Irla B. (1995)
-
Computer Models Used to Support Cleanup Decision Making at Hazardous
and Radioactive Waste Sites. In: G.E.G. Beroggi and W.A.
Wallace [Eds.] Computer Supported Risk Management.
Kluwer Academic Publishers. Dordrecht. The Netherlands.
pp. 275-319.
-
Mieth, P.; Unger, S.; Gerharz, I. (1999)
- A model based tool for
environmental risk management after accidental atmospheric release of
toxic substances, In: MODSIM 99 - International Congress on Modeling
and Simulation (Proceedings),
Vol. 3, Oxley, L.; Scrimgeour, F.; Jakeman, A. (eds.), 562-572
-
Mieth, P.; Unger, S.; Gerharz, I.; Jugel, M. L. (1999)
- HITERM: ein Arbeitsplatz für das
Störfall-Management, Der GMD-Spiegel, Nr. 1/2, 45-47
-
O'Brien J.J. (1970)
-
Alternative solutions to the classical vertical velocity profile. J. Applied
Meteorol., 9: 197-203.
-
Obukhov, A.M. (1959)
-
Description of Turbulence in Terms of Lagrangian Variables. Advances in
Geophysics, 6: 113 -116.
-
Rumbaugh,et al., (1991)
- Object Oriented Modelling and Design.
Prentice Hall, NJ, USA. ISBN 0-13-629841-9.
-
Smith F.B. (1968)
-
Conditioned Particle Motion in a Homogeneous Turbulent Field. Atmospheric
Environment, 2: 491-508.
-
Taylor G.I. (1921)
-
Diffusion by Continuous Movements. London Mathematical Society, 20: 196-211.
-
Thomson D.J. (1987)
-
Criteria for the Selection of Stochastic Models of Particle Trajectories
in Turbulent Flows. Journal of Fluid Mechanics, 180: 529-586.
-
TNO (1997)
- Yellow Book (CPR 14E), Third Edition, 2 Volumes, 820 pages.
TNO Institute of Environmental Sciences, Energy Research and Process Innovation,
Apeldoorn, The Netherlands.
-
Unger, S. ; Gerharz, I. ; Mieth, P. ; Wottrich, S. (1998)
- HITERM - High-Performance Computing for Technological Risk Management,
Transactions of the Society for Computer Simulation, Vol. 15, 3, 109-114
-
Überhuber C. (1995)
-
Computernumerik. Bd. 1, Springer Verlag, Berlin Heidelberg.
-
Yamada T., Bunker S., Niccum N. (1987)
-
Simulation of the ASCOT Brush Creek Data by a Nested-grid, Second Moment
Turbulence-closure Model and a Kernel Concentration Estimator. In Proceedings
of the AMS 4th Conference on Mountain Meteorology, (Seattle, WA, August
24-28). 175-179.
-
Zani, F. (1998)
- HITERM High Performance Technological and environmental Risk Management:
strumenti informatici on-line di supporto alla pianificazione e gestione
delle emergenze industriali.
VGR 98 Conference, Pisa (I) 6-8 October
for one and two-phase releases, pool evaporation,
and infiltration (stochastic, Monte Carlo framework);
The air pollution
emergency modeling system consists of:
based on INPUFF 2.4, using the diagnostic 3-D wind model
DWM as a pre-processor; The model directly utilises the output
of the SPILL model above.
TNT equivalence and a fuel-air charge blast explosion model
from the TNO Yellow Book (Third Edition 1997);
can describe pool and trech fires (see the Attachment to D10, Italian case Study)
as well as BLEVE (Boiling Liquid Expanding Vapor Explosion) based on the
TNO Yellow Book formulas.
estimates the arrival time of a spill at the water table,
using substance viscosity, soil properties, and the
groundwater level (distance from soil surface).
Monte Carlo implementation. The model is based on a set of Nomograms
used routinely by the Swiss chemical intervention forces.
fast empirical estimation method from Italy;
(PIANIFICAZIONE DI EMERGENZA ESTERNA PER IMPIANTI INDUSTRIALI A RISCHIO DI
INCIDENTE RILEVANTE, LINEE GUIDA, January 1994)
it uses tabulated data for substance classes,
amounts and storage conditions,and weather conditions.
