Communication and Decision Support Systems

An emergency can be defined as any deviation from normal operating conditions, such as to determine situations of possible damage to people or things. In Italy, those who mainly deal with emergency management are firefighters (Fire and Rescue Service) [1] and Civil Protection Department. The Italian Fire and Rescue Service, in order to look after the safety of people and preservation of property, ensures the technical measures characterized by the requirement of immediacy performance, for which technical skills are required (even if highly specialized teams and appropriate skills are required) and for the same purpose it carries out studies and experimental tests in the specific sector. The Italian Fire and Rescue Service urgent technical rescue activity includes:

1. rescue activity in the event of fires, uncontrolled releases of energy, structural collapses, landslides, floods, or other public calamities.

2. contrasting risks from nuclear energy and the use of biological, chemical and radiological substances.

The relevant literature and, above all, the experience gained in the field, tell us that the two characteristics of a crisis, compared to periods of quiet, are the need to make decisions quickly and (often) in the absence of all the information that would be needed and the emotional stress that derives from this time pressure and from having to make decisions, without the certainty that they are the correct ones.

To overcome these difficulties, the organizations that have been dealing with rescue and civil protection for several years have shown interest in technologies that can be useful for the management of emergencies.

This work describes decision support and voice/data communication systems, technologies and resources in use by the Italian Fire and Rescue Service and commonly used in case of disasters, to respond to the needs of strategic assessment of scenarios and emergency management. It also discusses its strengths and weaknesses, which will represent important challenges for the future.

3.1 Basic of decision support systems

3.jpg

Figure 3. Computerized DSS components

A Decision Support System (DSS) is an interactive computer-based system or subsystem intended to help decision makers use communications technologies, data, documents, knowledge and/or models to identify and solve problems, complete decision process tasks, and make decisions. Decision support system is a general term for any computer application that enhances a person or group's ability to make decisions [3]. Also, decision support systems refer to an academic field of research that involves designing and studying analytical information systems. In general, DSSs are a class of computerized information system that support decision-making activities [4].

A computerized DSS [5] is composed of the following three components (see Figure 3):

1. Knowledge System (KS), which contains all the information relating to the problem to be addressed

2. Problem Processing System (PPS), consisting of a processor, which generates useful responses to the process

3. User-System Interface (USI), which is the main interaction mechanism between user and system

The Knowledge System, in turn, consists of three parts:

1. Data Base (DB), database, containing quantitative and structured data records, textual information, georeferenced data, images, photos and maps processed by computer

2. Model Base (MB), model base, containing statistical routines and mathematical/simulation/management models

3. Rule Base (RB), knowledge base, containing rules and logical relations.

The Problem Processing System, on the other hand, is composed of three parts:

1. Data ‒ Base Management System (DBMS), which is the management system of the Data ‒ Database

2. Model ‒ Base Management System (MBMS), which is the management system of the models DB

3. Inference Engine (MOT. INF.), which is the hardware and software system with artificial intelligence functions.

The User System Interface, finally, consists of two parts:

1. Language System (LS), interface with the user for data entry and possibly models choice

2. Presentation System (PS), interface with the user for answers presentation (tables, graphs, maps, etc.)

Even if the concept of decision support was born in the 60s and has seen a great evolution already in the 80s, its application to emergency management is relatively recent. Lately, some European research projects have aimed at identifying new tools and technological resources for the management of multi-agency and cross-border emergencies. One of them, in which the Italian firefighters took part is FIRE IN [6], the aim of this 5-year project is to find capability gaps in fire/emergency/rescue activities in the EU and to suggest promising solutions, addressing the gaps. DSS are one of the promising solutions identified by the EU project FIRE IN. Main advantages in using a DSS are: better assessment of complex scenarios, communication and interoperability improvement, standardization of procedures, time reduction, faster population alert and technical confirmation of the choices made. Moreover, the use of DSS allows to verify emergency plans and to carry out multi-agency exercises.

3.2 DSS for emergency management

DSSs are used in the financial services, commerce, telecommunications and healthcare sectors with the aim of facilitating the use of data, providing an interactive environment, decision-making support and effectively using models to data analysis.

