Keywords

Introduction

Pathogens are a determining factor in emergency response due to their life-threatening nature, both for the public as well as for the First Responder (FR) safety. Waterborne pathogen contamination events can occur anywhere, and may be caused by various reasons, i.e., natural events, accidents or malicious attacks, illegal activities, and cascading effects. To manage such incidents, FRs have ex-pressed the need for a number of new technologies and tools, including but not limited to, sensors for rapid detection of pathogen contaminations, technologies for safe water sampling, decision support tools, tools to isolate the contaminant source and to conduct forensic investigation, restoration guidelines, etc.

To ensure the design and deployment of better and more effective products and services, the PathoCERT project relies on participatory and cocreative approaches. Specifically, the PathoCERT’s multistakeholder engagement approach builds upon several interlinked activities, among others the engagement of stakeholders via the establishment of six Communities of Practice (CoPs). A CoP can be defined as a structure that brings together a group of actors who share a common interest in a topic and come together to fulfill both individual and group goals. To identify relevant actors and analyze to be engaged in the CoPs and to better understand their interconnections, relationships and interest within as well as to form an understanding of the current situation or status quo of a system, PathoCERT follows the stakeholder mapping methodology [1] and baseline requirement analysis [2, 3].

The above analysis was conducted by local consortium partners of each region under study (i.e., Granada, Spain; Amsterdam, The Netherlands; Limassol, Cyprus; Thessaloniki, Greece; Sofia, Bulgaria; and Seoul, South Korea) and which will host the validation tests and demonstration exercises. Moreover, it developed a good understanding of the current emergency response and disaster management systems in each region, including applied technologies, and main challenges and opportunities for improvement within. The examination and analysis of requirements, needs, challenges, and opportunities are important to ensure that the project develops and tests appropriate solutions that contribute to improving and advancing the emergency and disaster management system.

More specifically, the emergency and disaster management system in Greece, is advanced and keeps track of the most recent developments, but lacks coordination among operational actors. Moreover, operational entities effectively follow and implement emergency civil protection plans, nonetheless, factors such as scale or timing of disaster, reduced human resources, frequent staff changes, improper definition of each actor’s role and responsibilities, as well as bureaucracy, can diminish this effectiveness. Accordingly, providing relevant guidelines and clarification to each actor involved, on their roles and responsibilities in emergency management would support in effectively addressing such a challenge [4].

PathoCERT aims to strengthen the coordination capability of the FRs during such incidents, allowing the rapid and accurate detection of pathogens, improving their situational awareness and their ability to control and mitigate emergency situations involving waterborne pathogens. Overall, the new solutions will span from individual responders to the Command-and-Control (C2) Center in the field and the Coordination Center in Headquarters. PathoCERT incorporates the PathoIMS incident management system to monitor and coordinate FR activities.

PathoCERT Solution

To identify all the modules required in PathoCERT architecture, it was necessary to identify the actors involved (Fig. 9.1) in such incidents and identify their needs. These are the FR on the field, that can be from different organizations and have different ways of operating. They communicate with the FR form C2 Center which is on the field (usually a vehicle). The C2 Center, communicates with Crisis Management Headquarters (HQ) in which specialists are working collecting, exchanging, and processing information. They communicate with water quality specialists and other water authorities. Each one provides information to the HQ that gives information back to the C2 Center and FR on the fields.

Fig. 9.1
5 photos of the crisis management headquarters. The photographs are of crisis management headquarters, first responders on the field, first responders command and control center, water quality specialists, and water authorities.

PathoCERT main actors

Full size image

After identifying the actors, it was important to understand how they manage water pathogen contamination events and understand their needs. During several meetings, user stories have been identified and shared to facilitate the collection of requirements. Technically, user stories consist of three parts, the person/role that the solution is developed for, what they are trying to achieve, and what is the overall benefit and problem that needs to be solved. Based on the User Stories, then, the software modules of PathoCERT architecture (Fig. 9.2) and the ways in which these modules interact with each other were identified.

Fig. 9.2
A block diagram of the 4-layer Patho C E R T architecture. It consists of a data collection layer along with the device manager having data sources and the I o T gateway, followed by a data management layer through interoperability and data harmonization layer, a data processing layer, and application layer.

PathoCERT Architecture Overview

Full size image

