TeamAware Secure and Standardized Communication Network

The aim of TeamAware Secure and Standardized is to establish a cloud-based secure network. All of the components of TeamAware will communicate over this network, which means it will be at the core of the architecture. The network will use standard based data models and APIs in order to enable wider adoption of our platform. We plan to integrate it to existing first responder Operation Centers.

During the implementation of the network, first a TeamAware Data Ontology will be defined based on data models of existing sensor types and operation centers used in first responder operations. For this purpose, first a survey will be carried out in the TeamAware Consortium (data models of Sensor Gateways in the TeamAware Architecture and interfaces of the Operation Centers of the end users).

After that the survey will be extended with the existing standardized data models (OGC SensorThings API for sensor communication and OASIS Emergency Data Exchange Language – EDXL). Based on the survey, the data models will be harmonized and formalized into TeamAware Data Ontology.

Based on the TeamAware Data Ontology, a set of Sensor and Operation Center Adapter interfaces will be defined to manage the integration of sensors as well as the integration of operation centers to the TeamAware Network. (These will be called as TeamAware Interoperability Service APIs.) The Interoperability Services will respect existing procedures of actors in the whole disaster management cycle like (prevention, preparedness, response, recovery) fire brigades or ambulance services and will be integrated seamlessly in the workflow of decision makers. The adapter interfaces will provide registration, removal and querying of sensors dynamically as well as creation of sensor networks for cases requiring utilisation of complementary sensor types.

After the definition of the interfaces (TeamAware Interoperability Service APIs), the envisaged cloud network architecture will be designed and implemented based on open-source tools. The main objective at this point is a network architecture design, which will be scalable and optimized to connect different types and numbers of wearable, portable, and drone-borne sensors. The TeamAware Secure Cloud Architecture will be composed of three main parts:

1. Data Ingestion Layer: The data in the TeamAware Platform comes from a variety of data sources including IoT Devices, Social Media, Camera and Operation Centers. Most of the data is streaming data. Furthermore, considering the database requirements of the above listed TeamAware components, both NoSQL and Relational databases are used. For example, social media data is required to be stored in NoSQL database. Before storage the data should also be transferred to TeamAware Data Ontology for data interoperability. This means data from a number of data source (with different data rates) should be stored to different data bases. In the literature it is called flow management. Considering these requirements, the data ingestion layer has different aspects.

1. Flow Management: This part is responsible to retrieve (supporting any type of transport protocol) data from a data source, transform it to TeamAware Ontology and send it (or store it) to corresponding system. Currently, the Apache Nifi tool is one of the best open-source tools to realize flow management. Apache NiFi is an integrated data logistics platform for automating the movement of data between disparate systems. It provides real-time control that makes it easy to manage the movement of data between any source and any destination. It is data source agnostic, supporting disparate and distributed sources of differing formats, schemas, protocols, speeds and sizes such as machines, geo location devices, click streams, files, social feeds, log files and videos and more. It is configurable plumbing for moving data around through its Web based GUI, similar to how Fedex, UPS or other courier delivery services move parcels around. And just like those services, Apache NiFi allows you to trace your data in real time, just like you could trace a delivery. The data transformation will realize in Nifi through custom TeamAware processors. Based on the interoperability service definitions and ontology, the processors for each sensor (Sensor Gateway Adapter Processors) and operation center system (Operation Center Gateway Adapter Processors) will be developed.

2. Robust (Fault-Tolerant) Fast Streaming Bus: Inline with this tool, a scalable, robust, fast and durable (fault-tolerant) message queue is required to accommodate streaming data in TeamAware. For this purpose, the widely used Apache Kafka (open-source tool from LinkedIn) distributed data store will be used.

3. Database: Considering database as mentioned before there are many data requirements in the TeamAware platform. NoSQL, relational and streaming data is used in the system. For this purpose, the following open-source databases are considered to be used: MongoDB as NoSQL database, PostgreSQL as relational database and TimescaleDB as timeseries database.

2. Data Query/Retrieval Layer: After the data is stored to its proper location, interoperability services for query will be implemented to get required data (for presentation and/or analysis). The queries can be simple or complex, like requiring distributed querying. In those cases, Apache Spark will be used. Apache Spark is an open-source unified analytics engine for large-scale data processing. Spark provides an interface for programming entire clusters with implicit data parallelism and fault tolerance. An alternative implementation can be Apache Flink.