Only in the emergency sector has their use stopped in research. Projects in this sense that have shown the feasibility of technological solutions have also concerned Italy, such as LIAISON (Location Based Services and Emergency Indoor Location Systems, ECIST 2003), REACT (Control centers and emergency services interoperability, EC-IST 2005), SAVE ‒ ME (Disaster mitigation and evacuation in transportation hubs, EC ‒ SST 2008), IDIRA (Interoperability in large ‒ scale multinational disaster, EC ‒ SEC 2010), AF3 (Advanced Forest Fire Fighting, EC ‒ FP7 ‒ SEC 2013), IN-PREP (An INtegrated next generation PREParedness program for improving effective inter‒organizational response capacity in complex environments of disasters and causes of crises [7], EC ‒ H2020 ‒ SEC ‒ 01 ‒ DRS 2016). These projects have shown that decision support systems can provide real-time event status, and simulation of forest fires, weather events, tsunami waves, floods and provide usable information, together with data from sensors, to make decisions about what people exposed to risk should do.

The purpose of the DSS is therefore to include real-time data and simulation results in the assessment procedures, to substantially improve the safety of people and the efficiency of rescue. The main tools that can be used are:

Sensors:

1. satellite terrestrial monitoring

2. video surveillance (forest fires, traffic, structures, etc.)

3. crowd sensing (position of people, seismic events, etc.)

4. specific sensors (seismic, hydrographic, etc.)

Simulation:

1. weather events

2. flood

3. forest fires

4. tsunami waves

5. diffusion of dangerous substances in the atmosphere

Emergency communication to the public:

1. television, radio

2. sms

3. social networks

4. internet.

With these tools it becomes possible to switch from a “static” to a “dynamic” Geographic Information System: in other words, it is possible to use cartographic data and alphanumeric data in the context of operational procedures, to monitor in time real activities, procedures and information flows in order to support both the planning and the real-time management of the emergency with greater efficiency. The System, for example, in a computerized and updated cartography can display, on different layers, the critical infrastructures, the houses, the viability, the systems and networks, the signals and requests for assistance, the available resources and movements on the territory, fire and safety devices, information deriving from the same emergency plan and the presence of fragile people, sensitive targets, people with reduced mobility. Furthermore, it can manage the flow of communications between the various operating rooms and the exchange of data and information, also keeping track of all this in a logbook updated in real time. This amount of information is clearly presented in a selective and orderly manner to the decision makers, made up of the top management of the rescue and civil protection organizations, in order to be able to easily and quickly identify the information sought. A DSS, really, is able to do much more, in fact it can simulate using special software, starting from the data entered also in real time and provided by sensors (for example weather stations and seismographs) and by rescue teams, consequences on the population and on the territory of an emergency event, presenting them on the aforementioned cartography in the form of risk areas based on threshold values taken from national and international regulations, but also definable by users. Likewise, it may also be able to simulate the evacuation of some areas, calculating the times and evaluating the feasibility of this operation.

An application of DSS, based on Machine Learning, which could in the future be implemented by the Italian Fire Brigade relates to the possibility of automatically labeling an intervention as relevant, or as not relevant, to be able to warn the competent authorities and better manage the event, avoiding both bureaucratic and political problems. Currently the Fire Brigade uses a deterministic system based on a system of fixed parameters, which tries to capture all the characteristics that an intervention must have to be classified as relevant, but this approach often leads to an excessive generation of false positives. Therefore, the main challenge to be faced concerns the very definition of relevant intervention, i.e., what characteristics an intervention must have to be defined as relevant. To implement such a system, it is necessary first of all to use a correct set of intervention data, with the classifications as relevant or not relevant (based on the reports received) and then establish a series of other relevant parameters (features), such as the number of updates, the overall duration of the operations, but also the description of the characteristics of the territory from the GPS coordinates (to understand if you are in a built-up area, an industrial area or in an inaccessible area).

The objective of using DSS, in this case, is to “automate” and therefore speed up the response of the structures involved in an emergency, leading to a significant reduction in intervention times by the structures and subjects who must take action in case of need, as well as an increase in the response efficiency in qualitative terms.

3.3 Technical features of an emergency management DSS

