Emergency Management at Sea: A Decision Support System for Search and Rescue Operations

The relevance of Search and Rescue (SAR) maritime operations has been recently emphasized by the increasing migrations by sea. In the Mediterranean area, for example, a number of boats, often crowded, bad equipped and driven by non-professional sailors, travel from the coasts of Africa and Middle East to the ones of Europe: the wideness of the phenomenon and the occurrence of several mournful events have pushed the Italian government and the European Union to conduct large security operations (e.g. Mare Nostrum and Triton). Therefore, it has become urgent to support Maritime Rescue Coordination Centers and Sub–Centers and provide them with a Decision Support System (DSS) for planning and managing SAR operations at sea. This paper illustrates the background and the research methodology of the research project called “Decision support system for maritime environment emergency management”. The project has been carried out from 2011 to 2015 by two Italian companies (i.e. Selex ES – now Leonardo and Codin SpA) and an Italian public university (i.e. Politecnico di Bari), and funded within the Italian National Operational Programme for "Research and Competitiveness" 2007-2013 (NOP for R&C). Based on an in depth analysis of the literature and a field analysis carried out by adopting Business Process Management techniques, the project team has designed a prototypal DSS that includes some innovative functionalities.


Introduction
The paper discusses the background and the research methodology of the research project "Decision support system for maritime environment emergency management", whose goal is to design and develop a prototypal decision support system to plan and manage Search and Rescue (SAR) operations at sea. The system is intended to support Maritime Rescue Coordination Centers and Sub-Centers in accomplishing the following processes: SAR mission identification, simulation, planning, monitoring, and training. To this aim it includes the following functionalities: (i) collection and integration of data from different external sources (e.g. meteorological data, encyclopedic databases, electronic cartography); (ii) friendly human-machine interaction supported by a touch screen interface which allows simple and fast data entry; (iii) support to mission planning (e.g. identification of the most suitable vessels, automatic creation of a navigation plan, selection of the most suitable search algorithm); (iv) SAR operations workflow management (from early warningautomatically launched based of the results of a periodical and automated check of eventual route deviations for all the AISsupported ships-to automated mission reporting); (v) knowledge retrieval on previous SAR mission. All the functionalities, carried out by using already existing technologies, are developed so as to guarantee interoperability with heterogeneous systems within multicountry and multi-forces scenarios. The main problems related to the design and development of the decision support system prototype dealt with the creation of the system knowledge base, the design of the software and hardware architecture, the design of the human machine interface, the design of the system communication layer, the design of the wireless autoforming communication architecture able to adapt to different situations while satisfying security issues. All the problems were jointly addressed by the three project partners, namely Selex ES, an Italian company of Finmeccanica group ((now Leonardo), Codin SpA, an information technology company, and Politecnico di Bari, an Italian public university. The paper is organized as follows. In Section 2, the relevance of the topic is discussed. In Section 3 the results of the analysis of the literature on decision support systems for emergency management is reported. In Sections 4, 5 and 6 the architecture of the decision support system and the activities carried out to build the DSS knowledge base and to design the DSS communication layer architecture are discussed. Finally, the ongoing research and development activities are discussed.

Background
Migrations by sea are a deep rooted phenomenon. In the Mediterranean Sea, for example, it was practiced by Phoenicians, Cretans and Greeks at least since 1200 b.C. Drivers of migrations range from better life conditions, including better education opportunities, to protection from wars and persecutions. The recent mournful events occurred off the coasts of Lampedusa (Italy) and the forecast for a huge increase of migrations from Africa and Asia towards Europe make the migration by sea an urgent topic. Moreover, the challenging operations carried out by the Italian Government (i.e. Mare Nostrum) and the European Union (i.e. Triton) stress the relevance of SAR missions. As  As any MRCC, the Italian MRCC is in charge of managing, also by managing relationships and coordinating itself with the other eventually involved MRCCs, the search and rescue operations that involve Italian vessels and/or citizens all over the world. Also it is in charge of SAR operations involving vessels and foreigners people in its territorial waters. To manage SAR operations, several advanced technologies are adopted (e.g. NISAT and VTS). Yet, as confirmed by the analysis conducted, the Italian Corps of Harbor Masters and Coast Guard lacks of a system to support decisions which presents all the functionalities described in Section 1.

Decision support system for emergency management
To point out the typology of DSS to be developed, a review of the literature on the technologies and the processes dealing with SAR operations was conducted.
Information Systems researchers and technologists have investigated and developed DSS for several decades starting from the sixties (Power, 2007). For the sake of brevity, in this section only the main results are reported. In the literature, different definitions of decision support system are provided. Such definitions often blend in with those of Expert System (Hussain and Hussain, 1995). The research team decided to adopt the two following definitions for DSS and Expert System, respectively. A DSS is a computer-based information system that helps one or more managers to address unstructured or illstructured problems by collecting, organizing, summarizing, analyzing and modeling data in a variety of ways (Hussain and Hussain, 1995;Sauter, 2010). An Expert System (ES) is a computer-program that, by drawing upon knowledge captured by experts, proposes (and possibly implements) a solution for a problem. Expert systems usually have an explanation facility. They are appropriate when the task to be addressed requires expertise/logic rather than computation (Hussain and Hussain, 1995 Although not reported in the previous classification, a further typology of DSS adopts the logic of Process-Aware Information Systems (PAIS). A PAIS is a software system that manages and executes processes involving people, applications and/or information sources on the basis of process models (Dumas et al., 2005). Examples are workflow management systems and Business Process Management Systems, software products which support the automated execution of workflows and often allow also process analysis (e.g. by what-if simulation) and monitoring (e.g. by supporting performance measurement and pointing out bottlenecks). Such systems are useful especially for emergency management (De Leoni et al., 2010) and are sometimes referred to as BPM-driven DSS.
As discussed in (French and Turoff, 2007), DSS for emergency management should (i) be "tailored to purpose and context and embedded into the prevailing culture if they are to provide the support that is intended"; (ii) have a strategic focus; (iii) be able to manage explicit and tacit knowledge; (iv) support the identification of conflicting data;(v) allow continuous monitoring and the recording of decisional processes so as to generate a shared vision on what happens in the specific emergency situation. To address such issues, a DSS should be integrated with a workflow system. Hernàndez  not support most of the functionalities described in Section 1 (e.g. it does not automatically acquire data, does not include algorithms to order data, does not support coordination and document exchange among actors involved in SAR operations).
Based on the analysis carried out, the project partners decided to develop a system in between a DSS and an ES. Similarly to a DSS, the system maintains the ability to support actors by facilitating the access to and the visualization of information. Similarly to a ES, the system maintains the ability to present the possible solutions to the problem (e.g. it informs on conflicting data and identifying, at least for documental activities, the steps to be carried out. Such steps are suggested by sending alerts which prompt for an action). However, the system does not force the implementation of any solution proposed but let the actors make the final decision. The DSS developed in the project is a knowledge-driven, model-driven and BPM-driven decision support system.
The DSS is intended to support SAR operations as to alerting, simulation, planning, management, monitoring as well as training of the missions. The system is developed to be used by all the actors involved in SAR operations, from MRCC to the civil and military vessels' masters. The architecture of the system is described in Section 4.

The DSS architecture
The implemented Decision Support System (DSS) is based on a multilayer architecture with the aim of coordinating and supervising the acquisition and integration of heterogeneous information, coming from several sources and defining an innovative command and control system for efficiently managing the crisis situations. The DS architecture is reported in Figure 1. The DSS architecture presents a communication layer, a decision layer and a network layer (which will be discussed in Section 6). The communication layer realizes the dynamic interconnections between system components and allows the integration of external heterogeneous planning, management, monitoring as well as training of the missions. The system is l the actors involved in SAR operations, from MRCC to the civil and military vessels' masters. The architecture of the system is described in The implemented Decision Support System architecture with the aim of coordinating and supervising the acquisition and integration of heterogeneous information, coming from several sources and defining an innovative command and control system for efficiently managing the crisis situations. The DSS architecture is reported in Figure 1. The DSS architecture presents a communication layer, a decision layer and a network layer (which will be discussed in Section 6). The communication layer realizes the dynamic interconnections s and allows the integration of external heterogeneous sources. Furthermore, the communication layer translates the custom languages of the external sources in the solution standard language and monitors the system status and the components operating modes. Essential part of communication layer is the BPM that coordinates all solution components to achieve the designed functionalities. The decision layer analyzes in real encyclopedic data and implements data fusion operations in order to give decision support during SAR operations. This layer also displays mission data in an operational picture. The DSS is developed using an Enterprise Application Integration (EAI) approach to providing interoperability between the several sub-systems. In an EAI infrastructure, each sub-system does not require a different interface to connect to every other one; rather it uses standardized methods to connect to a shared module that is taking care of integration and message delivering to the whole system. sources. Furthermore, the communication layer translates the custom languages of the external sources in the solution standard language and monitors the system status and the components . Essential part of communication layer is the BPM that coordinates all solution components to achieve the designed functionalities. The decision layer analyzes in real-time encyclopedic data and implements data fusion operations in order to give decision support during SAR operations. This layer also displays mission data in an operational The DSS is developed using an Enterprise Application Integration (EAI) approach to providing interoperability between the systems. In an EAI-based system does not require a different interface to connect to every other one; rather it uses standardized methods to connect to a shared module that is taking care of integration and message delivering to the The DSS is composed by the following objects: -Human Computer Interface (HCI) client, which manages the presentation tier, linked to a touch screen monitor for the Man Machine Interface (MMI) data. -DSS portal, which provides another presentation tier, composed by the consultation actions, with static data, as formatted messages, roles management, tracks and encyclopedic data.
-DSS server, which manages the information tier and provides the data to the display tier. This server is the NGC (New Generation Console) system core and handles the available operator actions.
-GIS server, the map tier, which answers to the bounding box query coming from HCI and DSS Core servers.
-DB server, which contains the encyclopedic information (DB tier) and provides interfaces to expand the data features.
-Communication Bus, which enables asynchronous messaging and the fulfilment of dynamic information paths between the system components. It manages the communication 1:n and n:n using publish-subscribe and request-reply messaging patterns. Message format is based on XML.
-Adapter DSS Server, which interfaces the DSS Server with the external system components -Business Process Manager (BPM), which by receiving data from the communication layer detects and correlates in real-time complex events to realize the designed functionalities.
-Adapter METOC, which integrates a Meteorological and Oceanographic system to gain the right weather information.
-Adapter AIS, which integrates into the solution the Automatic Identification System to provide information about the ship, including ship's identity, type, position, course, speed, etc. No 3), which enables the exchange of structured information between the S&R mission members according to the ADatP-3 standard.

Search and Rescue processes: analysis and mapping
The design of a BPM-driven DSS should be based on an in depth analysis of the processes the system is intended to support and of the organizational context within it is to be used. A business process is "any activities or group of activities that take an input, adds value to it, and provides an output to an internal or external customer. Processes use organization's resources to provide definitive results" (Harrington, 1991). As processes represent the modes based on which organizations work, in the last decades an increasing number of scholars and practitioners was attracted by the process thinking Crowston, 2003). Methodologies, techniques and knowledge used to manage business processes in a more effective and efficient way are labeled as Business Process Management (BPM). To carry out the analysis of a process three main steps are needed (Crowston, 2003): (i) definition of the process boundary and root definition; (ii) data collection (documents, interviews and direct observation); (iii) data analysis to characterize and map the as-is process.
Within the present research project, data were collected both from SAR documents (i.e. IAMSAR publications) and by interviewing actors involved in the process, whereas direct observation was not carried out. used as a reference by the actors involved in SAR operations. The IAMSAR provides some guidelines for accomplishing SAR processes at sea by adopting both vessels and airplanes. All SAR processes included in the IAMSAR were analyzed and mapped by adopting the Business Process Modeling Notation (BPMN), a standard for modeling processes and web services developed by the Business Process Management Initiative (BPMI). "The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. BPMN will also be supported with an internal model that will enable the generation of executable Business Process Execution Language for Web Services (BPEL4WS). Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation" (White, n.a.). SAR processes are triggered by a signal, usually a telephone call or a radio signal, which arrives at the MRCC or MRSC or UCG. The signal triggers the actions which are described in the national SAR plan (which in turn adopts and integrates the IAMSAR guidelines). The actions include: an assessment of the information on the emergency situation; a definition of the emergency phase (based on the seriousness they are classified as Uncertainty Phase -INCERFA, Alert Phase -ALERFA, Distress phase -DETRERFA); a pre-alert of vessels; a definition of a general action plan; the delivering of information on the situation to the superior hierarchical level; an assessment of the research area, the appointment of a On Scene Coordinator (OSC); the development of the navigation plan and a formal request for vessels. If the emergency occurs in between different national SRR or in between SRRs managed by different national authorities, first the competences and the actors which will be delegated to take action need to be identified (which is not always an easy task). All the mentioned actions are indeed sub-processes. Each of them involves many different tasks which, per space restriction, are not reported in the paper. All the tasks and interdependencies among them have been identified and described. All the subprocesses have been mapped. As an example, the tasks to be executed in case of DETRESFA are reported in Figure 2.  Processes were mapped in BPMN. The maps were presented to the local Unit of Coast Guard located in Taranto (Italy) and to the Headquarter of the Corps of Harbour Masters and Coast Guard, located in Rome (Italy). They validated the maps and also allowed the research team to identify further problems and information needs of SAR actors so contributing to (i) the identification of specific functionalities and (ii) the creation of the DSS knowledge base. Based on that for all the sub-processes, a to-be model was developed. The prototypal DSS permits the execution of such a process model.

The DSS network layer: functional analysis and development approaches
DSS overall resources should be dynamically aggregated, to effectively face unavoidable dynamics that characterize the emergency scenarios. To this aim, the telecommunication infrastructure should satisfy the following functional requirements: -Network autoforming: the network topology control should be dynamic, thus optimizing system performance, in terms of delay and bandwidth; -Load balancing: the systems should interconnect each couple of nodes through a unique path which can minimize a predefined performance function, able to redistribute the load among the different network links available, at the same time optimizing the links capacity and latency; -Data integrity: it should be assured, against interferences in the transmission channels.
All this, taking also into account an intelligent data aggregation. Data will be exchanged safely among nodes, making the system integration with other "foreign" systems easier.
To face all these issues, the extended-QOLSR (eQOLSR) protocol is proposed. It is an enhancement of the QOLSR protocol (Kuipers et al., 2002;Badis et al., 2004;Badis and Agha 2005), which is a routing protocol supporting the functionalities of Network Autoforming, Routing e Load Balancing.
eQOLSR exploits the information on delay and bandwidth capacity of the various links to select the optimal route based on the nodes Quality of Service (QoS). It operates by means of three different information types, including routing (address of the destination node and the next hop to route all the traffic to), QoS control (number of hops of the route, bandwidth, end-to-end delay (Reid and Seide, 2002), residual power, overall outage probability), and the status of the destination node (CPU type, percentage of occupied CPU and memory).
More specifically, in this case the metrics observed to investigate the eQOLSR overall performance are of two different types: application layer metrics, which refer to the data flows generated by applications utilizing the DSS; eQOLSR-specific metrics, used to evaluate the efficiency and scalability of the protocol.
Relatively to the first class of metrics, the chosen indicators are: -End-to-end average throughput: for each application layer data flow, the mean value is computed of the information data (expressed in bits) correctly received in the time unit; -End-to-end average delay: the average delay is computed of a data flow, on an end-to-end basis.
As to the second class of metrics, the chosen indicators are: To validate the proposed protocol, a scenario has been implemented, composed by four terminals, all communicating each other through direct links, and forming a complete mesh.
This scenario is used to test the network performance, with and without the proposed eQOLSR. In both cases the measured versus requested bit rate has been evaluated, together with the packet loss, in the case of a direct packet exchange between two of the four network nodes and with all the links active. On the direct link, bandwidth bottlenecks of 1, 2, 5, 10 and 20 Mbps respectively have been simulated.
By comparing results with and without the adoption of eQOLSR, a consistent gain in the obtained bitrate (if compared to the requested one) is observed. As an example, let us suppose a requested bitrate of 50 Mbps and a bandwidth bottleneck of 10 Mbps on the direct link. With eQOLSR, the effective observed bitrate is 30 Mbps, while with the classical OLSR protocol, is of 10 Mbps. A second example considers a bandwidth bottleneck of 1 Mbyte/s and a required bit rate of 20 Mbytes/s. The measured bit rate making use of eOQLSR is of 11 Mbytes/s, with a packet loss of 39%, while a 95% packet loss is experimented without eOQLSR.
This last result is obvious, since the bandwidth bottleneck brings to a consistent increase in data losses with the OLSR adoption. And this explains why, even if the direct link is the shortest path between two nodes, it cannot be the best choice.
The much better results obtained through the eOQLSR can be easily explained by noting that eOQLSR realizes, after a short time, that the direct link between two nodes is not the optimal path (with respect to the connection quality), and chooses another path, different from the direct link. This chosen path has the maximum available bandwidth, and balances the load among all the links of the mesh network. In this way, the obtained effective bit rate is higher than the bit rate experimented with OLSR. Similar results hold also for the other bandwidth bottlenecks, and considering also an incomplete mesh network topology (i.e., some broken links are simulated).
The eOQLSR adoption increases the overall network performance in several utilization scenarios, also including broken links, thanks to the network autoforming and load balancing features. Furthermore, it guarantees data integrity against the communication channel inefficiencies. The DSS presents some innovative functionalities and was designed based on an in depth analysis of the literature and a field analysis carried out by adopting Business Process Management techniques.The activities currently carried out include the development of the prototype and some simulators to be used during the test-bed, the development and implementation of a validation plan, the system integration and the design of the test-bed itself. The authors are also currently working on developing some demos (small real cases) to clearly show the data and processes treated and how they are managed by the system as well as to test the system performance.