Final Report Summary - PHAROS (PROJECT ON A MULTI-HAZARD OPEN PLATFORM FOR SATELLITE BASED DOWNSTREAM SERVICES)
Executive Summary:
The efficient integration of satellite and terrestrial based systems and tools has become essential for disaster management and emergency response. Nevertheless, the potential added value of satellite-based systems had not yet been achieved. On the one hand, Earth observation (EO) satellites provide highly valuable data for forecast, short and long term monitoring as well as disaster impact evaluation. On the other hand, satellite communication systems, being reliable and robust against natural and man-made disasters, can be used to rapidly restore communications for responders, and also to provide risk and hazard-related information to citizens at risk. Furthermore, satellite navigation systems are unavoidable for logistics, first aid resources deployment and rescue operations.
The project PHAROS has designed, implemented and demonstrated an innovative multi-hazard open service platform which integrates space-based observation, satellite communications and navigation assets with other technologies to provide sustainable services for a wide variety of users in multi-application domains, such as prediction/early detection of emergencies, population alerting, environmental monitoring, crisis management and risk management, targeting several users, such as crisis managers, operators of critical infrastructures, insurance companies and academic/research.
PHAROS has followed an iterative engineering approach in close cooperation with the end users to conceive a flexible and scalable modular system providing integrated services, as illustrated in Figure 3-2, through one service platform and exploiting capabilities from EO systems (GMES/Copernicus), in-situ sensor data and data provided by responders on the field (human data) to provide highly efficient tools and enhanced services to the following user profiles:
• Primary users (PU): any responsible authority (i.e. entity which is formally assumed to directly confront a particular situation and/or incident) uses the system for institutional purposes.
• Secondary users (SU): any third-party entity (apart from institutional users as defined above), for instance, a research institution or a private company that exploits a service of the system, for instance, to increase awareness about a particular situation and/or incident, not acting on behalf of any responsible authority.
Additionally, PHAROS addresses society as whole and in particular citizens at risk by defining the role of “recipients”, who are the individuals (i.e. citizens) that are provided with information that is sent/made available through the PHAROS system.
On the one hand, the capability of PHAROS to satisfy such different user profiles means an advantage in terms economies of scale for a sustainable service; on the other hand, this service scalability feature requires a service-centric system design.
PHAROS has carried out a complete engineering process, from the conception of the system until its demonstration in an operational environment scenario using forest fires as reference scenario. The pilot demonstration was successfully carried out from the 2nd to the 4th of March 2016 with the cooperation of the Catalan fire brigades (Bombers de la Generalitat de Catalunya) and the support of the Forest Sciences Centre of Catalonia (CTFC). In the pilot demonstration, over 100 stakeholders, including end users, civil protection agents, decision makers and the media, could observe the system operation during a live controlled forest fire performed by the fire brigades in the context of a prescribed burning in the region of Catalonia.
Project Context and Objectives:
The integration of services covering a wide range of hazards and operational domains is one important asset in the context of multi-hazard disaster and emergency management. In this regard, Earth Observation (EO), commonly used for performing risk and crisis monitoring, detection and assessment, as well as communication systems, used on one hand to allow members of the rescue teams and first responders on the field to access the different needed facilities and to communicate with the corresponding control centre and, on the other hand, to communicate with the population at risk in order to put in practice the corresponding response or recovery strategies, provide important tools whose added value can be increased if the proper integration is provided, allowing exploiting the existing synergies between the available assets. Finally, Global Navigation Satellite Systems (GNSS), taking into consideration the widespread use of navigation devices, not only in vehicles, but also embedded in mass market receivers such as smartphones, and the evolution of location based services (LBS), become another important means to communicate with the population. By integrating the different mentioned elements, with additional terrestrial assets, it is possible to provide services that cover the four elements of effective Early Warning Systems (EWS), namely, risk knowledge, monitoring and warning, dissemination and communication and response capability, while not being restricted to them.
Therefore, there seems to be a need for tools that allow the gathering, integration and processing of different information sources in a systematic way (for instance, provided by EO and in-situ sensors), making it possible to use the collected information for decision support purposes, disaster management and communication towards the population. Additionally, these tools shall enable information sharing among different jurisdictional levels (local, regional, national or international) and different involved authorities, as well as allow integration of the offered products to be imported to already existing systems, thus increasing the added value of the system and fostering the acceptance of the proposed solution.
Taking this context into account, the PHAROS overall objectives are:
- To design and implement an innovative multi-hazard open service platform which integrates space-based observation, satellite communications and navigation (Galileo/GNSS) services to provide sustainable (pre-operational) services for a wide variety of users in multi-application domains, such as prediction/early detection of emergencies, population alerting, environmental monitoring, crisis management and risk management, targeting several users (crisis managers, operators of critical infrastructures, insurance companies, academic, etc.).
- To validate the developed service platform for a specific scenario, forest fires have been chosen.
To accomplish these top-level objectives, the following scientific and technological (S&T) objectives are identified:
- To specify a sustainable service concept and architecture for the PHAROS platform;
- To define and further consolidate the economic model for the PHAROS service deployment through a business plan, that exploits flexibility and scalability advantages of the PHAROS architecture;
- To specify interfaces for input data to the PHAROS platform;
- To implement the functionalities that provide the PHAROS services:
o To implement the PHAROS service platform based on an existing platform;
o To develop the PHAROS user interface for fixed and mobile users;
o To develop decision support services based on information fusion and situation assessment, deriving a COP;
o To adapt an advanced Wildfire simulator provided by TSYL to be integrated in the PHAROS platform and allow automated simulation service coupled with existing sensor capabilities for fire detection (the FireWatch system);
o To deploy appropriate data acquisition, processing workflows and services to provide EO-based sensor input;
o To adapt the specifications of a satellite-based communications standard for messaging applications suitable as uplink for sensor networks (the S-band Mobile Interactive Multimedia) to operate in Ka-band and implement them in a prototype terminal and at the hub;
o To integrate the Ka-band S-MIM prototype terminal with FireWatch sensors;
o To deploy a prototype alert message dispatcher developed in a previous project and integrate it with a Cell Broadcast Centre as alert dissemination channel to the population;
o To integrate the alert message dispatcher with the a GNSS service centre to issue alert messages over EGNOS;
- To prepare suitable satellite EO data and free-space optical downlink integrated in the PHAROS platform;
- To integrate the developed subsystems, test and validate them with end users in a pilot demonstration for the “forest fire” case.
Project Results:
Emergency management systems have a great potential to reduce damages in emergency situations, both in terms of economic impact and loss of lives. In this regard, PHAROS has provided an integrated solution to exploit the synergies existing between satellite and terrestrial systems and solutions and fostered a multi-hazard approach for emergency management.
The PHAROS system has been conceived and demonstrated following an iterative approach with close interaction with the end users, including fire brigades, civil protection agents, police departments and decision makers. The system has been demonstrated in an operational environment using forest fires as reference scenario.
To fulfil the PHAROS objectives the project has established and followed a system engineering strategy which has allowed a permanent revision and tracking of the user requirements and their translation into system and technical requirements to be satisfied by the different system modules.
In this section of the report, the main results and foregrounds with regard to each work package (WP) will be described.
4.1.1. Multi-Hazard Open Service Platform Specification and Business Aspects:
4.1.1.1. Service concept, requirements and system engineering:
As a first step, the project has defined the overall service approach of the PHAROS platform, identifying and describing the services to be provided by the system, as well as the involved actors and roles. The outcome of this task (Task 2.1) has been documented in D2.1 (PHAROS Service Concept Specification).
The main challenges to achieve the corresponding objectives have been on one hand, understanding the expectations from end users regarding the capabilities that the PHAROS system shall provide and, on the other hand, defining a service concept which contemplates all the requested capabilities and integrates them in a consistent manner. In order to tackle the challenges, the project has benefitted from a close interaction with end users represented by the members of the Advisory Board and by additional local end users. In particular, the service concept specification is strongly based on the outcome of the 1st Advisory Board (AB) workshop, held on the 12th of March in Barcelona (Spain). The workshop attendees provided opinions from different operational profiles related not only with wildfires, but also with other application domains, such as the regional police and traffic management authorities, or with crisis management in general, such as civil protection representatives. This way, it has been possible to obtain inputs from end users covering a wide spectrum of hazards and crisis typologies in order not to miss the multi-hazard capabilities to be provided by the system. In order to prepare the AB workshop, the Consortium celebrated an internal workshop in which a brainstorming session was dedicated to identify the capabilities that the system should provide according to the expertise and experience of the different partners. This preliminary list of capabilities was used as basis for the preparation of the AB workshop, in which a similar brainstorming session was carried out with the workshop attendees. During the workshop, the desired capabilities identified by the end users were classified according to the different phases of the emergency management cycle and later mapped to the ones identified by the project team in order to assign priorities and identify areas in which the system might not provide meaningful features. These areas were further discussed in order to identify new capabilities which could improve users’ operations during the whole emergency management cycle. The interaction between the Consortium and the end users contributing to the specification of the service concept is depicted in Figure 3-3.
As part of the outcome of the task and taking into account the discussions with the AB and the end users, several concepts have been defined in order to lay the foundations of the PHAROS system. Firstly, the main actors interacting with the system have been identified. These actors are the different users which may benefit from the system and also the recipients of the information provided by the system (citizens receiving information or alert messages), according to the following classification:
• Primary users (PU): any responsible authority (i.e. entity which is formally assumed to directly confront a particular situation and/or incident) who uses the system for institutional purposes. This category takes into account also the first responders located in the operational field that may access remotely the system, obtaining the provided information and allowing the use of the system.
• Secondary users: any third-party entity (apart from institutional users as defined above), like for instance, a research institution or a private company that exploits a service or product provided by the system, for example, to increase awareness about a particular situation and/or incident, not acting on behalf of any responsible authority.
• Recipients: the individuals (i.e. citizens) that are provided with information that is sent/made available through the PHAROS system.
According to the wide range of capabilities identified by the end users, two different time approaches have been defined:
• Short term: It takes into account the services that can and shall be provided by PHAROS by the end of the project life, taking into account the existing time and resource limitations. The short term approach is based on the wildfire (forest fire) scenario selected for the implementation and pilot phases.
• Long term: It takes into account not only the project duration, but what a system like PHAROS should be in the long run, keeping a visionary approach in mind. Therefore, the long term version of PHAROS shall consider also services that cannot be provided by PHAROS during the project life time due to several reasons, such as time or resources limitations, but that shall be provided by PHAROS if the necessary tools and inputs are available at a certain point of time.
Keeping in mind the different time approaches, the capabilities identified by the end users have allowed the identification of four main application scenarios, which gather the identified use cases and allow the identification of the key users’ needs to be satisfied. These four application scenarios are: (i) risk assessment; (ii) risk and disaster detection and monitoring; (iii) disaster management; and (iv) communication. Further processing of the capabilities to be provided for each application scenario in the short and long term have allowed the definition of the PHAROS service concept, depicted in Figure 3-2.
The PHAROS service concept takes the open service platform as central element which integrates, on one hand, the different available data inputs and, on the other hand, the different available algorithms and processing tools in order to provide data and advanced products and services. Data products and services are based on the gathering of information from different sources (EO, data sensors and human data) and its proper presentation to the user, both for visualisation and download. The amount and type of data to be gathered and presented will depend on the availability of the information sources, which could be added or removed according to the situation. For the different data products provided by the system, two main services can be defined within this category: data visualisation and data download. Primary users will be able to visualise on screen the different gathered data and download it in the proper format, if necessary. Secondary users instead do not have direct access to the system, and they will not be allowed to visualise the data by using it. However, a particular sub-set of data will be available for them in a pre-defined set of formats. In order to offer advanced services and products, the PHAROS system makes use of data processing and fusion techniques applied to the available input data. Although the provision of particular advanced services can be added to and removed from the system, by installing the corresponding models and algorithms for each case, allowing or disabling the provision of new products, the general advanced products and services to be provided by the system are classified in the following categories: monitoring and detection, data fusion and decision support, simulation services, alert and information services and provision of a Common Operation Picture (COP). Advanced services are mainly conceived for primary users in order to provide them with tools to be used during the whole emergency management cycle. Nevertheless, several products which are the outcome of using the advanced services can also be made available to secondary users. Regarding the timing, almost all services are intended to be used or triggered in real time. Additionally, historical data and the outcome of the different services will be also available in the system in order to allow the analysis of the different emergency management strategies and identify room for improvement and lessons learned. Another important aspect to be remarked is the fact that advanced services are intended to interact with each other, meaning that the outcome of a service, if available, can be used as input by another service (service chaining). This increases the added value of the complete service chain by integrating the different services.
After the definition of the service concept, the activities performed within T2.3 have been strongly based on the close interaction with the end users, represented both by the members of the AB and also by local end users who participated in the different workshops and contributed with additional feedback by means of questionnaires. Therefore, this interaction with the end users together with the service concept described in Task 2.1 have been the basis for the identification of the user and system requirements documented initially in D2.4. Thereafter, a new interaction with the end users took place during the 2nd AB Workshop held on the 14th of October 2014 in Barcelona (Spain). This new interaction allowed the Consortium to present the first version of the system architecture to the workshop attendees and to discuss with them about the service concept, the first draft of the graphical user interface (GUI), and the alerting procedures to be implemented by the system. Additionally, an analysis of the user needs when dealing with a real fire situation was performed taking as basis a real scenario located in the region of Catalonia. This analysis allowed the Consortium to get a better overview of the needs of different user profiles (fire brigades and civil protection) regarding information assets and the overall decision making processes. Thanks to this exercise, the relevant information items were identified as well as the different users and locations where this information should be provided. Thereafter, the development of the technical activities taking place in WP 3, WP 4 and WP 5 have led to the definition of the technical requirements, which have been compiled for completeness in D2.5. Afterwards, the conclusions of the 3rd AB Workshop, held on the 14th of October 2015 in Barcelona (Spain) have been used to further review the user requirements (and consequently, the system and technical requirements), mainly based on usability and interoperability issues. Finally, the latest recommendations obtained in the analysis performed in Task 2.5 and the outcome of the end user evaluation carried out during the pilot demonstration have been used to provide the last version of the user requirements and the recommendations for the target system, documented in D2.7. The overall end user interaction process performed within the task and the contribution to the different deliverables is depicted in Figure 3-4. All the modifications in requirements updated from D2.4 to D2.7 have been documented by means of using change requests where the proposed modifications are described, together with an estimation of the impact of the modification in terms of time and budget and the final decision about the proposal.
The main outcome of this process, documented in D2.4 to D2.7 is the identification of the user and system requirements which must be satisfied in order to provide the services defined in D2.1. According to this outcome, the user requirements and their corresponding system requirements have been classified using different categories in order to fit with the short and long term system approaches and to differentiate the requirements related to the fire case scenario to be considered in the short term approach and the ones dealing with the multi-hazard aspects to be fulfilled in the long term. In the first stage of the project, two categories have been used to differentiate the short (DS, Developed System) and long (TS, Target System) term aspects. It must be highlighted that a high number of requirements emphasised the need of providing features to cover also the preparedness and mitigation phases (for instance, for early detection of risks) and also the importance of providing a system whose outcome can be integrated within already existing systems, allowing interoperability between users and authorities.
The definition of the user and system requirements triggered the definition of the system architecture within Task 2.4. Once the architecture was defined, the technical requirements related to each system module (which are the starting point for the design activities performed within WP 3, WP 4 and WP 5) have been gathered in D2.5 in order to allow tracking of the technical requirements during the whole duration of the project and once the corresponding WP 3, 4 and 5 deliverables have been submitted.
Regarding the definition of the overall system tests performed during the second project phase, for each system and technical requirement, the fit criteria to assess their fulfilment have been defined in order to serve as basis for the definition of the test plan.
4.1.1.2. Overall system architecture:
The procedure to design the system architecture has been an iterative process which has involved the Consortium, where different expertise domains are represented, and the end users, intended to benefit from the system in the short and long term. This has allowed the Consortium to discuss with the participants of the different workshops about operational issues, such as system scalability and interconnection with other systems.
The basic pillar on which the system architecture design is based is the necessity for providing a modular architecture in order to satisfy the flexibility and scalability requirements both from a functional and operational perspective.
• The term “functional scalability” must be understood as the capability that the system shall provide in order to add or remove functionalities (modules) according to the situation, the hazards to be addressed and the corresponding operational domains. The benefits that functional scalability is intended to provide are: (i) Allow total, partial and/or incremental deployment of the PHAROS components, tailored to the situation, needs and capabilities of the corresponding authority; (ii) Allow addition of new data sources, modules and algorithms when they become available, by using open available standard interfaces as far as possible, thus allowing extending the system to tackle new operational domains and hazards; (iii) Allow a (totally or partially) distributed system deployment regardless of the hardware platform and geographical location where the different functional modules are installed, taking advantage of the use of remote connections. This type of deployment is transparent to the user, who will access the system as if it was a unique entity, regardless of the type of deployment used. A distributed approach may increase the system resilience towards disasters and emergencies, by distributing the location of the different modules, on one hand, and providing redundant modules in different (and potentially not affected) geographical locations, on the other hand. The modular approach minimizes also the complexity of the system in case of using redundant implementations to ensure system availability on a 24/7 basis.
• “Operational scalability” refers to the capability of the system deployment to allow its use adapting to the widest range of operational structures. These structures vary depending on the different political and organisational/administrative structures, as well as on the type of hazard, its scope and evolution. This means that on one hand, the authority in charge may vary depending on the hazard type (for instance, firemen might be the responsible authority in forest fire cases while civil protection might be in charge of other types of hazards). On the other hand, a higher-level authority might get involved in the management of the crisis, depending on its scope and how the crisis evolves. Generally, the higher levels of the command hierarchy are involved if the crisis escalates though several jurisdictions at the same level (for instance, national authorities may get involved if the crisis exceeds the borders of the region where the crisis was originated). The organisational and administrative structures used for crisis management and alerting in the different European countries vary from country to country, ranging from fully centralised structures to fully distributed ones, and including different degrees of distributed management.
Taking into account the scalability requirements as well as the provision of interconnectivity with already existing and future emergency management systems, the activities within the tasks have led to the design of the overall functional architecture for the PHAROS system, considering the long and short term dimensions. The long term approach of the system architecture (see Figure 3-5) is intended to be used in a multi-hazard context, where the different generic modules shall be replaced by particular (and many times, hazard-dependent) modules to be used according to the type of hazard. In the short term approach (see Figure 3-6), the focus is given to the forest fire (wildfire) case and therefore, the generic modules presented in the long term version are replaced by the particular modules devised for forest fire management. In this regard, a differential description with respect to the long term architecture has been provided in D2.9. Therefore, the particular modules to tackle the forest fire case have been introduced, presenting the different functionalities and interfaces to be considered, taking the long term approach as basis. The two presented versions provide a picture of the overall system architecture both from a generic design perspective (long term) and an implementation point of view (short term), focusing on the tools used or designed to implement each module and the suitable means for interconnecting them to provide pre-operational services.
4.1.1.3. Multi-hazard aspects:
PHAROS has identified and described additional hazards that the system can be used for, including information on how PHAROS would need to be extended in terms of input data, algorithms, EO data and simulation capabilities. Furthermore, an overview of necessary changes shall be given to operate the system in the context of the identified additional hazard types. The draft structure of the resulting report (D2.10) the preliminary selection of additional hazard types to be considered and the interim status of the case studies have been presented to the Advisory Board and End Users during the 3rd AB Workshop (October 2015, Barcelona). The feedback collected has been incorporated into the report. Based on the result of the PHAROS Multi-Hazard Case Studies, additional multi-hazard requirements have been derived (and existing requirements updated accordingly were necessary) that have been integrated in the final issue of the PHAROS Requirements and System Engineering Deliverable (D2.7).
4.1.1.4. Service sustainability and business plan:
Apart from the engineering perspective, PHAROS has developed the concepts of service sustainability and the corresponding business plan. The main objectives of this activity are to develop the project business sustainability roadmap, determine CAPEX and OPEX for the development of the system, determine organisational structures to operate the service and the platform, produce the financial model to determine the costs and funding requirements and identify methods to ensure sustainability of the services by finding funding sources and other possible scenarios. During this period, the necessary bases for the development of the project business plan and sustainability roadmap have been analysed. The outcome of the task has been documented in D2.2 (Business Model Spreadsheet and Business Plan Report - Draft) and D2.3 (Business Model Spreadsheet and Business Plan Report –Final).
The first step taken towards the fulfillment of this objective has been the analysis of the possible benefits that the system could provide by enhancing the performance and awareness of emergency systems and general population and the costs that the system could have depending on what business model is adopted by the service provider. In order to estimate what benefits the adoption of the PHAROS system could imply, a list of key features and functionalities was compiled and circulated among the end users involved in PHAROS, taking the ranking of these into account for the design of the overall system so the benefits could be quantifiable.
The second step was to analyse the possible organisational structures and models that the service provider could adopt, so that they can be compared with the system’s characteristics and features in order to recommend those that are more suitable. Also, an overview of the cost drivers (costs associated with bringing the system from its pre-operational state to an operational state), the CAPEX and the OPEX costs for the deployment of a decentralised PHAROS system (i.e. offered as a standalone product) are included in the final version of the Service Sustainability and Business Plan Specification document.
Regarding the business plan and the roadmap for exploitation and commercialisation of the PHAROS system, the exploitable outputs are collected, as well as exploitation plan for these from each one of the project partners. Also, a description of the transition from the PHAROS developed system to the target system is included in the document, together with the description of the service provider as well as a commercialisation plan and a draft roadmap plan in order to achieve the commercial viability of the PHAROS system.
According to the agreement among the Consortium partners and the Project Officer, an additional update of D2.3 has been provided at the end of the project (M30) in order to document the activities associated to T2.2 carried out between M22 and M30. Thereafter, a new submission of the deliverable has been provided on the 19th of July in order to address the recommendations given by the Project Reviewer and agreed with the Project Officer during the Final Review Meeting.
4.1.2. Situation assessment, decision support and Earth observation:
4.1.2.1. Information fusion and situation assessment:
In this area, PHAROS has identified and implemented the required sensor and data fusion techniques in order to generate situational awareness information using the available data (sensor data, historical data sets, background and baseline data, modelling and simulation results, a priori knowledge about the environment and human input).
The DSS architecture has been developed based on the requirements analysis and the interaction with end users and the AB (see Figure 3-7). The DSS combines incident management, information fusion, situation assessment, and decision support functionality. As shown in Figure 3-6, each functionality is encapsulated by a corresponding component, (i) the Sensor Processing Service (DSS-SP) for the processing of incoming sensor and field observations; (ii) the Incident Management Service (DSS-IM); (iii) Information Fusion and Situation Assessment Services (DSS-IF, DSS-SA); and (iv) the Decision Support Service (DSS-DS).
In order to comply with the modular PHAROS system approach, DSS components have been designed as web services which respond to requests from the Service Platform (SP). The PHAROS system will be able to exchange resources such as incidents and decision proposals in a standardised way using the HTTP protocol (REST conformity).
• DSS-IF performs spatial analysis based on sensor and field input data, simulation results, and pre-defined geo-data. It creates several geospatial outputs which are used by DSS-SA to enhance situation information and to perform further situation assessment procedures.
• DSS-SA performs situation management and assessment and the generation and provision of the Incident COP as a formal view of a situation. In detail, it takes care of the following tasks:
o Generates and updates the situation data resource for an incident; for this, it uses incident-related data including sensor and field observations, SM simulation runs for the incident (input parameters and reference to the simulation result), and decision proposals, operational data such as user events, information on disseminated messages, and information on resources in the field, information fusion results, and situation assessment results
o Provides a formal view of the situation in the form of an Incident COP for a standardised exchange either in a lean JSON representation or conforming to the shared Common Operational Picture (sCOP) schema represented in XML
o Generates a set of input parameters for SM and requests simulations
o Requests DSS-IF for information fusion functions regarding the incident
o Performs situation assessment processes such as the assessment of situation severity
o Triggers the Decision Support Service (DSS-DS) for the generation and update of decision proposals
Based on the requirements gathered, the interfaces of the SM and the available data required fusion techniques have been identified and are being implemented.
The DSS services (except DSS-DS) have been specified in Deliverable D3.1 (Draft) and Deliverable D3.2 (Final). For the description of situational awareness information, the DSS-SA uses the sCOP format which was developed in Task 3.5. As foreseen, the configuration of the DSS has been updated throughout the project to reflect the test findings and user feedback during the system integration and testing phase.
4.1.2.2. Risk and incident modelling
PHAROS has developed and deployed modelling services for (i) calculation of fire risk and (ii) forest fire incidents based on the inputs of available sensor systems, the results of T3.1 and T3.4 as well as on the simulation capabilities of the operational forest fire simulator. The service is coupled with sensor systems whose inputs allow the adjustment of real fire behaviour simulations for the subsequent operational periods. During this task, the technical requirements have been derived based on the user requirements and the system requirements, identified and documented in D2.4 to D2.7. Based on this, the specification of the Simulation Module (SM) architecture has been described as well as the specification of each of its components by describing their role and purpose inside the specified architecture (see Figure 3-8).
Taking into account the risk and incident modelling services to be provided together with the identified technical requirements several simulation modes have been defined and described. The services to be provided by the SM have been categorised into several simulation modes, each of these provide an output or a set of outputs that have a certain purpose. In this regard, these simulation modes have been classified into operational and non-operational according to their purpose, i.e. for their operational use (operational mode) or for fire planning and mitigation tasks (non-operational mode).
Operational simulation modes:
• Fire spread: Provides a set of raster and vectorial outputs that represent the forecast of the behaviour of the fire for forest fire incidents with the capability of calibration of the results. This mode can be triggered manually by the user through the GUI, through ignition points identified by FireWatch sensors (in-situ) or by ignition points identified through Earth Observation sensors.
• Evacuation time: Provides a set of raster and vectorial outputs that forecasts the time the fire would take to reach a certain critical point defined by the user when starting in a certain location.
Non-operational simulation modes:
The non-operational simulation modes run daily providing the users of PHAROS with the latest assessment of fire risk.
• Forest fire structural hazard: In general terms it can be explained as representing the risk of fire for a certain area i.e. the easiness that a fire has to spread for each cell of the considered area based on several fire behaviour variables.
• Forest fire growth potential based on critical infrastructures: Provides the assessment of fire spread potential based on ignition points of critical infrastructures such as electric supply networks.
• Potential impact of forest fires on critical infrastructures: Provides a representation of the potential impact of the forest fire on critical infrastructures such as electric supply networks.
According to this, the necessary basis data that is used by the several modes of the simulation module has been defined and integrated in the SM. The several sets of outputs of the described simulation modes have been developed and implemented.
The SM interfaces with the PHAROS Service Platform that provides simulations requests and necessary simulation input parameters and in turn the SM provides the processed outputs to the SP to be graphically represented through the GUI or to be used by the DSS to analyse them and provide proposals to the users of PHAROS. Besides, two INSPIRE-compliant metadata profiles have been defined and implemented, one for vector outputs and another for raster outputs. Each output of the SM integrates the corresponding metadata. Task 3.2 implemented the modelling services mentioned above and tested them successfully on a module level.
4.1.2.3. Decision support
PHAROS developed and deployed decision support services that generate and update decision proposals, relying on the services provided by T3.1 to generate and update situational information. Relevant workflows, rulesets and expert knowledge have been gathered and compiled in order to transform the situational awareness into decision proposals and decision implementations for the decision maker/user.
Requirements and the input of the Advisory Board have been analysed to derive what situational aspects need to be part of the situational analysis (Task 3.1) which formed the basis of the decision support specified in Task 3.3.
Apart from the mandatory decision support regarding the dissemination of alerts, additional decision support has been provided to the user focusing on the management of the situation.
Situational information has been provided by the DSS-SA service using the sCOP format, specified in Task 3.5. DSS-DS enriched this sCOP format by two additional resource types:
• Proposals: the decision proposals are intended for PHAROS primary users and are shown via the PHAROS GUI. Different types of proposals exist; the most relevant are
o Notification: purpose of a Notification proposal is to notify the user of something important (similar to an internal alarm);
o Dissemination: purpose of a Dissemination proposal is to suggest the dissemination of a message to external recipients, if the internal conditions for alerting are met.
• Products: products are intended to be disseminated to external recipients; in case the DSS-DS proposes to disseminate a product, at the same time a proposed product is also provided.
All DSS-DS resources are provided via RESTful interfaces (see D3.1 and D5.3). DSS-DS uses a product structure according to the Common Alerting Protocol (CAP 1.2). Products are provided in different formats, e.g. JSON and CAP (XML). The DSS-DS service interface allows to retrieve and update proposals, while for products also the creation of a product (e.g. in case of a manually created product/alert triggered by the user) as well as the update of parts of the product.
Beside the specification and development of the DSS-DS service, PHAROS has also specified the workflows used to orchestrate system-wide service-chains, including automatic (periodic) and on-demand workflows. The DSS-DS service has been specified in Deliverable D3.6 (Draft) and Deliverable D3.7 (Final). Task 3.3 implemented the DSS-DS service and tested it successfully on a module level. Finally, the configuration of the DSS has been updated to reflect the test findings and user feedback (e.g. number and frequency of proposals, content of proposals) during the system integration and testing phase.
4.1.2.4. Earth Observation data access and processing
Regarding Earth Observation, the first aim of this task was the provision of an operational “fire service” processing chain (near real time). In the focus of the development and implementation is the derivation of fire-hot-spots with MODIS (Moderate Resolution Imaging Spectroradiometer) data acquisitions with an automated processing chain and publishing via WebGIS-Client. The existing fire service was extended in two ways:
i) An OGC-Interface (WMS, WFS, WCS) for data provision was added
ii) An MSG-SEVIRI hotspot service was added
Because of the lack of availability of BiROS and Sentinel 3 only NPP VIIRS data where investigated for further usage as backup for MODIS.
The second component was the provision of Earth Observation images and their thematic products and generated maps for the recovery, mitigation and preparedness phases. The data are available in a high (< 30m) to very high spatial resolution (< 2.5m) and in a medium to low temporal resolution (> 1d) and were ordered from the CSCDA.
According to the project plan the first part of the project duration was focused on the extension of the existing MODIS Hot Spot Service with an OGC-Interface, and the feasibility check to improve the temporal resolution. In the second part of the project the MSG SEVIRI sensor as an additional hot spot detection service was implemented.
The detection of high temperature events (HTE) uses the MOD14 algorithm. The algorithm based on the shift of radiances to shorter wavelengths (middle infrared) with an increasing surface temperature. MOD14 is well documented and tested in operational services and guarantees comparability and reproducibility as well as a standardised international acknowledged product. The thermal information is collected at 1000 m spatial resolution twice daily by each sensor (Terra and Aqua), providing up to four thermal observations daily. The MODIS images used for fire detection are acquired from two direct broadcast receiving stations from DLR located in Oberpfafffenhofen and Neustrelitz, Germany. The MODIS Hotspot Service is based on a three-layer system architecture – the data layer, service layer and client layer (see Figure 3-9).
The main part of the service layer is the WPS (Web processing service) to orchestrate the process chain. The output of the WPS is the provision of a WFS with the location of the hot spots in near-real time for Europe and surrounding countries, including information about:
• Latitude and longitude,
• Administrative boundaries,
• Vegetation and land cover (Corine land cover, 100 m resolution and Global Land Cover, 1000 m product)
MSG SEVIRI (Spinning Enhanced Visible and Infrared Imager)-is mounted on the geostationary satellite MSG 2 (Meteosat Second Generation satellite)It provides hot spots in a high temporal resolution (up to 15 minutes), covers Europe and northern Africa and detects fires during the night as well. The SEVIRI Sensor provides data in 12 different wavelengths within the visible to infra-red spectrum and with a pixel size of 1 km for the high resolution visible channels, and up to 3 km for the infrared channels. Regarding MODIS, the active fire detection uses the shift of the peak emission and the increased sensitivity to temperature changes to detect high temperature events within a pixel. For a surface at a brightness temperature around 300 K the spectral radiance peaks is at a wavelength around 10 µm. The peak wavelength decreases as the brightness temperature increases. The algorithm detects hot spots by a combination of threshold tests using band 9 (3.8 micron) and band 14 (10.5 micron). In comparison to MODIS, DLR does not receive directly the MSG-SEVIRI data in near real time. In order to use the Eumetsat (European Organisation for the Exploitation of Meteorological Satellites) near real time processing service, this service will fetch up the derived hot spots (5 minutes after the data acquisition) and will provide the information through the MODIS processing chain to the PHAROS service platform.
For the pilot demonstration in Solsona a large amount of remote sensing data were ordered. Products and maps based on these data must be generally created manually and require high expert knowledge. For the implemented short term approach of the project, a limited implementation was prepared by the ZKI service from DLR/DFD. On the long term run these products will be created on demand (in the case of a fire emergency activation or for pre- and post-operational purposes, e.g. forest inventory regarding fuel capacity, change detection, seasonal variations). In addition to the satellite data, aerial data from the VABENE++ project and thermal data from the AirSIG sensor from Fraunhofer IOSB were used.
4.1.2.5. Shared Common Operational Picture
PHAROS has also addressed the issue of exchange and interoperability of situational awareness and decision support information. Based on existing standards, a technical exchange format has been proposed which is used by PHAROS services dealing with this type of information. The so called shared Common Operational Picture (sCOP) exchange format serves several purposes:
• Exchange format between PHAROS services, especially among the set of DSS services (situation awareness service, decision support service), and
• Exchange format for incident-related COP information with external systems and other PHAROS instances.
Both the syntactical and semantical level of interoperability has been addressed:
• Syntactical interoperability allows the exchange of data (e.g. using the same ASCII or Unicode format; other examples are XML and SQL);
• Semantical interoperability includes the ability to interpret the information exchanged meaningfully, which requires both sides (sender and recipient) to refer to a common information exchange reference model.
Regarding the exchange of information relevant for disaster management applications, three different levels can be identified:
• Sensor Data: on this level a number of (de-facto) standards exist to support the exchange of sensor data from sensor systems such as tide gauges, buoys, seismic sensors, GPS stations, etc.
• Situation Data, including situation assessments and forecasts, risk and vulnerability information: several approaches exist in the military and civilian domain to standardise the description and the exchange of situation information.
• Products: the exchange and interoperability of products such as warnings, alerting and other emergency information (e.g. hospital availability information) is supported by a number of standards.
The protocols and formats listed below have been evaluated considering the PHAROS requirements targeting at interoperability and efficiency. Further criteria have been:
• Domain coverage: the protocol/format shall allow the description of all information relevant for situation awareness and decision support in the (civil) disaster management domain;
• Incident based: the protocol/format shall support the incident/event concept;
• Mapping: the effort for mapping the internal PHAROS data model to the elements and attributes of the protocol/format shall be straightforward.
The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems.
The Tactical Situation Object (TSO) has been developed within the project Open Advanced System for CrisIS Management (OASIS) with the aim to support interoperability to exchange reports and mission information among agencies involved in disaster management, civil protection and societal security. It is now further developed as Emergency Management Shared Information (EMSI) by the ISO technical committee for social security and resilience in the technical report ISO/TR 22351.
Within the project Alert4All an extension of TSO has been developed, the so-called Alerting COP (A-COP), to cover the provision of additional features, such as the provision of alerting plans, management of users’ security or accessing the history of sent alert messages.
Emergency Data Exchange Language (EDXL) is a suite of XML-based messaging standards that facilitate emergency information sharing between government entities and the full range of emergency-related organizations. EDXL standardises messaging formats for communications between these parties. The XML-based Emergency Data Exchange Language (EDXL) Situation Reporting specification describes a set of standard reports and elements that can be used for data sharing among emergency information systems, and that provide incident information for situation awareness on which incident command can base decisions.
The Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM) is a model that aims to enable the interoperability of systems and projects required to share Command and Control (C2) information. JC3IEDM is an evolution of the C2IEDM standard that includes joint operational concepts, just as the Land Command and Control Information Exchange Data Model (LC2IEDM) was extended to become C2IEDM.
As result of the evaluation process, EMSI (TSO) has been chosen as best basis to develop an extension in order to fully cover the required domain and all PHAROS requirements towards an interoperable exchange format for situational information.
The sCOP format has been developed within Task 3.5 and has been implemented in the PHAROS DSS for internal communication and as an export functionality for COP information. The sCOP format is currently being proposed as contribution to EMSI to Working Group 3 of ISO / TC 22351.
4.1.3. Satellite communication, navigation and alerting:
4.1.3.1. Satellite-based uplink for in-situ sensor data:
PHAROS has performed a review of the satellite communication standard, S-MIM, so that it can operate in Ka-band, according to the requirements of the PHAROS applications, and implement the required adaptations at the prototype terminal and hub. The reviewed standard, called F-SIM, includes a revision and adaptation of the physical layer, link layer and control planes. Additionally, the task aims at designing, implementing and testing the data interface between the FireWatch system and the prototype terminal.
Although two specific technologies, FireWatch and F-SIM, have been selected and considered throughout the lifetime of the project, alternative solutions, both terrestrial and satellite, in compliance with the modular and flexible approach that characterises PHAROS, have been reviewed in D4.1 so to be possibly taken into account for the long term phase. Moreover, D4.1 describes the reference scenario taken into account, which details the different components while moving from a general to a particular perspective and which ultimately focuses on the architecture taken into account in the short term approach (see Figure 3-10). In this light, D4.1 describes the architecture of FireWatch, which is a system that, through its smoke detection capabilities, allows very early fire recognition in large open areas. It is responsible for the collection of data from in-situ sensors, which can be transferred to the Service Platform over the satellite link provided through the F-SIM standard. The F-SIM protocol, in turn, copes perfectly with the bursty transmission typical for emergency alert notification, and allows for very low Packet Error Rate against an affordable implementation complexity. D4.1 describes in detail how the F-SIM physical layer has been adapted based on S-MIM, and accounts for the F-SIM link layer and the protocol’s performance. In the second project period, PHAROS has implemented the data interface between the FireWatch system and the prototype satellite terminal.
4.1.3.2. GNSS-supported alert message delivery
With regard to the distribution of alert messages towards the population at risk, the PHAROS objectives are to document the interface between the service platform, the alert gateway and the two channels chosen in this project, namely, cell broadcast and GNSS, and adapt the alerting gateway to provide pre-operational services.
During this activity, the technical requirements for the alerting module have been identified based on the user and system requirements identified and documented in D2.4 to D2.7. The specification of each component (Alerting Gateway, Cell broadcast and GNSS) of the system has been described and the necessary architecture to support these components has been designed, implemented and tested. These activities have been reported in D4.3 and D4.4.
The Alerting Gateway (AG) design has been based on the Global Alerting Gateway (GAG) which has been developed in the framework of the EU FP7 Alert4All project. Some amendments have been performed in terms of design:
• Creation of alert messages in two different ways: using the GUI or as an outcome from the DSS.
• Adaptation of the interfaces towards other system modules.
• Providing suitable interfaces with different alerting channels.
• Adaptation to the wildfire use case.
The main feature of the AG is to send alert messages to the population via various alerting channels. The first selected channel is cell-broadcast enabling to use the telecom network to send geo-localised messages. An analysis of the cell-broadcast system has been performed and used to confirm that cell broadcast messaging has a number of features that make it particularly appropriate for emergency purposes:
• Large penetration of the population (resident in mobile network infrastructures and in mobile phone terminals)
• Not affected by traffic load
• It is geo-scalable and geo-specific: can reach millions of people across continents within a short time
A design for sending messages using the existing cell broadcast system has been described in D4.3. A test lab version of a fully deployed alert Cell Broadcast messaging service has been implemented using the OpenBTS software and a GNU radio setup (D4.4).
The second selected channel is GNSS enabling to send alert messages via the SBAS payload of EGNOS satellites to target a wider part of the population and take advantage of the resiliency of satellite technologies in case of disaster.
D4.3 describes the architecture of the EGNOS system and explains how alert messages can be sent via this medium. The European Space Agency (ESA) MLU testbed had initially been selected to test the sending of messages via the EGNOS system but it has been de-commissioned by ESA and therefore it could not be used anymore. Several solutions have been considered. The main solution envisaged is to use the Artemis payload. Artemis is a satellite owned by Avanti (who is a project partner) equipped with an EGNOS payload. This payload was not in use at the start of the project but Avanti re-activated it in the course of the UK Space Agency project SBAS Africa. It has been possible to use the EGNOS payload to perform the sending of an A4A message. The sending of alert messages using Galileo satellites has also been analysed and documented in D4.4.
4.1.4. Integrated service platform:
4.1.4.1. Service platform architecture, workflows and interfaces:
As a starting point, the general system requirements laid out in WP 2 were used to derive the specific technical requirements for the Service Platform (SP). Functional requirements (e.g. access control, user management, configuration, access to historical data, monitoring, geospatial data storage and incident management) as well as non-functional requirements (e.g. robustness and resilience, stability, expandability and virtualisation) were specified. In addition, interfacing requirements were specified, covering the communication of the SP with the user front-end (GUI), secondary user services, Earth Observation (EO) data sources, simulation services, Decision Support Systems, alerting services as well as third-party external services, such as weather providers.
Using the technical requirements, Task 5.1 specified 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, as shown in Figure 3-11, were identified to be the following:
• A Data repository, for geospatial as well as 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.
• An Access Control layer for managing permissions related to the stored content as well as the services.
Last, the SP also included management-related services, which allow the supervision of its operation and the configuration of the individual components.
Following the specification phase, the core components of the SP were developed, such as the data repository (for both spatial and generic data) as well as interfaces for data communication. SP 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.
In parallel to the design and implementation of the SP architecture, and using the requirements and exploiting common architectural concepts found in mature WF engine frameworks, the architecture of the PHAROS workflow (WF) Engine was defined and implemented, consisting of the following key components:
• A Management front-end for management and configuration;
• A Workflow storage repository for storing registered workflows, defined in WS-BPEL (Web Service Business Process Execution Language);
• A BPEL compiler, for compiling workflows into a machine-readable format;
• A BPEL Engine Runtime, for executing the workflows and managing concurrent workflow instances;
• A Database Management System (DBMS) subsystem for storing persistent data, mostly associated with workflow instance information;
• An Integration Layer and a Web Services Engine for facilitating communication with orchestrated services via WS protocols.
Also, a mechanism for asynchronous communication based on callbacks (and/or webhooks) was established, so that workflow execution can continue while at the same time waiting for a response from a module/subsystem
In addition to the implementation of the workflow engine, an initial set of PHAROS workflows have been specified and implemented. The four workflows applicable to the PHAROS system are:
• WF #1 – Event handling and Creation: Defines the process of inspecting incoming events and mapping them to incidents;
• WF #2 – On-demand Simulation/Recommendation: Defines the process of invoking a simulation and handling the Decision Support System (DSS) recommendation;
• WF #3 – Alerting: Defines the process of creating, confirming and configuring an alert;
• WF #4 – Periodic Risk Assessment: Defines the process of producing and presenting risk assessments on a periodic basis.
The PHAROS workflow concept has been implemented using open technologies and standards not only for the definition and the description of the workflows (where WS-BPEL is adopted) but also for the design and development of the Workflow Engine.
Finally, PHAROS has defined and implemented the internal interfaces for the communication between PHAROS components for data exchange, service invocation and signalling, as well as the external services (Service Gateway) to be offered to secondary users. Since the PHAROS system has been designed to mostly rely on Web-based communication for the exchange of information among modules, the implemented interfaces are in the form of web services exposed by the PHAROS modules. In summary, the services which were specified and implemented are:
• Service Platform services: Web Map Service (WMS), Web Coverage Service (WCS), Web Feature Service (WFS), Coverage/Feature publication, Events and Observations, Asset Management, Weather Data and MODIS Service Proxy.
• Simulation Services: Invoke Simulation, Simulation Results (using asynchronous communications).
• EO Services: MODIS Hotspots, EO Imagery.
• DSS Services: Observations Retrieve/Create/Update/Delete, Incident Retrieve/Create/Update, Situation Retrieve/Update, Proposals Retrieve/Create/Update Results (using asynchronous communications).
• Alerting Gateway Services: Message Select, Message Reset, Alert Dispatch, Channel Refresh and Message Filter.
• First responder data: store and retrieve position as well as multimedia content from first responders on the field.
• Secondary User Services: WMS/ WCS/ WFS (proxied SP services) and simulation invocation.
Also a data export feature was added to the SP, via which users can download products (in KML and other formats) via the GUI.
Last but not least, a dedicated web portal, based on CMS (Content Management System) technologies, was built for the secondary users. A mechanism was implemented in the SP in order to automatically publish data to the secondary users’ portal. The services and interfaces described above were validated, tested and documented in D5.3 and D5.6 (updates).
4.1.4.2. User interfaces, visualisation and mobile clients:
The main objective within this topic has been to design the graphical user interface (GUI) to access the system (including the access through mobile devices), the GUI for the mobile application receiving alert messages and the web portal to be subsequently implemented in order to enable PHAROS users to access all the designed services/features.
The Graphical User Interface (GUI) of the web application enables end users to interact with the whole PHAROS platform. A mock-up has been designed prior to the implementation of the application to decide how to provide the required information and services to the user. It has also been decided to enhance the mobile application used by first responders on the field to access the portal to include new features like sending of GPS location to the central platform and including chat features.
The technical aspects of the web application have been documented in D5.4. The web application is built on top of JavaScript libraries and a lightweight Java back-end webserver. The client-side heavily uses AngularJS and jQuery frameworks, beside the Leaflet and DataTables JavaScript technologies.
The PHAROS GUI elements that have been implemented are:
• AngularJS frame to contain the various components of the application.
• Login functionality.
• Multi-language feature (English and Spanish).
• Cartographic display.
• Weather data.
• Real-time Earth Observation imagery (covering Spain).
• Incident view including an events timeline (based on Highcharts JS): the timeline is interactive, zoomable, scrollable and the events are clickable.
• UI for sending alerts (the user can draw on a map, choose values based on the Common Alerting Protocol specifications – CAP ...)
• Notification systems
• DSS proposals display
• Display of simulation results
• User management
• Settings panels
The style and usability of the application have been enhanced to provide the user with a more intuitive and user-friendly experience. In terms of back end, all the requests are going directly to the SP via a VPN (virtual private network) connection. The web portal has been heavily tested during the integration phase and has been updated/enhanced taking into account the feedback from the users.
4.1.5. Pilot demonstration and user evaluation:
Apart from the scientific/technical developments PHAROS has designed, prepared and deployed a pilot demonstration using an operational scenario: forest fires. The demonstration has been planned in two parts or Phases:
• PHASE 1, has focused on the validation of the PHAROS system with the main purpose of gathering feedback from end-users. This phase took place in Solsona (Spain) between the 2nd and the 4th of March 2016. Three prescribed burns have been organized and executed during this phase. The different parts of the PHAROS system have been evaluated. Although weather conditions could have been the main limitations for the execution of the prescribed burns, the appointed firefighters could finally execute the burns. During this phase, around 100 stakeholders from different organizations have attended the presentation and 25 of them could try during some hours the platform.
• PHASE 2, also included a PHAROS system validation and dissemination event. This phase took place in Oberpfaffenhofen (Germany) on the 12th of May 2016. In this dissemination event the outputs and results from the measurements taken during Phase 1 have been presented as they could not be processed in real time. The end users invited to the event could see the PHAROS platform in the last stages of development and give further feedback to the consortium partners for the future steps of the project and also for future projects.
In order to prepare the PHAROS demonstration, aerial images have been acquired and integrated within the service platform in order to support end users. The work performed within this task has been focused on the preparation of the image acquisition (selection of sensors and data to be acquired, definition of the products to be provided, definition of the architecture to be implemented, preparation of the logistics for image acquisition and test of the corresponding modules). The sensors and aerial means used were on one hand, the 4K system and the transmission of real time data to the control room that allowed primary users to perform a better monitoring of the situation, validating in real time, the correctness of the data available in the PHAROS platform. On the other hand, the generated thermal data was gathered during the pilot demonstration and to be provided after post-processing it, allows a better understanding of the fire dynamics and a deeper analysis of the fire evolution.
The overall PHAROS demonstration has been a successful event that accomplished the project objectives. The participation of a large number of end users (more than 110 participants) in the two phases of the demonstration has allowed carrying out a good evaluation of the platform from an end-user perspective, which is a fundamental step to validate the platform, its products and services. This wide range of participants has had a positive impact in the provision of an accurate feedback, key to support further development of the platform. Moreover, the participation of stakeholders in both Phases has attracted the media and has been an opportunity to disseminate the project to local and regional media (10 representatives from TV, radio and press participated in the demonstration).
Finally, PHAROS has analysed and processed the feedback given by a selected group of end uses that have participated in the Pilot demonstration. The feedback gathered during the pilot demonstration (Phase 1) revealed how the end-users held a very positive opinion of the platform and the different components that they were able to test during the demonstration. The end-users described the PHAROS platform as a spine of the emergency system. The novel component of this platform is that it integrates an emergency prevention and prediction system and a simulation and evaluation system. Altogether, the different components of the platform go further than the current emergency management systems and will allow a better decision making before and during the early stages of the emergency allowing preventing natural and humanitarian disasters.
In general, minor improvements were suggested to increase the effectiveness of the platform to manage disaster emergencies. The highly valuable feedback given by the end-users has been translated into recommendations for the target system, and constitutes a basis to advance in the development and implementation of the PHAROS platform. The PHAROS system also has been seen as a major opportunity to provide a standardized emergency response alert system, in collaboration with mobile network operators, manufacturers and governmental agencies. This will allow the possibility to reach the general population via a pre-installed mobile application and via cell broadcast.
Potential Impact:
PHAROS has designed, implemented, tested and demonstrated in an operational environment (forest fire scenario) an integrative multi-hazard management platform to improve the effectiveness of emergency management. The technical pillars on which the platform is based are:
• Integration of multiple data sources for risk and hazard detection and monitoring (satellite, aerial and terrestrial earth observation, in-situ sensors, human-collected data and external services);
• Information fusion techniques to achieve an improved situational awareness to help primary users to keep an updated overview of the emergency situation and allow an efficient management through consistent monitoring;
• Flexible simulation tools to foresee the expected evolution of the risk or hazard according to the available information and allowing the possibility of manually introducing information or updating the inputs to be used by the simulator according to the real evolution of the risk or hazard;
• Integrated tools for advanced decision support which ease the decision making processes providing information about the areas, infrastructure or relevant elements which might be affected in the near future, according to the available information and the forecast of the corresponding simulation tools.
• Efficient warning of the population at risk using consistent information dissemination over multiple channels and, particularly, cell broadcast and satellite navigation.
Therefore, the corresponding tools on which the system success is based have been developed and integrated beyond the initial state of the art, as described in the previous section, consolidating the project’s scientific impact. Moreover, the integration of the different tools allows exploiting the synergies existing between them, thus providing a service chain not existing until now and increasing the added value of the overall system.
PHAROS has brought together experts from a wide range of disciplines, including end users of the system (civil protection authorities, police departments and fire brigades), international emergency organisations (The International Emergency Management Society, TIEMS), scientist, engineers and industrial partnerships. This inter-disciplinary participation has been achieved by different means: (i) first of all, thanks to the heterogeneity of the consortium, including partners from the research community, industrial partners (including SMEs) and representatives of the end users; (ii) by establishing an Advisory Board formed by experts on the field of emergency management and belonging to different European organisations, thus providing information and feedback taking into account different geographical and social constraints; (iii) by organising periodical workshops with the Advisory Board and an extended team of end users to track the project development and (iv) by participating in a large number of dissemination events, which provided the opportunity to present the project results and gather feedback from the scientific and emergency management community. This has clearly strengthened the overall PHAROS approach in two main aspects: on one hand, it has allowed the project consortium to design and implement the system tailored to the user needs identified in the different interactions with the end user community and on the other hand, this close contact has allowed an efficient dissemination of the project results. Both elements shall have a positive impact in increasing the acceptance of the system at European level.
The PHAROS system has been developed in a modular fashion to be able to adapt it to the particularities of the different European countries and regions and to the structures of the different organisations in charge of emergency management. The modular and flexible architecture used by PHAROS, centralised in the service platform, allows adapting and applying the PHAROS concept in a wide range of scenarios, since the system provides functional and operational scalability. From a functional point of view, the system can be adapted to different types of crisis by integrating the corresponding sensors and processing tools in a modular fashion, thanks to the use of standardised interfaces. This would allow a high impact at European level, since the hazards typically affecting the different European areas present different characteristics which have to be taken into account. PHAROS allows a simple adaptation to the corresponding hazards by means of adding or removing sensors (data sources) to/from the system and integrating the corresponding processing modules. This way, the same system can be used in several European regions, allowing also a consistent exchange of information between regions/countries. This functional scalability, allowing PHAROS to address multi-hazard events is clearly a relevant asset when dealing with cascading effects in situations when one hazard triggering subsequent ones. From an operational point of view, the implemented web-service approach allows the system to be tailored to different operational architectures thanks to a flexible user management. This way, entities using different types of hierarchies and organisational structures can use the same system and define their own profiles and roles to adapt the user privileges to the corresponding organisation. In addition to that, the system can be physically deployed using several approaches (centralised, distributed, partly distributed), increasing robustness of the system with regard to natural and man-made hazards by means of installing redundant elements in several locations and enabling an efficient use of the resources by allowing sharing the resources among different organisations by means of an intelligent allocation of access rights.
Improved situation assessment through all phases of the emergency management cycle
The combined use of a wide range of data sources (satellite and aerial earth observation, in-situ sensors, data provided by citizens and first responders) and the fusion of the information in a consistent manner allow end users to keep a solid and up-to-date picture of the situation during all phases of the emergency management cycle. The continuous monitoring allows early detection not only of the existing hazards, but also of the relevant variables which could derive in a given risk. Therefore, measures can be applied already during the mitigation phase. Moreover, the project has defined and implemented a new data format to store situational information and share it with other emergency management organisations which might be involved. This way, information can be shared among authorities in an easy and pre-defined manner in cases where several organisations with different responsibilities are participating in the emergency response, in cross-border emergencies and in emergencies which escalate to affect several jurisdictional areas at a given moment. In order to increase the acceptance of the proposed format and thus, booster the impact of the proposed solutions, the proposed format (sCOP, shared Common Operational Picture) is based on the TSO standard. Finally, the system allows the relevant information to be accessed from de-centralised locations thanks to the web-based access.
Enhanced decision support tools fostering emergency planning
The proposed PHAROS solution will have a positive impact not only during emergency response, making it easier to end users to take operational decisions by means of proposals provided by the system (currently proposals provide notifications about the relevant elements prone to be affected by the hazard and the corresponding alerting strategies to be followed), but also fostering the definition and implementation of alerting and response plans to be used in the different affected regions. These plans shall be the basis of the proposals provided by the decision support services and shall be adapted in a case by case fashion (learning tool).
Effective communication towards the population at risk and first responders on the field
PHAROS can have a high impact with regard to the communication strategies used to communicate with citizens at risk (alert recipients) and first responders on the field. On one hand, PHAROS has further developed the alerting solutions envisioned in the Alert4All project in order to integrate them in the overall service platform (thus benefitting from the synergies with the other tools) and adding new communication channels, such as Cell broadcast and GNSS (satellite navigation systems). The added value of these channels is that they make use of standard commercial devices (smartphones, cell phones, navigation devices, etc.) to receive the transmitted alert messages, therefore achieving a high message penetration and improving the efficiency of their distribution.
With regards to communication with the first responders on the field, they are allowed to access all relevant information they need from the central platform since this is relevant for them to take the corresponding decisions. This is particularly important to achieve a big impact of the proposed solution, since many times, decisions are taken on the operations field and not in the control centres. Furthermore, first responders can communicate with the control centre using their dedicated devices, which are equipped with the PHAROS application, which includes a “chat” feature to maintain secured communications.
Dissemination
The project impact has been re-enforced by carrying out a detailed dissemination strategy, whose main objectives have been to disseminate the project outcomes to relevant stakeholders and to develop an exploitation plan, taking into account two of the three main pillars of the dissemination strategy depicted in Figure 3-12: dissemination to relevant stakeholders and liaisons with other relevant initiatives and projects. In the former group, dissemination activities, comprising among others, publications and participation to conferences, meetings with stakeholders to present the project, meetings with the Advisory Board, have been focused on presenting the project overall approach and results to three different audience groups: (i) the general public, as beneficiaries of the overall system and in order to increase the system acceptance; (ii) the end user community, in order to benefit from their feedback to improve the system and tackle their requirements, as well as increasing the acceptance and (iii) the scientific community, in order to disseminate the different technical and scientific results provided by the technical WPs.
Figure 3-13 shows how the interactions among the different dissemination strategy components and the targeted or consequentially reached audience by each of the activities, indicating the intensity of each interaction by the width of the arrows. It shall be noted that through the dissemination activities carried out (or planned to be carried out), contacts with relevant other research projects and institutional initiatives have allowed closing liaisons. Furthermore, even if not specifically targeted, the general public (with no end user or scientific background) is reached by means of some dissemination activities, e.g. web, flyers, newsletters and new media. A detailed list of publications and dissemination activities in provided in Section 4.2.
Cooperation with other projects
During the first reporting period, dissemination activities focused on the first two groups (End users and general public), while during the second period a wider audience has been targeted to achieve dissemination of the project results to all the targeted groups in Figure 3 12. In the second reporting period, PHAROS has been very active in monitoring the relevant related activities and initiatives which are taking place at the time being in order to identify synergies with other projects and benefit from them. Among the relevant initiatives and partnerships, the following can be highlighted:
• Project VABENE++: VABENE++ is a German project (DLR) where powerful tools are being developed to aid public offices and organisations with security responsibilities as well as traffic authorities when dealing with disasters and large public events. The goal is to efficiently manage the required rescue logistics and the nearby traffic flow even under extreme conditions, thereby enabling response teams to rapidly reach the locations where they are needed. Scientists from various DLR institutes collaborate in this research project with the support of DLR’s Research Flight Facilities. The Chair of Remote Sensing Technology at Munich Technical University (TU München) and the Department of Geoinformatics and Remote Sensing at Osnabrück University also participate in VABENE++. Research focuses on areas such as simulation and large-scale traffic modelling, aerial traffic monitoring, traffic risk assessment, data fusion, data management, and further developing Web technologies in a GIS environment.
A number of topics addressed in VABENE++ are of complementary relevance to PHAROS, addressing the risks related to traffic in emergency and large events situations, with sensors integrated in an aerial platform.
The provision of real time aerial images to be received in the control centre has been performed during the pilot demonstration. This cooperation has supported end users with close to real time data, increasing the added value of the project and allowing the provision of a service to replace the initially planned satellite imagery to be provided by BiROS.
• EC FP7 - PREFER: The PREFER project is an FP7 SPACE project that was flagged by the Project Officer as relevant for PHAROS during the Kick-Off meeting. The main objective of PREFER is to set up space-based end-to-end information services to support prevention, preparedness and recovery phases of the forest fire emergency cycle in the EU Mediterranean Region. At first, the project managers of both projects had a teleconference. This drove the participation of the PHAROS project manager to the next PREFER progress meeting that took place on June 6, 2014. During this meeting, the PHAROS project manager could attend presentations from the PREFER team and also present the objectives and scope of the PHAROS project to the PREFER team. Additionally, representatives of both projects have participated together in several dissemination events, such as the European Space Solutions Conference and the Copernicus Emergency Projects Workshop in December 2014 and the LAMPRE Final Dissemination Event in February 2015. Further exchange of project information has been carried out to analyse the possibility of integrating PREFER products within the PHAROS service platform. As an outcome of this cooperation, the PHAROS platform is able to integrate the PREFER-generated products.
• Project FRISK-GO: This project is being implemented by the European Forest Institute and investigates a roadmap for a fully operational European risk facility for different types of disturbances. During the project, several workshops are planned. Each workshop focuses on one type of disturbance; hence the participants to each workshop are experts on the disturbance type, but also civil protection and response forces. The PHAROS project manager participated to the first FRISK-GO workshop, which focused on the forest fire scenario. The participants were experts in forestry and fire fighting from several European countries. During the workshop, the PHAROS project manager attended and participated to expert discussions on preparedness and mitigation for forest fire, visiting in-situ several areas that were affected by big forest fires with different impact range. The project manager had the opportunity to present the PHAROS project to the participants, enlarging significantly the visibility of the project towards European stakeholders and placing PHAROS as potential platform for the targeted risk facility by FRISK-GO.
• EC FP7 - LAMPRE: The EC FP7 LAMPRE (Landslide Modelling and tools for vulnerability assessment preparedness and recovery management) project aims at executing innovative research and technological developments to increase GMES limited operational capacity to cope with landslide events. The first contact with LAMPRE was established during the European Space Solutions Conference in June 2014. After this first contact, several teleconferences have been hold between LAMPRE and PHAROS to identify the possible synergies between the projects as well as between PHAROS and other Copernicus Emergency Projects. This cooperation resulted in the consideration of landslides as use case for the multi-hazard analysis carried out in PHAROS Task 2.5. Additionally, LAMPRE provides products related to landslides that could be integrated within the PHAROS platform, in case landslides were tackled and considering that landslides can be a consequence of land erosion due to wildfires. Therefore, the synergies of the chain of events wildfire-erosion-landslides could be exploited in a multi-hazard platform like PHAROS to cover the complete scenario. Finally, LAMPRE has performed an analysis of the synergies among the Copernicus Emergency projects and identified further synergies between PHAROS and the PREFER project. The synergies between PHAROS and LAMPRE have been also documented in the LAMPRE dissemination deliverable (D8.2).
• Initiative for the integration of persons with disabilities during the emergency management cycle: As an initiative from the Latvian presidency of the Council of the European Union during the first semester of 2015, a “Workshop on the needs of persons with disabilities throughout the emergency management cycle” was organised in Riga on the 12th-13th of January. Participants of the workshop were representatives from the Civil Protection authorities from the member states, representatives of the Latvian government and the European Commission, representatives from emergency management initiatives which include solutions for people with disabilities, as well as representatives of several associations representing people with disabilities. Within this context, PHAROS was invited to participate in the panel session titled “Innovative solutions and technologies in civil protection for persons with disabilities” due to the features that the receiver application is intended to provide in order to allow the use of several modes for the presentation of alert messages in order to tackle the needs of people with disabilities. The final document of the workshop is intended to be used at European level to derive the guidelines of policies to be fostered with regards to fulfilling the needs of people with disabilities during the emergency management cycle.
Standardisation and interoperability
Standardisation activities help increasing the impact of project results, since they can help the developed technologies to be implemented in mass market devices. In order to achieve this objective, the Consortium has specified the objectives related to interoperability and standardisation and elaborated a detailed strategy in order to achieve them.
The overall mission of the PHAROS interoperability and standardisation strategy, depicted in Figure 3-14, is to enhance system interoperability and, therefore, system acceptance. To fulfil this mission, the PHAROS approach is based on three main objectives, which are:
• Fostering and easing system functional scalability. The strategy to achieve this objective consists of (i) the identification of the relevant standards related to the interfaces towards external data and service providers which act as data sources to the system and (ii) the implementation of the identified standard-compliant interfaces. Therefore, by means of implementing standard interfaces whenever possible, the system provides the necessary mechanisms to be extended with new data sources and tools in an easy manner, fostering system functional scalability.
• Fostering interoperability with already existing systems. Interoperability with already existing systems increases system acceptance, allowing smoother transition to the new system and/or partial adoption of the provided tools. The strategy to achieve this objective consists of (i) the identification of the relevant standards related to data and metadata formats and communication protocols to allow exporting/importing information to/from external systems; (ii) the adoption of the identified standards within the PHAROS system, when possible; (iii) the implementation of export functions using the identified standards.
• Contributing to standardisation bodies. Solutions designed and implemented within the PHAROS system development activities shall be disseminated in the relevant standardization bodies in order to contribute with relevant items prone to be standardised, ensuring interoperability with future systems. The strategy to achieve this objective consists of (i) the identification of PHAROS developments which can be targeted as new standards or extensions to already existing standards; (ii) performance of the necessary steps to foster the standardisation of the identified items.
In the following, an outlook of the planned standardisation activities to be carried out after project completion is presented. The activities included in this section are focused on the standardisation of the PHAROS outcome and therefore, do not take into account activities related to the application of already existing standards in the design and implementation of the PHAROS system.
• Further contribution to the SC-EMTEL technical report TR 103 273 (Recommendations for public warning making use of pre-defined libraries).
• Foster the proposal for the creation of a TS within SC-EMTEL to contain the normative aspects included in TR 103 273.
• Prepare and support another STF proposal to develop syntax rules for alerting libraries in several languages.
• Further contribution to the ETSI TC-HF for developing the recommendations to be included in TR 103 335 Human Factor (HF); Guidelines for accessibility of warning messages.
• Prepare and support another STF proposal to create an ETSI specification for standardising the A4A protocol.
• Monitor the different activities in ISO/TC 292 (especially WG 3) regarding the standardisation of EMSI (TSO) and, if possible, support a national standardisation organisation (probably DIN) to request an ISO/TR 22351 update procedure during which the sCOP extensions developed in PHAROS can be contributed to the standardisation process.
Service Roll out
The service roll-out is dependent on the consumer technology readiness (implementation of receiver applications in mass market devices), the willingness of civil protection agencies to pay for the service (several provision modalities have been foreseen) and the creation of a service provider (or adoption of the service by an existing service provider). The contacts to the different stakeholders have already started during the project and access to the PHAROS services during a testing period have been agreed with the Catalan Fire Brigades. Regarding the communication part for the distributing information and alerts to the population, service level agreements need to be set up with intermediate providers (e.g. satellite broadcasters, terrestrial broadcasters, operators of EGNOS, mobile network operators, etc.) to ensure the message delivery and establish the conditions.
List of Websites:
Website: http://www.pharos-fp7.eu/
Contact details:
Mr. Javier Mulero Chaves
PHAROS Project Manager
DLR - German Aerospace Center
Member of the Helmholtz Association
Institute of Communications and Navigation
Oberpfaffenhofen
82234 Weßling
Germany
Telephone: + 49 8153 28-3815
Telefax: +49 8153 28-2844
E-Mail: Javier.MuleroChaves@dlr.de
Internet: http//www.dlr.de/kn
The efficient integration of satellite and terrestrial based systems and tools has become essential for disaster management and emergency response. Nevertheless, the potential added value of satellite-based systems had not yet been achieved. On the one hand, Earth observation (EO) satellites provide highly valuable data for forecast, short and long term monitoring as well as disaster impact evaluation. On the other hand, satellite communication systems, being reliable and robust against natural and man-made disasters, can be used to rapidly restore communications for responders, and also to provide risk and hazard-related information to citizens at risk. Furthermore, satellite navigation systems are unavoidable for logistics, first aid resources deployment and rescue operations.
The project PHAROS has designed, implemented and demonstrated an innovative multi-hazard open service platform which integrates space-based observation, satellite communications and navigation assets with other technologies to provide sustainable services for a wide variety of users in multi-application domains, such as prediction/early detection of emergencies, population alerting, environmental monitoring, crisis management and risk management, targeting several users, such as crisis managers, operators of critical infrastructures, insurance companies and academic/research.
PHAROS has followed an iterative engineering approach in close cooperation with the end users to conceive a flexible and scalable modular system providing integrated services, as illustrated in Figure 3-2, through one service platform and exploiting capabilities from EO systems (GMES/Copernicus), in-situ sensor data and data provided by responders on the field (human data) to provide highly efficient tools and enhanced services to the following user profiles:
• Primary users (PU): any responsible authority (i.e. entity which is formally assumed to directly confront a particular situation and/or incident) uses the system for institutional purposes.
• Secondary users (SU): any third-party entity (apart from institutional users as defined above), for instance, a research institution or a private company that exploits a service of the system, for instance, to increase awareness about a particular situation and/or incident, not acting on behalf of any responsible authority.
Additionally, PHAROS addresses society as whole and in particular citizens at risk by defining the role of “recipients”, who are the individuals (i.e. citizens) that are provided with information that is sent/made available through the PHAROS system.
On the one hand, the capability of PHAROS to satisfy such different user profiles means an advantage in terms economies of scale for a sustainable service; on the other hand, this service scalability feature requires a service-centric system design.
PHAROS has carried out a complete engineering process, from the conception of the system until its demonstration in an operational environment scenario using forest fires as reference scenario. The pilot demonstration was successfully carried out from the 2nd to the 4th of March 2016 with the cooperation of the Catalan fire brigades (Bombers de la Generalitat de Catalunya) and the support of the Forest Sciences Centre of Catalonia (CTFC). In the pilot demonstration, over 100 stakeholders, including end users, civil protection agents, decision makers and the media, could observe the system operation during a live controlled forest fire performed by the fire brigades in the context of a prescribed burning in the region of Catalonia.
Project Context and Objectives:
The integration of services covering a wide range of hazards and operational domains is one important asset in the context of multi-hazard disaster and emergency management. In this regard, Earth Observation (EO), commonly used for performing risk and crisis monitoring, detection and assessment, as well as communication systems, used on one hand to allow members of the rescue teams and first responders on the field to access the different needed facilities and to communicate with the corresponding control centre and, on the other hand, to communicate with the population at risk in order to put in practice the corresponding response or recovery strategies, provide important tools whose added value can be increased if the proper integration is provided, allowing exploiting the existing synergies between the available assets. Finally, Global Navigation Satellite Systems (GNSS), taking into consideration the widespread use of navigation devices, not only in vehicles, but also embedded in mass market receivers such as smartphones, and the evolution of location based services (LBS), become another important means to communicate with the population. By integrating the different mentioned elements, with additional terrestrial assets, it is possible to provide services that cover the four elements of effective Early Warning Systems (EWS), namely, risk knowledge, monitoring and warning, dissemination and communication and response capability, while not being restricted to them.
Therefore, there seems to be a need for tools that allow the gathering, integration and processing of different information sources in a systematic way (for instance, provided by EO and in-situ sensors), making it possible to use the collected information for decision support purposes, disaster management and communication towards the population. Additionally, these tools shall enable information sharing among different jurisdictional levels (local, regional, national or international) and different involved authorities, as well as allow integration of the offered products to be imported to already existing systems, thus increasing the added value of the system and fostering the acceptance of the proposed solution.
Taking this context into account, the PHAROS overall objectives are:
- To design and implement an innovative multi-hazard open service platform which integrates space-based observation, satellite communications and navigation (Galileo/GNSS) services to provide sustainable (pre-operational) services for a wide variety of users in multi-application domains, such as prediction/early detection of emergencies, population alerting, environmental monitoring, crisis management and risk management, targeting several users (crisis managers, operators of critical infrastructures, insurance companies, academic, etc.).
- To validate the developed service platform for a specific scenario, forest fires have been chosen.
To accomplish these top-level objectives, the following scientific and technological (S&T) objectives are identified:
- To specify a sustainable service concept and architecture for the PHAROS platform;
- To define and further consolidate the economic model for the PHAROS service deployment through a business plan, that exploits flexibility and scalability advantages of the PHAROS architecture;
- To specify interfaces for input data to the PHAROS platform;
- To implement the functionalities that provide the PHAROS services:
o To implement the PHAROS service platform based on an existing platform;
o To develop the PHAROS user interface for fixed and mobile users;
o To develop decision support services based on information fusion and situation assessment, deriving a COP;
o To adapt an advanced Wildfire simulator provided by TSYL to be integrated in the PHAROS platform and allow automated simulation service coupled with existing sensor capabilities for fire detection (the FireWatch system);
o To deploy appropriate data acquisition, processing workflows and services to provide EO-based sensor input;
o To adapt the specifications of a satellite-based communications standard for messaging applications suitable as uplink for sensor networks (the S-band Mobile Interactive Multimedia) to operate in Ka-band and implement them in a prototype terminal and at the hub;
o To integrate the Ka-band S-MIM prototype terminal with FireWatch sensors;
o To deploy a prototype alert message dispatcher developed in a previous project and integrate it with a Cell Broadcast Centre as alert dissemination channel to the population;
o To integrate the alert message dispatcher with the a GNSS service centre to issue alert messages over EGNOS;
- To prepare suitable satellite EO data and free-space optical downlink integrated in the PHAROS platform;
- To integrate the developed subsystems, test and validate them with end users in a pilot demonstration for the “forest fire” case.
Project Results:
Emergency management systems have a great potential to reduce damages in emergency situations, both in terms of economic impact and loss of lives. In this regard, PHAROS has provided an integrated solution to exploit the synergies existing between satellite and terrestrial systems and solutions and fostered a multi-hazard approach for emergency management.
The PHAROS system has been conceived and demonstrated following an iterative approach with close interaction with the end users, including fire brigades, civil protection agents, police departments and decision makers. The system has been demonstrated in an operational environment using forest fires as reference scenario.
To fulfil the PHAROS objectives the project has established and followed a system engineering strategy which has allowed a permanent revision and tracking of the user requirements and their translation into system and technical requirements to be satisfied by the different system modules.
In this section of the report, the main results and foregrounds with regard to each work package (WP) will be described.
4.1.1. Multi-Hazard Open Service Platform Specification and Business Aspects:
4.1.1.1. Service concept, requirements and system engineering:
As a first step, the project has defined the overall service approach of the PHAROS platform, identifying and describing the services to be provided by the system, as well as the involved actors and roles. The outcome of this task (Task 2.1) has been documented in D2.1 (PHAROS Service Concept Specification).
The main challenges to achieve the corresponding objectives have been on one hand, understanding the expectations from end users regarding the capabilities that the PHAROS system shall provide and, on the other hand, defining a service concept which contemplates all the requested capabilities and integrates them in a consistent manner. In order to tackle the challenges, the project has benefitted from a close interaction with end users represented by the members of the Advisory Board and by additional local end users. In particular, the service concept specification is strongly based on the outcome of the 1st Advisory Board (AB) workshop, held on the 12th of March in Barcelona (Spain). The workshop attendees provided opinions from different operational profiles related not only with wildfires, but also with other application domains, such as the regional police and traffic management authorities, or with crisis management in general, such as civil protection representatives. This way, it has been possible to obtain inputs from end users covering a wide spectrum of hazards and crisis typologies in order not to miss the multi-hazard capabilities to be provided by the system. In order to prepare the AB workshop, the Consortium celebrated an internal workshop in which a brainstorming session was dedicated to identify the capabilities that the system should provide according to the expertise and experience of the different partners. This preliminary list of capabilities was used as basis for the preparation of the AB workshop, in which a similar brainstorming session was carried out with the workshop attendees. During the workshop, the desired capabilities identified by the end users were classified according to the different phases of the emergency management cycle and later mapped to the ones identified by the project team in order to assign priorities and identify areas in which the system might not provide meaningful features. These areas were further discussed in order to identify new capabilities which could improve users’ operations during the whole emergency management cycle. The interaction between the Consortium and the end users contributing to the specification of the service concept is depicted in Figure 3-3.
As part of the outcome of the task and taking into account the discussions with the AB and the end users, several concepts have been defined in order to lay the foundations of the PHAROS system. Firstly, the main actors interacting with the system have been identified. These actors are the different users which may benefit from the system and also the recipients of the information provided by the system (citizens receiving information or alert messages), according to the following classification:
• Primary users (PU): any responsible authority (i.e. entity which is formally assumed to directly confront a particular situation and/or incident) who uses the system for institutional purposes. This category takes into account also the first responders located in the operational field that may access remotely the system, obtaining the provided information and allowing the use of the system.
• Secondary users: any third-party entity (apart from institutional users as defined above), like for instance, a research institution or a private company that exploits a service or product provided by the system, for example, to increase awareness about a particular situation and/or incident, not acting on behalf of any responsible authority.
• Recipients: the individuals (i.e. citizens) that are provided with information that is sent/made available through the PHAROS system.
According to the wide range of capabilities identified by the end users, two different time approaches have been defined:
• Short term: It takes into account the services that can and shall be provided by PHAROS by the end of the project life, taking into account the existing time and resource limitations. The short term approach is based on the wildfire (forest fire) scenario selected for the implementation and pilot phases.
• Long term: It takes into account not only the project duration, but what a system like PHAROS should be in the long run, keeping a visionary approach in mind. Therefore, the long term version of PHAROS shall consider also services that cannot be provided by PHAROS during the project life time due to several reasons, such as time or resources limitations, but that shall be provided by PHAROS if the necessary tools and inputs are available at a certain point of time.
Keeping in mind the different time approaches, the capabilities identified by the end users have allowed the identification of four main application scenarios, which gather the identified use cases and allow the identification of the key users’ needs to be satisfied. These four application scenarios are: (i) risk assessment; (ii) risk and disaster detection and monitoring; (iii) disaster management; and (iv) communication. Further processing of the capabilities to be provided for each application scenario in the short and long term have allowed the definition of the PHAROS service concept, depicted in Figure 3-2.
The PHAROS service concept takes the open service platform as central element which integrates, on one hand, the different available data inputs and, on the other hand, the different available algorithms and processing tools in order to provide data and advanced products and services. Data products and services are based on the gathering of information from different sources (EO, data sensors and human data) and its proper presentation to the user, both for visualisation and download. The amount and type of data to be gathered and presented will depend on the availability of the information sources, which could be added or removed according to the situation. For the different data products provided by the system, two main services can be defined within this category: data visualisation and data download. Primary users will be able to visualise on screen the different gathered data and download it in the proper format, if necessary. Secondary users instead do not have direct access to the system, and they will not be allowed to visualise the data by using it. However, a particular sub-set of data will be available for them in a pre-defined set of formats. In order to offer advanced services and products, the PHAROS system makes use of data processing and fusion techniques applied to the available input data. Although the provision of particular advanced services can be added to and removed from the system, by installing the corresponding models and algorithms for each case, allowing or disabling the provision of new products, the general advanced products and services to be provided by the system are classified in the following categories: monitoring and detection, data fusion and decision support, simulation services, alert and information services and provision of a Common Operation Picture (COP). Advanced services are mainly conceived for primary users in order to provide them with tools to be used during the whole emergency management cycle. Nevertheless, several products which are the outcome of using the advanced services can also be made available to secondary users. Regarding the timing, almost all services are intended to be used or triggered in real time. Additionally, historical data and the outcome of the different services will be also available in the system in order to allow the analysis of the different emergency management strategies and identify room for improvement and lessons learned. Another important aspect to be remarked is the fact that advanced services are intended to interact with each other, meaning that the outcome of a service, if available, can be used as input by another service (service chaining). This increases the added value of the complete service chain by integrating the different services.
After the definition of the service concept, the activities performed within T2.3 have been strongly based on the close interaction with the end users, represented both by the members of the AB and also by local end users who participated in the different workshops and contributed with additional feedback by means of questionnaires. Therefore, this interaction with the end users together with the service concept described in Task 2.1 have been the basis for the identification of the user and system requirements documented initially in D2.4. Thereafter, a new interaction with the end users took place during the 2nd AB Workshop held on the 14th of October 2014 in Barcelona (Spain). This new interaction allowed the Consortium to present the first version of the system architecture to the workshop attendees and to discuss with them about the service concept, the first draft of the graphical user interface (GUI), and the alerting procedures to be implemented by the system. Additionally, an analysis of the user needs when dealing with a real fire situation was performed taking as basis a real scenario located in the region of Catalonia. This analysis allowed the Consortium to get a better overview of the needs of different user profiles (fire brigades and civil protection) regarding information assets and the overall decision making processes. Thanks to this exercise, the relevant information items were identified as well as the different users and locations where this information should be provided. Thereafter, the development of the technical activities taking place in WP 3, WP 4 and WP 5 have led to the definition of the technical requirements, which have been compiled for completeness in D2.5. Afterwards, the conclusions of the 3rd AB Workshop, held on the 14th of October 2015 in Barcelona (Spain) have been used to further review the user requirements (and consequently, the system and technical requirements), mainly based on usability and interoperability issues. Finally, the latest recommendations obtained in the analysis performed in Task 2.5 and the outcome of the end user evaluation carried out during the pilot demonstration have been used to provide the last version of the user requirements and the recommendations for the target system, documented in D2.7. The overall end user interaction process performed within the task and the contribution to the different deliverables is depicted in Figure 3-4. All the modifications in requirements updated from D2.4 to D2.7 have been documented by means of using change requests where the proposed modifications are described, together with an estimation of the impact of the modification in terms of time and budget and the final decision about the proposal.
The main outcome of this process, documented in D2.4 to D2.7 is the identification of the user and system requirements which must be satisfied in order to provide the services defined in D2.1. According to this outcome, the user requirements and their corresponding system requirements have been classified using different categories in order to fit with the short and long term system approaches and to differentiate the requirements related to the fire case scenario to be considered in the short term approach and the ones dealing with the multi-hazard aspects to be fulfilled in the long term. In the first stage of the project, two categories have been used to differentiate the short (DS, Developed System) and long (TS, Target System) term aspects. It must be highlighted that a high number of requirements emphasised the need of providing features to cover also the preparedness and mitigation phases (for instance, for early detection of risks) and also the importance of providing a system whose outcome can be integrated within already existing systems, allowing interoperability between users and authorities.
The definition of the user and system requirements triggered the definition of the system architecture within Task 2.4. Once the architecture was defined, the technical requirements related to each system module (which are the starting point for the design activities performed within WP 3, WP 4 and WP 5) have been gathered in D2.5 in order to allow tracking of the technical requirements during the whole duration of the project and once the corresponding WP 3, 4 and 5 deliverables have been submitted.
Regarding the definition of the overall system tests performed during the second project phase, for each system and technical requirement, the fit criteria to assess their fulfilment have been defined in order to serve as basis for the definition of the test plan.
4.1.1.2. Overall system architecture:
The procedure to design the system architecture has been an iterative process which has involved the Consortium, where different expertise domains are represented, and the end users, intended to benefit from the system in the short and long term. This has allowed the Consortium to discuss with the participants of the different workshops about operational issues, such as system scalability and interconnection with other systems.
The basic pillar on which the system architecture design is based is the necessity for providing a modular architecture in order to satisfy the flexibility and scalability requirements both from a functional and operational perspective.
• The term “functional scalability” must be understood as the capability that the system shall provide in order to add or remove functionalities (modules) according to the situation, the hazards to be addressed and the corresponding operational domains. The benefits that functional scalability is intended to provide are: (i) Allow total, partial and/or incremental deployment of the PHAROS components, tailored to the situation, needs and capabilities of the corresponding authority; (ii) Allow addition of new data sources, modules and algorithms when they become available, by using open available standard interfaces as far as possible, thus allowing extending the system to tackle new operational domains and hazards; (iii) Allow a (totally or partially) distributed system deployment regardless of the hardware platform and geographical location where the different functional modules are installed, taking advantage of the use of remote connections. This type of deployment is transparent to the user, who will access the system as if it was a unique entity, regardless of the type of deployment used. A distributed approach may increase the system resilience towards disasters and emergencies, by distributing the location of the different modules, on one hand, and providing redundant modules in different (and potentially not affected) geographical locations, on the other hand. The modular approach minimizes also the complexity of the system in case of using redundant implementations to ensure system availability on a 24/7 basis.
• “Operational scalability” refers to the capability of the system deployment to allow its use adapting to the widest range of operational structures. These structures vary depending on the different political and organisational/administrative structures, as well as on the type of hazard, its scope and evolution. This means that on one hand, the authority in charge may vary depending on the hazard type (for instance, firemen might be the responsible authority in forest fire cases while civil protection might be in charge of other types of hazards). On the other hand, a higher-level authority might get involved in the management of the crisis, depending on its scope and how the crisis evolves. Generally, the higher levels of the command hierarchy are involved if the crisis escalates though several jurisdictions at the same level (for instance, national authorities may get involved if the crisis exceeds the borders of the region where the crisis was originated). The organisational and administrative structures used for crisis management and alerting in the different European countries vary from country to country, ranging from fully centralised structures to fully distributed ones, and including different degrees of distributed management.
Taking into account the scalability requirements as well as the provision of interconnectivity with already existing and future emergency management systems, the activities within the tasks have led to the design of the overall functional architecture for the PHAROS system, considering the long and short term dimensions. The long term approach of the system architecture (see Figure 3-5) is intended to be used in a multi-hazard context, where the different generic modules shall be replaced by particular (and many times, hazard-dependent) modules to be used according to the type of hazard. In the short term approach (see Figure 3-6), the focus is given to the forest fire (wildfire) case and therefore, the generic modules presented in the long term version are replaced by the particular modules devised for forest fire management. In this regard, a differential description with respect to the long term architecture has been provided in D2.9. Therefore, the particular modules to tackle the forest fire case have been introduced, presenting the different functionalities and interfaces to be considered, taking the long term approach as basis. The two presented versions provide a picture of the overall system architecture both from a generic design perspective (long term) and an implementation point of view (short term), focusing on the tools used or designed to implement each module and the suitable means for interconnecting them to provide pre-operational services.
4.1.1.3. Multi-hazard aspects:
PHAROS has identified and described additional hazards that the system can be used for, including information on how PHAROS would need to be extended in terms of input data, algorithms, EO data and simulation capabilities. Furthermore, an overview of necessary changes shall be given to operate the system in the context of the identified additional hazard types. The draft structure of the resulting report (D2.10) the preliminary selection of additional hazard types to be considered and the interim status of the case studies have been presented to the Advisory Board and End Users during the 3rd AB Workshop (October 2015, Barcelona). The feedback collected has been incorporated into the report. Based on the result of the PHAROS Multi-Hazard Case Studies, additional multi-hazard requirements have been derived (and existing requirements updated accordingly were necessary) that have been integrated in the final issue of the PHAROS Requirements and System Engineering Deliverable (D2.7).
4.1.1.4. Service sustainability and business plan:
Apart from the engineering perspective, PHAROS has developed the concepts of service sustainability and the corresponding business plan. The main objectives of this activity are to develop the project business sustainability roadmap, determine CAPEX and OPEX for the development of the system, determine organisational structures to operate the service and the platform, produce the financial model to determine the costs and funding requirements and identify methods to ensure sustainability of the services by finding funding sources and other possible scenarios. During this period, the necessary bases for the development of the project business plan and sustainability roadmap have been analysed. The outcome of the task has been documented in D2.2 (Business Model Spreadsheet and Business Plan Report - Draft) and D2.3 (Business Model Spreadsheet and Business Plan Report –Final).
The first step taken towards the fulfillment of this objective has been the analysis of the possible benefits that the system could provide by enhancing the performance and awareness of emergency systems and general population and the costs that the system could have depending on what business model is adopted by the service provider. In order to estimate what benefits the adoption of the PHAROS system could imply, a list of key features and functionalities was compiled and circulated among the end users involved in PHAROS, taking the ranking of these into account for the design of the overall system so the benefits could be quantifiable.
The second step was to analyse the possible organisational structures and models that the service provider could adopt, so that they can be compared with the system’s characteristics and features in order to recommend those that are more suitable. Also, an overview of the cost drivers (costs associated with bringing the system from its pre-operational state to an operational state), the CAPEX and the OPEX costs for the deployment of a decentralised PHAROS system (i.e. offered as a standalone product) are included in the final version of the Service Sustainability and Business Plan Specification document.
Regarding the business plan and the roadmap for exploitation and commercialisation of the PHAROS system, the exploitable outputs are collected, as well as exploitation plan for these from each one of the project partners. Also, a description of the transition from the PHAROS developed system to the target system is included in the document, together with the description of the service provider as well as a commercialisation plan and a draft roadmap plan in order to achieve the commercial viability of the PHAROS system.
According to the agreement among the Consortium partners and the Project Officer, an additional update of D2.3 has been provided at the end of the project (M30) in order to document the activities associated to T2.2 carried out between M22 and M30. Thereafter, a new submission of the deliverable has been provided on the 19th of July in order to address the recommendations given by the Project Reviewer and agreed with the Project Officer during the Final Review Meeting.
4.1.2. Situation assessment, decision support and Earth observation:
4.1.2.1. Information fusion and situation assessment:
In this area, PHAROS has identified and implemented the required sensor and data fusion techniques in order to generate situational awareness information using the available data (sensor data, historical data sets, background and baseline data, modelling and simulation results, a priori knowledge about the environment and human input).
The DSS architecture has been developed based on the requirements analysis and the interaction with end users and the AB (see Figure 3-7). The DSS combines incident management, information fusion, situation assessment, and decision support functionality. As shown in Figure 3-6, each functionality is encapsulated by a corresponding component, (i) the Sensor Processing Service (DSS-SP) for the processing of incoming sensor and field observations; (ii) the Incident Management Service (DSS-IM); (iii) Information Fusion and Situation Assessment Services (DSS-IF, DSS-SA); and (iv) the Decision Support Service (DSS-DS).
In order to comply with the modular PHAROS system approach, DSS components have been designed as web services which respond to requests from the Service Platform (SP). The PHAROS system will be able to exchange resources such as incidents and decision proposals in a standardised way using the HTTP protocol (REST conformity).
• DSS-IF performs spatial analysis based on sensor and field input data, simulation results, and pre-defined geo-data. It creates several geospatial outputs which are used by DSS-SA to enhance situation information and to perform further situation assessment procedures.
• DSS-SA performs situation management and assessment and the generation and provision of the Incident COP as a formal view of a situation. In detail, it takes care of the following tasks:
o Generates and updates the situation data resource for an incident; for this, it uses incident-related data including sensor and field observations, SM simulation runs for the incident (input parameters and reference to the simulation result), and decision proposals, operational data such as user events, information on disseminated messages, and information on resources in the field, information fusion results, and situation assessment results
o Provides a formal view of the situation in the form of an Incident COP for a standardised exchange either in a lean JSON representation or conforming to the shared Common Operational Picture (sCOP) schema represented in XML
o Generates a set of input parameters for SM and requests simulations
o Requests DSS-IF for information fusion functions regarding the incident
o Performs situation assessment processes such as the assessment of situation severity
o Triggers the Decision Support Service (DSS-DS) for the generation and update of decision proposals
Based on the requirements gathered, the interfaces of the SM and the available data required fusion techniques have been identified and are being implemented.
The DSS services (except DSS-DS) have been specified in Deliverable D3.1 (Draft) and Deliverable D3.2 (Final). For the description of situational awareness information, the DSS-SA uses the sCOP format which was developed in Task 3.5. As foreseen, the configuration of the DSS has been updated throughout the project to reflect the test findings and user feedback during the system integration and testing phase.
4.1.2.2. Risk and incident modelling
PHAROS has developed and deployed modelling services for (i) calculation of fire risk and (ii) forest fire incidents based on the inputs of available sensor systems, the results of T3.1 and T3.4 as well as on the simulation capabilities of the operational forest fire simulator. The service is coupled with sensor systems whose inputs allow the adjustment of real fire behaviour simulations for the subsequent operational periods. During this task, the technical requirements have been derived based on the user requirements and the system requirements, identified and documented in D2.4 to D2.7. Based on this, the specification of the Simulation Module (SM) architecture has been described as well as the specification of each of its components by describing their role and purpose inside the specified architecture (see Figure 3-8).
Taking into account the risk and incident modelling services to be provided together with the identified technical requirements several simulation modes have been defined and described. The services to be provided by the SM have been categorised into several simulation modes, each of these provide an output or a set of outputs that have a certain purpose. In this regard, these simulation modes have been classified into operational and non-operational according to their purpose, i.e. for their operational use (operational mode) or for fire planning and mitigation tasks (non-operational mode).
Operational simulation modes:
• Fire spread: Provides a set of raster and vectorial outputs that represent the forecast of the behaviour of the fire for forest fire incidents with the capability of calibration of the results. This mode can be triggered manually by the user through the GUI, through ignition points identified by FireWatch sensors (in-situ) or by ignition points identified through Earth Observation sensors.
• Evacuation time: Provides a set of raster and vectorial outputs that forecasts the time the fire would take to reach a certain critical point defined by the user when starting in a certain location.
Non-operational simulation modes:
The non-operational simulation modes run daily providing the users of PHAROS with the latest assessment of fire risk.
• Forest fire structural hazard: In general terms it can be explained as representing the risk of fire for a certain area i.e. the easiness that a fire has to spread for each cell of the considered area based on several fire behaviour variables.
• Forest fire growth potential based on critical infrastructures: Provides the assessment of fire spread potential based on ignition points of critical infrastructures such as electric supply networks.
• Potential impact of forest fires on critical infrastructures: Provides a representation of the potential impact of the forest fire on critical infrastructures such as electric supply networks.
According to this, the necessary basis data that is used by the several modes of the simulation module has been defined and integrated in the SM. The several sets of outputs of the described simulation modes have been developed and implemented.
The SM interfaces with the PHAROS Service Platform that provides simulations requests and necessary simulation input parameters and in turn the SM provides the processed outputs to the SP to be graphically represented through the GUI or to be used by the DSS to analyse them and provide proposals to the users of PHAROS. Besides, two INSPIRE-compliant metadata profiles have been defined and implemented, one for vector outputs and another for raster outputs. Each output of the SM integrates the corresponding metadata. Task 3.2 implemented the modelling services mentioned above and tested them successfully on a module level.
4.1.2.3. Decision support
PHAROS developed and deployed decision support services that generate and update decision proposals, relying on the services provided by T3.1 to generate and update situational information. Relevant workflows, rulesets and expert knowledge have been gathered and compiled in order to transform the situational awareness into decision proposals and decision implementations for the decision maker/user.
Requirements and the input of the Advisory Board have been analysed to derive what situational aspects need to be part of the situational analysis (Task 3.1) which formed the basis of the decision support specified in Task 3.3.
Apart from the mandatory decision support regarding the dissemination of alerts, additional decision support has been provided to the user focusing on the management of the situation.
Situational information has been provided by the DSS-SA service using the sCOP format, specified in Task 3.5. DSS-DS enriched this sCOP format by two additional resource types:
• Proposals: the decision proposals are intended for PHAROS primary users and are shown via the PHAROS GUI. Different types of proposals exist; the most relevant are
o Notification: purpose of a Notification proposal is to notify the user of something important (similar to an internal alarm);
o Dissemination: purpose of a Dissemination proposal is to suggest the dissemination of a message to external recipients, if the internal conditions for alerting are met.
• Products: products are intended to be disseminated to external recipients; in case the DSS-DS proposes to disseminate a product, at the same time a proposed product is also provided.
All DSS-DS resources are provided via RESTful interfaces (see D3.1 and D5.3). DSS-DS uses a product structure according to the Common Alerting Protocol (CAP 1.2). Products are provided in different formats, e.g. JSON and CAP (XML). The DSS-DS service interface allows to retrieve and update proposals, while for products also the creation of a product (e.g. in case of a manually created product/alert triggered by the user) as well as the update of parts of the product.
Beside the specification and development of the DSS-DS service, PHAROS has also specified the workflows used to orchestrate system-wide service-chains, including automatic (periodic) and on-demand workflows. The DSS-DS service has been specified in Deliverable D3.6 (Draft) and Deliverable D3.7 (Final). Task 3.3 implemented the DSS-DS service and tested it successfully on a module level. Finally, the configuration of the DSS has been updated to reflect the test findings and user feedback (e.g. number and frequency of proposals, content of proposals) during the system integration and testing phase.
4.1.2.4. Earth Observation data access and processing
Regarding Earth Observation, the first aim of this task was the provision of an operational “fire service” processing chain (near real time). In the focus of the development and implementation is the derivation of fire-hot-spots with MODIS (Moderate Resolution Imaging Spectroradiometer) data acquisitions with an automated processing chain and publishing via WebGIS-Client. The existing fire service was extended in two ways:
i) An OGC-Interface (WMS, WFS, WCS) for data provision was added
ii) An MSG-SEVIRI hotspot service was added
Because of the lack of availability of BiROS and Sentinel 3 only NPP VIIRS data where investigated for further usage as backup for MODIS.
The second component was the provision of Earth Observation images and their thematic products and generated maps for the recovery, mitigation and preparedness phases. The data are available in a high (< 30m) to very high spatial resolution (< 2.5m) and in a medium to low temporal resolution (> 1d) and were ordered from the CSCDA.
According to the project plan the first part of the project duration was focused on the extension of the existing MODIS Hot Spot Service with an OGC-Interface, and the feasibility check to improve the temporal resolution. In the second part of the project the MSG SEVIRI sensor as an additional hot spot detection service was implemented.
The detection of high temperature events (HTE) uses the MOD14 algorithm. The algorithm based on the shift of radiances to shorter wavelengths (middle infrared) with an increasing surface temperature. MOD14 is well documented and tested in operational services and guarantees comparability and reproducibility as well as a standardised international acknowledged product. The thermal information is collected at 1000 m spatial resolution twice daily by each sensor (Terra and Aqua), providing up to four thermal observations daily. The MODIS images used for fire detection are acquired from two direct broadcast receiving stations from DLR located in Oberpfafffenhofen and Neustrelitz, Germany. The MODIS Hotspot Service is based on a three-layer system architecture – the data layer, service layer and client layer (see Figure 3-9).
The main part of the service layer is the WPS (Web processing service) to orchestrate the process chain. The output of the WPS is the provision of a WFS with the location of the hot spots in near-real time for Europe and surrounding countries, including information about:
• Latitude and longitude,
• Administrative boundaries,
• Vegetation and land cover (Corine land cover, 100 m resolution and Global Land Cover, 1000 m product)
MSG SEVIRI (Spinning Enhanced Visible and Infrared Imager)-is mounted on the geostationary satellite MSG 2 (Meteosat Second Generation satellite)It provides hot spots in a high temporal resolution (up to 15 minutes), covers Europe and northern Africa and detects fires during the night as well. The SEVIRI Sensor provides data in 12 different wavelengths within the visible to infra-red spectrum and with a pixel size of 1 km for the high resolution visible channels, and up to 3 km for the infrared channels. Regarding MODIS, the active fire detection uses the shift of the peak emission and the increased sensitivity to temperature changes to detect high temperature events within a pixel. For a surface at a brightness temperature around 300 K the spectral radiance peaks is at a wavelength around 10 µm. The peak wavelength decreases as the brightness temperature increases. The algorithm detects hot spots by a combination of threshold tests using band 9 (3.8 micron) and band 14 (10.5 micron). In comparison to MODIS, DLR does not receive directly the MSG-SEVIRI data in near real time. In order to use the Eumetsat (European Organisation for the Exploitation of Meteorological Satellites) near real time processing service, this service will fetch up the derived hot spots (5 minutes after the data acquisition) and will provide the information through the MODIS processing chain to the PHAROS service platform.
For the pilot demonstration in Solsona a large amount of remote sensing data were ordered. Products and maps based on these data must be generally created manually and require high expert knowledge. For the implemented short term approach of the project, a limited implementation was prepared by the ZKI service from DLR/DFD. On the long term run these products will be created on demand (in the case of a fire emergency activation or for pre- and post-operational purposes, e.g. forest inventory regarding fuel capacity, change detection, seasonal variations). In addition to the satellite data, aerial data from the VABENE++ project and thermal data from the AirSIG sensor from Fraunhofer IOSB were used.
4.1.2.5. Shared Common Operational Picture
PHAROS has also addressed the issue of exchange and interoperability of situational awareness and decision support information. Based on existing standards, a technical exchange format has been proposed which is used by PHAROS services dealing with this type of information. The so called shared Common Operational Picture (sCOP) exchange format serves several purposes:
• Exchange format between PHAROS services, especially among the set of DSS services (situation awareness service, decision support service), and
• Exchange format for incident-related COP information with external systems and other PHAROS instances.
Both the syntactical and semantical level of interoperability has been addressed:
• Syntactical interoperability allows the exchange of data (e.g. using the same ASCII or Unicode format; other examples are XML and SQL);
• Semantical interoperability includes the ability to interpret the information exchanged meaningfully, which requires both sides (sender and recipient) to refer to a common information exchange reference model.
Regarding the exchange of information relevant for disaster management applications, three different levels can be identified:
• Sensor Data: on this level a number of (de-facto) standards exist to support the exchange of sensor data from sensor systems such as tide gauges, buoys, seismic sensors, GPS stations, etc.
• Situation Data, including situation assessments and forecasts, risk and vulnerability information: several approaches exist in the military and civilian domain to standardise the description and the exchange of situation information.
• Products: the exchange and interoperability of products such as warnings, alerting and other emergency information (e.g. hospital availability information) is supported by a number of standards.
The protocols and formats listed below have been evaluated considering the PHAROS requirements targeting at interoperability and efficiency. Further criteria have been:
• Domain coverage: the protocol/format shall allow the description of all information relevant for situation awareness and decision support in the (civil) disaster management domain;
• Incident based: the protocol/format shall support the incident/event concept;
• Mapping: the effort for mapping the internal PHAROS data model to the elements and attributes of the protocol/format shall be straightforward.
The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems.
The Tactical Situation Object (TSO) has been developed within the project Open Advanced System for CrisIS Management (OASIS) with the aim to support interoperability to exchange reports and mission information among agencies involved in disaster management, civil protection and societal security. It is now further developed as Emergency Management Shared Information (EMSI) by the ISO technical committee for social security and resilience in the technical report ISO/TR 22351.
Within the project Alert4All an extension of TSO has been developed, the so-called Alerting COP (A-COP), to cover the provision of additional features, such as the provision of alerting plans, management of users’ security or accessing the history of sent alert messages.
Emergency Data Exchange Language (EDXL) is a suite of XML-based messaging standards that facilitate emergency information sharing between government entities and the full range of emergency-related organizations. EDXL standardises messaging formats for communications between these parties. The XML-based Emergency Data Exchange Language (EDXL) Situation Reporting specification describes a set of standard reports and elements that can be used for data sharing among emergency information systems, and that provide incident information for situation awareness on which incident command can base decisions.
The Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM) is a model that aims to enable the interoperability of systems and projects required to share Command and Control (C2) information. JC3IEDM is an evolution of the C2IEDM standard that includes joint operational concepts, just as the Land Command and Control Information Exchange Data Model (LC2IEDM) was extended to become C2IEDM.
As result of the evaluation process, EMSI (TSO) has been chosen as best basis to develop an extension in order to fully cover the required domain and all PHAROS requirements towards an interoperable exchange format for situational information.
The sCOP format has been developed within Task 3.5 and has been implemented in the PHAROS DSS for internal communication and as an export functionality for COP information. The sCOP format is currently being proposed as contribution to EMSI to Working Group 3 of ISO / TC 22351.
4.1.3. Satellite communication, navigation and alerting:
4.1.3.1. Satellite-based uplink for in-situ sensor data:
PHAROS has performed a review of the satellite communication standard, S-MIM, so that it can operate in Ka-band, according to the requirements of the PHAROS applications, and implement the required adaptations at the prototype terminal and hub. The reviewed standard, called F-SIM, includes a revision and adaptation of the physical layer, link layer and control planes. Additionally, the task aims at designing, implementing and testing the data interface between the FireWatch system and the prototype terminal.
Although two specific technologies, FireWatch and F-SIM, have been selected and considered throughout the lifetime of the project, alternative solutions, both terrestrial and satellite, in compliance with the modular and flexible approach that characterises PHAROS, have been reviewed in D4.1 so to be possibly taken into account for the long term phase. Moreover, D4.1 describes the reference scenario taken into account, which details the different components while moving from a general to a particular perspective and which ultimately focuses on the architecture taken into account in the short term approach (see Figure 3-10). In this light, D4.1 describes the architecture of FireWatch, which is a system that, through its smoke detection capabilities, allows very early fire recognition in large open areas. It is responsible for the collection of data from in-situ sensors, which can be transferred to the Service Platform over the satellite link provided through the F-SIM standard. The F-SIM protocol, in turn, copes perfectly with the bursty transmission typical for emergency alert notification, and allows for very low Packet Error Rate against an affordable implementation complexity. D4.1 describes in detail how the F-SIM physical layer has been adapted based on S-MIM, and accounts for the F-SIM link layer and the protocol’s performance. In the second project period, PHAROS has implemented the data interface between the FireWatch system and the prototype satellite terminal.
4.1.3.2. GNSS-supported alert message delivery
With regard to the distribution of alert messages towards the population at risk, the PHAROS objectives are to document the interface between the service platform, the alert gateway and the two channels chosen in this project, namely, cell broadcast and GNSS, and adapt the alerting gateway to provide pre-operational services.
During this activity, the technical requirements for the alerting module have been identified based on the user and system requirements identified and documented in D2.4 to D2.7. The specification of each component (Alerting Gateway, Cell broadcast and GNSS) of the system has been described and the necessary architecture to support these components has been designed, implemented and tested. These activities have been reported in D4.3 and D4.4.
The Alerting Gateway (AG) design has been based on the Global Alerting Gateway (GAG) which has been developed in the framework of the EU FP7 Alert4All project. Some amendments have been performed in terms of design:
• Creation of alert messages in two different ways: using the GUI or as an outcome from the DSS.
• Adaptation of the interfaces towards other system modules.
• Providing suitable interfaces with different alerting channels.
• Adaptation to the wildfire use case.
The main feature of the AG is to send alert messages to the population via various alerting channels. The first selected channel is cell-broadcast enabling to use the telecom network to send geo-localised messages. An analysis of the cell-broadcast system has been performed and used to confirm that cell broadcast messaging has a number of features that make it particularly appropriate for emergency purposes:
• Large penetration of the population (resident in mobile network infrastructures and in mobile phone terminals)
• Not affected by traffic load
• It is geo-scalable and geo-specific: can reach millions of people across continents within a short time
A design for sending messages using the existing cell broadcast system has been described in D4.3. A test lab version of a fully deployed alert Cell Broadcast messaging service has been implemented using the OpenBTS software and a GNU radio setup (D4.4).
The second selected channel is GNSS enabling to send alert messages via the SBAS payload of EGNOS satellites to target a wider part of the population and take advantage of the resiliency of satellite technologies in case of disaster.
D4.3 describes the architecture of the EGNOS system and explains how alert messages can be sent via this medium. The European Space Agency (ESA) MLU testbed had initially been selected to test the sending of messages via the EGNOS system but it has been de-commissioned by ESA and therefore it could not be used anymore. Several solutions have been considered. The main solution envisaged is to use the Artemis payload. Artemis is a satellite owned by Avanti (who is a project partner) equipped with an EGNOS payload. This payload was not in use at the start of the project but Avanti re-activated it in the course of the UK Space Agency project SBAS Africa. It has been possible to use the EGNOS payload to perform the sending of an A4A message. The sending of alert messages using Galileo satellites has also been analysed and documented in D4.4.
4.1.4. Integrated service platform:
4.1.4.1. Service platform architecture, workflows and interfaces:
As a starting point, the general system requirements laid out in WP 2 were used to derive the specific technical requirements for the Service Platform (SP). Functional requirements (e.g. access control, user management, configuration, access to historical data, monitoring, geospatial data storage and incident management) as well as non-functional requirements (e.g. robustness and resilience, stability, expandability and virtualisation) were specified. In addition, interfacing requirements were specified, covering the communication of the SP with the user front-end (GUI), secondary user services, Earth Observation (EO) data sources, simulation services, Decision Support Systems, alerting services as well as third-party external services, such as weather providers.
Using the technical requirements, Task 5.1 specified 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, as shown in Figure 3-11, were identified to be the following:
• A Data repository, for geospatial as well as 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.
• An Access Control layer for managing permissions related to the stored content as well as the services.
Last, the SP also included management-related services, which allow the supervision of its operation and the configuration of the individual components.
Following the specification phase, the core components of the SP were developed, such as the data repository (for both spatial and generic data) as well as interfaces for data communication. SP 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.
In parallel to the design and implementation of the SP architecture, and using the requirements and exploiting common architectural concepts found in mature WF engine frameworks, the architecture of the PHAROS workflow (WF) Engine was defined and implemented, consisting of the following key components:
• A Management front-end for management and configuration;
• A Workflow storage repository for storing registered workflows, defined in WS-BPEL (Web Service Business Process Execution Language);
• A BPEL compiler, for compiling workflows into a machine-readable format;
• A BPEL Engine Runtime, for executing the workflows and managing concurrent workflow instances;
• A Database Management System (DBMS) subsystem for storing persistent data, mostly associated with workflow instance information;
• An Integration Layer and a Web Services Engine for facilitating communication with orchestrated services via WS protocols.
Also, a mechanism for asynchronous communication based on callbacks (and/or webhooks) was established, so that workflow execution can continue while at the same time waiting for a response from a module/subsystem
In addition to the implementation of the workflow engine, an initial set of PHAROS workflows have been specified and implemented. The four workflows applicable to the PHAROS system are:
• WF #1 – Event handling and Creation: Defines the process of inspecting incoming events and mapping them to incidents;
• WF #2 – On-demand Simulation/Recommendation: Defines the process of invoking a simulation and handling the Decision Support System (DSS) recommendation;
• WF #3 – Alerting: Defines the process of creating, confirming and configuring an alert;
• WF #4 – Periodic Risk Assessment: Defines the process of producing and presenting risk assessments on a periodic basis.
The PHAROS workflow concept has been implemented using open technologies and standards not only for the definition and the description of the workflows (where WS-BPEL is adopted) but also for the design and development of the Workflow Engine.
Finally, PHAROS has defined and implemented the internal interfaces for the communication between PHAROS components for data exchange, service invocation and signalling, as well as the external services (Service Gateway) to be offered to secondary users. Since the PHAROS system has been designed to mostly rely on Web-based communication for the exchange of information among modules, the implemented interfaces are in the form of web services exposed by the PHAROS modules. In summary, the services which were specified and implemented are:
• Service Platform services: Web Map Service (WMS), Web Coverage Service (WCS), Web Feature Service (WFS), Coverage/Feature publication, Events and Observations, Asset Management, Weather Data and MODIS Service Proxy.
• Simulation Services: Invoke Simulation, Simulation Results (using asynchronous communications).
• EO Services: MODIS Hotspots, EO Imagery.
• DSS Services: Observations Retrieve/Create/Update/Delete, Incident Retrieve/Create/Update, Situation Retrieve/Update, Proposals Retrieve/Create/Update Results (using asynchronous communications).
• Alerting Gateway Services: Message Select, Message Reset, Alert Dispatch, Channel Refresh and Message Filter.
• First responder data: store and retrieve position as well as multimedia content from first responders on the field.
• Secondary User Services: WMS/ WCS/ WFS (proxied SP services) and simulation invocation.
Also a data export feature was added to the SP, via which users can download products (in KML and other formats) via the GUI.
Last but not least, a dedicated web portal, based on CMS (Content Management System) technologies, was built for the secondary users. A mechanism was implemented in the SP in order to automatically publish data to the secondary users’ portal. The services and interfaces described above were validated, tested and documented in D5.3 and D5.6 (updates).
4.1.4.2. User interfaces, visualisation and mobile clients:
The main objective within this topic has been to design the graphical user interface (GUI) to access the system (including the access through mobile devices), the GUI for the mobile application receiving alert messages and the web portal to be subsequently implemented in order to enable PHAROS users to access all the designed services/features.
The Graphical User Interface (GUI) of the web application enables end users to interact with the whole PHAROS platform. A mock-up has been designed prior to the implementation of the application to decide how to provide the required information and services to the user. It has also been decided to enhance the mobile application used by first responders on the field to access the portal to include new features like sending of GPS location to the central platform and including chat features.
The technical aspects of the web application have been documented in D5.4. The web application is built on top of JavaScript libraries and a lightweight Java back-end webserver. The client-side heavily uses AngularJS and jQuery frameworks, beside the Leaflet and DataTables JavaScript technologies.
The PHAROS GUI elements that have been implemented are:
• AngularJS frame to contain the various components of the application.
• Login functionality.
• Multi-language feature (English and Spanish).
• Cartographic display.
• Weather data.
• Real-time Earth Observation imagery (covering Spain).
• Incident view including an events timeline (based on Highcharts JS): the timeline is interactive, zoomable, scrollable and the events are clickable.
• UI for sending alerts (the user can draw on a map, choose values based on the Common Alerting Protocol specifications – CAP ...)
• Notification systems
• DSS proposals display
• Display of simulation results
• User management
• Settings panels
The style and usability of the application have been enhanced to provide the user with a more intuitive and user-friendly experience. In terms of back end, all the requests are going directly to the SP via a VPN (virtual private network) connection. The web portal has been heavily tested during the integration phase and has been updated/enhanced taking into account the feedback from the users.
4.1.5. Pilot demonstration and user evaluation:
Apart from the scientific/technical developments PHAROS has designed, prepared and deployed a pilot demonstration using an operational scenario: forest fires. The demonstration has been planned in two parts or Phases:
• PHASE 1, has focused on the validation of the PHAROS system with the main purpose of gathering feedback from end-users. This phase took place in Solsona (Spain) between the 2nd and the 4th of March 2016. Three prescribed burns have been organized and executed during this phase. The different parts of the PHAROS system have been evaluated. Although weather conditions could have been the main limitations for the execution of the prescribed burns, the appointed firefighters could finally execute the burns. During this phase, around 100 stakeholders from different organizations have attended the presentation and 25 of them could try during some hours the platform.
• PHASE 2, also included a PHAROS system validation and dissemination event. This phase took place in Oberpfaffenhofen (Germany) on the 12th of May 2016. In this dissemination event the outputs and results from the measurements taken during Phase 1 have been presented as they could not be processed in real time. The end users invited to the event could see the PHAROS platform in the last stages of development and give further feedback to the consortium partners for the future steps of the project and also for future projects.
In order to prepare the PHAROS demonstration, aerial images have been acquired and integrated within the service platform in order to support end users. The work performed within this task has been focused on the preparation of the image acquisition (selection of sensors and data to be acquired, definition of the products to be provided, definition of the architecture to be implemented, preparation of the logistics for image acquisition and test of the corresponding modules). The sensors and aerial means used were on one hand, the 4K system and the transmission of real time data to the control room that allowed primary users to perform a better monitoring of the situation, validating in real time, the correctness of the data available in the PHAROS platform. On the other hand, the generated thermal data was gathered during the pilot demonstration and to be provided after post-processing it, allows a better understanding of the fire dynamics and a deeper analysis of the fire evolution.
The overall PHAROS demonstration has been a successful event that accomplished the project objectives. The participation of a large number of end users (more than 110 participants) in the two phases of the demonstration has allowed carrying out a good evaluation of the platform from an end-user perspective, which is a fundamental step to validate the platform, its products and services. This wide range of participants has had a positive impact in the provision of an accurate feedback, key to support further development of the platform. Moreover, the participation of stakeholders in both Phases has attracted the media and has been an opportunity to disseminate the project to local and regional media (10 representatives from TV, radio and press participated in the demonstration).
Finally, PHAROS has analysed and processed the feedback given by a selected group of end uses that have participated in the Pilot demonstration. The feedback gathered during the pilot demonstration (Phase 1) revealed how the end-users held a very positive opinion of the platform and the different components that they were able to test during the demonstration. The end-users described the PHAROS platform as a spine of the emergency system. The novel component of this platform is that it integrates an emergency prevention and prediction system and a simulation and evaluation system. Altogether, the different components of the platform go further than the current emergency management systems and will allow a better decision making before and during the early stages of the emergency allowing preventing natural and humanitarian disasters.
In general, minor improvements were suggested to increase the effectiveness of the platform to manage disaster emergencies. The highly valuable feedback given by the end-users has been translated into recommendations for the target system, and constitutes a basis to advance in the development and implementation of the PHAROS platform. The PHAROS system also has been seen as a major opportunity to provide a standardized emergency response alert system, in collaboration with mobile network operators, manufacturers and governmental agencies. This will allow the possibility to reach the general population via a pre-installed mobile application and via cell broadcast.
Potential Impact:
PHAROS has designed, implemented, tested and demonstrated in an operational environment (forest fire scenario) an integrative multi-hazard management platform to improve the effectiveness of emergency management. The technical pillars on which the platform is based are:
• Integration of multiple data sources for risk and hazard detection and monitoring (satellite, aerial and terrestrial earth observation, in-situ sensors, human-collected data and external services);
• Information fusion techniques to achieve an improved situational awareness to help primary users to keep an updated overview of the emergency situation and allow an efficient management through consistent monitoring;
• Flexible simulation tools to foresee the expected evolution of the risk or hazard according to the available information and allowing the possibility of manually introducing information or updating the inputs to be used by the simulator according to the real evolution of the risk or hazard;
• Integrated tools for advanced decision support which ease the decision making processes providing information about the areas, infrastructure or relevant elements which might be affected in the near future, according to the available information and the forecast of the corresponding simulation tools.
• Efficient warning of the population at risk using consistent information dissemination over multiple channels and, particularly, cell broadcast and satellite navigation.
Therefore, the corresponding tools on which the system success is based have been developed and integrated beyond the initial state of the art, as described in the previous section, consolidating the project’s scientific impact. Moreover, the integration of the different tools allows exploiting the synergies existing between them, thus providing a service chain not existing until now and increasing the added value of the overall system.
PHAROS has brought together experts from a wide range of disciplines, including end users of the system (civil protection authorities, police departments and fire brigades), international emergency organisations (The International Emergency Management Society, TIEMS), scientist, engineers and industrial partnerships. This inter-disciplinary participation has been achieved by different means: (i) first of all, thanks to the heterogeneity of the consortium, including partners from the research community, industrial partners (including SMEs) and representatives of the end users; (ii) by establishing an Advisory Board formed by experts on the field of emergency management and belonging to different European organisations, thus providing information and feedback taking into account different geographical and social constraints; (iii) by organising periodical workshops with the Advisory Board and an extended team of end users to track the project development and (iv) by participating in a large number of dissemination events, which provided the opportunity to present the project results and gather feedback from the scientific and emergency management community. This has clearly strengthened the overall PHAROS approach in two main aspects: on one hand, it has allowed the project consortium to design and implement the system tailored to the user needs identified in the different interactions with the end user community and on the other hand, this close contact has allowed an efficient dissemination of the project results. Both elements shall have a positive impact in increasing the acceptance of the system at European level.
The PHAROS system has been developed in a modular fashion to be able to adapt it to the particularities of the different European countries and regions and to the structures of the different organisations in charge of emergency management. The modular and flexible architecture used by PHAROS, centralised in the service platform, allows adapting and applying the PHAROS concept in a wide range of scenarios, since the system provides functional and operational scalability. From a functional point of view, the system can be adapted to different types of crisis by integrating the corresponding sensors and processing tools in a modular fashion, thanks to the use of standardised interfaces. This would allow a high impact at European level, since the hazards typically affecting the different European areas present different characteristics which have to be taken into account. PHAROS allows a simple adaptation to the corresponding hazards by means of adding or removing sensors (data sources) to/from the system and integrating the corresponding processing modules. This way, the same system can be used in several European regions, allowing also a consistent exchange of information between regions/countries. This functional scalability, allowing PHAROS to address multi-hazard events is clearly a relevant asset when dealing with cascading effects in situations when one hazard triggering subsequent ones. From an operational point of view, the implemented web-service approach allows the system to be tailored to different operational architectures thanks to a flexible user management. This way, entities using different types of hierarchies and organisational structures can use the same system and define their own profiles and roles to adapt the user privileges to the corresponding organisation. In addition to that, the system can be physically deployed using several approaches (centralised, distributed, partly distributed), increasing robustness of the system with regard to natural and man-made hazards by means of installing redundant elements in several locations and enabling an efficient use of the resources by allowing sharing the resources among different organisations by means of an intelligent allocation of access rights.
Improved situation assessment through all phases of the emergency management cycle
The combined use of a wide range of data sources (satellite and aerial earth observation, in-situ sensors, data provided by citizens and first responders) and the fusion of the information in a consistent manner allow end users to keep a solid and up-to-date picture of the situation during all phases of the emergency management cycle. The continuous monitoring allows early detection not only of the existing hazards, but also of the relevant variables which could derive in a given risk. Therefore, measures can be applied already during the mitigation phase. Moreover, the project has defined and implemented a new data format to store situational information and share it with other emergency management organisations which might be involved. This way, information can be shared among authorities in an easy and pre-defined manner in cases where several organisations with different responsibilities are participating in the emergency response, in cross-border emergencies and in emergencies which escalate to affect several jurisdictional areas at a given moment. In order to increase the acceptance of the proposed format and thus, booster the impact of the proposed solutions, the proposed format (sCOP, shared Common Operational Picture) is based on the TSO standard. Finally, the system allows the relevant information to be accessed from de-centralised locations thanks to the web-based access.
Enhanced decision support tools fostering emergency planning
The proposed PHAROS solution will have a positive impact not only during emergency response, making it easier to end users to take operational decisions by means of proposals provided by the system (currently proposals provide notifications about the relevant elements prone to be affected by the hazard and the corresponding alerting strategies to be followed), but also fostering the definition and implementation of alerting and response plans to be used in the different affected regions. These plans shall be the basis of the proposals provided by the decision support services and shall be adapted in a case by case fashion (learning tool).
Effective communication towards the population at risk and first responders on the field
PHAROS can have a high impact with regard to the communication strategies used to communicate with citizens at risk (alert recipients) and first responders on the field. On one hand, PHAROS has further developed the alerting solutions envisioned in the Alert4All project in order to integrate them in the overall service platform (thus benefitting from the synergies with the other tools) and adding new communication channels, such as Cell broadcast and GNSS (satellite navigation systems). The added value of these channels is that they make use of standard commercial devices (smartphones, cell phones, navigation devices, etc.) to receive the transmitted alert messages, therefore achieving a high message penetration and improving the efficiency of their distribution.
With regards to communication with the first responders on the field, they are allowed to access all relevant information they need from the central platform since this is relevant for them to take the corresponding decisions. This is particularly important to achieve a big impact of the proposed solution, since many times, decisions are taken on the operations field and not in the control centres. Furthermore, first responders can communicate with the control centre using their dedicated devices, which are equipped with the PHAROS application, which includes a “chat” feature to maintain secured communications.
Dissemination
The project impact has been re-enforced by carrying out a detailed dissemination strategy, whose main objectives have been to disseminate the project outcomes to relevant stakeholders and to develop an exploitation plan, taking into account two of the three main pillars of the dissemination strategy depicted in Figure 3-12: dissemination to relevant stakeholders and liaisons with other relevant initiatives and projects. In the former group, dissemination activities, comprising among others, publications and participation to conferences, meetings with stakeholders to present the project, meetings with the Advisory Board, have been focused on presenting the project overall approach and results to three different audience groups: (i) the general public, as beneficiaries of the overall system and in order to increase the system acceptance; (ii) the end user community, in order to benefit from their feedback to improve the system and tackle their requirements, as well as increasing the acceptance and (iii) the scientific community, in order to disseminate the different technical and scientific results provided by the technical WPs.
Figure 3-13 shows how the interactions among the different dissemination strategy components and the targeted or consequentially reached audience by each of the activities, indicating the intensity of each interaction by the width of the arrows. It shall be noted that through the dissemination activities carried out (or planned to be carried out), contacts with relevant other research projects and institutional initiatives have allowed closing liaisons. Furthermore, even if not specifically targeted, the general public (with no end user or scientific background) is reached by means of some dissemination activities, e.g. web, flyers, newsletters and new media. A detailed list of publications and dissemination activities in provided in Section 4.2.
Cooperation with other projects
During the first reporting period, dissemination activities focused on the first two groups (End users and general public), while during the second period a wider audience has been targeted to achieve dissemination of the project results to all the targeted groups in Figure 3 12. In the second reporting period, PHAROS has been very active in monitoring the relevant related activities and initiatives which are taking place at the time being in order to identify synergies with other projects and benefit from them. Among the relevant initiatives and partnerships, the following can be highlighted:
• Project VABENE++: VABENE++ is a German project (DLR) where powerful tools are being developed to aid public offices and organisations with security responsibilities as well as traffic authorities when dealing with disasters and large public events. The goal is to efficiently manage the required rescue logistics and the nearby traffic flow even under extreme conditions, thereby enabling response teams to rapidly reach the locations where they are needed. Scientists from various DLR institutes collaborate in this research project with the support of DLR’s Research Flight Facilities. The Chair of Remote Sensing Technology at Munich Technical University (TU München) and the Department of Geoinformatics and Remote Sensing at Osnabrück University also participate in VABENE++. Research focuses on areas such as simulation and large-scale traffic modelling, aerial traffic monitoring, traffic risk assessment, data fusion, data management, and further developing Web technologies in a GIS environment.
A number of topics addressed in VABENE++ are of complementary relevance to PHAROS, addressing the risks related to traffic in emergency and large events situations, with sensors integrated in an aerial platform.
The provision of real time aerial images to be received in the control centre has been performed during the pilot demonstration. This cooperation has supported end users with close to real time data, increasing the added value of the project and allowing the provision of a service to replace the initially planned satellite imagery to be provided by BiROS.
• EC FP7 - PREFER: The PREFER project is an FP7 SPACE project that was flagged by the Project Officer as relevant for PHAROS during the Kick-Off meeting. The main objective of PREFER is to set up space-based end-to-end information services to support prevention, preparedness and recovery phases of the forest fire emergency cycle in the EU Mediterranean Region. At first, the project managers of both projects had a teleconference. This drove the participation of the PHAROS project manager to the next PREFER progress meeting that took place on June 6, 2014. During this meeting, the PHAROS project manager could attend presentations from the PREFER team and also present the objectives and scope of the PHAROS project to the PREFER team. Additionally, representatives of both projects have participated together in several dissemination events, such as the European Space Solutions Conference and the Copernicus Emergency Projects Workshop in December 2014 and the LAMPRE Final Dissemination Event in February 2015. Further exchange of project information has been carried out to analyse the possibility of integrating PREFER products within the PHAROS service platform. As an outcome of this cooperation, the PHAROS platform is able to integrate the PREFER-generated products.
• Project FRISK-GO: This project is being implemented by the European Forest Institute and investigates a roadmap for a fully operational European risk facility for different types of disturbances. During the project, several workshops are planned. Each workshop focuses on one type of disturbance; hence the participants to each workshop are experts on the disturbance type, but also civil protection and response forces. The PHAROS project manager participated to the first FRISK-GO workshop, which focused on the forest fire scenario. The participants were experts in forestry and fire fighting from several European countries. During the workshop, the PHAROS project manager attended and participated to expert discussions on preparedness and mitigation for forest fire, visiting in-situ several areas that were affected by big forest fires with different impact range. The project manager had the opportunity to present the PHAROS project to the participants, enlarging significantly the visibility of the project towards European stakeholders and placing PHAROS as potential platform for the targeted risk facility by FRISK-GO.
• EC FP7 - LAMPRE: The EC FP7 LAMPRE (Landslide Modelling and tools for vulnerability assessment preparedness and recovery management) project aims at executing innovative research and technological developments to increase GMES limited operational capacity to cope with landslide events. The first contact with LAMPRE was established during the European Space Solutions Conference in June 2014. After this first contact, several teleconferences have been hold between LAMPRE and PHAROS to identify the possible synergies between the projects as well as between PHAROS and other Copernicus Emergency Projects. This cooperation resulted in the consideration of landslides as use case for the multi-hazard analysis carried out in PHAROS Task 2.5. Additionally, LAMPRE provides products related to landslides that could be integrated within the PHAROS platform, in case landslides were tackled and considering that landslides can be a consequence of land erosion due to wildfires. Therefore, the synergies of the chain of events wildfire-erosion-landslides could be exploited in a multi-hazard platform like PHAROS to cover the complete scenario. Finally, LAMPRE has performed an analysis of the synergies among the Copernicus Emergency projects and identified further synergies between PHAROS and the PREFER project. The synergies between PHAROS and LAMPRE have been also documented in the LAMPRE dissemination deliverable (D8.2).
• Initiative for the integration of persons with disabilities during the emergency management cycle: As an initiative from the Latvian presidency of the Council of the European Union during the first semester of 2015, a “Workshop on the needs of persons with disabilities throughout the emergency management cycle” was organised in Riga on the 12th-13th of January. Participants of the workshop were representatives from the Civil Protection authorities from the member states, representatives of the Latvian government and the European Commission, representatives from emergency management initiatives which include solutions for people with disabilities, as well as representatives of several associations representing people with disabilities. Within this context, PHAROS was invited to participate in the panel session titled “Innovative solutions and technologies in civil protection for persons with disabilities” due to the features that the receiver application is intended to provide in order to allow the use of several modes for the presentation of alert messages in order to tackle the needs of people with disabilities. The final document of the workshop is intended to be used at European level to derive the guidelines of policies to be fostered with regards to fulfilling the needs of people with disabilities during the emergency management cycle.
Standardisation and interoperability
Standardisation activities help increasing the impact of project results, since they can help the developed technologies to be implemented in mass market devices. In order to achieve this objective, the Consortium has specified the objectives related to interoperability and standardisation and elaborated a detailed strategy in order to achieve them.
The overall mission of the PHAROS interoperability and standardisation strategy, depicted in Figure 3-14, is to enhance system interoperability and, therefore, system acceptance. To fulfil this mission, the PHAROS approach is based on three main objectives, which are:
• Fostering and easing system functional scalability. The strategy to achieve this objective consists of (i) the identification of the relevant standards related to the interfaces towards external data and service providers which act as data sources to the system and (ii) the implementation of the identified standard-compliant interfaces. Therefore, by means of implementing standard interfaces whenever possible, the system provides the necessary mechanisms to be extended with new data sources and tools in an easy manner, fostering system functional scalability.
• Fostering interoperability with already existing systems. Interoperability with already existing systems increases system acceptance, allowing smoother transition to the new system and/or partial adoption of the provided tools. The strategy to achieve this objective consists of (i) the identification of the relevant standards related to data and metadata formats and communication protocols to allow exporting/importing information to/from external systems; (ii) the adoption of the identified standards within the PHAROS system, when possible; (iii) the implementation of export functions using the identified standards.
• Contributing to standardisation bodies. Solutions designed and implemented within the PHAROS system development activities shall be disseminated in the relevant standardization bodies in order to contribute with relevant items prone to be standardised, ensuring interoperability with future systems. The strategy to achieve this objective consists of (i) the identification of PHAROS developments which can be targeted as new standards or extensions to already existing standards; (ii) performance of the necessary steps to foster the standardisation of the identified items.
In the following, an outlook of the planned standardisation activities to be carried out after project completion is presented. The activities included in this section are focused on the standardisation of the PHAROS outcome and therefore, do not take into account activities related to the application of already existing standards in the design and implementation of the PHAROS system.
• Further contribution to the SC-EMTEL technical report TR 103 273 (Recommendations for public warning making use of pre-defined libraries).
• Foster the proposal for the creation of a TS within SC-EMTEL to contain the normative aspects included in TR 103 273.
• Prepare and support another STF proposal to develop syntax rules for alerting libraries in several languages.
• Further contribution to the ETSI TC-HF for developing the recommendations to be included in TR 103 335 Human Factor (HF); Guidelines for accessibility of warning messages.
• Prepare and support another STF proposal to create an ETSI specification for standardising the A4A protocol.
• Monitor the different activities in ISO/TC 292 (especially WG 3) regarding the standardisation of EMSI (TSO) and, if possible, support a national standardisation organisation (probably DIN) to request an ISO/TR 22351 update procedure during which the sCOP extensions developed in PHAROS can be contributed to the standardisation process.
Service Roll out
The service roll-out is dependent on the consumer technology readiness (implementation of receiver applications in mass market devices), the willingness of civil protection agencies to pay for the service (several provision modalities have been foreseen) and the creation of a service provider (or adoption of the service by an existing service provider). The contacts to the different stakeholders have already started during the project and access to the PHAROS services during a testing period have been agreed with the Catalan Fire Brigades. Regarding the communication part for the distributing information and alerts to the population, service level agreements need to be set up with intermediate providers (e.g. satellite broadcasters, terrestrial broadcasters, operators of EGNOS, mobile network operators, etc.) to ensure the message delivery and establish the conditions.
List of Websites:
Website: http://www.pharos-fp7.eu/
Contact details:
Mr. Javier Mulero Chaves
PHAROS Project Manager
DLR - German Aerospace Center
Member of the Helmholtz Association
Institute of Communications and Navigation
Oberpfaffenhofen
82234 Weßling
Germany
Telephone: + 49 8153 28-3815
Telefax: +49 8153 28-2844
E-Mail: Javier.MuleroChaves@dlr.de
Internet: http//www.dlr.de/kn
