PHAROS System Architecture – Final (D2.9)

This deliverable presents the final version of the high level description of the multi-hazard open service platform to be designed, implemented and tested during the PHAROS project. The description, like when presenting its draft version, is done from a functional perspective, identifying the building modules (or sub-systems), describing their functionalities and identifying a series of interfaces to allow communication between them and with external actors and agents. External actors and agents can be defined as any entity interacting with the PHAROS system which is not included within the system boundaries defined in the current document. An example of external agent could be any emergency management system different from PHAROS and willing to use PHAROS data, for instance.

The deliverable documents the outcomes of “Task 2.4: Overall System Architecture”, whose main objectives are:

• To identify the system elements based on the functional architecture
• To specify the system and network architecture, identifying also the interfaces between system elements and also with external agents [1].

The deliverable presents the final version of the system architecture taking as a basis the draft version described in [2], the ongoing works in the work packages dedicated to the different system modules (WP 3 to 5) and the discussions carried out with the members of the Advisory Board (AB) and local end users. These discussions, which have been hold mostly in the context of the second Advisory Board Workshop (AB WS 2) have triggered a new revision of the user and system requirements which were collected in [3] and will be documented in [4] (due in February 2015).

The main differences between this final version of the document and the draft version are as follows:

• Accommodate the latest modifications in the system architecture derived from the successive works carried out within the design and development work packages of the different system modules (WP 3, 4 and 5) and from the latest discussions with the members of the AB and local end users.
• Include a discussion and argumentation on the different scalability options that the system shall take into consideration and which will have an influence in the business model to be devised.
• Differentiate the short and long term system approaches to set the basis for the design and implementation in the short term.

The primary inputs which have been used to define the system architecture as described in the draft version [3] are:

• the application scenarios and service concept specification defined within Task 2.1 [5] and
• (2) the first issue of the collection of user (UR) and system requirements (SR) defined within Task 2.3 [3].

In this second version, apart from the already mentioned inputs, the outputs coming from the on-going tasks within WP 2 (“Multi-hazard open service platform specification and business aspects”), WP 3 (“Situation assessment, decision support and earth observation”), WP 4 (“Satellite communication, navigation and alerting”) and 5 (“Integrated service platform”) have been also taken into consideration.

The outcome of this deliverable will be used as input for the design and implementation tasks to be carried out within WP 3, 4, 5 and 6 (“System integration, testing and validation”) as well as for the system engineering tasks within WP 2 and the definition of the business model to be carried out within Task 2.2 (“Service sustainability and business plan”).

Regarding the structure of the document, it must be pointed out that, for the sake of clarity and unlike stated in the PHAROS DoW [1], the documentation of the corresponding works to derive the system functional architecture has been included in [2] and the present document (instead of documenting it in [3] and its successive issues). The main reason for this modification has been to try to separate the documentation regarding the process for gathering and defining the requirements, carried out in Task 2.3, from the documentation regarding the process of identifying the functional and system architecture. Since the two tasks have been carried out in parallel, it has been possible to allow communication between the tasks and benefit from the synergies between them. The system architecture has been derived from the analysis of the user and system requirements (first collected in [3] and being updated in [4] at the time of submitting the present document), but for documentation purposes, it has been considered that it would be clearer for the reader to keep all the information related to the PHAROS architecture grouped together in the present deliverable.

Unlike in the draft version of the deliverable, the system architecture is described using two temporal approaches, according to the definitions given in [5]: the long term and the short term approach. The architecture presented in the long term approach is a generic architecture independent from the type of hazard to be tackled and the real tools and solutions to be used in the implemented version of the system. The objective of this section  is to highlight the multi-hazard characteristics of the system and ensure that the system architecture does not impose any limitation to extend the system to handle other types of hazards. Therefore, all the descriptions and discussion presented in the document, use generic terminology for referring to the different system modules (sub-systems) and not the particular names of the tools that might be used during the implementation phase. For the short term, the architecture presents the particular modules to be taken into consideration during the duration of the PHAROS project, focusing on the forest fire scenario to be used for the implemented and demonstrated system.