The PathoCERT reference architecture [5] is composed of the following layers:

  • Data Collection Layer: Responsible to collect information from heterogeneous sources such as the PathoSENSE IoT gateway, the PathoDRONE, the PathoSAT, the PathoTWEET, the PathoCAM, as well as the SCADA systems of Water Utilities and relevant open data sources. The layer consists of:

    • IoT agents that enable sensors and actuators to exchange data with a Context Data Broker using their own native protocols.

    • IoT Device Manager that allows the centralized management of IoT devices, providing the possibility for a decision-maker to increase situational awareness about the territory and the sensors available on the field.

    • Data Connectors used to get data from non-IoT device (i.e., PathoTWEET, OpenData, PathoSAT, PathoCAM, and PathoDRONE images).

  • Interoperability and Data Harmonization Layer: Responsible for the harmonization of the data according to the adopted FiWARE smart data models and ontology used in PathoCERT.

  • Data Management Layer: Responsible for the data storage and dispatch to the other components of PathoCERT. It consists of the:

    • Context Broker (CB) which enables discovering gathering and publishing of context information through NGSI-based APIs.

    • Alert Broker, dedicated to generating real-time alerts to PathoVIEW.

    • Media Server, responsible for sharing and processing of media.

    • Fileserver, which is responsible for storing large files (e.g., GeoTIFF provided by PathoSAT).

    • Geospatial server, used to share, process, and edit geospatial data.

    • Spatial and nonspatial DBMS, responsible for the storage of geospatial data and nongeospatial data.

    • PathoSTH, in charge of managing (storing and retrieving) historical data and aggregating time-series information.

    • Open data federator, a single point of access (i.e., catalog) to data of the city/territory, coming from different sources: for example, Open Data portals related to demographic information, endpoints of local legacy systems such as SCADA, etc.

  • Data Processing Layer: Where actual processing and analysis of the data is performed in order to generate added value for the decision makers. It leverages the real-time streaming analytics component and the software modules that will be used for detection, epidemiological risk assessment (PathoTHREAT), and criminal investigation (PathoINVEST).

  • Application Layer: Contains the services/applications offered to the FRs, to the C2 Center, to the HQ, and to Water Authorities. It is composed of PathoIMS, PathoVIEW, and PathoGIS.

  • Security and Privacy Layer: Contains a set of modules aimed at ensuring data and privacy protection, management of identities, authentication and authorization of users accessing assets, while also logging information regarding access for audit purposes.

All above layers comprise the PathoWARE Platform, that provides the communication and integration infrastructure to all the other modules of the architecture.

The PathoCERT Incident Management System

According to the architecture (Fig. 9.2), the components of the PathoCERT framework are grouped into two main categories: the components that are related to data management and processing and the applications that support the actual interface of the framework with the end users.

PathoIMS is part of the application layer that receives data from the data layers, presenting a situation overview to the commanders and first responders and providing the required incident management capabilities to them. PathoIMS is planned to be deployed in the HQ (desktop version) and on mobile control centers (mobile/tablet version) (Fig. 9.3), supporting the operations of commanders in the HQ and the team leaders on the field, and the sharing of operational information among them. Both types of PathoIMS applications will be synchronized, presenting a common picture of the situation to all users (considering their responsibilities and access rights). The sharing of data among the data and application layers is provided by the PathoWARE component.

Fig. 9.3
A flow diagram of Patho I M S. It has the pathoWARE interconnected to patho I M S desktop version and mobile version. The desktop version is connected to the headquarters. The mobile version is connected to the mobile control center and team leaders.

PathoIMS deployment and communication with the framework

Full size image

In more details, PathoIMS is based on the ENGAGE IMS/CAD system,Footnote 1 enhanced in order to support the response activities of the waterborne pathogen contamination events. The design of the PathoIMS capabilities has been based on the initial project objectives, as well as the feedback provided by the stakeholders during the CoP events, considering the following:

  • Flexible and intuitive Graphical User Interface (GUI), requiring the minimum intervention of commanders in order to use functionalities and take decisions, but also presenting information to users in a user-friendly way.

  • Maximizing the performance of the solution to support operations without delay.

  • The system is designed to be open and interoperable with third-party and agencies’ legacy systems, through using interoperability standards.

  • Multiuser collaborative capabilities, enabling situation monitoring and communication among FRs, to support multidisciplinary users that have to be simultaneously active and execute response missions [6].

PathoIMS N-tier architecture comprises a diverse set of Servers and Services suitably interconnected to scale and support clients’ needs. More specifically the ecosystem consists of the following layers:

  • Database Layer: Providing the geospatially enabled relational database for data persistence and supporting the storing of all data managed by PathoIMS.

  • Messaging Layer: It enables event-driven communication with the internal and external systems (incidents, alerts, and warnings).

  • Communication Layer: Consists of diverse services for bidirectional communication with the devices on the field, tracking devices, Messaging Layers, and other data providers, allowing open and flexible data sharing from/to third parties.

  • Application Layer: The back-end service that implements the whole business logic that is required by the PathoIMS clients.

  • Clients Layer: Contains two types of PathoIMS clients, the desktop and the mobile/tablet version.

  • OS/Virtualization Layer: The system supports all editions of Windows Server and many editions of Linux Operating Systems. In addition, containerization via Docker technologies is also supported.

  • Load Balancing Layer: Implemented either via software or via hardware enabling the scaling and support of thousands of users.

  • Security Layer: Advanced security and authentication techniques are used. Additionally, the access to the information by the users is controlled by the system, considering their hierarchy, access rights, and responsibilities (Fig. 9.4).

