TeamAware System Architecture

Before the start of the project, TeamAware’s subsystems represented separate and standalone entities, and their operation was not tailored for their use as a part of a broader platform to be used by first responders.

During the first months of the project, WP2 has worked on describing the different subsystems that will be integrated into the whole TeamAware ecosystem. These systems will be adapted later in the project in their respective work packages according to the needs from end users and technical specifications defined by the technical work packages. Indeed, WP2’s descriptions have provided a common ground for the technical work packages that have officially kicked off in November 2021.

Nevertheless, these descriptions are just the first iteration, and they will be discussed and adapted within the technical work packages. This will result in a second iteration of the specifications which will be compiled and harmonised by WP2 to achieve interoperability with the TeamAware platform. As a result, a second version of the subsystems’ specifications will be generated by April 2022.

Except for the secure and standardised communication network, the description of all the subsystems has followed a systematic approach comprising a description of the following points:

1. General information, including a description of the subsystem and its functionality principles.
2. Team members who are supposed to use it.
3. A brief description of the underlying technologies and sensors.
4. A high-level architecture depiction.
5. The power source and power consumption of the subsystem.
6. The main data types it operates with.
7. The software stack of the prototypes, if it operates in a master-slave structure, and if it complies with any standards and recommendations, among others.
8. Information on the communications and integration, such as the data flows into and out of the subsystem as well as the formats and protocols used.
9. The need for fail-proof data transmission.
10. The existence of reference APIs.
11. The scalability of the subsystem and potential bottlenecks.
12. Typical data rates per unit.
13. IT resources (e.g. hardware, software, bandwidth, storage) required for the subsystem to operate with the whole TeamAware system.
14. Any other additional information that may be useful to achieve the integration with the platform.
15. Information on the operation of the subsystem, such as its essential features and operational parameters.
16. Whether they rely on other systems (such as a sensor depending on a drone).
17. The monitoring of the subsystem’s health.
18. Whether the system can be moved into the scene by alternative means if the scenario was too risky for humans.
19. Specific information which does not fall into any of the previous categories, because it is tied to the distinctive operation and characteristics of the subsystem. It has been structured as a set of specific questions for each individual subsystem.

Not only was this approach adopted in order to increase the readability and internal coherence of the specifications, but also to facilitate subsequent analysis and evolution of the specifications into their final version.

Additionally, it was possible to evaluate the targeted integration level of each subsystem into the overall TeamAware platform by the end of the project. The degree of integration has been divided into six incremental steps:

1. Step 1: any integration of system-specific data visualisation and/or GUI components only (for those subsystems which have them). This is the very minimal requirement to ensure common and single data visualisation in the TeamAware platform.

2. Step 2: “dockerising” system-specific data processing components, i.e. run system-specific components “as is” inside a Docker container in the TeamAware common cloud and deliver the system’s processing results “as is” into the TeamAware platform.

3. Step 3: common data storage under the TeamAware platform. Systems’ server-side components will store data on the same technological stack as they do in a standalone operation but relying on a common data lake instead of a separate system own storage.

4. Step 4: wrapping system-specific Docker containers together with I/O and flow control API. This would enable to control the system processes execution from the common TeamAware workflow, share common state control, or process logging.

5. Step 5: integrating into the TeamAware workflow server-side components which were used by the system in standalone mode (e.g. Apache Airflow). Here, minimal refactoring may be needed, although the component in general should not be re-implemented.

6. Step 6: fully integrating system server-side components into TeamAware as plugins, microservices or other kind of batch jobs according to the major TeamAware workflow framework.

For the purposes of this analysis all subsystems have been considered as black boxes, although for the second iteration of the specifications the analysis will zoom into the specific architecture elements of each subsystem and evaluate how that integration can be achieved.

TeamAware system	Integration level up to step #	Comments
Visual Scene Analysis System	1-2	VSAS Machine Learning results are stored together with video, and there is no separate GUI for integration.
Infrastructure Monitoring System	1+	Further integration levels could be considered, although a robust laptop deployed on-site may suffice to perform infrastructures’ analysis in a reasonable amount of time.
Chemical Detection System	3	Little or no complex CDS-specific data processing or GUI.
Acoustic Detection System	3	Step 1 (GUI) feasible. Subsequent integration steps may take place later in the project.
Team Monitoring Systems (Continuous Outdoor Indoor Localisation System)	1+	Step 1 (GUI) is agreed as a basic scenario with passive GUI. However, an “interactive” GUI (sending info to a mobile client) would need deeper levels of integrations.
Team Monitoring Systems (Activity Monitoring System)	3	Step 3 is the most feasible one since it provides both privacy and data fusion.
Citizen Involvement and City Integration System	3	The CICIS system operates as a two-way communications channel with citizens (i.e. collects messages from them and sends messages back to them). CICIS has its own GUI with a very specific data flow related to navigation logic. This GUI and workflow functionality are internal parts of CICIS, and do not need to integrate it into the TeamAware platform at any of the integration steps.