From the user's point of view, the main characteristics that a DSS of this type must possess are:

1. to be as feasible and platform independent as possible.

2. to be easy to use and user-friendly to users with intermediate computer skills.

A valid and tested technological architecture for these systems is the client-server one, because it ensures the division of the application operation logical model into smaller functional units [7]. The user interface can be easily based on a web platform and this choice offers the following advantages:

1. the communication protocol has already been implemented and tested on an international scale (HTTP/HTTPS).

2. at the client level, no specialized software is required, only a web browser is needed, so the architecture can be implemented on many systems, without particular configuration requirements.

3. system upgrading can be a simple operation.

4. data transmission security is ensured by using the HTTPS, which provides a secure channel between the client station and the system residing on the server.

On the client-side, as mentioned, a web browser and an internet/intranet connection are required, while on the server side, at least:

1. an Operation System, for example Linux Based, which has good stability both in terms of security and performance.

2. a software for managing the various system components, written in a programming language that allows effective interaction and data exchange.

3. a DBMS, that is the software system that enables users to define, create, maintain, and control access to databases [8], which had already been mentioned.

4. a web server, that is a software and underlying hardware that accepts requests via HTTP, the network protocol created to distribute web pages.

3.4 DSSs and emergency planning

Many emergency plans on a territorial scale seem to have been created in analogy to those that are prepared for buildings, despite the great difference between the realistically possible scenarios. For buildings, information is known on what to do in the event of a well-known event (i.e., a fire), in a context already planned for the exodus, with a well-known occupancy and crowding, a partially predictable scenario and fire detection and alarm systems specially designed which the occupants are familiar with, but very little of this can be foreseen on a territorial scale. The fundamental variables for planning with accuracy are too many to solve the problem of managing the exodus phases a priori. Furthermore, the infrastructures have rarely been designed according to risks and equally rarely according to the exodus, with numbers of people involved and much more onerous situations and risks to be foreseen. A traditional planning, which defines in advance what to do during the emergency and foresees what information to give to the people involved, should consider a number of scenarios equal to the risks multiplied by the number of areas that can be affected and by the number of different conditions (night, day, summer, winter, weather conditions, etc.), which affect the distribution of people and the availability of rescuers. The related evacuation plans, however accurate, could never be as realistic as those assessed on the situation existing in the emergency scenario. A valid reference for identifying the potential risks to which the population may be exposed, which the plan plans to secure in the event of an emergency is offered by Chapter 5 of the NFPA 1600 standard (2020 edition). It divides risks into categories, including geological, meteorological, biological, human unintentional (including industrial risk and conventional CBRN risk), intentional human (including the risk of terrorist attacks), IT, economic ‒ financial and strategic. Starting from this reference, it is possible to understand how great the number of risks and credible scenarios can be for a typical territory and therefore how demanding the task of planning for the emergency becomes. The plans prepared to manage emergencies at a territorial level are usually conceived to proceed in an organized way with the deployment of rescue and civil protection resources. A civil protection emergency plan answers questions like this: where are the base camps located? Which entities should be involved? Who has to coordinate locally? Where are the command and control centers established?

The Italian guidelines on civil protection planning provides that each plan must include these three parts:

1. General part, inherent to the characteristics of the territory concerned.

2. Outlines of planning, in which response objectives and competences are set by the various agencies.

3. Intervention model, in which decision-making responsibilities are assigned, a chain of command and criteria are established for a rational use of resources and communications.

The plan, of course, must be constantly updated both because of the evolution of territory and population, and because of the feedback from the exercises.

A further and important functionality, which can be available in a DSS used for prevention and rescue purposes, is precisely that of carrying out simulations of emergency scenarios, which can be studied, or used directly to carry out protection and civil defense exercises, multi-agency, both multi-agency and with partial deployment of resources on the territory. The simulation allows, in this case, to verify the effectiveness of some choices made during the drafting of the plan and to appropriately allocate the available resources, always having an overview of the situation (thanks to the Geographic Information System) constantly updated.