Fig. 9.4
A block diagram of the system architecture. It comprises database servers, messaging, operating software, load balancing, security, communication services, application servers, and clients.

PathoIMS internal design

Full size image

All PathoIMS functionalities are provided to users through a rich and user-friendly GUI. The desktop version supports an advanced set of incident management functionalities. On the other side, the functionalities and the graphical user interface of the mobile/tablet are optimized to the small screen size of the devices and to the capabilities that are required by the commanders on the field/mobile centers. The main list of functionalities that are supported are:

  1. (i)

    Creation of the Common Operational Picture (COP);

  2. (ii)

    Incident Management;

  3. (iii)

    Alarm Management;

  4. (iv)

    Resource Tracking;

  5. (v)

    Interconnection with external resource tracking systems;

  6. (vi)

    Support of Standard Operational Procedures;

  7. (vii)

    Visual presentation of operational information (map, tabular views);

  8. (viii)

    Reporting;

  9. (ix)

    User management;

  10. (x)

    Logging & Audit; and

  11. (xi)

    System Administration.

All the above functionalities are demonstrated and validated during the project pilots in Limassol, Thessaloniki, Sofia, and Granada. Through the live demonstration and exercise-based pilots, the developed tools and technologies will be tested, validated, and evaluated by internal and external stakeholders.

PathoCERT Testing and Evaluation: The Greek Pilot

Specifically, within the pilot in Thessaloniki (Greece), IMS capabilities will be tested as part of an exercise scenario related to water pathogen contamination due to extreme rainfall phenomena that cause flooding on the river Axios, in the western suburbs of Thessaloniki. The impact of the flood involves both Water Supply & Sewage Company (EYATH) and Hellenic Rescue Team (HRT), the main actors of this exercise, who will get a hands-on experience of the capabilities offered and the impact of the tools with regard to the management of such an incident.

More specifically two scenarios will take place, one regarding the river overflow due to flooding, with possible pollution of the crossing open channel that transports water to the Thessaloniki Drinking Water Treatment Plant (area A in Fig. 9.5), while the second scenario (area B in Fig. 9.5) is linked with Search and Rescue (SAR) activities for people carried out by the increased flow of the river [7].

Fig. 9.5
A map of the wider Greek pilot area. It has two points of interest. The first is the overflow of a river due to flooding. The second is the search and rescue activities area.

Map of the wider Greek pilot area with the two points of interest

Full size image

These scenarios will set the stage so that on the one hand the internal stakeholders involved in the project, (HRT and EYATH) to test those tools and on the other, the external stakeholders (General Secretary for Civil Protection, Fire Service, Directorate of Public Health and Social Welfare, etc.) to observe their demonstration that will:

  • Increase the coordination among operational actors, by providing clarification to the actors based on their role/responsibilities, reducing response time, enhancing resource allocation, etc.

  • Exploit the advantages toward involved Authorities, increasing acceptance toward new technologies, and expanding the financial resources allocated.

  • Improve citizens’ understanding and engagement in emergency events through capacity-building activities, educational and informative campaigns.

Specifically, the PathoIMS will be validated and evaluated according to the following needs and criteria presented in Table 9.1.

Table 9.1 User needs related to PathoIMS
Full size table

Conclusions and Next Steps

In this paper, the authors present the concept and added value of an integrated solution, PathoCERT, which captures the complete spectrum of waterborne pathogen contamination management from detection and situation awareness, to epidemiological, threat risk assessment, and criminal investigation. Overall, the new solutions will address a different part of the FR organization chain, starting from the individual responder who is out in the field, to the mobile Command and Control which coordinates the operations in the field, to the Headquarters that monitor and provide information to the Incident Management System (PathoIMS).

PathoIMS, which will be used by the Incident Commander who is responsible for coordinating the event, is developed to support information exchange and effective coordination on the contamination event management between the Command-and-Control Center and the FR Headquarters.

PathoIMS capabilities offered, include but are not limited to, Incident Man-agement, Alarm Management, Resource Tracking, Support of Standard Opera-tional Procedures, Visual presentation of operational information (map, tabular views), Reporting, etc., all of which will be demonstrated and validated during the pilots of the project and specifically in Cyprus, Greece, Bulgaria, and Spain.

Specifically, PathoIMS will be evaluated through the following Key Performance Indicators: (1) Optimized tactical response: 40% reduction in manpower, 40% reduction in response times; (2) Reduced time between victim extraction from hazardous area and proper medical treatment: 50% reduction; (3) Optimized victims/citizens handling, during a hazardous event: >50% increase in worksite declassification time.