TELEIOS FP7-257662. Deliverable 7.1. Requirements specification for the real-time fire monitoring application. and. Consortium members 30/11/2010

TELEIOS FP7-257662 Deliverable 7.1 Requirements specification for the real-time fire monitoring application Charalabos (Haris) Kontoes, Ioannis Papoutsis and Dimitrios Michail Status: final and Consortium members 30/11/2010 Scheduled Delivery Date: 30 November 2010

Executive Summary The main purpose of this document is to specify functional requirements as well as the service requirements in terms of accuracy, reliability and usage, for the development of a fully automatic and advanced technological solution for real-time hot spot and active fire front detection, and enhanced estimation of burnt areas on a daily basis during the fire season. The issue of fire monitoring and management in Europe in general and Greece in particular is considered to be of paramount importance. Almost every summer massive forest fires break out in several areas across Greece, leaving behind severe destructions in forested and agricultural lands, infrastructure and private property, and mostly many losses of human lives. In this use case, we would like to demonstrate that the TELEIOS infrastructure can be used to develop technological solutions for (i) real time hot spot and active front detection, and (ii) burnt area assessments. Technological solutions to both of these case studies require integration of multiple, heterogeneous data sources with data of varying quality. Aiming at designing a system capable of accommodating these services, it is crucial to identify the functional and non-functional requirements of such a platform. Functional requirements describe what a system should do, as envisaged by a user for solving a problem that she faces. The requirements of the TELEIOS Use Case II are primarily defined by use cases that describe a concrete, functionally self-contained subprocess. The entirety of the use cases then defines the system behavior. As a first step, the various user roles that will utilize the system either directly or indirectly have been identified. These roles are the end user, the Earth Observation Scientist, the Service Provider, the Intermediate Service Provider, and the Administrator. Then, following the TELEIOS workshop held in Frascati their respective user stories have been collected and used to map the Use Cases and their processes. Non-functional requirements were then decided with respect to the performance, reliability, interface, security, storage and persistence, and documentation requirements. Finally the acceptance criteria, which specify the criteria to be fulfilled upon service delivery in order to meet the requirements, were thoroughly specified in a measurable way. From a contractual point of view, these acceptance criteria describe the conditions for the decision as to whether the final product fulfills the requirements or not. Acceptance criteria referred to both functional and non-functional requirements. i

Document Information Contract Number FP7-257662 Acronym TELEIOS Full title Project URL EU Project officer Virtual Observatory Infrastructure for Earth Observation Data http://www.earthobservatory.eu/ Francesco Barbato Deliverable Number D7.1 Name Requirements specification for the real-time fire monitoring application Task Number T7.1 Name Capturing the requirements for a reliable real-time fire monitoring application Work package Number WP7 Date of delivery Contractual M3 (Nov.2010) Actual 30 Nov. 2010 Status Nature Distribution Type Authoring Partner QA Partner Contact Person draft final Prototype Report Public Restricted Consortium National Observatory of Athens (NOA) Fraunhofer IGD Dr Charalabos (Haris) Kontoes Email kontoes@space.noa.gr Phone +30-2108109186 Fax +30-2106138343 ii

Project Information This document is part of a research project funded by the IST Programme of the Commission of the European Communities as project number FP7-257662. The Beneficiaries in this project are: Partner Acronym Contact National and Kapodistrian University of Athens Department of Informatics and Telecommunications (Coordinator) Fraunhofer Institute for Computer Graphics Research German Aerospace Center The Remote Sensing Technology Institute Photogrammetry and Image Analysis Department Image Analysis Team NKUA Fraunhofer DLR Prof. Manolis Koubarakis National and Kapodistrian University of Athens Dept. of Informatics and Telecommunications Panepistimiopolis, Ilissia, GR-15784 Athens, Greece Email: koubarak@di.uoa.gr Tel: +30 210 7275213, Fax: +30 210 7275214 MSc. Thorsten Reitz Fraunhofer Institute for Computer Graphics Research Fraunhofer Strasse 5, D-64283 Darmstadt, Germany Email: thorsten.reitz@igd.fraunhofer.de Tel: +49 6151 155 416, Fax: +49 6151 155 444 Prof. Mihai Datcu German Aerospace Center The Remote Sensing Technology Institute Oberpfaffenhofen, D-82234 Wessling, Germany Email: mihai.datcu@dlr.de Tel: +49 8153 28 1388, Fax: +49 8153 28 1444 Stichting Centrum voor Wiskunde en Informatica Database Architecture Group National Observatory of Athens Institute for Space Applications and Remote Sensing Advanced Computer Systems A.C.S S.p.A CWI NOA ACS Prof. Martin Kersten Stichting Centrum voor Wiskunde en Informatica P.O. Box 94097, NL-1090 GB Amsterdam, Netherlands Email: martin.kersten@cwi.nl Tel: +31 20 5924066, Fax: +31 20 5924199 Dr. Charalambos Kontoes National Observatory of Athens Institute for Space Applications and Remote Sensing Vas. Pavlou & I. Metaxa, Penteli, GR 152 36 Athens, Greece Email: kontoes@space.noa.gr Tel: +30 210 8109186, Fax: +30 210 6138343 Mr. Ugo Di Giammatteo Advanced Computer Systems A.C.S S.p.A Via Della Bufalotta 378, RM-00139 Rome, Italy Email: udig@acsys.it Tel: +39 06 87090944, Fax: +39 06 87201502 iii