Furthermore, being able to manage information flows and, in some cases, also communication tools, a DSS can allow, in a short time, to send alerts to the population. Some examples of the aforementioned tools are notices on motorway and road panels, the sending of text messages and the use of messaging systems and the use of special mobile applications to provide information in the event of an emergency. More particularly, the use of technological platforms of the type of Decision Support System, i.e., decision aid systems, can serve to immediately direct information to people exposed to risks.

3.5 Evacuation simulation and DSSs

During an emergency there can easily be a need to evacuate people from an area. When planning an evacuation, it is essential for civil protection authorities to know which areas will be affected by the event (for example a forest fire, a flood, a dangerous concentration of a toxic substance, etc.), when the areas will become untenable, how long it will take occupants in these regions to evacuate and how long it will take occupants to reach a designated place of safety.

Urban scale agent-based evacuation modeling tools offer the potential to address all these issues, especially if they can be integrated with emergency management DSS. In agent-based modeling (ABM), a system is modeled as a collection of autonomous decision-making entities called agents. Each agent individually assesses its situation and makes decisions on the basis of a set of rules.

The EXODUS large scale evacuation modelling system is an agent-based evacuation model capable of simulating the evacuation of large populations, measured in the hundreds of thousands, in large scale environments, as many square kilometers. It is based on the popular buildingEXODUS [8, 9] software and consists of three components: three parts:

1. urbanEXODUS, a desktop interface, which was developed to enable the EXODUS engine to easily represent large scale urban space.

2. webEXODUS, a portable GIS based web interface, which was developed to be utilized during an incident.

3. the EXODUS engine, which receives simulation inputs from urbanEXODUS or webEXODUS, performs the simulations and returns the results.

EXODUS can simulate an evacuation on foot of an area, but to have a realistic simulation it is necessary to consider also evacuation by car. A possible solution is the software “Simulation of Urban Mobility” (SUMO), which is an open source, highly portable, microscopic and continuous traffic simulation package, designed to handle large networks. It allows for intermodal simulation including pedestrians [10].

The integration of the two software models therefore allows realistically simulating an evacuation and as we will see it can be used by a DSS.

3.6 Application of a DSS

4.jpg

Figure 4. EXODUS, SUMO and hazard models integration

5.jpg

Figure 5. The process/architecture of the DSS adopted in the exercises of the IN-PREP project

A DSS for emergency management has been used during the exercises of the IN-PREP EU project. The project held its 2^nd full-scale exercise (FSX) in Genova and Savona, Italy on 28 October 2020. This was the penultimate full-scale exercise of the IN-PREP Project and the first to be carried out remotely due to the Covid-19 pandemic. The 2^nd FSX of the project simulated the response to a motorway incident involving a chlorine chemical spill, in the Italian region of Liguria affecting mainly the municipalities of Vado, Quilano and Savona. The analysis of the evacuation scenarios provides a quantitative assessment of the impact of different evacuation procedures on the evacuation performance including the population’s likely hazmat exposure [11, 12]. During the exercise were used EXODUS as pedestrians’ evacuation simulation model and the well validated SUMO vehicle movements simulation model. Figure 4 shows the integration of EXODUS, SUMO and hazard models in the DSS. The scenario started from a single non-intentional incident: a truck carrying hazardous material (Chlorine) has an accident and starts losing its contents within an urban area. The exercise was carried out using the resources realistically available at specific dates and hours. The DSS used was fed with real/realistic data, taking into account the possibility that the emergency managers could realistically access such data in the time available.

The diagram in Figure 5 shows the main parameters and data considered by the DSS and how they interact with each other [11, 12].

1. Modeling area: the definition of the area to be modeled within the EXODUS evacuation tool it represents a trade-off between the accuracy of the model and the commitment of computers in terms of time and resources to build it. The area considered is inhabited by 22,981 people, divided between the three municipalities of Vado, Quilano and Savona.

2. Location: is where the accident occurred, in the municipality of Vado.

3. Hazmat: Chlorine was used because it is a toxic substance which does not ignite, but remains buoyant harming people in its path.

4. Evolution: three release quantities and durations for Chlorine (450 kg, 810 kg and 216 kg).

5. Weather and Population distribution: The incident was assumed to take place in October 2020, with good weather conditions, light wind and no rain. Weather forecasts over 6-8 hours after the event time were calculated through the U.S. National Oceanic and Atmospheric Administration HYSPLIT [13] web app.

