Service Platform Design Document (D5.1)

Deliverable D5.1 reflects the work carried out so far in the frame of Task 5.1 and presents  the architecture of the software-based Service Platform, describing its components, the purpose they serve and the way they interact with each other.

The main motivation behind a generic multi-mission software Service Platform, as opposed to application-specific solutions, is the observation that most disaster management platforms share some common aspects such as acquisition and processing of Earth Observation (EO) data, leveraging information from in-situ sensors using data fusion algorithms, using Geographical Information Systems (GIS) for information management/representation and using workflows for incident management. It is thus possible to build a generic application- agnostic core system to which all peripheral application-specific components will interface.

In the PHAROS context, the general system requirements laid out in D2.4 are used to derive the specific technical requirements for the Service Platform (SP). Functional requirements refer to access control, user management, configuration, access to historical data, monitoring, geospatial data storage and incident management. Interfacing requirements mandate the standards-based communication of the SP with: a user front-end (GUI), secondary user services, EO data sources, simulation services, Decision Support Systems, alerting services as well as third-party external services, such as weather providers. Non- functional requirements are associated to robustness and resilience, stability, expandability and virtualisation.

From the technical requirements, it is possible to specify an architecture which is fully modular and reconfigurable, by using “pluggable” mission-specific external services and modules, yet maintaining the core platform as generic as possible. The basic components of the Service Platform architecture are identified to be the following:

• a Data repository, for geospatial, sensor and generic data, allowing the Service Platform to act as information hub for all interconnected modules. Communication of data is achieved via open standardised services (OGC WMS/WFS/WCS/SOS).
• an Enterprise Service Bus for message routing, forwarding and adaptation, allowing the SP to act as mediator, facilitating communication in a unified way.
• a Workflow Engine for component orchestration, enabling the SP to run specific processes in order to pool data from sources, adapt them, invoke processing  modules and integrate the final product. This process is application-domain specific, yet it is easily reconfigurable and can be edited even via graphical editors.
• Last, the SP implements Management-related services, which allow the supervision of its operation and the configuration of the individual components.

It is concluded that it is feasible to design an efficient architecture which properly addresses all functional requirements, being at the same time open, scalable and generic/multi-mission. The proposed architecture exploits well-established contemporary paradigms in software engineering and relies on widely adopted standards and technologies. Service Platform interfaces mostly comply with global open standards (including the OGC specifications for geospatial and sensor data), thus promoting the applicability and future commercial adoption of the platform.