Table of Contents 1. Introduction... 1 1.1. Purpose of this Document... 1 1.2. Structure of this document... 1 2. Initial Situation and Objectives... 2 3. Functional Requirements... 3 3.1. Data and products... 3 3.2. Actors / User Roles... 5 3.3. User Stories... 5 3.4. Use Cases... 8 3.4.1. Use Cases Overview... 8 3.4.2. Use cases for SERVICE_PROVIDER... 9 3.4.3. Use Case for EO_SCIENTIST... 17 3.4.4. Use Cases for END_USER... 17 3.4.5. Use Cases for INTERMEDIATE_SERVICE_PROVIDER... 20 3.4.6. Use Cases for ADMINISTRATOR... 22 4. Non-Functional Requirements... 23 4.1. Performance Requirements... 23 4.2. Reliability Requirements... 23 4.3. Interface Requirements... 24 4.4. Security Requirements... 24 4.5. Storage and Persistence Requirements... 25 4.6. Documentation Requirements... 25 5. Acceptance Criteria... 26 6. List of Abbreviations... 29 7. References... 29 8. List of Figures... 29 9. List of Tables... 29 iv

1. Introduction 1.1. Purpose of this Document The main purpose of this document is to specify the service and platform/system requirements in terms of accuracy, reliability and usage for the development of a fully automatic and advanced technological solution for enhanced hot spot and active fire front detection on a five-fifteen minutes basis, and enhanced estimation of burnt areas on a daily basis during the fire season. The methodology adopted for the gathering and structuring of the requirements is thoroughly presented in D8.1 [1]. Within TELEIOS, the National Observatory of Athens (NOA) in collaboration with stakeholders (civil protection, environmental and governmental agencies in Greece like HMOA/DGF, FRI/NAGREF, HCBW and GSCP), taking into account the collected feedback of past experiences and the remarks gathered during the TELEIOS workshop [1] from the project s partners and the end user community, attempts to draw the technical and procedural baseline for a state-of-the-art system for fire monitoring. The information provided in this document will be the basis for the development of the TELEIOS infrastructure (system architecture, functionalities and relative interfaces) to accommodate Use Case II, Real-time fire monitoring based on continuous acquisitions of EO images and geospatial data described in the DoW [2]. This deliverable follows the V-Model template and most sections contain (in italics) a short description of what the section is about, derived from the V-Model requirements template. 1.2. Structure of this document The rest of the document is organized as follows. Chapter 2 provides an introduction to Use Case II, describes briefly the state-of-the-art in fire monitoring and presents the main problems encountered with current systems. Chapter 3 defines the functional requirements of the TELEIOS infrastructure, taking into account the user roles of those that will use the TELEIOS system for fire monitoring and their respective user stories. Chapter 4 delivers the non-functional requirements of the TELEIOS infrastructure that contribute decisively to the applicability of the system, and define quality, safety, security and performance requirements. Chapter 5 contains the envisaged overall system architecture from the user perspective. Chapter 6 sets the acceptance criteria to be fulfilled by the TELEIOS infrastructure to meet the requirements. Chapters 7, 8 and 9 are dedicated to the list of abbreviations, the references and the list of figures respectively of the present document. 1

2. Initial Situation and Objectives The issue of fire monitoring and management in Europe in general and Greece in particular is considered to be of paramount importance. Almost every summer massive forest fires break out in several areas across Greece, leaving behind severe destructions in forested and agricultural lands, infrastructure and private property, and many losses of human lives. In this use case, we would like to demonstrate that the TELEIOS infrastructure can be used to develop technological solutions for (i) real time hot spot and active front detection, and (ii) burnt area assessments. Technological solutions to both of these case studies require integration of multiple, heterogeneous data sources with data of varying quality. European initiatives in the area of Earth Observation like GMES [3] have taken an active role in the area of fire monitoring and management in Europe, and supported the development of relevant European pre-operational infrastructures through projects such as linker and SAFER [4] supporting the implementation of an operational GMES service in the field of emergency management. A number of EO data handling organisations and service providers in GMES ERS projects (e.g. RISK-EOS, SAFER), offer near real-time fire monitoring services, which are based on the use of MSG/SEVIRI 1 and MODIS 2 acquisitions. These organisations receive and process automatically all collected raw images every five or fifteen minutes, and deliver qualified geo-referenced raster and vector fire products worldwide. However, the reliable application and transferability of these services to any geographic area, present certain limitations. We acknowledge the need for improvements in the existing processing chains in order to avoid a large number of false alarms. The problem of false alarm is well known and has been also reported in the validation of SAFER products [5], namely FMM-1 (hot spots MSG/SEVIRI) and FMM-2 (Fire Area Mapping/MODIS), as well as in several precursor activities like RISK-EOS. These problems relate to several factors, e.g., image miss-registrations, the algorithmic inadequacies, unresolved inconsistencies in fire detection in relevance to observation time and location, and also unresolved inconsistencies in relevance to other available geospatial information and site specific knowledge. In this respect Service Providers like NOA and individual end users (civil protection agencies, regional authorities, decision makers, etc.) could potentially benefit from TELEIOS infrastructure and processing tools. In the following we summarise some of the expected improvements: 1 MSG stands for the Meteosat Second Generation series of geostationary meteorological satellites, whereas SEVIRI (Spinning Enhanced Visible and Infrared Imager) is the onboard main optical sensor of MSG. 2 MODIS (Moderate-resolution Imaging Spectroradiometer) is the scientific instrument onboard the Terra and Aqua satellites, which are in a sun-synchronous orbit around the Earth. 2