6. SOP Stand-off distances or Cloud modeling: on the basis of the scenario and the parameters introduced, the system identifies the evolution of the chlorine cloud and the distances from the accident below which irreversible and reversible injuries can occur. The distances were derived from the WISER app and software [14].

7. First responder availability: a realistic first responder availability as a function of date and hour for the selected days was considered, including roles, activation sequence and distance from their base.

8. Exit closed: the system considers the main communication routes exiting the places to be evacuated, the information provided to the population and both the spontaneous behavior of people aware of the danger as well as the impact on them of the instructions provided.

9. Hazard parameters: the evacuation model allowed for the calculation of time-distribution of the exposure of the population to risk of the potential impact on health in case of chlorine propagation. To do this, the model received as input the scenario-depending time series of iso-concentration shapes based on two toxic threshold concentrations: AEGL-1 and AEGL-2 [15].

10. Simulation stop times: for each scenario the evacuation simulation ended at the first-time step where the hazard parameters fell below the previously mentioned thresholds.

11. Notification parameters: For the exercise the notification methods considered included: the most common soon after the event, based on officers’ direct alert, by ringing the intercom, and automated Phone Call systems (or texts).

In Figure 6, an image provided by the software is shown: there are fifteen “alert zones” (areas to be eventually evacuated) in three municipalities which are Vado Ligure (orange), Savona (yellow) and Quiliano (dark grey) and the light grey cloud shows the trend of the chlorine gas dispersion. The red circles on the map indicate shelter/refuge locations for people evacuating by foot and the red stars are the exit points from the region for people using vehicles. During the exercise, the DSS simulated six scenarios, related to six different strategies, evaluating their outcomes to assist authorities to make well-informed decision. The six scenarios were: no kind of instructions given to the population, all people shelter-in-place, all people evacuate, two, four and seven zones shelter-in-place. The simulation showed that the third scenario (all evacuate) has the highest exposure levels, the first and second scenario have the lowest exposure levels and generally the more zones that are notified to shelter the lesser the exposure.

6.jpg

Figure 6. Screenshot of IN PREP DSS, during the 2^nd FSX

3.7 Criticality in the use of DSS

The use of DSS with support functions in emergency management certainly shows positive aspects, as we have seen in the previous paragraphs, but it, however powerful it may be, can only be useful if the emergency management policy provides that:

1. the authorities in charge of emergency management integrate in the emergency plans the elements for assessing the situation in real time (evolution of a fire, propagation of a toxic cloud, flooding, etc.) that the DSS provide.

2. citizens are adequately informed on the greater management capabilities that the platform allows and, on the channels, and methods of communication in emergencies.

However, also in view of the findings on the use of these systems, obtained in Italy and Europe, some factors have emerged that can make their effective use difficult by the emergency managers [12]. The main problems encountered may be summarized in the following points:

1. the cost and complexity of systems that are able to keep the evolution of the event under observation (from the moment it arises for the entire duration of the emergency, for example, forest fire, flood, release of toxic effluents into the atmosphere), factors that have slowed down the demand for the design of integrated DSS.

2. the ability to assess on an objective basis whether the time of departure is adequate to save people. What is normally done in fire safety (the comparison between the time available for the exodus and the time needed to escape) is only now beginning to be applicable to larger scales. The main obstacle is the availability of simulation applications for the exodus on a territorial scale, starting from updated data on the position of people (i.e., central areas of cities are much more crowded during the day than at night, tourist areas are more crowded in summer, etc.).

3. the difficulty of using information channels that reach the entire population. An example of such communication problems is the impromptu use of social networks. The alarm should reach all citizens, regardless of the tools they use to be informed (an issue that concerns the digital divide present in all societies). Also in this case, while considering that informing one hundred percent of citizens in real time is an unrealistic goal, the systems and protocols capable of integrating the various means of communication (media) are only now starting to be disseminated.

4. the lack of a unified data exchange protocol. The costs of creating a sensor network could be considerably contained if the DSS could use data from devices present in the area. The role of the data exchange.

