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 warning – automatically launched based of the results of a periodical and automated check of eventual route deviations for all the AIS-supported 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 multi-country 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 auto-forming 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 an example, within the operation called Mare Nostrum, managed from October 18, 2013 to October 17, 2014 by the Italian Ministry of Defense, 421 missions were carried out1 and 150,810 migrants rescued (more than 400 per day), so allowing to hold down the number of confirmed victims at 3,000.
The international conventions on safety of life at sea and maritime search and rescue are numerous and articulated. The most important treaties are the International Convention for the Safety of Life at Sea (SOLAS), the International Convention on Maritime Search and Rescue (SAR) and the United Nations Convention on the Law of the Sea (UNCLOS). SOLAS (London 1974) mostly deals with the safety of merchant ships. SAR (Hamburg, 1979) concerns the organization, coordination and management of search and rescue operations. Based on it, each country appoints a national Maritime Rescue Coordination Centre (MRCC), which is responsible for coordinating and managing SAR operations within the own Search and Rescue Regions (SRR). Such regions were defined by the International Maritime Organization (IMO), a United Nations specialized agency with responsibility for the safety and security of shipping and the prevention of marine pollution by ships. UNCLOS (Montego Bay, 1982) mainly concerns the “navigational rights, territorial sea limits, economic jurisdiction, legal status of resources on the seabed beyond the limits of national jurisdiction, passage of ships through narrow straits, conservation and management of living marine resources, protection of the marine environment, a marine research regime and, a more unique feature, a binding procedure for settlement of disputes between States”2.
In the case of Italy, the Ministry of Transportation and Infrastructure is the Italian Authority in charge of Maritime Search and Rescue operations. Operations are carried out by the Corps of Harbor Masters and Coast Guard Headquarter (Comando Generale del Corpo delle Capitanerie di Porto) which is the Italian Maritime Rescue Coordination Centre (IMRCC). It coordinates 16 sub centers (Maritime Rescue Sub Center – MRSC) which in turn coordinate 54 Units of Coast Guard (UCG) and other minor sub-centers. 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 ill-structured 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).
There exist several and sometimes ambiguous DSS classifications: some of them adopt different terms to refer to the same typology or vice versa (e.g. Bhargava et al., 2007, Arnott e Pervan, 2005, Power 2007). The classification proposed in Power (2007) is the following:
– Model-Driven (Optimization and simulation; Realistic data and forecasts but quite complex to be used)
– Data-Driven (Access to data by free queries, OLAP, data mining, data analysis, data warehouses; Rapid access to data and integration of databases)
– Communication-Driven (Network and communication technology; Real time video and audio communication)
– Document-driven (Document retrieval and analysis, search engine; Transformation of unstructured into structured and re-usable data
– Knowledge-driven (Support based on experience; Recommendations to decision makers)
– Web-based-driven (Support based on web applications)
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 and Serrano (2001) present some characteristics of knowledge-based DSS specific for emergency management. The characteristics include the capability to describe the most relevant events in the monitored area, the capability to make forecasts on the evolution of the situation by the means of scenarios and the capability to support more critical decisions.
Several examples of DSS for emergency management (e.g. earthquakes, nuclear incidents, infectious diseases) are reported in the literature (e.g. Wallace and De Balogh, 1985, Fiedrich and Burghardt, 2007; Ghaderi et al., 2007; Yoon et al., 2008; Amdahl and Hellan 2009; Wang et al., 2013; Wysok et al., 2014; Filippoupolitis and Gelenbe n.a.). However, (i) in most cases neither the architecture nor the working mode are sufficiently discussed and (ii) the systems proposed are not developed for managing maritime emergencies. To the best knowledge of the authors, the only DSS ad hoc settled to support SAR operations is the CNR SAR System, developed by the Institute of High Performance Computing and Networking of the Italian National Research Council (Istituto di Calcolo e Reti ad Alte Prestazioni — CNR), located in Palermo (Italy)3. The system supports many procedures involved in SAR operations. However, it does 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 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 between system components 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-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 picture.
The DSS is developed using an Enterprise Application Integration (EAI) approach to providing interoperability between the several sub-systems. In an EAI-based 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.
Figure 1: The DSS Architecture.
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.
Adapter ADatP-3 (Allied Data Publication 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.
International Aeronautical and Maritime Search and Rescue (IAMSAR) is a three-volume publication developed and published by IMO and the International Civil Aviation Organization (ICAO). It is 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 sub-processes have been mapped. As an example, the tasks to be executed in case of DETRESFA are reported in Figure 2.
Figure 2: DETRESFA: sequence of tasks
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:
”’ The total number of HELLO messages sent and received by the network nodes. An HELLO message is a message periodically emitted by a node to detect neighbors and the corresponding state of the communication line.
”’ The total number of Topology Control (TC) messages sent and received by the network nodes. A TC message sent by a node gives information about the network topology. It includes the list of neighbor nodes that can relay the control information (MultiPoint Relay, MPR) and the QoS metrics (bandwidth, delay, the computational overhead, total and available memory, and residual battery power) related to the link connecting the selected node to the MPRs.
By combining all the information previously illustrated, a routing table is built, which takes into account all the aforementioned constraints to route the traffic to destination.
The error control technique proposed in this context is the Random Linear Network Coding strategy (Ghaderi et al., 2007) that allows the realization of reliable communications in multicast, with reduced times of message delivery, a low computational complexity and high flexibility.
This strategy allows the integrity of received data, also through heterogeneous links, against interferences in communication channels.
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.
Conclusions
The paper discusses the background and the research methodology adopted within “Decision support system for maritime environment emergency management”, a research project whose goal is to design and develop a prototypal decision support system to plan and manage Search and Rescue (SAR) missions at sea.
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.
Acknowledgements
This research was financially supported by Italian Ministry of University, Research and Instruction within the Italian National Operational Programme for “Research and Competitiveness” 2007-2013 (NOP for R&C), project ID: PON01_02499.
http://www.marina.difesa.it/EN/operations/Pagine/MareNostrum.aspx.
2http://www.un.org/Depts/los/convention_agreements/convention_historical_perspective.htm#Historical%20Perspective
3http://www.pa.icar.cnr.it/icar2/content/view/58/75/lang,it/
References
1. Amdahl, J. and Hellan, Ø. (2009) ‘Intentional grounding of disabled ships – On-board and shore based decision support system’ Proceedings of the 3rd International Conference on Collision and Grounding of Ship, 25-27 October 2009, Izu, Japan.
2. Arnott, D., Pervan, G. (2005) ‘A critical analysis of decision support systems research’, Journal of Information Technology, Vol. 20, pp. 67—87
3. Badis, H. and Agha, K. A. (2005) ‘QOLSR, QoS routing for ad hoc wireless networks using OLSR’ European Transactions on Telecommunications, 16( 5), 427-442.
4. Badis, H., Gawedzki, I. and Al Agha, K. Al. (2004) ‘QoS routing in ad hoc networks using QOLSR with no need of explicit reservation’ Proceedings of the 60th IEEE Vehicular Technology Conference (VTC ’04), no. 4, pp. 2654-2658, September 2004, Los Angeles, CA, USA.
5. Bhargava, H.K., Power, D.J., Sun, D. (2007) Progress in Web-based decision support technologies, Decision Support Systems, Vol. 43, pp. 1083— 1095.
6. Crowston, K..(2003) Process as Theory in Information System Research. In Malone, T.W., Crowston, K. and Herman, G.A. (2003) Organizing Business Knowledge, The MIT Process Handbook, The MIT Press, Cambridge, MA, USA.
7. De Leoni, M., Marrella, A. and Russo, A. (2010) ‘Process-aware Information Systems for Emergency Management’ Proceedings of EMSOA, 13-15 December 2010, Ghent, Belgium.
8. Dumas, M., van der Aalst, W. and Hofstede, A.H.M. (2005) Process aware information systems: Bridging People and Software through Process Technology, John Wiley and Sons, New Jersey, USA.
9. Fiedrich, F. and Burghardt, P. (2007) ‘Agent based systems for disaster management,’ Communications of the ACM, 50(3), 41-42.
10. Filippoupolitis, A. and Gelenbe, E., (n.a.) ‘A Decision Support System for Disaster Management in Buildings’ [Online], [Retrieved October 10, 2012], http://sa.ee.ic.ac.uk/publications/filippoupolitis-gelenbe_scsc09.pdf.
11. French, S. and Turoff, M. (2007) ‘Decision support systems,’ Communications of the ACM, 50 (3), 39-40.
12. Fu, T. (2006) Environmental Emergency and Typical Cases, China Environmental Science Press, Beijing, China.
13. Ghaderi, M., Towsley, D. and Kurose, J. (2007) ‘Network coding performance for reliable multicast’ Proceedings of 2007 Military Communications Conference (MILCOM 2007), 1-7 october 2007.
14. Harrington, H. J.(1991) Business Process Improvement, McGraw Hill, New York, USA.
15. Hernà ndez, J.Z. and Serrano, J.M. (2001) ‘Knowledge-based models for emergency management systems,’ Expert Systems with Applications, 20, 173-186.
16. Hussain, K.M. and Hussain, D. (1995) Information Systems: Analysis, design and implementation, Tata Mc Graw-Hill, New Delhi, India.
17. Kuipers, F., Van Mieghem, P., Korkmaz, T. and Krunz, M. (2002) ‘An overview of constraint-based path selection algorithms for QoS routing,’ IEEE Communications Magazine, 40(12), 50—55.
18. Power, D.J., (2007), ‘A brief history of Decision Support Systems,’ DSSResources.COM. [Online], [Retrieved October 10, 2012], http://DSSResources.COM/history/dsshistory.html.
19. Reid N. and Seide, R. (2002) 802.11 (Wi-Fi): networking handbook, The McGraw-Hill, New York, USA.
20. Sauter, V.L. (2010) Decision support systems for business intelligence, John Wiley & Sons, Inc. Publication, Hoboken, New Jersey, USA.
21. Wallace, W.A. and De Balogh, F. (1985) ‘Decision support systems for disaster management,’ Public Administration Review, 45, 134-146
22. Wang, D., Pan, L., Lu, L., Zhu, J., and Liao, G. (2013), ‘Emergency management business process reengineering and integrated emergency response system structure design for a city in China,’ Procedia Engineering, 371-376.
23. White, S.A., (n.d.) ‘Introduction to BPMN’[Online], [Retrieved October 10, 2012], http://www.omg.org/bpmn/ Documents/Introduction_to_BPMN.pdf
24. Wysok, I. M., Marcjan, R., and Dajda, J. (2014) ‘Decision support software for search & rescue operations,’ Procedia Computer Science, p. 776-785.
25. Yoon, S., Velasquez, J., Partridge, A., and Nof, S. (2008) ‘Transportation security decision support system for emergency response: a training propotype,’ Decision Support Systems, p. 136-148.