a) Advanced semantics-based querying applied on image archives of raw images. b) Higher level enhanced processing of raw images invoking algorithms for data georeferencing, improved fire detection and feature extraction, integration of geospatial and temporal information, as well as integration of auxiliary vector and/or raster data (e.g. administrative boundaries, coastline data, land use/land cover information) which introduce additional knowledge and help to draw enhanced decisions of the type fire or no fire reducing considerably the level of uncertainty. c) Advanced semantics-based querying and retrieval of ready to use hot spot detection Emergency Response Service (ERS) products, and automatic invoking of processes to assess products consistency in time and space and compatibility with existing ancillary information layers and knowledge (e.g. land use/land cover layers, coastline data, other knowledge), in order to redraw final decisions excluding cases of false fire alarms in the delivered ERS. d) Advanced semantics-based querying and retrieval of ready to use burnt area mapping products, and automatic invoking of processes to assess products compatibility with existing spatial information and landscape knowledge (e.g. land use/land cover maps, existing forest maps, administrative boundaries, cadastral data, agricultural register data, other), in order to redraw enhanced decisions excluding cases of false burnt area mapping and false burnt area assessments in the delivered ERS. e) Provide a simple and easy to use web based viewing tool for fire monitoring in realtime conditions. An end user would use this tool to view hot spot and burnt area locations, in an Area Of Interest (AOI), select GIS layers to add and export map quick-looks and vector data. 3. Functional Requirements Functional requirements describe the system capabilities required by a user for solving a functional problem. The requirements are primarily defined by use cases. A use case describes a concrete, functionally self-contained sub-process. The entirety of the use cases then defines the system behavior. The functional requirements are the central pieces of information for the development of specifications. They will be integrated into the overall system specification and concretized as required. The methodology adopted for drawing the functional requirements is thoroughly described in D8.1 [1]. The requirements definition process used is to firstly identify the various user roles within the system, then gather their User Stories and finally derive the respective Use Cases. 3.1. Data and products In the context of the fire monitoring Use Case II, the TELEIOS technologies will be applied to the available satellite imagery and other ready products. These datasets are presented in this section. 3

MSG/SEVIRI raw acquisitions: A collection of raw image data with a temporal resolution of 5 minutes and spatial resolution of 4 km, covering the entire fire season (~4GB per day). In-house processing of these data results to hot spots which correspond to point-vector shapefiles. FMM-1 ready products: Collection of hot spot kml and shapefiles available every 15 minutes, originating from SAFER. FMM-2 ready products: Collection of burnt area polygon shapefiles on a daily basis and with a spatial resolution of 1km, originating from SAFER. Figure 1: Map of FMM-2 products in the period June-July 2010 4

3.2. Actors / User Roles The TELEIOS project mainly aims to accommodate the needs of NOA as a Service Provider for fire monitoring and mapping applications in the framework of GMES ERS programs [3, 4], but at the same time intends to serve a wider user community of SPs and end users at European level, who benefit from the TELEIOS technology and the final end products respectively. Hence it is crucial to identify the various user roles that will utilize the system either directly or indirectly. Then, by gathering the user stories from an inhomogeneous group of users, different types of functional requirements are set. The various user roles, identified during the TELEIOS workshop in Frascati [1] are presented below: END_USER: Uses fire monitoring products on an operational daily basis (e.g. officers on duty in the fire brigade and GSCP, staff responsible for decision making within GSCP, regional authorities and staff responsible for planning activities within the HMOA/DGF) providing them with crucial information that aids them in their emergency response decision making processes and risk planning activities. EO_SCIENTIST: Research groups (e.g. the Natural Disasters group of the Institute for Space Applications & Remote Sensing of NOA and the Remote Sensing Laboratory of the National Technical University of Athens) and scientists related to Earth Observation. They are considered as an advanced user with prior experience with GIS, remote sensing and related technology. Their main goal is to either enhance the algorithmic modules of a processing chain or to integrate fire monitoring products with their in-house processes. SERVICE_PROVIDER: Processes raw data and generates and provides finalized value added products derived from raw earth observation imagery. In the context of TELEIOS, NOA assumes the role of the service provider. INTERMEDIATE_SERVICE_PROVIDER: Provides added-value products derived on the basis of other ready products generated by third parties or other SPs. Typical bodies that undertake such a task are the FRI/NAGREF and HCBW. NOA will play this role also, as the FMM-1 and FMM-2 products are ready products that will be enhanced through the TELEIOS technologies. ADMINISTRATOR: User who has full access to the system and may change configuration data. In the framework of this project NOA assumes such a role. 3.3. User Stories User stories are short natural language sentences of the intended functionality of a software system, written in the language of the user or stakeholder of the system. The following User Stories were gathered during the TELEIOS workshop [1], documented and managed using the redmine 3 system again described in D8.1 [1] and are summarized in the following table: 3 http://www.redmine.org/ 5