5. protocol is to allow different systems to communicate without changes for the systems themselves. Unfortunately, adherence to unified protocols (in the emergency sector the most used protocol is the CAP - Common Alerting Protocol, described before) occurs only on a consensual basis. This among the problems is one of the most relevant, as the adoption of a single and widely shared and tested protocol among the various entities would allow to greatly streamline the complexity of the system.

6. the difficulty in finding new professionals capable of designing and managing systems that involve such different disciplines (emergency management, data exchange technologies, sensors, communications and risk assessment), which however could be solved in the future, with the development of the industry.

In general reliability is defined as the probability that a given system or component will operate without any failure for a given time when used under specified environmental condition. For ICT systems a distinction must be made between:

1. hardware reliability

2. software reliability

3. quality of the data provided.

The first two relate to the ability of an ICT system to perform its function without interruption and the third is linked to the system's ability to produce output data that meet the requirements set by users. An output that does not meet the requirements could be, for example, an incomprehensible conversation, or an imprecise geographical location. The DSS for emergency management and the ICT systems for emergency communication are called “mission critical”, in the sense that they are essential for the organization and that their malfunction has a significant impact on the activities of the organization itself. An additional difficulty is constituted by the fact that ICT systems for emergencies must work in real-time, responding immediately to user requests and changes in the scenario.

The reliability of the hardware, however complex, can be traced back to that of electronic devices and can be increased with the use of redundant systems. For the software it is different. Mission critical software are vastly different from normal personal computer programs. In many situations, failure of this kind of software results in loss of life, therefore failure is not an option for them and in the odd situation that they do fail, there must be back up measures in place to prevent catastrophe. This is the reason why, to increase reliability, the software engineering must include the following functions: fault prevention, fault detection and fault reaction.

This software usually run on multiprocessor machines, which can perform multiple computations at the same time. Parallel processing is necessary in real-time systems because the nature of the real world is such that various data are requested at the same time. When multiple processes are executed simultaneously, the system must manage the resources available in terms of computing power and memory between them, preventing two different processes from competing for the same resource, which would lead to failure. Software faults can be permanent, transient, or recurrent; the first occur and persist until the cause is repaired, the latter occur, persist for a time, then disappear and the third occasionally repeat themselves. A system fault may instead consist in an interruption of operation, in providing correct data but not at the requested time or in providing wrong data. While in the first case the cause can be both hardware and software, in the second and third the cause will depend on the software and there will also be output quality problems. To deal with software faults which can lead to failure there are two approaches: fault prevention and fault tolerance. The best results in terms of reliability are obtained by using both. The first approach is characterized by an accurate software design, by a careful selection of the input data and by an intense testing before use. The second approach foresees that in the presence of errors the system works with limitations, resets itself by restarting, or maintains full functionality even if for a limited time. This latter case represents the goal towards which mission critical software aims [21].

To prevent a system, such as a DSS, from supplying wrong data, it is necessary to foresee both the presence of output verification algorithms and the possibility of reaching the same results with different models and comparing the data provided by them. Essentially there must be a voting algorithm capable of evaluating the reliability of the output by comparing it with forecasts, probabilistic distributions and historical data [22].

In addition to internal errors, ICT systems for emergencies must also be protected from external threats. Cyber-attacks are becoming more frequent and can be launched for various reasons. The subtraction of personal data from large databases, such as those mentioned above, can be a source of income for cybercriminals and a very widespread attack is precisely that of the ransomware type, in which data is encrypted and to decrypt it is asked for a ransom. Another frequent attack is that of the denial-of-service type, which floods systems, servers, or networks with traffic to exhaust resources and bandwidth. As a result, the system is unable to fulfill legitimate requests.

Against cyber-attacks it is necessary to use all available hardware and software resources, but also to develop and maintain an IT culture in those who use the systems, aimed at maintaining cybersecurity standards. In fact, recently both private companies and public bodies have been subjected to phishing attacks, in which false communications are sent, which appear to come from a reputable source, usually through email, to steal sensitive data, as passwords.

In summary, although the bodies that deal with emergency management are often public institutions, with ICT systems well protected from external threats, it is evident that the reliability of these systems depends on many factors, none of which can be overlooked.