Project Technical Documents


Requirements and Constraints Analysis Report

(Integrated part of the on-line deliverable D01.0)

    Programme name: ESPRIT
    Domain: HPCN
    Project acronym: HITERM
    Contract number: 22723
    Project title: High-Performance Computing and Networking
    for Technological and Environmental Risk Management
    Project Deliverable: D01.0
    Related Work Package:   WP 1
    Type of Deliverable: EXECUTIVE SUMMARY
    Dissemination level: public
    Document Author: Kurt Fedra, ESS
    Edited by: Kurt Fedra, ESS
    Document Version: 1.2
    First Availability: 1997 10 01
    Last Modification: 1998 02 17


The EXECUTIVE SUMMARY of the HITERM Requirements and Constraints Analysis Report (prepared by F. Zani, Syreco, and N. Seifert, ASIT) constitutes an integrated part of this report (project Deliverable D01.1). It is also available as a separate on-line document, D01.0.

The EXECUTIVE SUMMARY follows the structure of the main Report (D01.1). It provides a short introduction ot the HITERM project and the relationship of D01 to other, subsequent Deliverables and summarizes the objectives of the Report.

A summary of its main findings and highlights, following the main sections of the Report D01.1, is condensed and regrouped into:

  • Introduction:
    • Definition of the application domain
    • DSS approach and justification

  • Constraints and Background:
    • Regulatory Framework
    • Institutional Framework
    • Technical, financial, and human constraints
  • User Requirements:
    • Functional specifications
    • Technical specifications
  • Cost-Benefit Considerations:
    • HITERM benefits
    • HITERM costs

    Each section is followed by a short summary of the conclusions for the HITERM design, in terms of:

    • Systems architecture
    • Systems implementation
    • Systems functionality
    that can be drawn from the analysis of the report material.

    This is followed by a Summary of the Conclusions.


    The objectives of the Requirements and Constraints Analysis Report are to:
    • Compile background data and information on:
      • the state of the art of technological risk planning and management
      • the regulatory framework for risk planning and management
      • the institutional framework
      • the technical, financial, and human resources constraints
      • specific user requirements for risk analysis
    • Analyze the data, including a number of interviews with representative potential users of HITERM, in terms of user requirements and constraints
    • Develop a framework for cost-benefit considerations
    • Derive conclusions and guidelines from the requirements and constraints for the design and implementation of the HITERM system, described in the Deliverables:
      WP 2 Model Parallelization GMD
        D2.1 Model Specifications
        D2.2 Installation Manual (parallel environment)
        D2.3 User Manuals (basic models)
      WP 3 Communication and NetworkingFCCN
        D3 Communication Architecture: Technical Report
      WP 4 Visualization and Multi-MediaESS
        D4 Implementation and User Manual
      WP 5 Model Calibration and Uncertainty AnalysisGMD
        D5 Technical Report

    HITERM Project Overview:
    approach, work plan, and deliverables

    HITERM develops and tests a set of HPCN based descision support tools for technological risk management. The project proceeds in a number of overlapping phases and prototyping cycles:

    the initial exploratory phase compiles detailed user specifications and constraints, summarized in the Requirements and Constraints Analysis (D01.1) and its three case-study and country specific sections D01.2,3 and 4, summarized in an Executive Summary (this document, D01.0).

    The main development phase then implements the user requirements defined in D01 in the design and development of the prototype demonstrator; this will be described in the Deliverables:

    • D2 (simulation models);
    • D3 (communication architecture);
    • D4 (visualization and multi-media);
    • D5 (uncertainty analysis);
    • D6 (decision support functions)
    • D7 (system architecture and integration).
    Ths technical documentation will be continuously updated during the development and test phases of the project.

    The Demonstration prototype is then tested and evaluated in parallel case studies in Italy, Portugal, and Switzerland with the involvement of representative end users. Another set of Deliverables (D8, D9, D10) summarizes the case study scenarios and results.

    A final evaluation phase will analyze and summarize the experiences from the case studies, and conclude with a final evaluation report (D11).


    Definition of the application domain

    HITERM concentrates on technological risk, and in particular:
    • Emergency planning: consequence analysis, prevention support, accident scenario evaluation (Seveso I), public risk information (Safety plans)
    • Emergency response training: emergency plan evaluation (Seveso II)
    • Emergency management support: real-time intervention management.
    Emergency within the framework of HITERM is understood as an unintended release of hazardous material that causes, or threatens to cause, harmful effects (casualties, material damages) outside the area of private plants or storage locations.

    HITERM aims to develop HPCN decision support tools for technological risk management and the environment with:

    • better-than-real time complex simulation models (3D, dynamic)
    • fully integrated uncertainty analysis and error propagation (Monte Carlo)
    • on-line data interpretation, visualization
    • integrated MC decision support tools.

    HPCN and DSS: the HITERM approach

    The ultimate objective of a computer based decision support system 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, and possibly the general public.

    This information must be:

    • Timely in relation to the dynamics of decision problem;
      depending on the nature of the problem (planning, training, or operational risk management) this implies considerably better than real-time performance of any forecasting, and more or less immediate response in any situation of interactive use.
    • Accurate in relation to the information requirements;
      this requires the use of state-of-the-art tools, methods, and models, which usually are demanding in terms of their data requirements and computational resources;

    • Directly understandable and useful;
      this implies that the output of any numerical method can be presented in a format that is directly and reliably understandable, that is, graphical and symbolical (in multi-media formats rather than purely textual and numerical);

    • Easily obtainable, i.e., cheap in relation to the problems implied costs, which, however, in the case of technological risk, accidents and emergency situations can be considerable.

    All these requirements for decision support information can, at least in part, be addressed by high-performance computing and networking (HPCN).

    Many data processing, modelling, and communication tasks that appeared prohibitive only a short while ago become more and more feasible and also commercially viable with the rapid development of computer and information technology. In particular the possibility to use clusters of powerful PCs and workstations to configure virtual super-computers on demand opens new areas of promising applications.


    This section summarizes the main body of the Requirements and Constraints Report , General Part (D1.1) and Appendices, and the three case study specific parts D1.2, D1.3, and D1.4.

    Constraints and Background:

    Regulatory Framework

    Within the European Union technological risk management is covered by the EC Directive 82/501 EEC (referred to as Seveso I) and subsequent amendments (87-216 EEC, 88-610 EEC) and the Directive 96-82 EC (Seveso II). The Directive entered into force on 3 February 1997 and must be transposed into national law by the Member States within 24 months. It must be applied as from February 1999 (date of repeal of Directive 82/501/EEC-SEVESO I).

    Under this common umbrella, the individual countries have quite different national and regional implementations. Important aspects are different coverage (for example, the Seveso Directives do not apply to transportation of hazardous materials and intermediate storage). Regulations in Switzerland are again different in several details as compared to the EU regulations.

    Conclusions for HITERM: HITERM must be sufficiently flexible to accommodate the different national regulatory frameworks, which not only differ, but are also under ongoing modifications as the new Seveso II Directive reaches its national implementation.

    Institutional Framework

    The institutional framework for risk assessment and management shows considerable variability across Europe. No single form of organization can be identified, with a broad range from very centralized (such as in Italy) to very distributed (such as in Switzerland) models.

    Conclusions for HITERM: As a consequence, HITERM must be able to adapt to a range of organizational models easily. Interviews with potential end users have made clear that compatibility with existing organizational models is a must.

    Technical, financial, and human constraints

    The analysis of the current situation in the three case study countries demonstrates that neither the level of computer hardware generally in use, nor the (information technology) training of responsible personnel can be considered sufficient in the context of HITERM. Also, financial constraints seem to dictate policy in most institutions involved in risk management.

    Conclusions for HITERM: Demonstrated cost-efficiency, flexibility in terms of the required hardware, and ease-of-use (low training requirements) are important design objectives for HITERM.

    User Requirements:

    User requirements have been compiled from interviews with key industrial and governmental institutions, as well as a questionnaire, and the analysis of similar systems as well as established practice. User Requirements vary considerably, similar to the institutional framework and the different distributions of responsibilities and authority.

    The following list of user requirements is compiled from all three case studies in Italy (main end user: Regione Lombardia) , Portugal (main end user: Petrogal), and Switzerland (main end user: cantonal authorities). Although with different emphasis on the various functional requirements, no major contradictions were found between the different end users.

    Specific user requirements from representative institutions and individuals include:

    • Information on the evolution in time and space of an emergency and its driving conditions, in order to predict consequences and the impact area.

    • This should be derived from advanced state-of-the-art methods and models for atmospheric diffusion, surface and groundwater pollution.

    • The system has to be applicable for emergency planning as well as for emergency management.

    • Training applications include the definition of likely accident scenarios.

    • For emergency management, HITERM should be able to provide a basic estimation of the impact of a transportation accident.

    • For intervention management, HITERM must be able to acquire and analyze time-critical data necessary for the simulations fast and reliable.

    • Speed and reliability in data acquisition, analysis, and communication are general but crucial requirements.

    • Monitoring data acquisition should allow to test and re-calibrate the results of mathematical dispersion models.

    • Uncertainty of parameters and source terms should be explicitly considered as part of model based forecasts.

    • The system must have access to information about chemical and toxicological data of hazardous substances and suggestions for safety and emergency management.

    • Information on the environment including meteorological data, area characteristics, population density and sensitive points are important to the emergency management

    • Information from the Safety Reports must be an integrated part of the HITERM information system.

    • Information on traffic conditions and access route should be available for intervention forces.

    • A decision support component is required, although the emphasis varies between applications to emergency management and training and accident simulations.

    • The decision making structure of the intervention forces must not be affected by the system.

    It is suggested that HITERM must not have any impact on existing emergency organization structures. HITERM should be de-centrally operated and include existing manuals and guidelines. The representation of results should be transparent and easy to interpret.

    Technical specifications

    No general technical specification other than interoperability with existing legacy applications (data bases, GIS systems, existing communication technology) could be derived from requirements and constraints.

    Conclusions for the HITERM design:

    The overriding conclusions for the design of HITERM is the need for flexibility. The system must be able to accommodate, preferably in a fully data-driven manner:
    • Diverse regulatory frameworks
    • Diverse institutional and organizational structures
    • Interoperability with legacy systems (data bases, specific models)

    As a consequence, a highly flexible and modular client-server architecture based on standard protocols was chosen.

    Systems architecture

    The requirement for a high degree of configuration flexibility translates directly into a modular client-server architecture, where alternative and interchangeable components are integrated by a common communication protocol based on open standards.

    HITERM is based on a client-server architecture that links an easy-to-use front end (clients) with powerful High Performance Computing as the central analytical tool. The basic architecture of the system is organized around a central HITERM Server, that co-ordinates the various information resources (again servers in an N-tier architecture), prominently including the HPCN components like parallel computers or workstation clusters for better-than-real-time simulation of demanding models, potential 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, and a wide range of physical carriers, including wire-less connections, can be used to implement this communication protocol.

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

    • the develop platforms and the Demonstrator
    • the delivery platforms for a commercial exploitation phase
    with the latter constrained by cost considerations and interoperability requirements with existing hardware and software systems.

    Systems implementation

    For its implementation, HITERM must provide a number of alternative strategies and configurations to meet local needs and constraints. This includes the type of client hardware to support, the communication channels for the client-server linkage, and the provision of high-performance computing resources. For the latter, the alternatives:

    • fully locally integrated HPCN equipment:
      • High-performance (parallel) coputer(s)
      • ad-hoc virtual parallel computer (cluster)
    • network access to a remote HPCN center,
    • complete outsourcing to a service provider
    should be supported.

    Cost-Benefit Considerations

    A cost-benefit analysis for a system like HITERM faces the difficulty of estimating potential benefits from a decision support system in a low-probability but high consequence domain, that involves questions of valuation of environmental damage and human life. Rather than attempting a formal cost-benefit analysis with complete (and very controversial) monetization, we therefore enumerate major benefits of the system, and contrast them with the main cost categories.

    HITERM benefits

    Benefits from HITERM can be expected in several domains:

    • Meeting regulatory requirements efficiently
    • Improved emergency planning
    • Improved emergency training efficiency
    • Improved emergency management procedures

    Meeting regulatory requirements: HITERM is designed to support the implementation of the new Seveso Directive including its requirements for public access to safety plans.

    Improved emergency planning: HITERM is designed to analyze external safety plans. It will help to design and evaluate probable accident scenarios and their consequences with a high level of accuracy, based on advanced simulation technology, and thus to develop efficient and effective emergency plans.

    Improved emergency training: The simulation capabilities of HITERM provide a very cost-effective tool to support costly field exercises for emergency response training.

    Improved emergency management: Improved accident management through faster and better information on the likely evolution of an emergency, and decision support information for its management, can lead to considerable cost savings.

    HITERM costs

    Cost for a system like HITERM results from the following components:

    • Basic Computing and Communication hardware:
      Central server, clients, client-server communication, communication to external information resources like monitoring equipment.

      Costs will strongly depend on the number of clients, and the communication system and channels used.

    • High-Performance computing requirements:
      This can based on:
      • the purchase of the necessary computing equipment;
      • the configuration of a virtual parallel machine (cluster) on demand;
      • obtaining HPCN capacity from an external provider.

      Costs will primarily depend on the configuration chosen and the frequency and extent of use.

    • System software, licensing and maintenance:
      • Internal option that requires dedicated maintenance staff
      • External option based on outsourcing to a service provider
      Data compilation and maintenance:

      Costs will depend primarily on data availability as well as the geographical scope of the implementation.

    • User training:

      Depends primarily on the number of people involved and the frequency of training. Computer-based training modules within the system itself could provide a very flexible low-cost solution.

    In summary, the investment cost for a complete HITERM installation is expected range between 100 to 500 KECU, with annual operating and maintenance costs in the order of at least one full time person or approximately 100 KECU.


    HITERM must provide a high degree of flexibility for customization and local configuration, including alternative computational and communication strategies.

    It should therefor be developed as an open tool-kit rather than a fixed, rigid system. Regulatory and institutional constraints as well as national language requirements must be easy to meet as fully data-driven configuration options.

    HITERM must demonstrate its efficiency in terms of:

    • Improved access to large but integrated volumes of background information
    • Improved accuracy of analysis and forecasts (model results)
    • Improved speed and reliability of the information provided
    • Ease of use and a directly understandable graphical and symbolic user interface
    • Cost efficiency of the proposed solution.
    The specific conclusions related to the constraints identified are:
    Regulatory Framework:
    HITERM must be sufficiently flexible to accommodate the different national regulatory frameworks, which not only differ, but are also under ongoing modifications as the new Seveso II Directive reaches its national implementation.
    Institutional Framework:
    HITERM must be able to adapt to a range of organizational models easily. Interviews with potential end users have made clear that compatibility with existing organizational models is a must.
    Technical, Financial, and Human Constraints:
    Demonstrated cost-efficiency, flexibility in terms of the required hardware, and ease-of-use (low training requirements) are important design objectives for HITERM.

  • Copyright 1995-2002 by:   ESS   Environmental Software and Services GmbH AUSTRIA