Table 1: User Stories as cited in redmine, categorized according to the actors involved User Story title User Story Description User Story ID Actors involved Descriptive Language for retrieving information As an application developer / service provider, I want to use a descriptive language to retrieve information about fires using semantic, geographical and temporal constraints US_01 Service Provider Discovery based on thematic / spatial / temporal criteria As a service provider I want to be able to discover raw images using thematic / spatial / temporal criteria US_02 Service Provider Save and share query parameters As an expert user, I want to be able to save the parameters of a query and to share them with my colleagues, even remotely US_03 Service Provider Change / Substitute Algorithms As an expert user, I want to have the possibility to change / substitute any algorithm for my own algorithms US_04 Intermediate Service Provider Modify Algorithm Parameters As an expert user I want to have the possibility to modify any parameter of any algorithm used by TELEIOS US_05 Intermediate Service Provider Modular System As an expert user I want to have the possibility to split the system in different parts and to generate my own system by using these parts and other modules from my own US_06 Intermediate Service Provider Operational Systems As an expert user I want the system to be easily compiled in different operating systems (e.g. different versions of Unix and Windows) US_07 Intermediate Service Provider Standard Compliance As an expert user, I want the system to provide results at standard formats (OGC, ENBI, ERDAS, OpenGIS) US_08 Intermediate Service Provider Quality validation As a quality manager, I want access to up-to-date validation information about the accuracy of the detection system (e.g. information on whether the system has been tested with ground truth in recent times) US_09 end user / Intermediate Service Provider Combining with GIS data As an Intermediate Service Provider I want to integrate data that come from 1st level service providers and additional GIS data to reason about specific areas US_10 Intermediate Service Provider Products with high precision / accuracy As an end user I like to receive products that include high accuracy and precision in mapping, namely boundaries, vegetation type cover of burnt areas in order to enable the environmental administrator to be more effective in their recovery plans and after fire management of their respective area US_11 end user / Intermediate Service Provider Real-time notification As an end user I want to receive real-time notification of fire events for information integration (text/binary) US_12 end user 6

Enable / Disable notification by area of interest As an end user I want to define the area of interest (one or multiple) / I want to enable / disable notification (by area). US_13 end user Standardized notification format As an end user I want a standardized notification format. US_14 end user Real-time fire information and trend As an end user (real, field operative) I want to access real-time maps of fire status and its trend (e.g. direction, intensity (increasing / decreasing, meteorological conditions) to better perform emergency response activities US_15 end user Species of burnt vegetation As an end user I like to know from the system the species of vegetation that was burnt this year US_16 end user Reforestation As an end user I want to know whether an area that was burnt this year was burnt again in the past, so I can decide if it is necessary to re-forest it or it can recover itself. This is very important for future planning US_17 end user Web GIS platform for real-time fire monitoring As an end user I would like to be able to view hot spots and burnt areas on a Web GIS platform US_18 end user Final product format As an end user I would like to have both vector data & map quick-looks for the fire monitoring products US_19 end user Descriptive Language to implement annotation algorithms As an EO scientist, I want to use a high level descriptive language to implement my algorithms that annotate raw EO data with semantic meaning and store the annotation in the same (DB-) system that manages the raw EO data US_20 EO Scientist / Scientific User Descriptive Language to implement algorithms for combining data As an EO scientist, I want to use a high-level descriptive language to implement my algorithms that combine raw EO data, extracted features & semantic annotations to derive new semantic annotations, and store those for further reasoning in the same DBMS US_21 EO Scientist / Scientific User Combination of GIS data and extracted features As a scientific user I want to combine semantically annotated primitive features that were extracted from raw images, combine them with GIS data and create semantic labels that will be used for automatic feature extraction US_22 EO Scientist / Scientific User Geo-referencing EO images As an expert user, I want the functionality to georeference EO image data and products US_23 EO Scientist / Scientific User - Service Provider Threshold values for fire detection As an expert user, I want the system to maintain a set of threshold values for fire detection that are parameterized by location, sensor and the underlying land cover so that the accuracy of fire detection can be improved US_24 EO Scientist / Scientific User - Service Provider Input "validated hot spots" As an expert user, I want to be able to input the information on validated hot spots into the system that influences the fire detection algorithms / updates the thresholds US_25 EO Scientist / Scientific User - Service Provider 7

Trigger computation for updating threshold values As an end user / expert user, I want to be able to trigger a computation that updates the threshold values based on the information on validated hot spots I have input before US_26 EO Scientist / Scientific User - Service Provider Stream of EO images for fire detection As an expert user, I want the system to employ a set or stream of EO images for fire detection in order to increase the accuracy of the detection US_27 EO Scientist / Scientific User - Service Provider Combine GIS data with EO data for reducing false alarms As an expert user, I want the system to employ GIS data (land use / land cover, forest maps, administrative boundaries etc) in the hot spot detection algorithms in order to reduce cases of false alarms US_28 EO Scientist / Scientific User - Service Provider 3.4. Use Cases Following the User Stories gathering session conveyed above, the corresponding Use Cases are derived and presented in this section. 3.4.1. Use Cases Overview Herein, the specific Use Cases of the system are described. Note that User Stories differ from use cases. While User Stories are short natural language sentences describing desired functionality of a system, a Use Case often follows a formal structure (template) and cover details such as preconditions, steps in a success scenario or processed data [1]. The methodology that was followed in order to transfer user stories to use cases is described in D8.1 and can be briefly described by the following steps: - Identify user stories that cover functional requirements on the system - Group the user stories and identify related user stories and the nature of the relationship such as generalization, specialization. - Identify user stories that can be transferred to whole use cases and those that correspond to parts of use cases. In Use Case II, we partition the Use Cases depending on the actual user that is involved. The Use Cases are directly derived from the generic Use Case specification of TELEIOS and from the User Stories collected at the user community workshop. In the following figure an overview of the identified Use Cases is presented. Detailed information on these is available in the subsequent sections. 8

Figure 2: Overview of the identified Use Cases for fire monitoring 3.4.2. Use cases for SERVICE_PROVIDER The Service Provider (SP) is responsible for delivering finalized products or services to the end user community. An EO scientist on the other hand strives to identify the most suitable algorithms and techniques in order to allow the SP to offer more reliable and accurate products. In TELEIOS, the roles of SP and EO scientist are blended as NOA and its partners are the responsible parties for developing and enhancing the processing chain for fire monitoring products and wrapping them as a reliable service. Hence, in this section we focus on the Use Cases where the SP primarily and an EO scientist on the other hand are involved, aiming at presenting explicitly the underlying functional requirements. 9

Identifier Version 1.0, 13.11.2010 TELEIOS UC2 SERVICEPROVIDER1. Description Actors Initial conditions Final results Main process Generated data Related User Stories Definition of the pre-processing chain of level 0 MSG/SEVIRI data performed at the back-end of the TELEIOS infrastructure. SERVICE_PROVIDER, EO_SCIENTIST Access to the back-end of the TELEIOS infrastructure where the processing modules and thresholds Look Up Table (LUT) are. Initial hot spots product. USER logs in into the back-end of the TELEIOS infrastructure. USER can insert, delete and modify processing modules that perform data import, image registration, spectral calibration, band operations, classification and geo-referencing of images, conversion of raster products to vector formats, and generation of alternative vector products. USER can modify the processing chain either through a Graphical User Interface (GUI) or through a scripting language. USER can access and modify a Look Up Table (LUT) containing threshold values required for the classification module. Executable description of a pre-processing chain of modules. US_04, US_05, US_06, US_20, US_21, US_23, US_24, US_25 To allow for a better understanding of the pre-processing schema, the next figure shows the modular wise concept of an initially proposed pre-processing chain. As the goal of this use case is the modification of the pre-processing chain, the following example should not be considered binding. 10

Pre-processing Raw MSG/ SEVIRI data Image data Image metadata Data import Band separation & transformation of the raw image to internal format Spectral calibration Ensure spectral compatibility of images Image registration Align images at a pixel basis Band operations Derive physical indexes through the appropriate band operations Algorithms Parameter file Classification Assign to each pixel a fire, no-fire flag by thresholding the physical indexes Georeferencing Each pixel can be geographically identified Reference image Sensor model Output Raster conversion Export output to raster format (geotiff, img) Vector conversion Export output to vector format (shapefile) GE conversion Export output to Google Earth compatible format (kml) Figure 3: Pre-processing chain for fire monitoring 11

Identifier Version 1.0, 13.11.2010 TELEIOS UC2 SERVICEPROVIDER2. Description Actors Initial conditions Main process Generated data Related User Stories Definition of the post-processing of the hot spot products performed at the back-end of the TELEIOS infrastructure. SERVICE_PROVIDER, EO_SCIENTIST, INTERMEDIATE_SERVICE_PROVIDER Access to the back-end of the TELEIOS infrastructure where the respective query sequence is. USER logs in into the back-end of the TELEIOS infrastructure. USER can create sophisticated queries that update/modify the hot spots: according to the persistence of a hot spot in time and space. according to the frequency of occurrence of a detected hot spot in the last hour. according to the compatibility of these products with the underlying land cover. to the compatibility of these products with the respective administrative boundaries. by labeling each hot spot as fire, non-fire and potential fire uncertain. USER can select which queries will be executed in the automatic mode of operation, and their order of execution. Executable description of a post-processing chain of queries. US_01, US_02, US_03, US_05, US_10, US_16, US_17, US_20, US_21, US_22, US_27, US_28 12

Identifier Version 1.0, 13.11.2010 TELEIOS UC2 SERVICEPROVIDER3. Description Actors Initial conditions Main process Generated data Related User Stories Definition of the post-processing of the burnt areas products performed at the back-end of the TELEIOS infrastructure. SERVICE_PROVIDER, EO_SCIENTIST, INTERMEDIATE_SERVICE_PROVIDER Access to the back-end of the TELEIOS infrastructure where the respective query sequence is. USER logs in into the back-end of the TELEIOS infrastructure. USER can create queries that: delete the burnt areas whose area is less than the Minimum Mapping Unit of the method. update the burnt areas according to the spatial relationship of adjacent burnt areas. update/modify the burnt areas according to the compatibility of these products with the underlying land cover. update/modify the hot spots and burnt areas according to the consistency of these products with the respective administrative boundaries and other GIS data. update/modify the burnt areas by labeling each burnt area polygon as burnt, non burnt and uncertain. update/modify the burnt areas by applying spatial operations on each and between the polygons (smoothing, amalgamation, union, intersection). USER can select which queries will be executed in the automatic mode of operation, and their order of execution. Executable description of a post-processing chain of queries US_01, US_02, US_03, US_05, US_10, US_16, US_17, US_20, US_21, US_22, US_27, US_28 13

Identifier TELEIOS UC2 SERVICEPROVIDER4. Version 1.0, 13.11.2010 Description Actors Initial conditions Final results Main process Execution of the automatic mode of operation performed at the back-end of the TELEIOS infrastructure (START/STOP). In this use case the user instructs the system to automatically execute a specific already defined processing chain whenever new raw data is acquired. SERVICE_PROVIDER, EO_SCIENTIST Access to the back-end of the TELEIOS infrastructure where the processing takes place. At least one of TELEIOS UC2 SERVICEPROVIDER1, 2 or 3 must have been performed before. hot spots and burnt areas products. USER logs in into the back-end of the TELEIOS infrastructure. USER selects the location where the raw MSG/SEVIRI products are that the system monitors. USER selects the location where the FMM-1 ready products are that the systems monitors. USER selects the location where the FMM-2 ready products are that the systems monitors. USER selects the LUT to be used. USER selects the location of the GIS data. USER selects the output location of the service. USER defines whether the processing chains defined in TELEIOS UC2 SERVICEPROVIDER1, TELEIOS UC2 SERVICEPROVIDER2, or TELEIOS UC2 SERVICEPROVIDER3 are executed automatically (START/STOP procedure of the service). USER can choose product conversion format between raster, vector and Google Earth compatible formats. USER selects the projection system of the products. Exceptional situations Processed data ES1: MSG/SEVIRI receiver is out of service. ES2: MSG/SEVIRI sensor is out of service. ES3: FMM-1 ready product service provider fails. ES4: FMM-2 ready product service provider fails. MSG/SEVIRI raw data FMM-1 ready products 14

FMM-2 ready products TELEIOS FP7-257662 GIS data (CORINE land cover, administrative boundaries, coastline, road & rail network, population, points of interest and other auxiliary data). Generated data Related User Stories hot spots and burnt area products in raster and vector formats US_02, US_08, US_14, US_24, US_27, US_28 15

Identifier Version 1.0, 13.11.2010 TELEIOS UC2 SERVICEPROVIDER5. Description Actors Initial conditions Final results Main process Exceptional situations Processed data Generated data Related User Stories Execution of the processing chain performed at the back-end of the TELEIOS infrastructure in the offline mode. This is a onetime execution of an already defined processing chain. The user can select individual input and output locations. SERVICE_PROVIDER, EO_SCIENTIST Access to the back-end of the TELEIOS infrastructure where the processing takes place. At least one of TELEIOS UC2 SERVICEPROVIDER1, 2 or 3 must have been performed before. hot spots and burnt areas products. USER logs in into the back-end of the TELEIOS infrastructure. USER selects the raw MSG/SEVIRI products to be used. USER selects the FMM-1 ready products to use. USER selects the FMM-2 ready products to use. USER selects the LUT to be used. USER selects the location of the GIS data. USER selects the output location of the service. USER defines whether TELEIOS UC2 SERVICEPROVIDER1, TELEIOS UC2 SERVICEPROVIDER2, or TELEIOS UC2 SERVICEPROVIDER3 is executed. USER can choose product conversion format between raster, vector and Google Earth compatible formats. USER selects the projection system of the products. ES1: MSG/SEVIRI receiver is out of service. ES2: MSG/SEVIRI sensor is out of service. MSG/SEVIRI raw data FMM-1 ready products FMM-2 ready products GIS data (CORINE land cover, administrative boundaries, coastline, road & rail network, population, points of interest and other auxiliary data). hot spots and burnt area products in raster and vector formats US_02, US_08, US_14, US_24, US_27, US_28 16

3.4.3. Use Case for EO_SCIENTIST An Earth Observation scientist is considered an expert user that is familiar with the algorithmic processing chain adopted for fire monitoring within TELEIOS. For the specific purposes of the project NOA will assume the role of the EO scientist, aiming at enhancing the existing capabilities for detecting hot spots. The basic idea is to train the Lookup Table (LUT) used for setting the appropriate threshold values during the classification module, according to the underlying land cover and geographic location of the area under examination. The training set will be a reference dataset of validated hot spots. Identifier Version 1.0, 13.11.2010 TELEIOS UC2 EOSCIENTIST1. Description Actors Initial conditions Final results Main process Processed data Related User Stories Training of the Look Up Table to define optimum threshold values. Criteria are the underlying land cover and geographic location. EO_SCIENTIST, SERVICE_PROVIDER Access to the back-end of the TELEIOS infrastructure Updated LUT. USER logs in into the back-end of the TELEIOS infrastructure. USER selects location of reference dataset of validated hot spots. USER selects input dataset of raw MSG/SEVIRI acquisitions. USER selects location of GIS data. USER selects the location of the LUT to be updated. USER activates processing module for updating the LUT. This module accepts as inputs the reference dataset, the raw images and the relevant GIS data. MSG/SEVIRI raw data Reference hot spot product of validated fires. GIS data (CORINE land cover). US_24, US_25, US_26 3.4.4. Use Cases for END_USER The use cases related to the interaction of an end user with the system are subsequently described. The system should provide a web based front-end capable of displaying the 17

hot spots and burned areas present. Such data must be presentable together with any other relevant GIS data, in a layered fashion. These layers should be viewed with an interactive map component. The user should also be able to view other kinds of data available publicly on the web, e.g., Wikipedia data, population data, etc, and relate it with GIS data, hot spots and burned areas. The user must have the ability to specify query parameters such as the area of interest, the layers of information, and time period. The user must also be able to decide whether the information should be displayed online or offline, meaning that new products that are automatically generated may satisfy the query and thus should be automatically presented. The front-end should provide basic operations like zoom in and out, a pan and an identify tool. The user must also be able to export the map to a raster image and the hot spots and burned areas in vector formats (shp and kml). For every exportable product, the USER should be able to view the corresponding metadata. Identifier TELEIOS UC2 ENDUSER1. Version 1.0, 13.11.2010 Description Front-end support for end users. Actors Initial conditions Final results Main process END_USER The users have to be logged in the front-end of the system using a common web browser. The result is the illustration of different heterogeneous geo-data and other data publicly available on the web in combination with hot spots and/or burned areas. This illustration might be exported into a file. USER logs in into the front-end of the system. USER selects the investigation area. USER selects time period and whether the system should dynamically update the query results based on new products generated. USER chooses layers of information to be displayed based on the available information, such as GIS data layers, hot spots, burned areas, etc, and other data publicly available on the web. USER can do simple operations like zoom-in, zoom-out, pan and identify. USER can use an identify tool to view attributes of a hot spot or a 18

burnt area in the interactive map. TELEIOS FP7-257662 USER can view metadata information of the available geoinformation layers that appear on the front-end. USER can export the displayed image into a raster format. USER can export hot spots and burned areas in a vector format such as shp and kml. Generated data Related User Stories Raster image in open format such as geotiff. Vector data for hot spots/burned areas in shp and kml formats. US_02, US_08, US_13, US_15, US_16, US_17, US_18, US_19 Additionally, the front-end will allow the user to subscribe to an email notification service, for receiving alerts for fire events that occur in real-time. Identifier TELEIOS UC2 ENDUSER2. Version 1.0, 13.11.2010 Description Actors Initial conditions Final results Main process Processed data Email notification service for end users. The user would subscribe to an email notification service, for receiving alerts for fire events that occur in real-time. END_USER The users have to be logged in the front-end of the system using a common web browser. Email notifications with attached vector data for hot spots/burned areas in shp and kml formats. 1. USER logs in into the front-end of the system. 2. USER selects the investigation area. 3. USER chooses type of information to be displayed in the notification message (hot spots or burnt areas). 4. USER selects the format (shp or kml) of the attached product in the notification message. 5. USER subscribes to the email notification service. hot spots Burned Areas GIS data (CORINE land cover, administrative boundaries, coastline, road & rail network, population, points of interest and other auxiliary data). 19

Generated data Related User Stories An email notification with attached vector data for hot spots/burned areas in shp and kml formats. US_12, US_13, US_14 3.4.5. Use Cases for INTERMEDIATE_SERVICE_PROVIDER The service provider should have a similar interface with the end-user augmented with the ability to update and validate the information of the system. Moreover, the front-end should allow the INTERMEDIATE_SERVICE_PROVIDER to perform expert queries directly in the query language that will be used by the system and view these results. Identifier Version 1.0, 13.11.2010 TELEIOS UC2 INTERMEDIATE SERVICEPROVIDER1. Description Front-end support for intermediate service provider. Actors Initial conditions Final results Main process Alternative processes INTERMEDIATE_SERVICE_PROVIDER The user has to be logged in Updated, deleted or validated hot spots and/or burned areas. 1. USER logs in into the front-end of the system. 2. USER selects the investigation area. 3. USER selects time period. 4. USER chooses layers of information to be displayed based on the available information, such as GIS data layers, hot spots, burned areas, etc. 5. USER can do simple operations like zoom-in, zoom-out, pan and identify. 6. USER can update, delete or toggle a validated flag to hot spots and burned areas 7. USER can export the displayed image into a raster format. 8. USER can export hot spots and burned areas in a vector format such as shp and kml. USER logs in into the front-end of the system. USER writes an advanced query using the database query language and executes the query. USER chooses additional layers of information to be displayed 20

Processed data Related User Stories based on the available information, such as GIS data layers, etc. USER can do simple operations like zoom-in, zoom-out, pan and identify. USER can update, delete or toggle a validated flag to hot spots and burned areas. USER can export the displayed image into a raster format. USER can export hot spots and burned areas in a vector format such as shp and kml. hot spots Burned Areas GIS data (CORINE land cover, administrative boundaries, coastline, road & rail network, population, points of interest and other auxiliary data). US_02, US_03, US_08, US_10, US_13, US_15, US_16, US_17, US_18, US_19, US_20, US_21, US_22 An important Use Case is the following, where an intermediate service provider will be able to upload GIS auxiliary data to the system, adding value to the final map products. Identifier Version 1.0, 13.11.2010 TELEIOS UC2 INTERMEDIATE SERVICEPROVIDER2. Description GIS auxiliary data upload for intermediate service provider. Actors Initial conditions Final results Main process Processed data INTERMEDIATE_SERVICE_PROVIDER The user has to be logged in GIS auxiliary data available at the front-end. USER logs in into the front-end of the system. USER can upload GIS auxiliary data to the system. USER can upload metadata information on existing GIS data to the system. GIS data (CORINE land cover, administrative boundaries, coastline, road & rail network, population, points of interest and other auxiliary data) and associated metadata. 21

3.4.6. Use Cases for ADMINISTRATOR The administrator will be responsible for setting up, managing and maintaining the system. Identifier Version Description Actors Initial conditions Final results Main process TELEIOS UC2 ADMIN1. 1.0, 13.11.2010 The system administrator should be able to adjust users, passwords and user groups. ADMINISTRATOR The user must have a web browser. The result is an adjustment of users, passwords and user groups. USER logs in into the system as an ADMINISTRATOR USER selects users panel. USER adds or deletes users, adjusts user preferences such as name, password, etc, distinguishing between the back-end and the front-end of the system. USER adds or deletes users from predefined security groups such as administrator, service provider, intermediate service provider, end user. Exceptional situations Processed data ES1: In main process 3 the connection to the user database is not feasible. Users and groups, collected by web services. Identifier Version Description TELEIOS UC2 ADMIN2. 1.0, 13.11.2010 The system administrator should be able to view system logs. Actors Initial conditions ADMINISTRATOR The user must have a web browser. 22

Final results Main process The result is displaying the system s log. USER logs in into the system as an ADMINISTRATOR. USER selects log panel. USER views the system s logs dynamically. Viewing of system logs is also crucial for the management of the system. 4. Non-Functional Requirements Apart from the previous functional requirements the system has several requirements which can be categorized as non-functional. Such requirements arise easily due to the real-time nature of the system and the size of the data that needs to be handled. We next describe all such requirements categorized appropriately. 4.1. Performance Requirements UC2.PR.01 The time required for the generation of hot spots from the RAW MSG/SEVIRI images plus the time required for the dissemination of the results must not exceed the period of acquisition of the RAW images. The system should produce ready hot spots in less than 5 minutes. UC2.PR.02 Since the system receives and processes RAW images once every 5 minutes, the resulting collected dataset is very large. The system must be capable of handling data of several terabytes, without exhibiting any significant performance losses. UC2.PR.03 The query execution in the TELEIOS infrastructure must be efficient despite the huge data volumes. Even highly complex queries (including updates) must be optimized to be executed in less than 30 seconds. Since multiple queries are going to be automatically executed by the ingestion process, this is also necessary in order to be able to support the UC2.PR.01 requirement. 4.2. Reliability Requirements UC2.RR.01 UC2.RR.02 The system must exhibit increased availability. This is particularly important as the system will be used by organizations such as civil protection or fire brigade during a crisis situation. The products derived from the fire monitoring service should have high thematic accuracy i.e. low false alarm rate and omission errors. 23

UC2.RR.03 The products derived from the fire monitoring service should have high positional accuracy, i.e. the location of a potential fire should be as accurate as possible and the spatial distribution of a burnt area should correspond to the real scenario in map coordinates. 4.3. Interface Requirements UC2.IR.01 UC2.IR.02 UC2.IR.03 UC2.IR.04 UC2.IR.05 UC2.IR.06 UC2.IR.07 UC2.IR.08 The system should allow exporting any set of hot spots or burned areas in a shapefile vector format. The system should allow exporting any set of hot spots or burned areas in a raster format. The system should allow exporting any set of hot spots or burned areas in a kml (Google earth format) vector format. The system should allow exporting the interactive map view to an image file. The front-end should be as simple as possible. The system should allow metadata viewing for all the available geoinformation. The system should preserve the consistency of the geo-information that appears on the interactive map of the front-end The content that appears at the front-end interface should be complete and concise. 4.4. Security Requirements UC2.SR.01 UC2.SR.02 The system must be deployed in an environment where all available data such as earth-observation images or data computed and stored inside a database, are secured. Only authorized users (at the back-end or at the operating system level) should have access to any data of the system. Front-end authentication and authorization mechanism. The front-end of the system must contain an efficient authentication and authorization mechanism which has support for users and groups of users. All information of this mechanism must be stored inside a database. The front-end access to the system must provide the ability 24

to login, and based on the acquired credentials must provide only the appropriate functionality. There must be at least four different security levels, such as administrator, service provider, intermediate service provider, end user. 4.5. Storage and Persistence Requirements UC2.SPR.01 UC2.SPR.02 UC2.SPR.03 UC2.SPR.04 The system must retain all RAW images and ready products that it receives. The system must store any computed products in order to support efficient querying and retrieval. The system must support the storage and querying of GIS data such as land use, coast line, municipalities, etc. Storage of earth-observation images or ready-products must be done in an open standard format. 4.6. Documentation Requirements UC2.DR.01 UC2.DR.02 UC2.DR.03 UC2.DR.04 The system should be accompanied by an installation manual. A document which describes the available software components, necessary libraries and executables and a step-by-step procedure in order to install the system in a clean environment. This manual must be understandable by a system administrator. The system should be accompanied by an administrator manual. A document describing the different configuration parameters that affect the system, and how to adjust them appropriately. Also a brief description of the configuration that may be performed by the frontend when logged in as an administrator user. The system should be accompanied by an end-user manual. A document describing the front-end access provided by the system written for the end-user, who is not an earth observation scientist. The system should be accompanied by a database schema manual. A document describing the information that is stored inside the available database, the database schema (possible many if more than one database is used) and the queries that are performed. 25