Final Report Summary - DISASTER (Data Interoperability Solution At STakeholders Emergencies Reaction)
Executive Summary:
Emergency management involves several actors that must interact and share information to provide a quick and integrated response to the threatening event. Sharing information between international workforces is a challenging tasks in emergency management. This is due to the fact that, even if dedicated ICT systems have emerged (usually known as Emergency Management Systems - EMS), each stakeholder has deployed its own system of command, control and communication, resulting on diverse data models and formats that are invariably incompatible with each other. Moreover, in an international context, the EMS-to-EMS exchange of information provides a number of additional challenges, considering also diversity in language (more than 24 official languages in the EU), background and cultural particularities (e.g. units, metric system), methodology or structure (diversity of organizational structures starting at local level), legal issues (different regulation, complex legal landscape), or data representation (myriad colour codes, different graphical symbol sets), among others.
A twofold solution has been developed: a common and modular ontology taking into account different cultural, semantic and linguistic issues (named EMERGEL); and, from that point, the implementation of a transparent Service Oriented Architecture providing mediation algorithms compliant with current data formats and existing solutions (the whole solution named DISASTER system).
The EMERGEL (EMERgency ELements) is a context-dependent ontology defined by experts to provide semantic mediation services for emergency related concepts. EMERGEL plays a pivotal role in the software solution for data interoperability proposed in this work. It has been made publicly available at [http://purl.org/emergel]. It is divided into three main modules: 1) a core ontology, focusing exclusively on events and agents; 2) a transversal module dealing with time and space; and 3) vertical modules designed to host in the form of concept schemes any relevant vocabulary able to assist the core module. An ad-hoc viewer (called SKOSIĆ), and the DISASTER API, complements EMERGEL, in order to allow both, "human beings" and "machines" (third-party applications) to access the ontology.
The global DISASTER solution needs additional components to "put EMERGEL in use". The DISASTER solution is conceived as a network of components (mediators) and a central component (Core). A key element in the DISASTER systems is the semantic mediation through the use of the EMERGEL component on a totally transparent way for the involved EMSs. To enable seamless integration, the mediator components allow the EMSs to use external information transformed to their own protocols, formats and cultural and linguistic characteristics. Several components take care of standardizing the geographic information exported by any EMS in a non-intrusive way: these components work in background capturing information to be exported. In order to share information between two or more systems, WFS (Web Feature Service) and WMS (Web Map Service) protocols has been taken into account, with the purpose of provide an easy way to represent the geospatial information exported by the different systems involved in DISASTER. Thus, this information is transformed by the components into standard formats such as SHP (Shapefile), GML (Geographic Markup Language) and GeoJSON (Geographic Javascript Object Notation), among others.
Field trials were carried out in two locations and two phases during the project, where different versions of the prototypes were fully demonstrated and tested with first responders taking part in realistic exercises.
A Border Fire incident was used as the basis for a first early field exercise whereby the initial ontology and middleware EMS-to-EMS mediation platform were tested. This was enacted within Dutch national fire service training exercises at a military airfield near the German border, and so realistic cross-border usage was demonstrated involving all command and operational levels, and all relevant systems. The feedback supported maturation of the proof of concept pilot systems during the project and for the second exercise
An Aircraft Crash was used as the basis for a second field exercise whereby the second issue of the ontology and mediation platform were tested. This was enacted at Schiphol airport and involved collaboration of various security stakeholders in exchange of critical information during an Aircraft Crash exercise involving a real aircraft, passengers and risk-related cargo.
Feedback from users and stakeholders was gathered, analysed and enriched, after the two major experiments. The usage of geo-information as the primary focus has been accepted positively, and the DISASTER method of enrichment of the map display, via imported / exported icons and linked data, has been shown to improve understanding and efficiency by responders and decisions makers. The results of the experiments indicate that the technical approach enables semantic interoperability between heterogeneous EMS, using a map-based approach, with added meta data and linked data for explanation. DISASTER has shown "ease of access" to, and "ease of use of" critical safety information, a high level of usability, and has identified further areas of research that will improve service to responders in future. The DISASTER approach has shown how new ways of information delivery and sharing can have an impact on existing operational procedures, that may need to be redesigned to fully exploit new opportunities. Making crisis information more easily accessible allows different responder teams to coordinate more easily, but in addition to the technology, there is a need for future protocols for information exchange of joint-operation at international level. In the end, the achievements emphasise the readiness of technology to support responder ambitions, and the need for regional, national, and international agreements on information exchange to make it a reality.
Project Context and Objectives:
MOTIVATION AND CONTEXT
Emergency management involves several actors that must interact in order to prevent a risk or to coordinate their activities to react to hazardous situations. This interaction mainly implies the interchange of information about the “who”, the “what”, the “where” and the “when”, in order to provide a quick and integrated response to the threatened event. This integrated response can involve international stakeholders with heterogeneous objectives, needs and contexts. The tasks developed by each one of these stakeholders are usually not independent from the different workforces spread throughout the disaster, but there are pieces of information that should be shared between all active groups in order to obtain globally successful results. Sharing information and coordination between international workforces in rescue operations, dealing with a large amount of information in a highly dynamic environment, is one of the most challenging tasks in emergency management.
In order to manage and share this critical information in a dynamic context, dedicated ICT systems, usually known either as Emergency Management Systems (EMS) or Crisis Information Management Systems (CIMS), have emerged. In the Member States of the EU, each stakeholder has deployed its own system of command, control and communication. As a direct result of this situation, Emergency Management Systems manage different information data models and formats that are invariably incompatible with each other.
EMS have evolved within the cultural and political context of their respective countries. In an international context, the situation with regard to the EMS-to-EMS exchange of information provides a number of challenges, considering not only technical interoperability (data formats, models and communication protocols), but also diversity in language (e.g. 28 member states in the EU with more than 24 official working languages), background and cultural particularities (e.g. units, metric system), methodology or structure (diversity of organizational structures starting at local level), legal issues (different regulation, complex legal landscape), or data representation (myriad colour codes, different graphical symbol sets), among others.
From an organisational, procedural and legal perspective, EMSs have also been conditioned by political and socioeconomic factors. In example, there is a big difference between centralized or federal countries. For the former ones, the legislation applies to the whole territory of the country, but for the latter, the application of laws is one of the every federal entity duties or even legislation can be utterly transferred and each federal entity has its own laws. For example, in Germany there are 16 laws on disaster management encompassing to a certain extent fire services that operate on community/city level (a local authority or city having a distinct legislation on fire services), and an equal number of laws on EMS-services. As a result, existing systems fragmentation means that cooperation between emergency forces becomes almost impossible in many regions.
[See figure 1.2.A: Interoperability challenges in EMS-to-EMS communication]
Great improvements have been made by governments in the last years for managing and exchanging disasters information. These are only the first steps, though. If real and complete coordination between first responders and different stakeholders is desired, current mechanisms and technologies must be improved and interoperability problems resolved. As a matter of fact, the USA has had the same interoperability problems and they have faced those problems and drawbacks by adopting a standard format (EDXL) to exchange data between different stakeholders within the country. However, the challenges in developing a solution for the EU are very different from those in the USA. First of all, due to language heterogeneity, cultural fragmentation and different political frames, the common understanding and the exchange of information is very difficult, appearing hard interoperability problems. Moreover, in the case of the USA, there is a common emergency management framework that is provided by the government. This is missing in the EU, where each European country has different legislations and technological frameworks to deal with emergency situations,. The EU context makes collaboration and interaction difficult to achieve by means of the available technological solutions, which do not resolve the heterogeneity at the different communication levels. For all these reasons, the adoption of the USA solution is impossible, and a different technical approach must be developed.
To sum up, establishing a common response framework and a common information exchange format, as in USA, does not sound as a feasible solution in the short-term, both from a technical and political perspective. Instead, a technical solution was suggested oriented towards the various needs and demands of the European Union. Designing a solution to enable existing systems and organisations to interoperate effectively is the big step forward to be taken by DISASTER.
PROJECT APPROACH
The proposed solution does not involve the replacement of existing infrastructure and languages that are currently used by Emergency Management Systems. On the contrary, DISASTER proposed to address communication challenges by establishing indirect bridges between information systems. These bridges are not established between each pair of existing data models, but to converge into a common knowledge representation which allows the indirect transformation. From a complexity point of view, this means defining n transformations, where n are the current available data models in Emergency Management Systems, and which are enough to ensure any possible interaction between stakeholders. On the other hand, direct bridges require to define n2 translations.
Nowadays exist many formal ways to describe and to structure knowledge: thesauri, taxonomies and ontologies are the most representative. From less to most expressive tools, taxonomies are the less powerful ones, with limited features for representing not hierarchical knowledge, capturing pure linguistic knowledge. Thesauri are a more expressive means for representing knowledge. Apart from being able to express hierarchies of concepts, as taxonomies, thesauri can linguistically describe the concepts, capturing for instance synonym and homonym relations, and other semantic properties such as part/whole relations complementary to the hierarchical ones. These additional features provide more comprehensive classifications of knowledge, concepts and relations. Then last but not least, ontologies represent another formal and comprehensive way of knowledge representation, increasing thesaurus expressivity: ontologies provide mechanisms for creating complex and flexible relations between different concepts while separating the abstract meaning from the language representation. Another feature relative to ontologies is the definition of restrictions within controlled vocabularies so dedicated machines can apply algorithms for checking consistency or satisfiability of the concepts defined. For the reasons previously mentioned, designing and developing an ontology is the best solution for assuring and provide understanding of common knowledge between people from different countries and cultures.
The proposed solution implies that a common ontology should have a wide conceptual coverage, without sacrificing precision. These requirements call for a modular design of the ontology, i.e. the definition of an abstract framework built for extensibility. This ontology would be composed by three parts or modules where each one would have an specific purpose and motivation:
1) The core ontology which contains all the common knowledge and concepts related to emergencies and the stakeholders involved in a crisis situation.
2) A set of vertical ontologies focused on describing a comprehensive conceptualization of all the knowledge in a specific emergencies subdomain. These specific conceptual modules would be plugged to this central core in order to achieve the desired scope for any crisis subdomain (logistics, infrastructure, humanitarian aspects, etc.).
3) A transversal ontology containing knowledge and concepts from the core ontology as well as vertical ontologies. This ontology is mainly focus on describing general concepts (time, location, etc).
OWL is a standard ontology language that seems to be a good candidate to meet the requirements imposed by this endeavour. It is designed for open exchange of information in web environments, it allows for modular designs and extensibility and it deals with multilingualism. OWL is a language that also allows defining concepts with a high degree of detail, making it possible to align the ontology with existing data models and other information resources (such as thesauri or taxonomies) that range along all the possible levels of description.
In addition to the ontology itself, transforming the exchanged data and its format to and from the shared ontology and legacy EMSs is a critical task. These transformations to and from the ontology will be materialized by means of data mediation. Appropriate languages and techniques are applied in order to automatically perform the conversion of the exchanged data at the very moment of the interaction. This mediation deals with heterogeneity at three levels:
1) Data-model mediation addresses the differences between the data models by each end of the communication. This mediation is possible when every stakeholder shares the same concepts but from different points of view. Typically cultural and organization issues arise at this point.
2) Data-format mediation faces the reconciliation of the different forms that the data may acquire in IT systems. Even when two stakeholders share a common point of view for a given concept, they may use different data structures.
3) Protocol mediation for the communication between emergency agents. This is particularly relevant to ensure effective communication in SOA environments, where services from different providers have been created without a general picture of the interaction workflow.
As a summary, the technical approach used by this project involves applying innovative data mediation components to resolve the current challenges in service-oriented architectures, by means of indirect translations via a common, modular-designed ontology.
PROJECT OBJECTIVES
The project target outcome is an integrative and modular ontology for establishing a common knowledge structure between all the first responders involved in an emergency, but being compliant with legacy international data formats exchanged in the European Union as long as being seamlessly integrated within current SOA-based Emergency Management Systems.
A twofold solution has been developed: a common and modular ontology taking into account different cultural, semantic and linguistic issues (named EMERGEL); and, from that point, the implementation of a transparent Service Oriented Architecture providing mediation algorithms compliant with current data formats and existing solutions (the whole solution named DISASTER system).
The development of an integrative ontology was done through a set of scenarios involving end users for collecting all the requirements related to the emergency management arena. This information is the basis for modelling in an appropriate way the common and cross-domain knowledge of stakeholders surrounded by cultural and linguistic issues.
Seamlessly integration within current SOA-based Emergency Management Systems, was faced in two parts. Firstly, technical mediation components were designed and developed able to adapt current European data formats to the resulting data model. Secondly, these mediation components were adapted to be integrated in legacy SOA-based Emergency Management Systems by means of a middleware component designed for linking those legacy systems with the mediation common ontology
.
The global objective was detailed in the following scientific and technical objectives:
O1: Designing a reference architecture and providing a general approach to solve interoperability problems in data exchange in current SOA-based Emergency Management Systems, addressing interdisciplinary environment when dealing with emergency management at a European level.
O2: Designing and developing an integrative and modular interoperable data model. This objective may be split into two specific sub-objectives:
O2.1: Designing and developing the core framework data model, common to every stakeholder involved in emergency management.
O2.2: Designing and developing complementary transversal (spatial and temporal) & vertical (domain-specific) modules.
O3: Analysing, designing and developing mediation techniques, a set of bridges, enabling a transparent to the user integration of the resulting data model within already-existing SOA-based Emergency Management Systems.
O4: Defining, designing, developing and executing and specific implementation of the resulting technical approach. This will enable a validation pilot phase on actual environment, based on a representative scenario, in order to get feedback from end-users through the entities involved in the consortium, as well as evaluate project’s outcomes and their benefits to the European multicultural domain related to emergency management
Project Results:
WP2: THE DISASTER APPROACH
WP2 within the DISASTER project provides the basis for the development of the common modular ontology EMERGEL as well as for the development of the gateway. Therefore, objectives of WP 2 have been manifold. Starting from the scratch, basic requirements have been compiled. Possible scenarios for ensuring a practice-based development approach have been identified in an expert’s workshop. An online survey among emergency reaction professionals delivered profound insights in stakeholder’s requirements. A collection of differences and similarities with regard to legal, linguistic, semantic and cultural issues has been created. Finally, technical implications have been defined and the reference architecture and data model approach has been developed. In summary, WP 2 provided the basic research activities to build the further project work upon. This report will point out detailed the scientific and technical results of WP2 during its operational time from month 1 to month 18 in the project timetable.
END-USER REQUIREMENTS
To find out about the very requirements which emergency management stakeholders could have in an IT-based interoperability solution, an expert’s workshop was held at Cologne University of Applied Sciences. As a result, two scenarios were chosen to be the “guide” of the gateway and ontology development. “Air cargo scenario” deals with a plane carrying dangerous goods crashing down at an international airport. Main objective of this scenario is to point out the complexity of intraorganizational cooperation in the highly complex surrounding of an airport. Stakeholders with completely different aims, tasks and competencies must react sufficient in an ad-hoc crisis situation. Safety and security matters as well as business processes must be considered to bring the situation under control. Though all organizations in airport operations speak the same language, use the same semantics and are under the same legislation, establishing inter- and intraoperability poses a great challenge to an IT-based solution.
The second chosen scenario, “Moor fire scenario”, is about a large surface fire between Germany and The Netherlands based on a realistic incident. Stakeholders such as fire brigade, emergency medical service, police and technical relief from two different countries must work under close cooperation in a common operational situation. Different languages, semantics, responsibilities, legislations and command structures impede an uncomplicated management of such an event. Therefore, this scenario is a good example of how the DISASTER solution can enhance cross-country cooperation by bridging the gaps between varying management systems. It also points the importance of a common operational picture. Translation and mediation of tactical icons and symbols is the key for a common understanding of the situation. Connection of IT-based management systems and enabling cooperation between stakeholders is the main objective of this scenario. Both scenarios have been described in detail in WP 6.
Besides scenario definition, an online survey was undertaken in the scope of WP 2. Aiming on emergency responders and decision makers, the survey produced a profound insight in stakeholder’s actual requirements. This creates a practical approach of research and ensures stakeholder’s acceptance in the developed DISASTER solution. Most participants of the survey were experienced in firefighting or emergency medical service organizations. The survey clearly stated out, that most of the participants have experience in using radio communication, electronic data transfer and situation maps. Especially the fact that collection of information is mainly done with situational maps and with IT supported systems, and that implementation of electronic support is highly accepted, can be interpreted as a proof for the high relevance of the DISASTER project’s research.
INFORMATION MANAGEMENT AND REFERENCE FRAMEWORK
It is obvious, that “information” and “information sharing” are keywords of pivotal relevance in the work of the DISASTER project. In the end, the major goal of the project is to enable a technical solution to share information between stakeholders in an emergency situation. Handling of information and data in a defined situation (as a major incident is for sure) always takes place in a reference framework. The reference framework in major incident situations is defined by the state of knowledge and experiences of the operational forces. The importance of a broadly based reference framework heightens simultaneously to the level of responsibility. As an example, a firefighter in an incident has to execute commands. That means he has to fulfill tasks like extinguishing a fire, provide technical relief or safe people from a dangerous situation. He is able to do so, because he was educated in these tasks and fulfills them in his daily work. What about a decision maker in major incidents? He has to deal with the whole picture of an incident. Obviously, he needs a highly complex reference framework or must be able to create himself ad hoc a new framework based on past experiences. Therefore, he might depend on assistance. This assistance can be provided by advisory staff personnel and/or by electronic devices. Since information exchange always includes the danger of information erasing, changing and creating, challenges to a technical solution are highly complex. Considering cross-border incidents with language barriers etc. the DISASTER solution provides sufficient support in information exchange, handling, interpreting and understanding. Therefore, legal, linguistic, sematic and cultural issues have to be addressed.
LEGAL REGULATIONS AND NOMENCLATURE
Though the European Union is a merger of 28 member states, each state has its own governmental structures and legislation.
These structures differ a lot among the participating states. The DISASTER project does not aim to achieve any changes in legislation or emergency management structures, but to improve close cooperation in occurring cross-border disaster events. Arising from this premise, awareness of legal, linguistic, sematic and cultural differences must be considered within all research activities. Comprehension and compliance with these differences paves the way for the development of a common ontology covering all relevant contents.
As stated before, the EU consists of 28 member states. That means the DISASTER project has to deal with an enormous amount of legislation, laws and regulations. Nevertheless, a general understanding of governmental structures is vital since these structures have direct influence on the respective emergency management structures. It seems obvious, that considering all 28 member states would be way beyond the scope of the project. For that reason, research was limited to the five member states of the project consortium, namely The Netherlands, Spain, UK, Denmark and Germany.
Since state-building varies a lot among EU member states, a methodology was developed to point out on which levels responsibilities for emergency management are located. For that reason, description of authorities was split up into national, regional and local level. In federal states like Germany or Austria, responsibilities in emergency management are distributed to the regional level (federal states). On the contrary, in central states like France, Denmark or UK, responsibilities are primarily located on national level. To ensure interoperability between stakeholders, it has to be clearly highlighted on which level the corresponding contact person is located. This enables information exchange between the correct sender and receiver and minimizes the risk of derogation in information flow. Furthermore, a basic knowledge of emergency management legislation provides a deeper understanding of each other’s procedural methods. For that reason, WP 2 also provides tables displaying the legal basis of fire services, emergency medical services, police forces and, if existing, specific disaster coordination. These tables also point out regulations for leadership and command, crisis management and operational level and can be seen as a guideline in complex administrative networks.
LINGUISTIC AND SEMANTIC DIFFERENCES, CULTURAL BACKGROUND
One of the greatest challenges to be addressed by the DISASTER project is the fact, that within the European Union 24 official languages exist. Since communication is vital in emergency management operations, a methodology to deal with these language barriers is crucial. To make things even more complicated, speech in emergency management is characterized by a very special and technical terminology. This often impedes one-to-one translation of terms. Consequentially, not only linguistic but also semantic translation must be provided in order to avoid misunderstandings. What does that mean? An example: a fire truck in Germany might look almost the same like one in The Netherlands or the UK. But in reality, the operational team, technical equipment and capabilities might differ a lot. So a general structure of definitions and descriptions of terms in emergency management was defined in WP 2. This ensures a common linguistic and semantic basis and is of high relevance for the EMERGEL ontology.
Besides linguistic and semantic terminology, symbols and icons play a major role in the emergency management field. Most emergency management systems display operational areas by using operational maps. Units are not displayed via plain text but by icons, symbols or pictograms. Every icon includes specific information. E.g. a single ambulance or fire truck, fire company, helicopter landing place, command and control units, dangers etc. Since a major goal of DISASTER is information sharing by using these operational maps, these icons have to be mediated to enable a common understanding of the situation. Therefore, WP 2 provides a collection of icons and their meaning to be included in the ontology. A whole lot of icons from as much European and even non-European countries as possible were collected by applying international contacts of all consortium partners. Result is an extensive collection of icons and descriptions which adds high value to EMERGEL.
Even cultural peculiarities have been part of the work in WP 2. Mainly concentrating on governmental structures, emergency management and health care systems, relevant similarities and differences have been explored. A deep understanding of cultural background in participating countries enables a better sense for requirements to be fulfilled by the DISASTER solution.
TECHNICAL DEVELOPMENT APPROACH
In addition to end-user requirements, legal, linguistic and cultural requirements, WP 2 also dealt with technical requirements concerning EMERGEL ontology development, reference architecture and data models.
To find out about the very requirements for the ontology, a workshop was held in the beginning of the project. In order to make DISASTER a power- and useful tool to a broad audience of stakeholders, these domain-experts were included consequentially into the requirement compilation. The applied methodology created results which are in step with actual practice. Questions arising in an actual disaster situation were asked by domain experts, the answers were taken as requirements for EMERGEL. For example, the question “in which geographical point is the incident located?” leads to the fact that EMERGEL must be able to deal with data schemata such as NeoGeo, wgs84 and GeoSPARQL.
By defining the mediation workflow within the ontology, it was possible to derive requirements from every mediation step. The workflow consists of four steps: data acquisition, data alignment definition, data alignment execution and data exploitation. Resulting requirement were assessed and rated in a points-based system from 1 (optional, nice-to-have) to 5 (highest priority). This compilation of requirements provided the basis for the actual technical development of the ontology and has influence on other WPs.
Furthermore, WP 2 defines the DISASTER software architecture including the data model approach of the gateway components. Since emergency management systems do not use standardized data models, the connection of legacy system needs to be enabled by using data mediators. That means, DISASTER must provide a mediator which allows an EMS to use external data but transferred into its own data model, protocols, format etc. An example: two legacy EMS shall be connected via DISASTER solution. EMS 1 (Dutch side) has important information to share with EMS 2 (German side), e.g. an ambulance icon on the situational map. The output mediator receives this information from EMS1 and transforms it into RDF (Resource Description Framework). The DISASTER kernel is now able to process this information via EMERGEL ontology. The Dutch ambulance icon is mediated into the German icon. Via input mediator, the German EMS is now able to consume the information and display the icon with the correct design on the correct place on its own operational map. Interaction within in the DISASTER software architecture is enabled by using the Service Oriented Architecture (SOA) approach. Consortium’s domain experts chose this approach because it entails the possibility of bridging the gap between IT experts and emergency management stakeholders.
The scientific and technical results elaborated in WP 2 provide a broad basis for following and parallel running WPs. It highlighted end-user requirements, legal, linguistic, sematic and cultural issues to be concerned within the complete project runtime. Furthermore, it paves the way for the technical development by providing the data model and software architecture approach to be used in further work packages.
WP3: EMERGEL: THE EMERGENCY MANAGEMENT ONTOLOGY
The main outcome of WP3 is the EMERGEL ontology. EMERGEL (EMERgency ELements) is a modular ontology whose first cornerstone was an initial, thorough state of the art, which took into account previous work, formal languages and technological choices, as well as a solid anchoring on the domain to be dealt with. It is a modular vocabulary because it was compartmentalised in different modules from the very beginning.
The methodology followed to model the EMERGEL ontology involved an initial definition of semantic-coverage requirements, carried out in WP2. This task was complemented with the identification of existing ontologies and non-ontological domain resources that partially covered an aspect of the ontology. As a design decision, the ontology is modularised, i.e. application of ontology engineering guidelines to divide and structure the knowledge domain in meaningful segments.
This process finally led into a vocabulary composed of a core (abstract, upper-level ontology including transversal modules, namely spatial and temporal representation) and vertical modules (associated with specific domains). The W3C OWL2 ontology language was selected to describe the DISASTER data model.
One of the ways to determine the scope of an ontology is to chalk out a list of questions that the ontology should be able to answer. Competency questions are targets for what an ontology should be able to cover, given sufficient facts (i.e. data) in the knowledgebase. These questions served as a test and helped to find out if the ontology contains enough information. The answers assisted the ontology experts to work out the requirements for the level of detail needed or the representation of a particular area. The competency questions are just rough drawings and do not need to be exhaustive. To capture the requisites for the core ontology a number of competency questions were conceived during the first steps of the project. They were discussed by the consortium and included in Deliverable D2.40. The initial version of the core module of the ontology was grounded on those questions, which covered a number of wide subjects as time, space, resources, agents, etc.
The first and main module is the Core framework. This core module is a lightweight vocabulary limiting its scope to agents and events. EMERGEL uses some upper-level classes belonging to the DOLCE+DnS Ultralite (DUL) ontology. DUL is a simplification and an improvement of some parts of DOLCE Lite-Plus library and of the Descriptions and Situations ontology that provides a set of upper level concepts that can be the basis for easier interoperability among many middle and lower level ontologies.
In this aspect, to model what is involved in an emergency situation, EMERGEL uses dul:Event and also dul:PhysicalObject, two classes belonging to DUL. To model agents and roles, as it will be more specifically presented later, EMERGEL uses FOAF and WAI. FOAF is a vocabulary to describe people, the links between them and the things they create and do. To model people and groups EMERGEL reuses the FOAF classes foaf:Person and foaf:Group. WAI is a vocabulary aiming to extend the FOAF specification through introducing the concepts of roles and profiles. From WAI, EMERGEL takes foaf:Role, foaf:Profile and foaf:Context.
A disaster is defined as a natural, man-made or technological hazard resulting in an event of substantial extent causing significant physical damage or destruction, loss of life, drastic change to the environment or simply damage to property. It can affect and destroy the economic, social and cultural life of people. That kind of events stem from other events such as earthquakes, floods, catastrophic accidents, fires, or explosions. EMERGEL thus interprets a disaster as a kind of event. Therefore, an upper-level class is introduced: emergel:EmergencySituation as subclass of dul:Event.
The different agents involved in an emergency situation are modelled in EMERGEL reusing the WAI ontology, a vocabulary to describe roles and profiles. By using WAI, it can be smoothly attached to a given person different roles and profiles: a person can be for instance a fireman or a victim depending of the context or the moment within the emergency situation. WAI provides a class wai:Role and the corresponding property wai:plays to link up individuals and roles. This strategy was also applied by the DOLCE ontology, but with a general knowledge representation purpose. WAI instead is a specifically dedicated vocabulary to represent people and a given person can play more than one role.
Roles can also be arranged in a hierarchy of entities in a similar way as ontology classes are organised via a subsumption relation. For instance, a fireman can be specialised into a fireman corporal, which is also specialised into a fireman corporal of Germany’s fire brigade.
WAI introduces a primitive property wai:specializes able to capture these hierarchies of roles, thus allowing more generic roles to be successively refined into more specific ones.
Profiles are entities capturing the dynamic and temporal aspects of roles. Profiles are introduced to cover this knowledge representation gap. Roles are not inherent to people, as they are not essential properties. Profiles (wai:Profile in the ontology) are a mechanism allowing to refer to people when they are actually playing a particular role, i.e. “person-as-role”.
Profiles using WAI do not necessarily need to refer to a role. When contexts and groups are used to fix the interpretation coordinates of the profile, roles may be implicit. In this case, a profile is considered a “person-at-context” or a “person-in-group”, rather than “person-as-role”. Nevertheless, none of the three are exclusive but complementary.
The two Transversal Modules considered in EMERGEL are space and time. Other possible transversal modules, such as magnitudes, are not considered, as the primary focus of EMERGEL was to deal with the specific Proof of Concepts of the DISASTER project. However, the alignment of EMERGEL with the Measurement Units Ontology (MUO), a vocabulary implemented by CTIC, is an interesting future movement.
Regarding spatial representation of an emergency situation, EMERGEL introduces a pristine ontological distinction between the involved conceptual layers: (1) features, (2) geometries, and (3) feature-types classifications related with cartographic visual representation (i.e. maps). This distinction eases the reconciliation between the geographical-feature description of emergency entities and a pure geometrical representation of the space.
A common modelling choice in geospatial science is a distinction between a Feature and a Geometry, where the former is an entity in the real world with some spatial extent, such as airports, monuments, hospitals, hotels, etc. and the latter a geometric shape, such as a point, polygon or line.
In DISASTER, it is assumed that geographical information is captured by the NeoGeo Vocabulary, which provides the distinction between features and geometries by means of spatial:Feature and geom:Geometry classes. The property geom:geometry is used to reconcile both facets of the same geographical entity. URIs (implicitly) denoting a geom:Geometry might have any format based on HTTP content negotiation.
Finally, the visual aspect of maps is conformed by style guidelines. The styling of a map is aligned with final user visualisation requirements, i.e. the same geographic information is often presented with different styling according to the intended audience. Thus, styles usually conform to cartography style manuals or follow symbology standards to assure proper understanding. In this line, we can refer to maps as human-readable artefacts to visualise geospatial information. There are different maps depending on the kind of the visualised information: geocharts, i.e. statistical data associated with spatial information presented as maps; political maps, i.e. maps that emphasise the division of territory according to governmental directives; or physical maps, i.e. maps that represent the properties of the terrain such as mountains, rivers or lakes.
The style assigns a number of visual properties to each feature. The nature of style is dual, as it assigns graphical representations to concepts. EMERGEL captures this double identity of styles by linking features to SKOS concepts, and then SKOS concepts with graphical representations. We associate a neogeo:Feature to a skos:Concept using the dct:subject property. Finally, concepts can be linked using the property emergel:prefStyle to specific emergel:Style instances, which are in charge of containing, or linked to, their graphical representation.
As far as time as transversal module is concerned, an instant-based model is proposed as instants provide snapshots of a situation at a given moment. In other words, it is obtained a full vision of an event without considering evolution in time. This is important in order to guarantee interoperability between information systems and to come up with easily translatable visualisations. An interval-based interpretation of time does not disappear, but it is implicit in the 4D approach of the ontology, as every entity is a composition of successive temporal parts. We restrictively introduce the class dul:Event in the ontology, as a generic and broader concept meaning “something that happens” and “the occurrence of a process or a phenomenon”. Events are inherently time intervals, and so they can relate each other by means of the Allen’s temporal algebra. For instance, “the fire started before the explosion in the factory”.
The ontology introduces timeslices and fluents to provide the diachronic perspective of time. Timeslices represent the temporal parts of a specific entity at given snapshots in time (i.e. instants). Fluents are properties that hold at a specific moment in time, or at a specific interval in time. In other words, fluents and timeslices represent a vocabulary to capture temporal parts of individuals that change some property in time. This model however is combined with the W3C’s Time ontology, as it specifically covers with a rich model other aspects such as time zones.
EMERGEL establishes its Vertical Modules in a slightly different way than the core ontology. As to feed these vertical modules both at the class and the instance levels it is possible to (re)-use standard classifications, the use of the SKOS (Simple Knowledge Organization System), a standard vocabulary from the W3C used to model the basic structure and content of concept schemes, was decided. Several EU thesauri and vocabularies are available in SKOS and this way EMERGEL concepts can be easily mapped to concepts belonging to EuroVoc, Agrovoc or GEMET.
EMERGEL Core includes the class ConceptScheme from SKOS and from which more specific concept schemes hang. The list of concept schemes included in the EMERGEL vertical modules have been thatched with a user-friendly, accessible roofing. As the large number of lists, classifications and vocabularies encompasses several domains and present a rich number of divisions, a number of upper-level classes were designed to help the user browsing the vertical modules. In the following sections these upper-level classes are introduced together with their ramifications.
Notice that the vertical modules offer supple, generic upper classes capable of being populated (extended) at any time with new cultural, regional or national realities by means of instances. This way, the vertical modules are aligned with the aim of the EMERGEL ontology ensuring its own wide life cycle.
The EMERGEL ontology incorporates a number of datasets into the aforementioned common representation format SKOS, enabling the specification of semantic equivalences in order to drive data translation processes between IT crisis management systems. The methodology to assimilate these controlled vocabularies consists of a 3-step workflow, defined as following:
1) Taxonomy creation and mapping specification. The domain expert encodes original non-ontological resources and specifies correspondences between them in the form of a table that is specially formatted for further automatic processing.
2) Automatic generation of SKOS taxonomies and RDF mappings (EMERGEL vertical modules). The taxonomies and classifications are automatically encoded in SKOS/OWL. The previous correspondences are automatically extracted from the table and converted to mappings defined in a technical format, i.e. SKOS vocabulary to taxonomies alignment.
3) Execution of mappings. The mappings are available online as part of the EMERGEL ontology. They are used on demand by the mediation component (specified in D4.20) to perform a given data translation process.
Currently there are more than 350 different datasets incorporated into the EMERGEL Vertical modules, not counting their own multilingual versions, which come implemented as different datasets as they introduce an ad-hoc language point of view. Those more than 350 datasets are split into the theme areas defined in the ontology:
* Companies (corporations or business organizations potentially involved in an emergency situation, both as agents or victims)
* Places (Areas with definite or indefinite boundaries, such as geopolitical subdivisions, waterbodies, airports, power stations, etc.)
* Vehicles (aircrafts, ships, etc.)
* Dangerous goods (UN numbers for hazardous substances, HAZMAT classes, radionuclides, etc.)
* Emergency symbols (from different countries of the world and international standards)
* Third-party vocabularies (relevant vocabularies belonging to the EU, etc.)
* Standardisation organisations
* EMSs (Emergency Management Systems)
However, as the EMERGEL ontology is designed to have a vigorous post-project life and it has already been introduced in 2 W3C Working Groups, these datasets are being presently and will be continuously increased, enriched and developed
WP4: MEDIATION COMPONENTS
The goal of the Mediation Component is to provide transformation capabilities that solve the interoperability problems between legacy EMSs in the context of the DISASTER platform. These transformations occur at 3 different levels: protocol, format and data mediation:
* Protocol mediation bridges the gap between systems that communicate with external systems using different protocols.
* Format mediation solves the heterogeneity at the representation level. Information of the same nature can be represented in many formats: on the one hand standard formats, on the other de-facto standard formats chosen by the leading software applications in the field. The format mediation tackles this problem so same information can be converted from one source format to another target format.
* Finally, data mediation covers the transformation of core information, described at the semantic level. When communicating two parties, A and B with different legislation, culture, operation protocols, etc., their systems might reach the point where actual communication is feasible, thanks to the previous two mediation levels: protocol and format. However, information sourcing from A system and arriving at B system is not valuable unless is understandable by B. This understanding can only happen if information from A is translated into a meaningful form, i.e. complying with B schema or model, for party B. This is the chief objective of data mediation: transform information so it agrees to a target schema or model understood by the receiving end. The knowledge required to perform such translations is obtained from EMERGEL ontology, the main result of WP3.
The design of the Mediation Component needs to comply with DISASTER requirements driven by the use cases of WP6. The DISASTER interoperability platform needs to be designed in a fashion that remains open and extensible to potential client EMS systems that might benefit from its interoperability capabilities in the future. With this goal set, it is very important that the design of the Mediation Component does not only handle specific conversions at the three levels described above, but that remains open to new protocols, formats or models while maintaining the rest of existing functionalities.
These requirements are covered by the mediation architecture, which defines two types of components:
* Mediation component: performs model/schema mediation. Shares the name with the global WP4 objective because this is the software part that is vital for the mediation. Without model mediation two EMS legacy systems can reach the point where information is exchanged but the final agents cannot understand it. The implementation of this component was performed using the powerful capabilities of the RDF language, used to describe the relations between different collections/schemes in the form of EMERGEL mappings. These mappings are exploited by a pluggable RDF rule engine, thus transforming the information.
* Transformation adapters: perform different protocol and format mediations. Transformation adapters can be also classified as lifting and lowering components depending on the part of the mediation they cover. Lifting components adapt information from legacy EMS systems offered in different protocols and/or formats and source the information from the mediation component. Lowering components perform the inverse path: collect the information transformed by the mediation component and offer it to legacy EMS systems in the format/protocols they understand.
These two types of components of the architecture need to agree on the way of sharing information between them. The protocol chosen is the SPARQL query language, which is used by each transformation adapter to push or pull the information to/from the SPARQL Endpoint of the mediation component.
As part of the WP efforts, an extensive study was performed to cover the state of the art technologies in the domain of mediation. Alongside this study, a number of software components were developed. The purpose of this task was twofold: 1) breaching the sate of the art in the mediation of some formats identified as highly valuable in context of information interoperability in the domain of EMS systems; 2) serve in the mediations required by the Proof of Concepts of WP5.
The list of software components contains a large number of items, which fulfill various areas of mediation:
* Format mediation components:
* ESRI Shapefile to RDF and KML
* OGC SLD to SVG
* Tabular data to SKOS schemes and SKOS-based mappings
* DISMA XML to GeoJSON
* GeoJSON to ESRI Shapefile
* GML to PNG
* Protocol mediation components:
* WFS to WMS mediation applied to Dutch EMS
* German EMS DSMA XML messages as WFS
* Model mediation components:
* RDF-2-RDF mediation component
While the Mediation Component puts the full potential of EMERGEL mappings at the hand of external systems with mediation needs, its RDF-based interface can be cumbersome to exploit. This is especially true for early prototypes that adapt legacy EMSs, which often use databases or plain text as exchange format. In order to streamline the integration between the available mappings in EMERGEL and the WP5 Proof of Concept Border Fire prototype (PoC-BF), the EMERGEL API was devised under the efforts of WP4. This API offers a query-enabled layer on top of EMERGEL to provide lightweight mediation capabilities as REST web services, thus facilitating the integration with the existing PoC-BF prototype. This API has proved to be a useful way of consuming EMERGEL mappings, after the successful integration of the first integration prototype (PoC-BF), the second prototype under WP5, the Air Cargo Proof of Concept prototype (PoC-AC) leveraged the EMERGEL API to successfully showcase the DISASTER capabilities in a complete different scenario from the first PoC-BF. Furthermore, a third system, completely independent from the WP5 prototypes also benefited from EMERGEL API services. In this case, the Virtual Training Program, under the efforts of WP7, developed a simulation program to train stakeholders in scenarios where DISASTER platform capabilities are available. This simulator is directly consuming EMERGEL API services to carry out the mediation needs when information exchange between different EMSs takes place.
In the same line of the EMERGEL API, new ways of exploiting EMERGEL arose during the execution of DISASTER project. As EMERGEL Vertical Modules increased in number of modules and items, this ontology becomes a valuable resource of information for emergency domain experts. However, its RDF nature made it reachable only to machines and data browsers, the latter lacking basic usability for users not familiar with Semantic Web principles. In this context, the need for an EMERGEL viewer started to grow and drove the creation of SKOSIC, a SKOS viewer with special capabilities for improving the viewing experience of EMERGEL Vertical Modules.
While studying the most wide adopted formats to convey information in the emergency domain, a well-known format surfaced in addition of the expected GIS-related formats: the spreadsheet format. Under WP4 efforts, backed up by CTIC’s expertise in RDF modeling and format transformation, a lifting transformation adapter to extract information expressed in tabular form and convert it to RDF was developed. This module proved to be a cornerstone for EMERGEL Vertical Modules population methodology, which lowers the barrier for stakeholders that need to include their domain knowledge, symbology and terminology into EMERGEL knowledge and therefore DISASTER interoperability capabilities. Spreadsheets proved to be the format of choice for potential users coming from different backgrounds. Users find easy the process of filling tables with their domain knowledge, and the rest of the process that makes this information part of EMERGEL Vertical Module is transparent for the user. The tabular transformation programs executed by the lifting transformation adapter perform this last part of the process. As of this writing, 180 transformation programs were written under this effort.
WP5: PROOF-OF-CONCEPT
The DISASTER project is oriented to achieve the data interoperability between the emergency management systems (EMSs) around Europe. Nowadays, the lack of a standard for this communications complicates this task. The main achievement of the WP5 has been the definition, implementation and validation of a reference architecture to achieve format, protocol and semantic interoperability between the legacy systems. To achieve the results, this work package has structured its actions in three related phases: (i) analysis of existing technical solutions for emergency management, (ii) design and implementation of software components for protocol, format and semantic interoperability between legacy systems and (iii) validation of the proposed technical solution in realistic scenarios.
Analysis of existing technical solutions for emergency management: the deliverable D5.1 presents a technical analysis of different EMS already in use in Europe and this study is made at different emergency management levels. First of all the deliverable presents an overview of the present situation of the emergency management in Europe, analysing what laws applies, national/federal systems already in use and a summary of commercial systems. If there is any information exchange proposal or standard it is included to complete the study. The second point classifies the existing EMS at three different levels. At Governmental level the document differentiates national, regional and local systems, and compares differences amongst the same five countries studied before. At Management level the classification introduces the concepts gold, silver and bronze for strategic, tactical and operational levels respectively, and, once again, shows a comparison of the structure amongst the countries. And last but not least, the Stakeholder level compares how police, fire brigades, civil protection and healthcare services work in each country. Emergency management requires data and information not available directly from emergency brigades, so this information is provided by third-party services. These third-party services are divided in two main types, those that are generic and used in almost any possible scenario, e.g. weather information, and those that are specific services in a concrete scenario, i.e. information from a logistics company.
Design and implementation of software components for protocol, format and semantic interoperability between legacy systems: Deliverable D5.42 describes the specific software implementation of the reference architecture achieved in WP2. The DISASTER architecture relies on two main elements: DISASTER Core and DISASTER Mediator. Disaster Core is the kernel of the architecture and provides a set of functionalities shared by all involved participants. This element is also in charge of managing communications between existing DISASTER mediator taking the role of directory service. DISASTER Mediator plays the role of gateway for each EMS connected to the DISASTER ecosystem. There are two types of mediators according to its behaviour: input and output. Both element connects a concrete EMS to other EMS and existing resources but getting such exchange of information in a local way. In other words, the DISASTER Mediator allows an EMS to use external information but transformed according to its own protocol, format, cultural and linguistic characteristics. Protocols and formats considered by the Mediators include Web Map Service (WMS), Web Feature Service (WFS), Geography Mark-up Language (GML), Keyhole Mark-up Language (KML), Portable Network Graphics (PNG), ESRI Shapefile (SHP), Portable Document Format (PDF) and JSON Geometry and Feature Description (GeoJSON). The DISASTER architecture is defined, therefore, as a network of DISASTER Mediators with a central DISASTER Core. Main software units designed, implemented and integrated into the final solution are mediators, semantic-based mediators, handlers and adapters.
(i) Mediator is a piece of software that may include or use handlers, adapters and semantic-based mediator.
(ii) Semantic-based mediators aim to translate the geographic information provided by a source EMS in a way that a target EMS can understand. This translation transforms the external information to the target EMS own cultural and linguistic characteristics. Concepts are extracted from the source data by the mediator and, consuming the EMERGEL REST API, a mapping between different data schemas is executed.
(iii) Handlers invoked intercepting the messages and modifying the response between client and server. DISASTER implements a handler by each existing geographic protocol used in the most common GIS (Geographic Information System): Web Map Service (WMS) and Web Feature Service (WFS).
(iv) Adapters are in charge of format transformation. DISASTER includes generic adapters providing common functionalities for all EMSs, such as images creations, format transformations, sending information to the DISASTER server, etc.
Validation of the proposed technical solution in realistic scenarios: DISASTER project follows a scenario-based design for research and experimentation where the proofs of Concept (PoC) are the cornerstone. Deliverable D5.32 presents the template used to capture all important information concerning the scenario definition, implementation and evaluation. A PoC is defined from both functional and technical points of view in order to evaluate the solutions in realistic contexts but also to validate the software solutions. The scheme defines a context section where all functional requirements (scenario, end users, etc.) are detailed. Technical requirements (data model, technologies and mediation techniques) are described in specific sections. Finally, an evaluation section describes the results and conclusions obtained after the PoC development. DISASTER projects has defined, implemented and validated two realistic scenarios: Border Fire and Air Cargo.
The basis of the border fire scenario is a real incident that occurred at the Dutch-German border. At November the 03rd 2011 a moor-fire occurred at the Dutch-German Border in the area called “Amtsvenn” near the cities Enschede (NL) and Gronau (DE). An area of about 2.6 km2 of moor and turf soil was affected. The affected area is a nature reserve, which is home for rare plants and a sanctuary for rare animals. More than 1.300 German and 900 Dutch fire-fighters were deployed in order to get the situation under control. To fight the fire and control the burning a tight and intensive cooperation between Dutch and German emergency management organizations was necessary. The fire services on both sides of the border usually cooperate during larger incidents. In every situation with a size similar to the presented the supply-organization in the area is of great importance. The information exchange related to the supply of the deployed emergency personnel needs to be coordinated in the corresponding organizations and its ICT on the one hand and between the different organizations on the other hand. Especially in incidents like this that involve different emergency management philosophies due to the involvement of different countries it is of importance to create understanding of the possibilities and capabilities of the involved organizations. The described situation shows that interoperability solutions for large scale emergency events are important factors to improve the performance of the deployed units and the overall situation management. The easier information can be shared the better the involved units can react to the situation at hand. Since sharing this information is often done by using maps enabling interoperability for maps, symbols and icons is a key factor. The scenario used for the DISASTER PoC is a direct reproduction of the introduced situation at the Dutch-German border. It is assumed that a bush- and turf-fire occurs in the mentioned area that is moving from the German side of the border to the Netherlands, as in the real situation. The implementation of the Border Fire scenario showed the viability of the proposed technical approach. This solution allowed real-time interoperability between German and Dutch response teams each one using its own EMS without any change. According to the evaluation questions the following can be concluded: (i) It is possible to connect two systems in real operation environments. (ii) The connection is stable and secure during the operation. (iii) Technical security is achieved by using WS-Security technology. (iv) All sent messages are received by the receiver. (iv) The receive messages are actually sent by the sender. (vi) The messages are valid in terms of protocols and data formats. (vii) The content of the message is correct in terms of translation and mediation. (viii) DISASTER Core is able to carry out not exacting matching between concepts.
The Air Cargo scenario represents an airplane incident in the Schiphol Airport. An airplane which has just landed at its destination airport Schiphol (AMS, Amsterdam Airport Schiphol) is approaching to its scheduled pier. Because of some technical problem with the brake, the pilot is not able to bring the aircraft to a standstill at the pier. Recognizing the upcoming dangerous situation, the pilot as responsible person and equipped with radio connection to the Airside Control Center (ATC) declares “Pan Pan”. Shortly thereafter the plane crashes in the building of the terminal. The power of the impact destroys the exterior wall of the building and causes massive damage to the plane. A fire breaks out on the aircraft nose and threatens the cabin including the crew and passengers as well as the terminal. From now on, AMS emergency plans take precedence over AMS organization. While first responders are approaching to the incident scene, Regie Center informs the local dispatch center of Veiligheidsregio Kennemerland, MICK, about the incident. Depending on the order to the category of the incident, MICK releases a defined number of units (fire brigade, Emergency Medical Service, police) to Schiphol Airport. The challenge for the DISASTER project is to provide the correct information to the correct stakeholder in the correct time and the correct way (meaning translation/mediation/visualization issues). Each piece of information has an owner, and when this information is needed by any other stakeholder, the data flow has to be triggered in some way. When a mediation is needed (because a stakeholder wants to visualize specify information), DISASTER components get involved in the mediation and begin to transform it in the suitable format. Translation/mediation issues of the respective information have to be solved via the ontology and to be provided to the receiving system. This scenario has been evaluated at Schiphol Airport where a high number of end users were involved. As result of this evaluation, a positive feedback was received and the following points can be concluded: (i) Exchanging digital information and integrating data from different sources can help in the process of emergency reaction. (ii) Each organization receives only the necessary information. (iii) Incident information is exchanged in an efficient way. (iv) The information is presented in a friendly-user way to each stakeholder according to the format and cultural characteristics they are familiar with. (v) Incident information updates are presented in real-time to each receiver. (vi) Multiples devices, such as laptops, personal computers, tablets and mobile phones are able to query the information at the same time. (vii) Information are provided by DISASTER using standard protocols and formats so a high number of EMSs can consume this information. (viii) Extensibility can be achieved by implementing light-weight adapters.
WP6: DEMONSTRATION EXERCISES
Summary of Main WP6 Achievements.
The original objectives of WP6 have all been fully achieved:
1 - match functional semantic and symbolic prototype design with use case scenario.
2 - develop and implement technical interfaces between prototype and actual EMS.
3 - design and execute validation exercises from use case scenarios.
4 - evaluate and analyse the test results.
5 - deliver guidelines for European interoperability of emergency processes (via EMS).
WP6 objectives were addressed in an iterative fashion because the First Responder (FR) organisations requested early and realistic demonstration and exercises to test conformance with their requirements. Additional realistic testing meant all objectives became active earlier in the project for early learning.
Summary: Scenario and Prototype Functional Design produced 2 realistic scenarios (Moor Fire and Airport Collision) chosen for their relevance to FR, and for their coverage of different Interoperability problems. That work enabled Prototype and Use Case Technical Design concerning functional requirements, information to be exchanged, and necessary map related data. Development work then provided two semantic interoperability prototypes for deployment in two realistic field exercises addressing the two scenarios. The results of the realistic field exercises were then analysed and reported according to project objectives. The results of testing with key stakeholders in realistic settings clearly demonstrate that the DISASTER investment, supported by technology developers and stakeholders, created a clear pathway for interoperability. The results can be further deployed in Europe to ensure cross-border and cross-institutional collaboration where combined knowledge and capacity are required to effectively manage crisis events..
Scenario and Prototype Functional Design Work.
The project plan for Test Scenarios addressed 2 realistic exercises demanded security service partners.
Moor Fire - The first test scenario and its exercise were derived from the actual historic event-timeline (2011, Moor Fires at a Dutch/German cross border region). The information exchange requirements of key actors were identified and the stated priority of Responders was to “see” across the border using EMS maps, and to have icons and terms on both sides displayed in the chosen language. This process fed the Scenario and Prototype Functional Design which were published at GI4DM 2012 in parallel with the test.
Airport Collision - The second test scenario and its emergency exercise (Schiphol Airport Collision incident) was derived from various incidents. The scenario involved brake failure leading to on-ground collision between an aircraft carrying passengers, and a hangar building containing people and flammable materials. Critical Interoperability issues of concern to Schiphol Airport and its safety partners (exchange of data between regions, safety services, companies, and international actors) were addressed. The timeline and information exchanges defined by VRK formed the basis of planning for the field exercises and evaluation.
Technical Design of Prototypes and Use Cases.
Scenario 1 – Moor Fire - The partners investigated the technical and semantic match between the prototype functional design and the VRK operational crisis management system to ensure that needs would be met. Scenario information and protocols were analysed and information gaps were accounted for in the design of prototype V1 for the first exercise. Existing icons, terms, and map layers were included.
Scenario 2 – Airport Collision – The results of exercise-1 and historic Aircraft crisis data were analysed to deliver a scenario timeline and supporting data exchange events. The resulting crisis process model informed update of the prototype design to meet the functional requirements of the new scenario. Map data were provided by VRK, along with needs for information exchange and usage. Discussions with developers of tools used by VRK, along with VRK key staff, helped define the updated technical strategy.
Technical Design - In both cases, discussions with national and regional process innovators and experts allowed inclusion of design issues relating to emergency management; timeframe for information sharing; necessary level of detail and decision making level; usage purpose; clusters of systems; organisational barriers; likely user understanding; interoperability between the different systems involved; fitting information to the purpose and the moment in incident management. The delivery of the technical design of the DISASTER prototypes was achieved as planned (DISASTER platform and EMERGEL ontology) integrated with the LCMS architecture and interfaces to other systems.
Building the Prototype and Technical Detailing of Use Cases.
The semantic interoperability prototype was developed in 2 stages matched to the 2 exercises, based on discoveries from analyses in (iterative approach). Initial developments focused the textual ontology, the mediation tool for symbol association, the mapping of ontology objects and symbols to geographical data, and the practical arrangements for EMS-EMS communications. The second version of the prototype enhanced EMERGEL and the Mediation Platform to respond to discoveries in the first exercise, and sensitised to the new scenario requirements. A series of performance-oriented tests were defined to allow the technical partners to observe and monitor technical performance prior to deployment. The main activities and outputs were: Information and support service detailing; Ontology service, Geographic data service; Mobile vehicle terminal configured; Performance tests demonstrate PoC and confirmed readiness for deployment in the exercises.
Setting Up and Conducting Validation Exercises.
The schedule for validation exercises started early to allow realistic demonstration and field exercises, with a suitable time period between, allowing First Responder and Designer reflection to maximise impact at the second stage. Validation exercises used the agreed test scenarios, and VRK exercise methods were adapted.
Setup and Testing of the First Scenario : Moor Fire
Scenario History: Moor Fires initiate Peat Fires that travel underground. The cross-border region between Enschede (NL) and Ahaus / Gronau (DE) is prone to such fires, and at the last incident 350 fire officers from NL/DE cut into burning ground to expose the fire layer for water treatment. They faced significant risks (hot areas not always visible). German military mapped heat with thermal images by helicopter, but could not transfer these to NL security, so commanders had coordination problems.
Validation Exercise Overview: Large scale exercises are held by Dutch authorities at the Military Airfield at Enschede, directly adjacent to the geographical location of the Moor-Fire Scenario. The national military communications network (I-Bridge) was used, and the exercise engaged military personnel, regional fire service personnel (who had worked in the actual scenario), German fire experts, and a Dutch National Security Forum (Studio Veiligheid). The exercise was run in parallel to the annual GI4DM conference, and so researchers were “bussed in” as observers (and post-exercise interviewees). Equipment included various command vehicles, and field tents where command groups met – all had access to display screens to view LCMS (Dutch National EMS). The exercise methods of VRK were adapted, and external actors engaged (cross-border agency, crisis teams, airport, etc.). VRK and the project partners successfully designed and conducted an exercise to fully test the prototype data/information support. Commanders and staff used the enhanced LCMS (with added German maps and map data) to prove the concept, and noted that the prototype covered the information gaps (cross-border semantic/symbolic interoperability) identified by commanders during the analysis phase. The demonstration ensured commitment from VRK commanders and staff, and from the commanders and staff of the regional services present at the airfield exercises. LCMS was effectively linked to other EMS and data systems relevant to Interoperability at European level.
Setup and Testing of the Second Scenario : Airport Collision
Scenario History: There was an established history of discussion and negation between airport operators and all safety stakeholders concerning exchange of information during crisis events. A range of imperatives was recognised, and a range of organisational and user needs were already well identified. VRK negotiated the use of a working aeroplane, hangar space, and staff from all key stakeholders so that the DISASTER PoC solution could be demonstrated within the airport in a realistic exercise.
Accidents (e.g. air crash) and other crisis events (e.g. dangerous cargo) challenge stakeholders in working together because established protocols have restricted exchange of information between local actors (on site), and exchange of information with international actors (cross-border). Passenger lists, cargo manifests, aeroplane technical details (especially if adapted) have been very hard to access in times of crisis.
Stakeholders have been searching for a safe experimental opportunity to test secure and trusted exchange of information: agencies who determine protocols need to be convinced of secure exchange capacity; staff working in crisis need to examine new devices and information delivery in realistic usage.
Validation Exercise Overview: VRK arranged to use Hangar space at Schiphol airport, along with a working aircraft, volunteer passengers, and active information systems. They then engaged military police, airport fire safety staff, and regional fire service personnel, along with Studio Veiligheid (National Security Forum), and providers of trusted external systems (e.g. CityGIS). The exercise was run at Schiphol airport in the manner of a normal exercise (crews respond to an alarm call as if in a real crisis).
The exercise involved deployment of ground vehicles, responder staff, and command support. Current First Responder exercise methods were adapted to include new devices (hand held tablets) and new procedures (information exchange). The exercise engaged a range of actors in realistic activities: Regional Mayor; Amsterdam Airport Schiphol; Schiphol Airport Emergency Centre; VRK Regional Emergency Control Room; Transavia (aircraft provider); Regional Medical Emergency Service; Airport Medical Service; Koninklijke Marechaussee (Royal Constabulary); Noord-Holland Police; Airport Fire Service; VRK Fire Service; Air Traffic Control; Schiphol Customs Control (Freight data) and CVO Schiphol Operations.
Commanders and staff were involved in realistically using the enhanced LCMS, enhanced CityGIS, and other information services via normal displays, demonstration displays in the Aircraft Hangar, and in hand held tablets used by fire-crews and support staff around the runways and adjacent areas.
Analysis of the Test Results.
The test results from both exercises were analysed to show the benefits of the DISASTER solution, and to deduce lessons for EU interoperability of EMS.
The first exercise (Moor Fire) provided clear results from a realistic demonstration. Evaluation activities engaged all potential users (Gold, Silver and Bronze level, plus the various support staff present). A range of evaluation methods engaged all Stakeholders, and the results identified topics for investigation in the second exercise. Participants were impressed with the exercise demonstration, and could easily see the benefit of having a Common Operational Picture (COP) based on real data from participating regions.
The second exercise (Schiphol Airport Collision) involved a wider range of actors and information exchange challenges. Data were again gathered by a range of methods to cover the complexity of sub-events and evaluation challenges: a University team of process observer experts focused process; an Ergonomist observer focused individual staff usage; an Expert Responder observer team focused Emergency Management; and a Technical Support team monitored system performance and technical issues. Data from these sources and accompanying evaluation activities were analysed in a detailed evaluation of the overall Emergency Management Process. Challenges identified for stakeholders (e.g. changes to organisational process), and for technology (e.g. adapting hand held device usage to new situations). Safety regions identify the need to consider changes in procedures and protocols to exploit new opportunities, based on the enhanced common operational picture and easier collaboration, include more effective response and faster down scaling of emergency operations, thereby causing less disruptions of the business processes.
Both exercises showed that semantic mediation can “open” LCMS and other information systems to exchanges with other data systems relevant to Interoperability at European level. This is supported by clear observations of how different responders can collaborate better because of enhanced and easier information exchange for greater awareness and more rapid response.
Presentation of the results to high-ranking policy makers concerned with safety and public security provided very positive feedback and support. DISASTER exercises showed that technology is now at a high level of readiness - policymakers can now concentrate on organisational collaboration.
WP6 Added Value
In response to guidance from project reviewers, WP6 completed a set of studies to show that EMERGEL can accommodate interchange and semantic interoperability between many more National sets of icons, lexicons and explanations. As a result, EMERGEL now covers eighteen (18) countries. A further parallel study was conducted to show a range of Emergency Management Systems and their opportunities for interoperability using EMERGEL and the mediation platform
WP7: THE VIRTUAL TRAINING PROGRAM
The virtual training program developed by the DISASTER project is completed and ready to be used. The primary focus of this is training tool are first responders working where cross border operations are likely. However arising out of the DISASTER project, we have learnt that need for this type of training tool at a national level is of great importance. Different agencies working in the same environment such as airports or simply different first responder agencies (Police / Fire / Ambulance, etc.) working in the same region / county need to increase their understanding and awareness of other first responder agencies terminology and methods of working. Shared understanding will allow a more informed common operational picture to emerge quicker and therefore not only improve operational effectiveness but also operational efficiency which is very important at this time of austerity. The ultimate beneficiaries of this shared training are not only those agencies but the public they serve.
The final potential beneficiary from this training programme are also private companies as part of their resilience training process and this sector will allow strong links to be formed between this deliverable and the projects exploitation strategy.
In the first version of this deliverable we referred to this training program as a great alternative to real exercises, as they are costly and logistically demanding. This constitutes a bridge between the “tabletop” exercise and the real exercise, as the program can add realism, without having to use a lot of resources. The training program runs on standard computers and the only equipment needed is a headset, as the voice communication is recorded through it. This has been seen as a great strength by the end-user community who have the duty to train for disasters and crisis situations but operate within several financial constraints.
The training tool will be an excellent dissemination / exploitation asset for the post project dissemination period, as it is not only designed to develop better communication competences, but it also uses Emergel which has been developed under the same project. The maps that are used in the scenario built for this game can be used as an information source for all players, no matter where they come from. It is possible to add icons to describe the situation in the field and use Emergel to translate the icons to the receiver of the information. This way, we can assure that all actors involved do get the same information and have the same understanding of the situation. This definitely contributes to a better communication and a faster reaction time- In short it demonstrates the value of a common operational picture to all involved in the crisis.
The concept:
The training program has been design in order to give the opportunity to first responders, to train their competencies, more precisely, their communication competences. Communication and information / data sharing in major cross border incidents are complex and challenging. Training on this area is crucial to response during a disaster. If first responders are well trained, they will be more likely to respond effectively and rapidly. This also means that they will be more likely to save lives. As saving lives is one of the most significant purpose for first responders, we know that this training program will be relevant to societies within the EU.
The scenario:
For this training program, a plane crash scenario is used throughout the exercise.
The scenario is a passenger plane, crashing on the bridge between Copenhagen Denmark and Malmö Sweden. The scenario was chosen as it illustrates well the cross-border cooperation and involves many actors. It will also be applicable to other EU countries, since they all have airports, they will be able to adapt the scenario for they needs.
This scenario is not linked to the scenarios we will use to test the DISASTER data model, so it is not to be confused with.
IT structure:
The main core of the IT structure is build up to support the game play of the chosen scenario, the figure of the core and the game play structure. The core is able to handle communication in the virtual communication network via phone, email, text, mobile phone and radio, between the units or the incident handlers chosen to take part in the exercise.
[See figure 1.3.6.A: IT Structure]
The core is working just like the crisis communications system of the different EU countries.
But the communications tools have to be defined by each country/role, participating in the exercise.
The core is able to support any given scenario. That means that if any emergency service would like to add scenarios to this core, they will be able too. Then, they will have to develop a playbook and guidelines for the chosen scenario.
The user interface:
The user interface gives the possibility to communicate via landline, radio, text message, map or e-mail.
[See figure 1.3.6.B: The user interface]
The electronic log is another important functionality of the program. With it, it is possible for the instructor to make an evaluation of the exercise and give feedback to the participants. The log function demonstrates clearly all actions taken during the exercises, so it is easy to detect the problematic areas.
[See figure 1.3.6.C: The timeline of the log book]
Finally, the last feature we would like to focus on is the link between Emergel and the training program. Indeed the training program has a direct link with Emergel, which give the possibility to the participants to use the map and symbols in any language available in Emergel, and other participants will be able to see the symbols in the language they choose. For example, a participant playing the Danish fire brigade, can place a Danish symbol for a fire truck on the map and share this map with the other participants. A participant playing a Swedish fire brigade officer can press the button “translate icons”, and he/she will be able to see the equivalent symbol in Swedish.
[See figure 1.3.6.D: Symbol on the map]
Potential Impact:
POTENTIAL IMPACT
The analysis of potential impacts of the DISASTER project is based on the assumption that a more effective emergency management operation leads to a benefit for society. Events such as the floods in eastern and south Germany in the summer of 2013, and of course the repeated forest fires in southern Europe, once again show that cooperation between emergency management organisations and other organisations is a key factor for an effective and efficient operation.
Of course, with the rise of electronic support systems and electronic information exchange the need for interoperability solutions is obvious, though still challenging. It can be assumed that an improved information exchange and an improved cooperation between emergency management and other response organisations throughout Europe will lead to a more efficient and more effective response in times of crisis and emergency.
Improvements in emergency response resulting from the DISASTER project will have a direct impact on society, especially in the affected areas. The overall impact on society can be summarized as follows:
- More effective emergency response leads to increased safety and security of citizens, business, and infrastructure, as well as visitors/ tourism.
- If an incident is handled more efficiently, then there will be a reduced need for resources, as activities won’t be duplicated by responders from different countries.
- More efficient emergency response should mean that the greatest extent of disruption for any given event is lowered, because the situation is brought under control more quickly. This in turn means that less people will be affected by the incident and that the impact is reduced for those who are still affected. In turn, this also means that the return to ‘normalcy’ will be more expedient, as the damage will not be so great.
- More efficient emergency response leads to an overall improvement of the emergency response situation in the society due to more economical planning and execution of safety and security related tasks.
It can be seen that effectiveness and efficiency are the cornerstones of improvement for emergency management. Thus the detailed analysis of potential impact of the DISASTER project results is based on showing improvements of effectiveness, efficiency or both in emergency operations. A formal analysis of potential impact of the results of the DISASTER took place in the development of the DISASTER exploitation strategy, one of the three DISASTER exploitation pillars, which are: 1) The exploitation framework, 2) The exploitation strategy and 3) The exploitation implementation.
A graphic has been created (see attachments) that shows the interdependencies between these pillars as well as the planned interface to possible customers and the society for post-project exploitation efforts. We will now fist discuss details for the exploitation strategy and after that implications of the potential impact for exploitation activities.
In order to structure the analysis of potential impact the exploitation strategy defines three main exploitation model options that all partners agreed upon:
- Technical exploitation including software licensing,
- Exploitation of knowledge and
- Exploitation by training and education.
In addition to these three exploitation model options the consortium identified the potential impact of the consortium itself – meaning the established collaboration practices and workflows. During the project it became obvious that there is not only a need for technical interoperability solutions, but also for assistance and guidance in understanding the complex nature of interoperability, especially in emergency management operations. Most organisations explained that they are first of all in need of understanding the issues they are facing related to interoperability and that after this understanding they will need technical support (e.g. during the DISASTER workshop in January 2014 and the BSSAR symposium on Crete in November 20014). Following this need the consortium identified that the very knowledge that was created and exists between the partners of the consortium will help these organisations to understand their challenges and after that the DISASTER solution will be able to provide sustainable support. Summarizing this, the first potential impact of the DISASTER project is the creation of a single point of contact for interoperability challenges in emergency management. This impact will be quite great and valuable since it assures that the collective knowledge of the DISASTER project is available at one place, although the consortium does not exist anymore on a formal basis.
Based on this first potential impact we will now create a structure of potential impacts following the exploitation model options. We will start naturally with the exploitation of knowledge as the option closest to the first potential impact, after that explain potential impacts arising from the technical exploitation and finally explain impacts arising from training and education, which is build upon the technical results.
Potential impact of exploitation of knowledge
The exploitation of knowledge is tightly linked to the exploitation of the consortium itself as described above. The exploitation of knowledge is the means by which the consortium knowledge will be exploited by individual partners. This can happen in two ways: The first one is consulting. Consulting services aim to improve the situation of the client by means of organisation and advice. Consulting services are created out of reusable best practices and information from former projects and from a comprehensive approach towards improvement. The business case here is the fact that the client does either not have the required knowledge or that the client is in need of an external opinion. Both points have been discussed above as a main challenge faced by many emergency management organisations as well as the industry. Thus the potential impact for consulting derived from DISASTER results is the improvement of efficiency and effectiveness of emergency management operations as well as the preparation of emergency response by assisting in identifying relevant interoperable areas (e.g. process interactions), defining this areas in a formal way and deriving improvements based on the DISASTER results. The second way of knowledge exploitation is by auditing and certification. Auditing and certification means to assess a clients organization, process or product according to a given standard and to confirm if this organization, process or product does comply with the standard or not. The value for the client is the certificate itself and the related possibility to prove compliance with the standard for either legal or competitive reasons. Auditing and certification services require a respected DISASTER standard and brand that they can refer to. The DISASTER consortium aims to create such standard and brand after the project lifetime. This creation process will be supported by the creation of a post-project website as a point of contact for all interested people and potential clients. Thus the potential impact for auditing and certification actions is twofold. On the one hand auditing and certification will improve interoperability by finding non-standard behaviour and suggesting improvements. On the other hand the creation of necessary standards will directly improve emergency management effectiveness and efficiency. Standardisation work has been done intensively during the DISASTER project, especially with regards to the EMERGEL ontology.
Potential impact of technical exploitation and software licensing
In terms of technical exploitation and related impact there are two main assets that can be exploited:
- The Emergency Elements Ontology (EMERGEL) and
- The DISASTER mediator solution, consisting of a core and individual mediator components.
For both mentioned assets as well as any related products (such as software that uses the ontology) there are several licensing options available. In selling software products there are three main options to choose from and, if possible, to combine. Software licensing models can be split into three main types:
- Commercial software licensing
- Free software licensing and
- Open source software licensing.
As mentioned before the main potential impact for both, the ontology as well as the mediator solution, is the support of interoperability processes in emergency management by abstracting mediation and translation work. Both technologies are already in use in end-user environments (e.g. VRK) and several other end-users as well as software developers such as TÜV (Germany) have declared interest in the results. In addition, the software results have been recognized and reused by other research projects such as FORTRESS, so that the scientific development is ensured. It can be seen that the potential impact of the technical results of the DISASTER project perfectly supports the other already identified impact areas. The technical solutions provide means for standardisation (Ontology) and direct interoperability (Mediation component) and are available for all interested users and researchers. With the single point of contact mentioned above the consortium aims to concentrate the discussion about the extension of the ontology to one point and thus will be able to enhance and further improve the ontology in a community process. This will ensure that the ontology is always up to date and offer the best support in terms of the identified impact.
Potential impact of exploitation by training and education
In contrast to consulting, auditing and certification the exploitation by training and education refers to exploitation tasks that aim to improve the clients knowledge and capabilities about interoperability procedures rather than interoperability itself. Training in this context refers to improving habits and operational skills. Education on the other hand refers to the transition of knowledge and the creation of understanding. Training services aim to improve the skills or extend the operational knowledge of a person in a particular area, by applying structured programs. The client in this case is often an individual person or a group of persons from a particular organization. The project DISASTER has produced a training tool that aims to improve the interoperability capabilities of such persons. In contrast to education, training is often provided by companies that have a clear interest in revenue. The training tool is created by the partner DBI and will be available for all partners after the project. In addition, the IP used to create the training tool can be used to create courses without using the tool itself. The potential impact of the exploitation by training, especially with the training tool, is the improved ability of individuals to handle situations that contain interoperability challenges. Thus this result is the basic building block to create the overall improvement of effectiveness and efficiency mentioned above.
Next to the training related results the research underlying principles and issues of interoperability as well at the connected solutions can be used in higher education as well as in educational activities of the partners for their own employees. Education aims to improve a clients (or in this case students) knowledge about a particular field of knowledge (e.g. interoperability) by creating understanding for the underlying principles and concepts. Although education is known as a non-profit area many if not most educational institutions need to constantly update their services and courses in order to get the needed number of students. From this perspective education can be seen as an exploitable asset. Of course the project partner CUAS is the main partner to exploit the DISASTER results in the education section. However, each partner might be interested in educating their own personnel in interoperability topics. In summary, the potential impact of the identified training and education exploitation is the improvement of the capabilities of an individual to deal with a) interoperability in various situations and b) systems and tools (e.g. the DISASTER solution) that help with interoperability challenges.
Ensuring the identified potential impact in all areas
It is important that the identified potential impact per exploitation is supported by concrete means to create this impact. This will happen both on a collective as well as an individual level. The deliverable D7.32 Exploitation Plan V2 explains in detail the various collective and individual exploitation activities. To ensure the mentioned impact on all levels the consortium has set up a post-project website that will serve as a single point of contact for all questions and challenges related to interoperability in emergency management. How this website is working in the overall exploitation setup can be seen in the mentioned figure in the attachments. This website supports the building of an interoperability community (which is necessary according to the first impact explained) and will also support the individual exploitation efforts of all project partners by providing a framework in which each partner can offer its unique exploitable assets.
Potential impact by target group
Based on the exploitation model options explained above the consortium has identified different target groups that will be addressed by DISASTER solutions and will be represented on the post-project website. The following passages describe the potential impact of the DISASTER project by target group. We will then have drilled down from the societal perspective of possible impacts at the beginning over individual DISASTER exploitation model options to specific target groups for exploitation that will benefit from the mentioned impact.
Incident Commanders: Incident commanders will first of all benefit from an enhanced common operational picture available in a shorter period of time to facilitate more informed decision making. This will possibly lead to quicker decisions and thus a more effective handling of the situation at hand. The DISASTER training tool will also offer new training options.
Emergency Planners: Creation of guidelines and assistance for implementing international cooperation in the emergency management sector in the form of planning and plan writing at a local level.
Emergency Management Authorities: These authorities will benefit from the creation of guidelines and assistance for implementing international cooperation in the emergency management sector (e.g. the post-project website), in particular the more overarching support needed to be more interoperable. They will also benefit from the standardisation and certification work since this will make interoperability solutions easier to implement and more reliable.
Governmental agencies: Governmental agencies will also benefit from the creation of guidelines and assistance for implementing international cooperation in the emergency management sector (e.g. the post-project website). They will also benefit from advice and guidelines of how to create a political interoperability environment to enable organisations to work together in a cross-border emergency operation.
The European Union: Also the European Union, as framework entity for all emergency management happening in Europe will benefit from advice and guidelines of how to create a political interoperability environment to enable organisations to work together in a cross-border emergency operation. This is not limited to EU administration but also affects EU research since the results from the DISASTER project will be available for future projects to be used.
Private (multi-country) companies: Private (multi-country) companies will be able to improve their means to cope with emergencies, especially if different organisations or departments are involved. This will improve efficiency and effectiveness of emergency reaction in the particular organisation, resulting in reduced losses. In addition, especially the DISASTER standardisation work as well as the certification and audition exploitation will offer improvement of market position by showing compliance to DISASTER standards in interoperability for each interested organisation.
Software companies: Software companies will be able to improve their market placement of the software companies’ products by implementing the DISASTER mediation components in the software. This will also cause a more harmonic market environment for emergency management software and thus lead to more effective emergency management. Software companies will then also be able to improve their market position by showing compliance to DISASTER standards in interoperability.
Emergency Management Educational Institutes: Such institutes (like CUAS) will be able to create new educational resources and research results regarding interoperability and cooperation of emergency management organisation in international operations and between different organisations. This of course will then proved a benefit for the whole society.
Students: Students of the mentioned institutes will benefit from an improved education and understanding of interoperability in emergency operations, leading to a better position on the job market.
A partners own personnel: Finally, each project partner might want to train it’s own personnel, leading to improved education and understanding of interoperability in emergency operations, and thus to more efficient and effective processes and to a better outcome in emergency situations or more effective emergency management handling in emergency management projects.
MAIN DISSEMINATION AND EXPLOITATION ACTIVITIES
NOTE: A full catalog of dissemination activities has been attached as a separate file (pdf).
Throughout the duration of the DISASTER project, all partners have been actively involved in dissemination activities. The first six months of the project were used for developing a dissemination plan for the entire duration of the project. The strategy we adopted was to first look into what we wanted to disseminate which was:
- Our developed data model and modular ontology for facilitating data exchange between first-responders in European countries.
- Our developed service oriented architecture (SOA) mediation algorithms facilitating interoperability between emergency management systems (EMS).
- Published material provided by our partners that aims to share the underlying scientific and technical basis, and project specific developments, that contribute to interoperability of EMS. This will include project reports and published scientific and technical papers.
- Published material provided by our partners that aims to share the conceptual and operational vision of improved communications between first responders in crisis management. This will include presentations, exercises, cases, and publications addressing the organizational and operational aspects of interoperable EMS usage.
- We also want to communicate the overall goal of the project, which is to improve communication between first responders on the scene. We will fulfil both of these objectives by informing the stakeholders at different stages in the project.
We also determined who we wanted to address, what would be the audience for our dissemination strategy:
- Public Administrations planning and implementing emergency response solutions.
- Emergency Management Agencies who are actively dealing with crisis and emergency, and who seek to improve capacity for ensuring public safety through maintenance of best technology solutions.
- Assistive agencies such as NGO’s (red Cross etc.) who may be engaged in providing specific support to disaster management agencies.
- Technology Companies developing EMS and related technologies.
- Research communities where scientific and technical developments can be shared as contribution to general progress in any EMS related areas of research. This will be achieved via conferences, journals and dedicated workshops. In particular, DISASTER targets scientific communities of the Semantic Web and Linked Data technologies, and Geographical Information Systems and Data management and integration.
- Standardization bodies that ensure common and appropriate solutions for geographic and other visual and underlying data and metadata, as well as standards for communication relevant to disaster management.
- Media channels who are relevant to the broad community of interest (Trade Magazines, Technical Publications, etc.), as well as media and any other information provider groups that could be present on a disaster scene (not being an EMS, but sharing information).
The third point of the strategy was to look into how we would disseminate:
A) Plan: Planning of the dissemination strategy and the exploitation of the results.
This includes clarification of target communities and stakeholders throughout the first phase of the project.
B) Design: Agree on the logos, templates and other details for the website and promotional material, as well as templates for our internal documents and various types of reports.
C) Create: Creation of the website and other promotional material like leaflets and emails.
D) Distribute: Use of the website, leaflets and publications to promote the project, send emails to stakeholders and look into possible use of other websites.
E) Represent: Participate and organize workshops, conferences and seminars.
F) Evaluate: Evaluate efficiency of the dissemination strategy by looking into number of visitors to the website, attendance to conferences, participants to our events, number of publications, etc.
G) Distribute: Marketing and distribution of the project’s results.
We also tried to look into when each of the named steps would be completed. Some of the activities described in the figure above were completed within the first few months of the project. Planning, designing, creating and distributing were steps we did start with in the beginning of the project. We created, distributed and represented during the entire duration of the project. We have now reached the evaluation and the final distribution step, where we are looking at the success of our dissemination strategy and how we will do the marketing of the results. In order to look at our successful we have been with our dissemination strategy, it is relevant to look at the activities we performed during the project.
Participation in conferences, seminars and workshops:
Conferences: The project partners have attended/participated in seventeen conferences including one organized by partners and two co-organized. Examples of the conferences are: the international conference on Geo-information for disaster management, Conference for Disaster and Risk reduction, BSSAR symposium, ISCRAM, BAPCO, World congress on Disaster and Emergency medicine, German Fire protection Association conference, etc.
Workshops and seminars: The project partners participated and presented to over thirty-five different events such as, FKB yearly meeting (Municipal fire brigades), FEU yearly meeting (Federation of European Fire Chiefs Association), end users workshops in Germany and Denmark, meetings with law enforcement, fire brigades, airports, etc. CEN meetings,
Website and social media:
Treelogic, who is coordinating the project, has established the project website, quickly after the start of the project (http://disaster-fp7.eu).
[See figure 1.4.2.A - DISASTER website - Home]
A second website, targeting the exploitation of the project’s results is planned to be designed in 2015.
As for social media, we did use LinkedIn as a primary media, since our target audiences include experts, professors, emergency managers, etc. We wanted to assure that we would have contact to professionals.
Our LinkedIn group has a hundred and twenty members and project partners are also members of other expert groups so we can disseminate the project results via other groups. These groups are for example: Crisis, Emergency &Disaster Recovery professionals, International Disaster & Emergency Resilience, Institute of civil protection and emergency management, Disaster & Emergency Management.
[See figure 1.4.2.B - DISASTER LinkedIn discussion group]
Training:
The DISASTER training program has been used throughout the project duration in order to raise awareness to the project. We also had several ends users/stakeholders participating in the development of the program which strengthened their knowledge of the project. The training program will be used as a dissemination tool for the DISASTER model since it can demonstrate how it can work in the field. And it will be an excellent tool for training first responders in crisis communication. A more detailed explanation of what the training tool can do, can be found in section 1.3 “Description of the main S/T results/foreground”, in particular 1.3.6 “WP7: Training program” of the document, or the deliverable D7.13.
Publications:
Conference abstracts, conference articles, posters, scientific articles and magazine article have been published since the beginning of the project. In total, we around twenty-one publications were produced including: 1 scientific article, xx conference articles, 5 magazines articles, two press releases, two conference posters,
Network:
Throughout the project we have use our existing networks to disseminate the progress /results of the project and/or get them involved in the project. Existing networks include: Copenhagen Fire brigade, Helsingør Fire brigade, Copenhagen Police, Danish Emergency Management Agency.
This project contributed to strengthen the existing networks, but also gave us the opportunity to develop some new connections such as: FEU (Federation of European Fire Chiefs Association), Arlanda region fire brigade (Sweden), Lund University Centre for risk assessment and management.
Newsletters:
We created six newsletters, which constitute two newsletters per year. In each newsletter, we updated the stakeholders on the progress of the project, conference and/or other types of event we attended or would attend in the future, and pieces of scientific information that was linked to our project. The newsletters were distributed amongst our networks and contact, published on the project website and also shared on our linked in group.
Other dissemination material:
Other dissemination material has also been produced such as PowerPoint presentations, leaflets and posters. In total, five flyers have been produced, which were adapted to the nee d the project partners had at the time. We also created over thirty-five different presentation for the project, all adapted to the audience we were addressing, as well as language. Two official posters were created, which were first used for presentations at conferences but were also used in other situations (presentations, meetings) as dissemination material. Finally, we also made one video, from the Schiphol exercise, which demonstrates clearly the use of the DISASTER model.
List of Websites:
A) PROJECT WEBSITE: http://www.disaster-fp7.eu
B) TWITTER: http://twiter.com/disaster_fp7
C) LINKEDIN GROUP: http://www.linkedin.com/groups/Disaster-Project-4327860
D) CONTACT: info@disaster-fp7.eu
Emergency management involves several actors that must interact and share information to provide a quick and integrated response to the threatening event. Sharing information between international workforces is a challenging tasks in emergency management. This is due to the fact that, even if dedicated ICT systems have emerged (usually known as Emergency Management Systems - EMS), each stakeholder has deployed its own system of command, control and communication, resulting on diverse data models and formats that are invariably incompatible with each other. Moreover, in an international context, the EMS-to-EMS exchange of information provides a number of additional challenges, considering also diversity in language (more than 24 official languages in the EU), background and cultural particularities (e.g. units, metric system), methodology or structure (diversity of organizational structures starting at local level), legal issues (different regulation, complex legal landscape), or data representation (myriad colour codes, different graphical symbol sets), among others.
A twofold solution has been developed: a common and modular ontology taking into account different cultural, semantic and linguistic issues (named EMERGEL); and, from that point, the implementation of a transparent Service Oriented Architecture providing mediation algorithms compliant with current data formats and existing solutions (the whole solution named DISASTER system).
The EMERGEL (EMERgency ELements) is a context-dependent ontology defined by experts to provide semantic mediation services for emergency related concepts. EMERGEL plays a pivotal role in the software solution for data interoperability proposed in this work. It has been made publicly available at [http://purl.org/emergel]. It is divided into three main modules: 1) a core ontology, focusing exclusively on events and agents; 2) a transversal module dealing with time and space; and 3) vertical modules designed to host in the form of concept schemes any relevant vocabulary able to assist the core module. An ad-hoc viewer (called SKOSIĆ), and the DISASTER API, complements EMERGEL, in order to allow both, "human beings" and "machines" (third-party applications) to access the ontology.
The global DISASTER solution needs additional components to "put EMERGEL in use". The DISASTER solution is conceived as a network of components (mediators) and a central component (Core). A key element in the DISASTER systems is the semantic mediation through the use of the EMERGEL component on a totally transparent way for the involved EMSs. To enable seamless integration, the mediator components allow the EMSs to use external information transformed to their own protocols, formats and cultural and linguistic characteristics. Several components take care of standardizing the geographic information exported by any EMS in a non-intrusive way: these components work in background capturing information to be exported. In order to share information between two or more systems, WFS (Web Feature Service) and WMS (Web Map Service) protocols has been taken into account, with the purpose of provide an easy way to represent the geospatial information exported by the different systems involved in DISASTER. Thus, this information is transformed by the components into standard formats such as SHP (Shapefile), GML (Geographic Markup Language) and GeoJSON (Geographic Javascript Object Notation), among others.
Field trials were carried out in two locations and two phases during the project, where different versions of the prototypes were fully demonstrated and tested with first responders taking part in realistic exercises.
A Border Fire incident was used as the basis for a first early field exercise whereby the initial ontology and middleware EMS-to-EMS mediation platform were tested. This was enacted within Dutch national fire service training exercises at a military airfield near the German border, and so realistic cross-border usage was demonstrated involving all command and operational levels, and all relevant systems. The feedback supported maturation of the proof of concept pilot systems during the project and for the second exercise
An Aircraft Crash was used as the basis for a second field exercise whereby the second issue of the ontology and mediation platform were tested. This was enacted at Schiphol airport and involved collaboration of various security stakeholders in exchange of critical information during an Aircraft Crash exercise involving a real aircraft, passengers and risk-related cargo.
Feedback from users and stakeholders was gathered, analysed and enriched, after the two major experiments. The usage of geo-information as the primary focus has been accepted positively, and the DISASTER method of enrichment of the map display, via imported / exported icons and linked data, has been shown to improve understanding and efficiency by responders and decisions makers. The results of the experiments indicate that the technical approach enables semantic interoperability between heterogeneous EMS, using a map-based approach, with added meta data and linked data for explanation. DISASTER has shown "ease of access" to, and "ease of use of" critical safety information, a high level of usability, and has identified further areas of research that will improve service to responders in future. The DISASTER approach has shown how new ways of information delivery and sharing can have an impact on existing operational procedures, that may need to be redesigned to fully exploit new opportunities. Making crisis information more easily accessible allows different responder teams to coordinate more easily, but in addition to the technology, there is a need for future protocols for information exchange of joint-operation at international level. In the end, the achievements emphasise the readiness of technology to support responder ambitions, and the need for regional, national, and international agreements on information exchange to make it a reality.
Project Context and Objectives:
MOTIVATION AND CONTEXT
Emergency management involves several actors that must interact in order to prevent a risk or to coordinate their activities to react to hazardous situations. This interaction mainly implies the interchange of information about the “who”, the “what”, the “where” and the “when”, in order to provide a quick and integrated response to the threatened event. This integrated response can involve international stakeholders with heterogeneous objectives, needs and contexts. The tasks developed by each one of these stakeholders are usually not independent from the different workforces spread throughout the disaster, but there are pieces of information that should be shared between all active groups in order to obtain globally successful results. Sharing information and coordination between international workforces in rescue operations, dealing with a large amount of information in a highly dynamic environment, is one of the most challenging tasks in emergency management.
In order to manage and share this critical information in a dynamic context, dedicated ICT systems, usually known either as Emergency Management Systems (EMS) or Crisis Information Management Systems (CIMS), have emerged. In the Member States of the EU, each stakeholder has deployed its own system of command, control and communication. As a direct result of this situation, Emergency Management Systems manage different information data models and formats that are invariably incompatible with each other.
EMS have evolved within the cultural and political context of their respective countries. In an international context, the situation with regard to the EMS-to-EMS exchange of information provides a number of challenges, considering not only technical interoperability (data formats, models and communication protocols), but also diversity in language (e.g. 28 member states in the EU with more than 24 official working languages), background and cultural particularities (e.g. units, metric system), methodology or structure (diversity of organizational structures starting at local level), legal issues (different regulation, complex legal landscape), or data representation (myriad colour codes, different graphical symbol sets), among others.
From an organisational, procedural and legal perspective, EMSs have also been conditioned by political and socioeconomic factors. In example, there is a big difference between centralized or federal countries. For the former ones, the legislation applies to the whole territory of the country, but for the latter, the application of laws is one of the every federal entity duties or even legislation can be utterly transferred and each federal entity has its own laws. For example, in Germany there are 16 laws on disaster management encompassing to a certain extent fire services that operate on community/city level (a local authority or city having a distinct legislation on fire services), and an equal number of laws on EMS-services. As a result, existing systems fragmentation means that cooperation between emergency forces becomes almost impossible in many regions.
[See figure 1.2.A: Interoperability challenges in EMS-to-EMS communication]
Great improvements have been made by governments in the last years for managing and exchanging disasters information. These are only the first steps, though. If real and complete coordination between first responders and different stakeholders is desired, current mechanisms and technologies must be improved and interoperability problems resolved. As a matter of fact, the USA has had the same interoperability problems and they have faced those problems and drawbacks by adopting a standard format (EDXL) to exchange data between different stakeholders within the country. However, the challenges in developing a solution for the EU are very different from those in the USA. First of all, due to language heterogeneity, cultural fragmentation and different political frames, the common understanding and the exchange of information is very difficult, appearing hard interoperability problems. Moreover, in the case of the USA, there is a common emergency management framework that is provided by the government. This is missing in the EU, where each European country has different legislations and technological frameworks to deal with emergency situations,. The EU context makes collaboration and interaction difficult to achieve by means of the available technological solutions, which do not resolve the heterogeneity at the different communication levels. For all these reasons, the adoption of the USA solution is impossible, and a different technical approach must be developed.
To sum up, establishing a common response framework and a common information exchange format, as in USA, does not sound as a feasible solution in the short-term, both from a technical and political perspective. Instead, a technical solution was suggested oriented towards the various needs and demands of the European Union. Designing a solution to enable existing systems and organisations to interoperate effectively is the big step forward to be taken by DISASTER.
PROJECT APPROACH
The proposed solution does not involve the replacement of existing infrastructure and languages that are currently used by Emergency Management Systems. On the contrary, DISASTER proposed to address communication challenges by establishing indirect bridges between information systems. These bridges are not established between each pair of existing data models, but to converge into a common knowledge representation which allows the indirect transformation. From a complexity point of view, this means defining n transformations, where n are the current available data models in Emergency Management Systems, and which are enough to ensure any possible interaction between stakeholders. On the other hand, direct bridges require to define n2 translations.
Nowadays exist many formal ways to describe and to structure knowledge: thesauri, taxonomies and ontologies are the most representative. From less to most expressive tools, taxonomies are the less powerful ones, with limited features for representing not hierarchical knowledge, capturing pure linguistic knowledge. Thesauri are a more expressive means for representing knowledge. Apart from being able to express hierarchies of concepts, as taxonomies, thesauri can linguistically describe the concepts, capturing for instance synonym and homonym relations, and other semantic properties such as part/whole relations complementary to the hierarchical ones. These additional features provide more comprehensive classifications of knowledge, concepts and relations. Then last but not least, ontologies represent another formal and comprehensive way of knowledge representation, increasing thesaurus expressivity: ontologies provide mechanisms for creating complex and flexible relations between different concepts while separating the abstract meaning from the language representation. Another feature relative to ontologies is the definition of restrictions within controlled vocabularies so dedicated machines can apply algorithms for checking consistency or satisfiability of the concepts defined. For the reasons previously mentioned, designing and developing an ontology is the best solution for assuring and provide understanding of common knowledge between people from different countries and cultures.
The proposed solution implies that a common ontology should have a wide conceptual coverage, without sacrificing precision. These requirements call for a modular design of the ontology, i.e. the definition of an abstract framework built for extensibility. This ontology would be composed by three parts or modules where each one would have an specific purpose and motivation:
1) The core ontology which contains all the common knowledge and concepts related to emergencies and the stakeholders involved in a crisis situation.
2) A set of vertical ontologies focused on describing a comprehensive conceptualization of all the knowledge in a specific emergencies subdomain. These specific conceptual modules would be plugged to this central core in order to achieve the desired scope for any crisis subdomain (logistics, infrastructure, humanitarian aspects, etc.).
3) A transversal ontology containing knowledge and concepts from the core ontology as well as vertical ontologies. This ontology is mainly focus on describing general concepts (time, location, etc).
OWL is a standard ontology language that seems to be a good candidate to meet the requirements imposed by this endeavour. It is designed for open exchange of information in web environments, it allows for modular designs and extensibility and it deals with multilingualism. OWL is a language that also allows defining concepts with a high degree of detail, making it possible to align the ontology with existing data models and other information resources (such as thesauri or taxonomies) that range along all the possible levels of description.
In addition to the ontology itself, transforming the exchanged data and its format to and from the shared ontology and legacy EMSs is a critical task. These transformations to and from the ontology will be materialized by means of data mediation. Appropriate languages and techniques are applied in order to automatically perform the conversion of the exchanged data at the very moment of the interaction. This mediation deals with heterogeneity at three levels:
1) Data-model mediation addresses the differences between the data models by each end of the communication. This mediation is possible when every stakeholder shares the same concepts but from different points of view. Typically cultural and organization issues arise at this point.
2) Data-format mediation faces the reconciliation of the different forms that the data may acquire in IT systems. Even when two stakeholders share a common point of view for a given concept, they may use different data structures.
3) Protocol mediation for the communication between emergency agents. This is particularly relevant to ensure effective communication in SOA environments, where services from different providers have been created without a general picture of the interaction workflow.
As a summary, the technical approach used by this project involves applying innovative data mediation components to resolve the current challenges in service-oriented architectures, by means of indirect translations via a common, modular-designed ontology.
PROJECT OBJECTIVES
The project target outcome is an integrative and modular ontology for establishing a common knowledge structure between all the first responders involved in an emergency, but being compliant with legacy international data formats exchanged in the European Union as long as being seamlessly integrated within current SOA-based Emergency Management Systems.
A twofold solution has been developed: a common and modular ontology taking into account different cultural, semantic and linguistic issues (named EMERGEL); and, from that point, the implementation of a transparent Service Oriented Architecture providing mediation algorithms compliant with current data formats and existing solutions (the whole solution named DISASTER system).
The development of an integrative ontology was done through a set of scenarios involving end users for collecting all the requirements related to the emergency management arena. This information is the basis for modelling in an appropriate way the common and cross-domain knowledge of stakeholders surrounded by cultural and linguistic issues.
Seamlessly integration within current SOA-based Emergency Management Systems, was faced in two parts. Firstly, technical mediation components were designed and developed able to adapt current European data formats to the resulting data model. Secondly, these mediation components were adapted to be integrated in legacy SOA-based Emergency Management Systems by means of a middleware component designed for linking those legacy systems with the mediation common ontology
.
The global objective was detailed in the following scientific and technical objectives:
O1: Designing a reference architecture and providing a general approach to solve interoperability problems in data exchange in current SOA-based Emergency Management Systems, addressing interdisciplinary environment when dealing with emergency management at a European level.
O2: Designing and developing an integrative and modular interoperable data model. This objective may be split into two specific sub-objectives:
O2.1: Designing and developing the core framework data model, common to every stakeholder involved in emergency management.
O2.2: Designing and developing complementary transversal (spatial and temporal) & vertical (domain-specific) modules.
O3: Analysing, designing and developing mediation techniques, a set of bridges, enabling a transparent to the user integration of the resulting data model within already-existing SOA-based Emergency Management Systems.
O4: Defining, designing, developing and executing and specific implementation of the resulting technical approach. This will enable a validation pilot phase on actual environment, based on a representative scenario, in order to get feedback from end-users through the entities involved in the consortium, as well as evaluate project’s outcomes and their benefits to the European multicultural domain related to emergency management
Project Results:
WP2: THE DISASTER APPROACH
WP2 within the DISASTER project provides the basis for the development of the common modular ontology EMERGEL as well as for the development of the gateway. Therefore, objectives of WP 2 have been manifold. Starting from the scratch, basic requirements have been compiled. Possible scenarios for ensuring a practice-based development approach have been identified in an expert’s workshop. An online survey among emergency reaction professionals delivered profound insights in stakeholder’s requirements. A collection of differences and similarities with regard to legal, linguistic, semantic and cultural issues has been created. Finally, technical implications have been defined and the reference architecture and data model approach has been developed. In summary, WP 2 provided the basic research activities to build the further project work upon. This report will point out detailed the scientific and technical results of WP2 during its operational time from month 1 to month 18 in the project timetable.
END-USER REQUIREMENTS
To find out about the very requirements which emergency management stakeholders could have in an IT-based interoperability solution, an expert’s workshop was held at Cologne University of Applied Sciences. As a result, two scenarios were chosen to be the “guide” of the gateway and ontology development. “Air cargo scenario” deals with a plane carrying dangerous goods crashing down at an international airport. Main objective of this scenario is to point out the complexity of intraorganizational cooperation in the highly complex surrounding of an airport. Stakeholders with completely different aims, tasks and competencies must react sufficient in an ad-hoc crisis situation. Safety and security matters as well as business processes must be considered to bring the situation under control. Though all organizations in airport operations speak the same language, use the same semantics and are under the same legislation, establishing inter- and intraoperability poses a great challenge to an IT-based solution.
The second chosen scenario, “Moor fire scenario”, is about a large surface fire between Germany and The Netherlands based on a realistic incident. Stakeholders such as fire brigade, emergency medical service, police and technical relief from two different countries must work under close cooperation in a common operational situation. Different languages, semantics, responsibilities, legislations and command structures impede an uncomplicated management of such an event. Therefore, this scenario is a good example of how the DISASTER solution can enhance cross-country cooperation by bridging the gaps between varying management systems. It also points the importance of a common operational picture. Translation and mediation of tactical icons and symbols is the key for a common understanding of the situation. Connection of IT-based management systems and enabling cooperation between stakeholders is the main objective of this scenario. Both scenarios have been described in detail in WP 6.
Besides scenario definition, an online survey was undertaken in the scope of WP 2. Aiming on emergency responders and decision makers, the survey produced a profound insight in stakeholder’s actual requirements. This creates a practical approach of research and ensures stakeholder’s acceptance in the developed DISASTER solution. Most participants of the survey were experienced in firefighting or emergency medical service organizations. The survey clearly stated out, that most of the participants have experience in using radio communication, electronic data transfer and situation maps. Especially the fact that collection of information is mainly done with situational maps and with IT supported systems, and that implementation of electronic support is highly accepted, can be interpreted as a proof for the high relevance of the DISASTER project’s research.
INFORMATION MANAGEMENT AND REFERENCE FRAMEWORK
It is obvious, that “information” and “information sharing” are keywords of pivotal relevance in the work of the DISASTER project. In the end, the major goal of the project is to enable a technical solution to share information between stakeholders in an emergency situation. Handling of information and data in a defined situation (as a major incident is for sure) always takes place in a reference framework. The reference framework in major incident situations is defined by the state of knowledge and experiences of the operational forces. The importance of a broadly based reference framework heightens simultaneously to the level of responsibility. As an example, a firefighter in an incident has to execute commands. That means he has to fulfill tasks like extinguishing a fire, provide technical relief or safe people from a dangerous situation. He is able to do so, because he was educated in these tasks and fulfills them in his daily work. What about a decision maker in major incidents? He has to deal with the whole picture of an incident. Obviously, he needs a highly complex reference framework or must be able to create himself ad hoc a new framework based on past experiences. Therefore, he might depend on assistance. This assistance can be provided by advisory staff personnel and/or by electronic devices. Since information exchange always includes the danger of information erasing, changing and creating, challenges to a technical solution are highly complex. Considering cross-border incidents with language barriers etc. the DISASTER solution provides sufficient support in information exchange, handling, interpreting and understanding. Therefore, legal, linguistic, sematic and cultural issues have to be addressed.
LEGAL REGULATIONS AND NOMENCLATURE
Though the European Union is a merger of 28 member states, each state has its own governmental structures and legislation.
These structures differ a lot among the participating states. The DISASTER project does not aim to achieve any changes in legislation or emergency management structures, but to improve close cooperation in occurring cross-border disaster events. Arising from this premise, awareness of legal, linguistic, sematic and cultural differences must be considered within all research activities. Comprehension and compliance with these differences paves the way for the development of a common ontology covering all relevant contents.
As stated before, the EU consists of 28 member states. That means the DISASTER project has to deal with an enormous amount of legislation, laws and regulations. Nevertheless, a general understanding of governmental structures is vital since these structures have direct influence on the respective emergency management structures. It seems obvious, that considering all 28 member states would be way beyond the scope of the project. For that reason, research was limited to the five member states of the project consortium, namely The Netherlands, Spain, UK, Denmark and Germany.
Since state-building varies a lot among EU member states, a methodology was developed to point out on which levels responsibilities for emergency management are located. For that reason, description of authorities was split up into national, regional and local level. In federal states like Germany or Austria, responsibilities in emergency management are distributed to the regional level (federal states). On the contrary, in central states like France, Denmark or UK, responsibilities are primarily located on national level. To ensure interoperability between stakeholders, it has to be clearly highlighted on which level the corresponding contact person is located. This enables information exchange between the correct sender and receiver and minimizes the risk of derogation in information flow. Furthermore, a basic knowledge of emergency management legislation provides a deeper understanding of each other’s procedural methods. For that reason, WP 2 also provides tables displaying the legal basis of fire services, emergency medical services, police forces and, if existing, specific disaster coordination. These tables also point out regulations for leadership and command, crisis management and operational level and can be seen as a guideline in complex administrative networks.
LINGUISTIC AND SEMANTIC DIFFERENCES, CULTURAL BACKGROUND
One of the greatest challenges to be addressed by the DISASTER project is the fact, that within the European Union 24 official languages exist. Since communication is vital in emergency management operations, a methodology to deal with these language barriers is crucial. To make things even more complicated, speech in emergency management is characterized by a very special and technical terminology. This often impedes one-to-one translation of terms. Consequentially, not only linguistic but also semantic translation must be provided in order to avoid misunderstandings. What does that mean? An example: a fire truck in Germany might look almost the same like one in The Netherlands or the UK. But in reality, the operational team, technical equipment and capabilities might differ a lot. So a general structure of definitions and descriptions of terms in emergency management was defined in WP 2. This ensures a common linguistic and semantic basis and is of high relevance for the EMERGEL ontology.
Besides linguistic and semantic terminology, symbols and icons play a major role in the emergency management field. Most emergency management systems display operational areas by using operational maps. Units are not displayed via plain text but by icons, symbols or pictograms. Every icon includes specific information. E.g. a single ambulance or fire truck, fire company, helicopter landing place, command and control units, dangers etc. Since a major goal of DISASTER is information sharing by using these operational maps, these icons have to be mediated to enable a common understanding of the situation. Therefore, WP 2 provides a collection of icons and their meaning to be included in the ontology. A whole lot of icons from as much European and even non-European countries as possible were collected by applying international contacts of all consortium partners. Result is an extensive collection of icons and descriptions which adds high value to EMERGEL.
Even cultural peculiarities have been part of the work in WP 2. Mainly concentrating on governmental structures, emergency management and health care systems, relevant similarities and differences have been explored. A deep understanding of cultural background in participating countries enables a better sense for requirements to be fulfilled by the DISASTER solution.
TECHNICAL DEVELOPMENT APPROACH
In addition to end-user requirements, legal, linguistic and cultural requirements, WP 2 also dealt with technical requirements concerning EMERGEL ontology development, reference architecture and data models.
To find out about the very requirements for the ontology, a workshop was held in the beginning of the project. In order to make DISASTER a power- and useful tool to a broad audience of stakeholders, these domain-experts were included consequentially into the requirement compilation. The applied methodology created results which are in step with actual practice. Questions arising in an actual disaster situation were asked by domain experts, the answers were taken as requirements for EMERGEL. For example, the question “in which geographical point is the incident located?” leads to the fact that EMERGEL must be able to deal with data schemata such as NeoGeo, wgs84 and GeoSPARQL.
By defining the mediation workflow within the ontology, it was possible to derive requirements from every mediation step. The workflow consists of four steps: data acquisition, data alignment definition, data alignment execution and data exploitation. Resulting requirement were assessed and rated in a points-based system from 1 (optional, nice-to-have) to 5 (highest priority). This compilation of requirements provided the basis for the actual technical development of the ontology and has influence on other WPs.
Furthermore, WP 2 defines the DISASTER software architecture including the data model approach of the gateway components. Since emergency management systems do not use standardized data models, the connection of legacy system needs to be enabled by using data mediators. That means, DISASTER must provide a mediator which allows an EMS to use external data but transferred into its own data model, protocols, format etc. An example: two legacy EMS shall be connected via DISASTER solution. EMS 1 (Dutch side) has important information to share with EMS 2 (German side), e.g. an ambulance icon on the situational map. The output mediator receives this information from EMS1 and transforms it into RDF (Resource Description Framework). The DISASTER kernel is now able to process this information via EMERGEL ontology. The Dutch ambulance icon is mediated into the German icon. Via input mediator, the German EMS is now able to consume the information and display the icon with the correct design on the correct place on its own operational map. Interaction within in the DISASTER software architecture is enabled by using the Service Oriented Architecture (SOA) approach. Consortium’s domain experts chose this approach because it entails the possibility of bridging the gap between IT experts and emergency management stakeholders.
The scientific and technical results elaborated in WP 2 provide a broad basis for following and parallel running WPs. It highlighted end-user requirements, legal, linguistic, sematic and cultural issues to be concerned within the complete project runtime. Furthermore, it paves the way for the technical development by providing the data model and software architecture approach to be used in further work packages.
WP3: EMERGEL: THE EMERGENCY MANAGEMENT ONTOLOGY
The main outcome of WP3 is the EMERGEL ontology. EMERGEL (EMERgency ELements) is a modular ontology whose first cornerstone was an initial, thorough state of the art, which took into account previous work, formal languages and technological choices, as well as a solid anchoring on the domain to be dealt with. It is a modular vocabulary because it was compartmentalised in different modules from the very beginning.
The methodology followed to model the EMERGEL ontology involved an initial definition of semantic-coverage requirements, carried out in WP2. This task was complemented with the identification of existing ontologies and non-ontological domain resources that partially covered an aspect of the ontology. As a design decision, the ontology is modularised, i.e. application of ontology engineering guidelines to divide and structure the knowledge domain in meaningful segments.
This process finally led into a vocabulary composed of a core (abstract, upper-level ontology including transversal modules, namely spatial and temporal representation) and vertical modules (associated with specific domains). The W3C OWL2 ontology language was selected to describe the DISASTER data model.
One of the ways to determine the scope of an ontology is to chalk out a list of questions that the ontology should be able to answer. Competency questions are targets for what an ontology should be able to cover, given sufficient facts (i.e. data) in the knowledgebase. These questions served as a test and helped to find out if the ontology contains enough information. The answers assisted the ontology experts to work out the requirements for the level of detail needed or the representation of a particular area. The competency questions are just rough drawings and do not need to be exhaustive. To capture the requisites for the core ontology a number of competency questions were conceived during the first steps of the project. They were discussed by the consortium and included in Deliverable D2.40. The initial version of the core module of the ontology was grounded on those questions, which covered a number of wide subjects as time, space, resources, agents, etc.
The first and main module is the Core framework. This core module is a lightweight vocabulary limiting its scope to agents and events. EMERGEL uses some upper-level classes belonging to the DOLCE+DnS Ultralite (DUL) ontology. DUL is a simplification and an improvement of some parts of DOLCE Lite-Plus library and of the Descriptions and Situations ontology that provides a set of upper level concepts that can be the basis for easier interoperability among many middle and lower level ontologies.
In this aspect, to model what is involved in an emergency situation, EMERGEL uses dul:Event and also dul:PhysicalObject, two classes belonging to DUL. To model agents and roles, as it will be more specifically presented later, EMERGEL uses FOAF and WAI. FOAF is a vocabulary to describe people, the links between them and the things they create and do. To model people and groups EMERGEL reuses the FOAF classes foaf:Person and foaf:Group. WAI is a vocabulary aiming to extend the FOAF specification through introducing the concepts of roles and profiles. From WAI, EMERGEL takes foaf:Role, foaf:Profile and foaf:Context.
A disaster is defined as a natural, man-made or technological hazard resulting in an event of substantial extent causing significant physical damage or destruction, loss of life, drastic change to the environment or simply damage to property. It can affect and destroy the economic, social and cultural life of people. That kind of events stem from other events such as earthquakes, floods, catastrophic accidents, fires, or explosions. EMERGEL thus interprets a disaster as a kind of event. Therefore, an upper-level class is introduced: emergel:EmergencySituation as subclass of dul:Event.
The different agents involved in an emergency situation are modelled in EMERGEL reusing the WAI ontology, a vocabulary to describe roles and profiles. By using WAI, it can be smoothly attached to a given person different roles and profiles: a person can be for instance a fireman or a victim depending of the context or the moment within the emergency situation. WAI provides a class wai:Role and the corresponding property wai:plays to link up individuals and roles. This strategy was also applied by the DOLCE ontology, but with a general knowledge representation purpose. WAI instead is a specifically dedicated vocabulary to represent people and a given person can play more than one role.
Roles can also be arranged in a hierarchy of entities in a similar way as ontology classes are organised via a subsumption relation. For instance, a fireman can be specialised into a fireman corporal, which is also specialised into a fireman corporal of Germany’s fire brigade.
WAI introduces a primitive property wai:specializes able to capture these hierarchies of roles, thus allowing more generic roles to be successively refined into more specific ones.
Profiles are entities capturing the dynamic and temporal aspects of roles. Profiles are introduced to cover this knowledge representation gap. Roles are not inherent to people, as they are not essential properties. Profiles (wai:Profile in the ontology) are a mechanism allowing to refer to people when they are actually playing a particular role, i.e. “person-as-role”.
Profiles using WAI do not necessarily need to refer to a role. When contexts and groups are used to fix the interpretation coordinates of the profile, roles may be implicit. In this case, a profile is considered a “person-at-context” or a “person-in-group”, rather than “person-as-role”. Nevertheless, none of the three are exclusive but complementary.
The two Transversal Modules considered in EMERGEL are space and time. Other possible transversal modules, such as magnitudes, are not considered, as the primary focus of EMERGEL was to deal with the specific Proof of Concepts of the DISASTER project. However, the alignment of EMERGEL with the Measurement Units Ontology (MUO), a vocabulary implemented by CTIC, is an interesting future movement.
Regarding spatial representation of an emergency situation, EMERGEL introduces a pristine ontological distinction between the involved conceptual layers: (1) features, (2) geometries, and (3) feature-types classifications related with cartographic visual representation (i.e. maps). This distinction eases the reconciliation between the geographical-feature description of emergency entities and a pure geometrical representation of the space.
A common modelling choice in geospatial science is a distinction between a Feature and a Geometry, where the former is an entity in the real world with some spatial extent, such as airports, monuments, hospitals, hotels, etc. and the latter a geometric shape, such as a point, polygon or line.
In DISASTER, it is assumed that geographical information is captured by the NeoGeo Vocabulary, which provides the distinction between features and geometries by means of spatial:Feature and geom:Geometry classes. The property geom:geometry is used to reconcile both facets of the same geographical entity. URIs (implicitly) denoting a geom:Geometry might have any format based on HTTP content negotiation.
Finally, the visual aspect of maps is conformed by style guidelines. The styling of a map is aligned with final user visualisation requirements, i.e. the same geographic information is often presented with different styling according to the intended audience. Thus, styles usually conform to cartography style manuals or follow symbology standards to assure proper understanding. In this line, we can refer to maps as human-readable artefacts to visualise geospatial information. There are different maps depending on the kind of the visualised information: geocharts, i.e. statistical data associated with spatial information presented as maps; political maps, i.e. maps that emphasise the division of territory according to governmental directives; or physical maps, i.e. maps that represent the properties of the terrain such as mountains, rivers or lakes.
The style assigns a number of visual properties to each feature. The nature of style is dual, as it assigns graphical representations to concepts. EMERGEL captures this double identity of styles by linking features to SKOS concepts, and then SKOS concepts with graphical representations. We associate a neogeo:Feature to a skos:Concept using the dct:subject property. Finally, concepts can be linked using the property emergel:prefStyle to specific emergel:Style instances, which are in charge of containing, or linked to, their graphical representation.
As far as time as transversal module is concerned, an instant-based model is proposed as instants provide snapshots of a situation at a given moment. In other words, it is obtained a full vision of an event without considering evolution in time. This is important in order to guarantee interoperability between information systems and to come up with easily translatable visualisations. An interval-based interpretation of time does not disappear, but it is implicit in the 4D approach of the ontology, as every entity is a composition of successive temporal parts. We restrictively introduce the class dul:Event in the ontology, as a generic and broader concept meaning “something that happens” and “the occurrence of a process or a phenomenon”. Events are inherently time intervals, and so they can relate each other by means of the Allen’s temporal algebra. For instance, “the fire started before the explosion in the factory”.
The ontology introduces timeslices and fluents to provide the diachronic perspective of time. Timeslices represent the temporal parts of a specific entity at given snapshots in time (i.e. instants). Fluents are properties that hold at a specific moment in time, or at a specific interval in time. In other words, fluents and timeslices represent a vocabulary to capture temporal parts of individuals that change some property in time. This model however is combined with the W3C’s Time ontology, as it specifically covers with a rich model other aspects such as time zones.
EMERGEL establishes its Vertical Modules in a slightly different way than the core ontology. As to feed these vertical modules both at the class and the instance levels it is possible to (re)-use standard classifications, the use of the SKOS (Simple Knowledge Organization System), a standard vocabulary from the W3C used to model the basic structure and content of concept schemes, was decided. Several EU thesauri and vocabularies are available in SKOS and this way EMERGEL concepts can be easily mapped to concepts belonging to EuroVoc, Agrovoc or GEMET.
EMERGEL Core includes the class ConceptScheme from SKOS and from which more specific concept schemes hang. The list of concept schemes included in the EMERGEL vertical modules have been thatched with a user-friendly, accessible roofing. As the large number of lists, classifications and vocabularies encompasses several domains and present a rich number of divisions, a number of upper-level classes were designed to help the user browsing the vertical modules. In the following sections these upper-level classes are introduced together with their ramifications.
Notice that the vertical modules offer supple, generic upper classes capable of being populated (extended) at any time with new cultural, regional or national realities by means of instances. This way, the vertical modules are aligned with the aim of the EMERGEL ontology ensuring its own wide life cycle.
The EMERGEL ontology incorporates a number of datasets into the aforementioned common representation format SKOS, enabling the specification of semantic equivalences in order to drive data translation processes between IT crisis management systems. The methodology to assimilate these controlled vocabularies consists of a 3-step workflow, defined as following:
1) Taxonomy creation and mapping specification. The domain expert encodes original non-ontological resources and specifies correspondences between them in the form of a table that is specially formatted for further automatic processing.
2) Automatic generation of SKOS taxonomies and RDF mappings (EMERGEL vertical modules). The taxonomies and classifications are automatically encoded in SKOS/OWL. The previous correspondences are automatically extracted from the table and converted to mappings defined in a technical format, i.e. SKOS vocabulary to taxonomies alignment.
3) Execution of mappings. The mappings are available online as part of the EMERGEL ontology. They are used on demand by the mediation component (specified in D4.20) to perform a given data translation process.
Currently there are more than 350 different datasets incorporated into the EMERGEL Vertical modules, not counting their own multilingual versions, which come implemented as different datasets as they introduce an ad-hoc language point of view. Those more than 350 datasets are split into the theme areas defined in the ontology:
* Companies (corporations or business organizations potentially involved in an emergency situation, both as agents or victims)
* Places (Areas with definite or indefinite boundaries, such as geopolitical subdivisions, waterbodies, airports, power stations, etc.)
* Vehicles (aircrafts, ships, etc.)
* Dangerous goods (UN numbers for hazardous substances, HAZMAT classes, radionuclides, etc.)
* Emergency symbols (from different countries of the world and international standards)
* Third-party vocabularies (relevant vocabularies belonging to the EU, etc.)
* Standardisation organisations
* EMSs (Emergency Management Systems)
However, as the EMERGEL ontology is designed to have a vigorous post-project life and it has already been introduced in 2 W3C Working Groups, these datasets are being presently and will be continuously increased, enriched and developed
WP4: MEDIATION COMPONENTS
The goal of the Mediation Component is to provide transformation capabilities that solve the interoperability problems between legacy EMSs in the context of the DISASTER platform. These transformations occur at 3 different levels: protocol, format and data mediation:
* Protocol mediation bridges the gap between systems that communicate with external systems using different protocols.
* Format mediation solves the heterogeneity at the representation level. Information of the same nature can be represented in many formats: on the one hand standard formats, on the other de-facto standard formats chosen by the leading software applications in the field. The format mediation tackles this problem so same information can be converted from one source format to another target format.
* Finally, data mediation covers the transformation of core information, described at the semantic level. When communicating two parties, A and B with different legislation, culture, operation protocols, etc., their systems might reach the point where actual communication is feasible, thanks to the previous two mediation levels: protocol and format. However, information sourcing from A system and arriving at B system is not valuable unless is understandable by B. This understanding can only happen if information from A is translated into a meaningful form, i.e. complying with B schema or model, for party B. This is the chief objective of data mediation: transform information so it agrees to a target schema or model understood by the receiving end. The knowledge required to perform such translations is obtained from EMERGEL ontology, the main result of WP3.
The design of the Mediation Component needs to comply with DISASTER requirements driven by the use cases of WP6. The DISASTER interoperability platform needs to be designed in a fashion that remains open and extensible to potential client EMS systems that might benefit from its interoperability capabilities in the future. With this goal set, it is very important that the design of the Mediation Component does not only handle specific conversions at the three levels described above, but that remains open to new protocols, formats or models while maintaining the rest of existing functionalities.
These requirements are covered by the mediation architecture, which defines two types of components:
* Mediation component: performs model/schema mediation. Shares the name with the global WP4 objective because this is the software part that is vital for the mediation. Without model mediation two EMS legacy systems can reach the point where information is exchanged but the final agents cannot understand it. The implementation of this component was performed using the powerful capabilities of the RDF language, used to describe the relations between different collections/schemes in the form of EMERGEL mappings. These mappings are exploited by a pluggable RDF rule engine, thus transforming the information.
* Transformation adapters: perform different protocol and format mediations. Transformation adapters can be also classified as lifting and lowering components depending on the part of the mediation they cover. Lifting components adapt information from legacy EMS systems offered in different protocols and/or formats and source the information from the mediation component. Lowering components perform the inverse path: collect the information transformed by the mediation component and offer it to legacy EMS systems in the format/protocols they understand.
These two types of components of the architecture need to agree on the way of sharing information between them. The protocol chosen is the SPARQL query language, which is used by each transformation adapter to push or pull the information to/from the SPARQL Endpoint of the mediation component.
As part of the WP efforts, an extensive study was performed to cover the state of the art technologies in the domain of mediation. Alongside this study, a number of software components were developed. The purpose of this task was twofold: 1) breaching the sate of the art in the mediation of some formats identified as highly valuable in context of information interoperability in the domain of EMS systems; 2) serve in the mediations required by the Proof of Concepts of WP5.
The list of software components contains a large number of items, which fulfill various areas of mediation:
* Format mediation components:
* ESRI Shapefile to RDF and KML
* OGC SLD to SVG
* Tabular data to SKOS schemes and SKOS-based mappings
* DISMA XML to GeoJSON
* GeoJSON to ESRI Shapefile
* GML to PNG
* Protocol mediation components:
* WFS to WMS mediation applied to Dutch EMS
* German EMS DSMA XML messages as WFS
* Model mediation components:
* RDF-2-RDF mediation component
While the Mediation Component puts the full potential of EMERGEL mappings at the hand of external systems with mediation needs, its RDF-based interface can be cumbersome to exploit. This is especially true for early prototypes that adapt legacy EMSs, which often use databases or plain text as exchange format. In order to streamline the integration between the available mappings in EMERGEL and the WP5 Proof of Concept Border Fire prototype (PoC-BF), the EMERGEL API was devised under the efforts of WP4. This API offers a query-enabled layer on top of EMERGEL to provide lightweight mediation capabilities as REST web services, thus facilitating the integration with the existing PoC-BF prototype. This API has proved to be a useful way of consuming EMERGEL mappings, after the successful integration of the first integration prototype (PoC-BF), the second prototype under WP5, the Air Cargo Proof of Concept prototype (PoC-AC) leveraged the EMERGEL API to successfully showcase the DISASTER capabilities in a complete different scenario from the first PoC-BF. Furthermore, a third system, completely independent from the WP5 prototypes also benefited from EMERGEL API services. In this case, the Virtual Training Program, under the efforts of WP7, developed a simulation program to train stakeholders in scenarios where DISASTER platform capabilities are available. This simulator is directly consuming EMERGEL API services to carry out the mediation needs when information exchange between different EMSs takes place.
In the same line of the EMERGEL API, new ways of exploiting EMERGEL arose during the execution of DISASTER project. As EMERGEL Vertical Modules increased in number of modules and items, this ontology becomes a valuable resource of information for emergency domain experts. However, its RDF nature made it reachable only to machines and data browsers, the latter lacking basic usability for users not familiar with Semantic Web principles. In this context, the need for an EMERGEL viewer started to grow and drove the creation of SKOSIC, a SKOS viewer with special capabilities for improving the viewing experience of EMERGEL Vertical Modules.
While studying the most wide adopted formats to convey information in the emergency domain, a well-known format surfaced in addition of the expected GIS-related formats: the spreadsheet format. Under WP4 efforts, backed up by CTIC’s expertise in RDF modeling and format transformation, a lifting transformation adapter to extract information expressed in tabular form and convert it to RDF was developed. This module proved to be a cornerstone for EMERGEL Vertical Modules population methodology, which lowers the barrier for stakeholders that need to include their domain knowledge, symbology and terminology into EMERGEL knowledge and therefore DISASTER interoperability capabilities. Spreadsheets proved to be the format of choice for potential users coming from different backgrounds. Users find easy the process of filling tables with their domain knowledge, and the rest of the process that makes this information part of EMERGEL Vertical Module is transparent for the user. The tabular transformation programs executed by the lifting transformation adapter perform this last part of the process. As of this writing, 180 transformation programs were written under this effort.
WP5: PROOF-OF-CONCEPT
The DISASTER project is oriented to achieve the data interoperability between the emergency management systems (EMSs) around Europe. Nowadays, the lack of a standard for this communications complicates this task. The main achievement of the WP5 has been the definition, implementation and validation of a reference architecture to achieve format, protocol and semantic interoperability between the legacy systems. To achieve the results, this work package has structured its actions in three related phases: (i) analysis of existing technical solutions for emergency management, (ii) design and implementation of software components for protocol, format and semantic interoperability between legacy systems and (iii) validation of the proposed technical solution in realistic scenarios.
Analysis of existing technical solutions for emergency management: the deliverable D5.1 presents a technical analysis of different EMS already in use in Europe and this study is made at different emergency management levels. First of all the deliverable presents an overview of the present situation of the emergency management in Europe, analysing what laws applies, national/federal systems already in use and a summary of commercial systems. If there is any information exchange proposal or standard it is included to complete the study. The second point classifies the existing EMS at three different levels. At Governmental level the document differentiates national, regional and local systems, and compares differences amongst the same five countries studied before. At Management level the classification introduces the concepts gold, silver and bronze for strategic, tactical and operational levels respectively, and, once again, shows a comparison of the structure amongst the countries. And last but not least, the Stakeholder level compares how police, fire brigades, civil protection and healthcare services work in each country. Emergency management requires data and information not available directly from emergency brigades, so this information is provided by third-party services. These third-party services are divided in two main types, those that are generic and used in almost any possible scenario, e.g. weather information, and those that are specific services in a concrete scenario, i.e. information from a logistics company.
Design and implementation of software components for protocol, format and semantic interoperability between legacy systems: Deliverable D5.42 describes the specific software implementation of the reference architecture achieved in WP2. The DISASTER architecture relies on two main elements: DISASTER Core and DISASTER Mediator. Disaster Core is the kernel of the architecture and provides a set of functionalities shared by all involved participants. This element is also in charge of managing communications between existing DISASTER mediator taking the role of directory service. DISASTER Mediator plays the role of gateway for each EMS connected to the DISASTER ecosystem. There are two types of mediators according to its behaviour: input and output. Both element connects a concrete EMS to other EMS and existing resources but getting such exchange of information in a local way. In other words, the DISASTER Mediator allows an EMS to use external information but transformed according to its own protocol, format, cultural and linguistic characteristics. Protocols and formats considered by the Mediators include Web Map Service (WMS), Web Feature Service (WFS), Geography Mark-up Language (GML), Keyhole Mark-up Language (KML), Portable Network Graphics (PNG), ESRI Shapefile (SHP), Portable Document Format (PDF) and JSON Geometry and Feature Description (GeoJSON). The DISASTER architecture is defined, therefore, as a network of DISASTER Mediators with a central DISASTER Core. Main software units designed, implemented and integrated into the final solution are mediators, semantic-based mediators, handlers and adapters.
(i) Mediator is a piece of software that may include or use handlers, adapters and semantic-based mediator.
(ii) Semantic-based mediators aim to translate the geographic information provided by a source EMS in a way that a target EMS can understand. This translation transforms the external information to the target EMS own cultural and linguistic characteristics. Concepts are extracted from the source data by the mediator and, consuming the EMERGEL REST API, a mapping between different data schemas is executed.
(iii) Handlers invoked intercepting the messages and modifying the response between client and server. DISASTER implements a handler by each existing geographic protocol used in the most common GIS (Geographic Information System): Web Map Service (WMS) and Web Feature Service (WFS).
(iv) Adapters are in charge of format transformation. DISASTER includes generic adapters providing common functionalities for all EMSs, such as images creations, format transformations, sending information to the DISASTER server, etc.
Validation of the proposed technical solution in realistic scenarios: DISASTER project follows a scenario-based design for research and experimentation where the proofs of Concept (PoC) are the cornerstone. Deliverable D5.32 presents the template used to capture all important information concerning the scenario definition, implementation and evaluation. A PoC is defined from both functional and technical points of view in order to evaluate the solutions in realistic contexts but also to validate the software solutions. The scheme defines a context section where all functional requirements (scenario, end users, etc.) are detailed. Technical requirements (data model, technologies and mediation techniques) are described in specific sections. Finally, an evaluation section describes the results and conclusions obtained after the PoC development. DISASTER projects has defined, implemented and validated two realistic scenarios: Border Fire and Air Cargo.
The basis of the border fire scenario is a real incident that occurred at the Dutch-German border. At November the 03rd 2011 a moor-fire occurred at the Dutch-German Border in the area called “Amtsvenn” near the cities Enschede (NL) and Gronau (DE). An area of about 2.6 km2 of moor and turf soil was affected. The affected area is a nature reserve, which is home for rare plants and a sanctuary for rare animals. More than 1.300 German and 900 Dutch fire-fighters were deployed in order to get the situation under control. To fight the fire and control the burning a tight and intensive cooperation between Dutch and German emergency management organizations was necessary. The fire services on both sides of the border usually cooperate during larger incidents. In every situation with a size similar to the presented the supply-organization in the area is of great importance. The information exchange related to the supply of the deployed emergency personnel needs to be coordinated in the corresponding organizations and its ICT on the one hand and between the different organizations on the other hand. Especially in incidents like this that involve different emergency management philosophies due to the involvement of different countries it is of importance to create understanding of the possibilities and capabilities of the involved organizations. The described situation shows that interoperability solutions for large scale emergency events are important factors to improve the performance of the deployed units and the overall situation management. The easier information can be shared the better the involved units can react to the situation at hand. Since sharing this information is often done by using maps enabling interoperability for maps, symbols and icons is a key factor. The scenario used for the DISASTER PoC is a direct reproduction of the introduced situation at the Dutch-German border. It is assumed that a bush- and turf-fire occurs in the mentioned area that is moving from the German side of the border to the Netherlands, as in the real situation. The implementation of the Border Fire scenario showed the viability of the proposed technical approach. This solution allowed real-time interoperability between German and Dutch response teams each one using its own EMS without any change. According to the evaluation questions the following can be concluded: (i) It is possible to connect two systems in real operation environments. (ii) The connection is stable and secure during the operation. (iii) Technical security is achieved by using WS-Security technology. (iv) All sent messages are received by the receiver. (iv) The receive messages are actually sent by the sender. (vi) The messages are valid in terms of protocols and data formats. (vii) The content of the message is correct in terms of translation and mediation. (viii) DISASTER Core is able to carry out not exacting matching between concepts.
The Air Cargo scenario represents an airplane incident in the Schiphol Airport. An airplane which has just landed at its destination airport Schiphol (AMS, Amsterdam Airport Schiphol) is approaching to its scheduled pier. Because of some technical problem with the brake, the pilot is not able to bring the aircraft to a standstill at the pier. Recognizing the upcoming dangerous situation, the pilot as responsible person and equipped with radio connection to the Airside Control Center (ATC) declares “Pan Pan”. Shortly thereafter the plane crashes in the building of the terminal. The power of the impact destroys the exterior wall of the building and causes massive damage to the plane. A fire breaks out on the aircraft nose and threatens the cabin including the crew and passengers as well as the terminal. From now on, AMS emergency plans take precedence over AMS organization. While first responders are approaching to the incident scene, Regie Center informs the local dispatch center of Veiligheidsregio Kennemerland, MICK, about the incident. Depending on the order to the category of the incident, MICK releases a defined number of units (fire brigade, Emergency Medical Service, police) to Schiphol Airport. The challenge for the DISASTER project is to provide the correct information to the correct stakeholder in the correct time and the correct way (meaning translation/mediation/visualization issues). Each piece of information has an owner, and when this information is needed by any other stakeholder, the data flow has to be triggered in some way. When a mediation is needed (because a stakeholder wants to visualize specify information), DISASTER components get involved in the mediation and begin to transform it in the suitable format. Translation/mediation issues of the respective information have to be solved via the ontology and to be provided to the receiving system. This scenario has been evaluated at Schiphol Airport where a high number of end users were involved. As result of this evaluation, a positive feedback was received and the following points can be concluded: (i) Exchanging digital information and integrating data from different sources can help in the process of emergency reaction. (ii) Each organization receives only the necessary information. (iii) Incident information is exchanged in an efficient way. (iv) The information is presented in a friendly-user way to each stakeholder according to the format and cultural characteristics they are familiar with. (v) Incident information updates are presented in real-time to each receiver. (vi) Multiples devices, such as laptops, personal computers, tablets and mobile phones are able to query the information at the same time. (vii) Information are provided by DISASTER using standard protocols and formats so a high number of EMSs can consume this information. (viii) Extensibility can be achieved by implementing light-weight adapters.
WP6: DEMONSTRATION EXERCISES
Summary of Main WP6 Achievements.
The original objectives of WP6 have all been fully achieved:
1 - match functional semantic and symbolic prototype design with use case scenario.
2 - develop and implement technical interfaces between prototype and actual EMS.
3 - design and execute validation exercises from use case scenarios.
4 - evaluate and analyse the test results.
5 - deliver guidelines for European interoperability of emergency processes (via EMS).
WP6 objectives were addressed in an iterative fashion because the First Responder (FR) organisations requested early and realistic demonstration and exercises to test conformance with their requirements. Additional realistic testing meant all objectives became active earlier in the project for early learning.
Summary: Scenario and Prototype Functional Design produced 2 realistic scenarios (Moor Fire and Airport Collision) chosen for their relevance to FR, and for their coverage of different Interoperability problems. That work enabled Prototype and Use Case Technical Design concerning functional requirements, information to be exchanged, and necessary map related data. Development work then provided two semantic interoperability prototypes for deployment in two realistic field exercises addressing the two scenarios. The results of the realistic field exercises were then analysed and reported according to project objectives. The results of testing with key stakeholders in realistic settings clearly demonstrate that the DISASTER investment, supported by technology developers and stakeholders, created a clear pathway for interoperability. The results can be further deployed in Europe to ensure cross-border and cross-institutional collaboration where combined knowledge and capacity are required to effectively manage crisis events..
Scenario and Prototype Functional Design Work.
The project plan for Test Scenarios addressed 2 realistic exercises demanded security service partners.
Moor Fire - The first test scenario and its exercise were derived from the actual historic event-timeline (2011, Moor Fires at a Dutch/German cross border region). The information exchange requirements of key actors were identified and the stated priority of Responders was to “see” across the border using EMS maps, and to have icons and terms on both sides displayed in the chosen language. This process fed the Scenario and Prototype Functional Design which were published at GI4DM 2012 in parallel with the test.
Airport Collision - The second test scenario and its emergency exercise (Schiphol Airport Collision incident) was derived from various incidents. The scenario involved brake failure leading to on-ground collision between an aircraft carrying passengers, and a hangar building containing people and flammable materials. Critical Interoperability issues of concern to Schiphol Airport and its safety partners (exchange of data between regions, safety services, companies, and international actors) were addressed. The timeline and information exchanges defined by VRK formed the basis of planning for the field exercises and evaluation.
Technical Design of Prototypes and Use Cases.
Scenario 1 – Moor Fire - The partners investigated the technical and semantic match between the prototype functional design and the VRK operational crisis management system to ensure that needs would be met. Scenario information and protocols were analysed and information gaps were accounted for in the design of prototype V1 for the first exercise. Existing icons, terms, and map layers were included.
Scenario 2 – Airport Collision – The results of exercise-1 and historic Aircraft crisis data were analysed to deliver a scenario timeline and supporting data exchange events. The resulting crisis process model informed update of the prototype design to meet the functional requirements of the new scenario. Map data were provided by VRK, along with needs for information exchange and usage. Discussions with developers of tools used by VRK, along with VRK key staff, helped define the updated technical strategy.
Technical Design - In both cases, discussions with national and regional process innovators and experts allowed inclusion of design issues relating to emergency management; timeframe for information sharing; necessary level of detail and decision making level; usage purpose; clusters of systems; organisational barriers; likely user understanding; interoperability between the different systems involved; fitting information to the purpose and the moment in incident management. The delivery of the technical design of the DISASTER prototypes was achieved as planned (DISASTER platform and EMERGEL ontology) integrated with the LCMS architecture and interfaces to other systems.
Building the Prototype and Technical Detailing of Use Cases.
The semantic interoperability prototype was developed in 2 stages matched to the 2 exercises, based on discoveries from analyses in (iterative approach). Initial developments focused the textual ontology, the mediation tool for symbol association, the mapping of ontology objects and symbols to geographical data, and the practical arrangements for EMS-EMS communications. The second version of the prototype enhanced EMERGEL and the Mediation Platform to respond to discoveries in the first exercise, and sensitised to the new scenario requirements. A series of performance-oriented tests were defined to allow the technical partners to observe and monitor technical performance prior to deployment. The main activities and outputs were: Information and support service detailing; Ontology service, Geographic data service; Mobile vehicle terminal configured; Performance tests demonstrate PoC and confirmed readiness for deployment in the exercises.
Setting Up and Conducting Validation Exercises.
The schedule for validation exercises started early to allow realistic demonstration and field exercises, with a suitable time period between, allowing First Responder and Designer reflection to maximise impact at the second stage. Validation exercises used the agreed test scenarios, and VRK exercise methods were adapted.
Setup and Testing of the First Scenario : Moor Fire
Scenario History: Moor Fires initiate Peat Fires that travel underground. The cross-border region between Enschede (NL) and Ahaus / Gronau (DE) is prone to such fires, and at the last incident 350 fire officers from NL/DE cut into burning ground to expose the fire layer for water treatment. They faced significant risks (hot areas not always visible). German military mapped heat with thermal images by helicopter, but could not transfer these to NL security, so commanders had coordination problems.
Validation Exercise Overview: Large scale exercises are held by Dutch authorities at the Military Airfield at Enschede, directly adjacent to the geographical location of the Moor-Fire Scenario. The national military communications network (I-Bridge) was used, and the exercise engaged military personnel, regional fire service personnel (who had worked in the actual scenario), German fire experts, and a Dutch National Security Forum (Studio Veiligheid). The exercise was run in parallel to the annual GI4DM conference, and so researchers were “bussed in” as observers (and post-exercise interviewees). Equipment included various command vehicles, and field tents where command groups met – all had access to display screens to view LCMS (Dutch National EMS). The exercise methods of VRK were adapted, and external actors engaged (cross-border agency, crisis teams, airport, etc.). VRK and the project partners successfully designed and conducted an exercise to fully test the prototype data/information support. Commanders and staff used the enhanced LCMS (with added German maps and map data) to prove the concept, and noted that the prototype covered the information gaps (cross-border semantic/symbolic interoperability) identified by commanders during the analysis phase. The demonstration ensured commitment from VRK commanders and staff, and from the commanders and staff of the regional services present at the airfield exercises. LCMS was effectively linked to other EMS and data systems relevant to Interoperability at European level.
Setup and Testing of the Second Scenario : Airport Collision
Scenario History: There was an established history of discussion and negation between airport operators and all safety stakeholders concerning exchange of information during crisis events. A range of imperatives was recognised, and a range of organisational and user needs were already well identified. VRK negotiated the use of a working aeroplane, hangar space, and staff from all key stakeholders so that the DISASTER PoC solution could be demonstrated within the airport in a realistic exercise.
Accidents (e.g. air crash) and other crisis events (e.g. dangerous cargo) challenge stakeholders in working together because established protocols have restricted exchange of information between local actors (on site), and exchange of information with international actors (cross-border). Passenger lists, cargo manifests, aeroplane technical details (especially if adapted) have been very hard to access in times of crisis.
Stakeholders have been searching for a safe experimental opportunity to test secure and trusted exchange of information: agencies who determine protocols need to be convinced of secure exchange capacity; staff working in crisis need to examine new devices and information delivery in realistic usage.
Validation Exercise Overview: VRK arranged to use Hangar space at Schiphol airport, along with a working aircraft, volunteer passengers, and active information systems. They then engaged military police, airport fire safety staff, and regional fire service personnel, along with Studio Veiligheid (National Security Forum), and providers of trusted external systems (e.g. CityGIS). The exercise was run at Schiphol airport in the manner of a normal exercise (crews respond to an alarm call as if in a real crisis).
The exercise involved deployment of ground vehicles, responder staff, and command support. Current First Responder exercise methods were adapted to include new devices (hand held tablets) and new procedures (information exchange). The exercise engaged a range of actors in realistic activities: Regional Mayor; Amsterdam Airport Schiphol; Schiphol Airport Emergency Centre; VRK Regional Emergency Control Room; Transavia (aircraft provider); Regional Medical Emergency Service; Airport Medical Service; Koninklijke Marechaussee (Royal Constabulary); Noord-Holland Police; Airport Fire Service; VRK Fire Service; Air Traffic Control; Schiphol Customs Control (Freight data) and CVO Schiphol Operations.
Commanders and staff were involved in realistically using the enhanced LCMS, enhanced CityGIS, and other information services via normal displays, demonstration displays in the Aircraft Hangar, and in hand held tablets used by fire-crews and support staff around the runways and adjacent areas.
Analysis of the Test Results.
The test results from both exercises were analysed to show the benefits of the DISASTER solution, and to deduce lessons for EU interoperability of EMS.
The first exercise (Moor Fire) provided clear results from a realistic demonstration. Evaluation activities engaged all potential users (Gold, Silver and Bronze level, plus the various support staff present). A range of evaluation methods engaged all Stakeholders, and the results identified topics for investigation in the second exercise. Participants were impressed with the exercise demonstration, and could easily see the benefit of having a Common Operational Picture (COP) based on real data from participating regions.
The second exercise (Schiphol Airport Collision) involved a wider range of actors and information exchange challenges. Data were again gathered by a range of methods to cover the complexity of sub-events and evaluation challenges: a University team of process observer experts focused process; an Ergonomist observer focused individual staff usage; an Expert Responder observer team focused Emergency Management; and a Technical Support team monitored system performance and technical issues. Data from these sources and accompanying evaluation activities were analysed in a detailed evaluation of the overall Emergency Management Process. Challenges identified for stakeholders (e.g. changes to organisational process), and for technology (e.g. adapting hand held device usage to new situations). Safety regions identify the need to consider changes in procedures and protocols to exploit new opportunities, based on the enhanced common operational picture and easier collaboration, include more effective response and faster down scaling of emergency operations, thereby causing less disruptions of the business processes.
Both exercises showed that semantic mediation can “open” LCMS and other information systems to exchanges with other data systems relevant to Interoperability at European level. This is supported by clear observations of how different responders can collaborate better because of enhanced and easier information exchange for greater awareness and more rapid response.
Presentation of the results to high-ranking policy makers concerned with safety and public security provided very positive feedback and support. DISASTER exercises showed that technology is now at a high level of readiness - policymakers can now concentrate on organisational collaboration.
WP6 Added Value
In response to guidance from project reviewers, WP6 completed a set of studies to show that EMERGEL can accommodate interchange and semantic interoperability between many more National sets of icons, lexicons and explanations. As a result, EMERGEL now covers eighteen (18) countries. A further parallel study was conducted to show a range of Emergency Management Systems and their opportunities for interoperability using EMERGEL and the mediation platform
WP7: THE VIRTUAL TRAINING PROGRAM
The virtual training program developed by the DISASTER project is completed and ready to be used. The primary focus of this is training tool are first responders working where cross border operations are likely. However arising out of the DISASTER project, we have learnt that need for this type of training tool at a national level is of great importance. Different agencies working in the same environment such as airports or simply different first responder agencies (Police / Fire / Ambulance, etc.) working in the same region / county need to increase their understanding and awareness of other first responder agencies terminology and methods of working. Shared understanding will allow a more informed common operational picture to emerge quicker and therefore not only improve operational effectiveness but also operational efficiency which is very important at this time of austerity. The ultimate beneficiaries of this shared training are not only those agencies but the public they serve.
The final potential beneficiary from this training programme are also private companies as part of their resilience training process and this sector will allow strong links to be formed between this deliverable and the projects exploitation strategy.
In the first version of this deliverable we referred to this training program as a great alternative to real exercises, as they are costly and logistically demanding. This constitutes a bridge between the “tabletop” exercise and the real exercise, as the program can add realism, without having to use a lot of resources. The training program runs on standard computers and the only equipment needed is a headset, as the voice communication is recorded through it. This has been seen as a great strength by the end-user community who have the duty to train for disasters and crisis situations but operate within several financial constraints.
The training tool will be an excellent dissemination / exploitation asset for the post project dissemination period, as it is not only designed to develop better communication competences, but it also uses Emergel which has been developed under the same project. The maps that are used in the scenario built for this game can be used as an information source for all players, no matter where they come from. It is possible to add icons to describe the situation in the field and use Emergel to translate the icons to the receiver of the information. This way, we can assure that all actors involved do get the same information and have the same understanding of the situation. This definitely contributes to a better communication and a faster reaction time- In short it demonstrates the value of a common operational picture to all involved in the crisis.
The concept:
The training program has been design in order to give the opportunity to first responders, to train their competencies, more precisely, their communication competences. Communication and information / data sharing in major cross border incidents are complex and challenging. Training on this area is crucial to response during a disaster. If first responders are well trained, they will be more likely to respond effectively and rapidly. This also means that they will be more likely to save lives. As saving lives is one of the most significant purpose for first responders, we know that this training program will be relevant to societies within the EU.
The scenario:
For this training program, a plane crash scenario is used throughout the exercise.
The scenario is a passenger plane, crashing on the bridge between Copenhagen Denmark and Malmö Sweden. The scenario was chosen as it illustrates well the cross-border cooperation and involves many actors. It will also be applicable to other EU countries, since they all have airports, they will be able to adapt the scenario for they needs.
This scenario is not linked to the scenarios we will use to test the DISASTER data model, so it is not to be confused with.
IT structure:
The main core of the IT structure is build up to support the game play of the chosen scenario, the figure of the core and the game play structure. The core is able to handle communication in the virtual communication network via phone, email, text, mobile phone and radio, between the units or the incident handlers chosen to take part in the exercise.
[See figure 1.3.6.A: IT Structure]
The core is working just like the crisis communications system of the different EU countries.
But the communications tools have to be defined by each country/role, participating in the exercise.
The core is able to support any given scenario. That means that if any emergency service would like to add scenarios to this core, they will be able too. Then, they will have to develop a playbook and guidelines for the chosen scenario.
The user interface:
The user interface gives the possibility to communicate via landline, radio, text message, map or e-mail.
[See figure 1.3.6.B: The user interface]
The electronic log is another important functionality of the program. With it, it is possible for the instructor to make an evaluation of the exercise and give feedback to the participants. The log function demonstrates clearly all actions taken during the exercises, so it is easy to detect the problematic areas.
[See figure 1.3.6.C: The timeline of the log book]
Finally, the last feature we would like to focus on is the link between Emergel and the training program. Indeed the training program has a direct link with Emergel, which give the possibility to the participants to use the map and symbols in any language available in Emergel, and other participants will be able to see the symbols in the language they choose. For example, a participant playing the Danish fire brigade, can place a Danish symbol for a fire truck on the map and share this map with the other participants. A participant playing a Swedish fire brigade officer can press the button “translate icons”, and he/she will be able to see the equivalent symbol in Swedish.
[See figure 1.3.6.D: Symbol on the map]
Potential Impact:
POTENTIAL IMPACT
The analysis of potential impacts of the DISASTER project is based on the assumption that a more effective emergency management operation leads to a benefit for society. Events such as the floods in eastern and south Germany in the summer of 2013, and of course the repeated forest fires in southern Europe, once again show that cooperation between emergency management organisations and other organisations is a key factor for an effective and efficient operation.
Of course, with the rise of electronic support systems and electronic information exchange the need for interoperability solutions is obvious, though still challenging. It can be assumed that an improved information exchange and an improved cooperation between emergency management and other response organisations throughout Europe will lead to a more efficient and more effective response in times of crisis and emergency.
Improvements in emergency response resulting from the DISASTER project will have a direct impact on society, especially in the affected areas. The overall impact on society can be summarized as follows:
- More effective emergency response leads to increased safety and security of citizens, business, and infrastructure, as well as visitors/ tourism.
- If an incident is handled more efficiently, then there will be a reduced need for resources, as activities won’t be duplicated by responders from different countries.
- More efficient emergency response should mean that the greatest extent of disruption for any given event is lowered, because the situation is brought under control more quickly. This in turn means that less people will be affected by the incident and that the impact is reduced for those who are still affected. In turn, this also means that the return to ‘normalcy’ will be more expedient, as the damage will not be so great.
- More efficient emergency response leads to an overall improvement of the emergency response situation in the society due to more economical planning and execution of safety and security related tasks.
It can be seen that effectiveness and efficiency are the cornerstones of improvement for emergency management. Thus the detailed analysis of potential impact of the DISASTER project results is based on showing improvements of effectiveness, efficiency or both in emergency operations. A formal analysis of potential impact of the results of the DISASTER took place in the development of the DISASTER exploitation strategy, one of the three DISASTER exploitation pillars, which are: 1) The exploitation framework, 2) The exploitation strategy and 3) The exploitation implementation.
A graphic has been created (see attachments) that shows the interdependencies between these pillars as well as the planned interface to possible customers and the society for post-project exploitation efforts. We will now fist discuss details for the exploitation strategy and after that implications of the potential impact for exploitation activities.
In order to structure the analysis of potential impact the exploitation strategy defines three main exploitation model options that all partners agreed upon:
- Technical exploitation including software licensing,
- Exploitation of knowledge and
- Exploitation by training and education.
In addition to these three exploitation model options the consortium identified the potential impact of the consortium itself – meaning the established collaboration practices and workflows. During the project it became obvious that there is not only a need for technical interoperability solutions, but also for assistance and guidance in understanding the complex nature of interoperability, especially in emergency management operations. Most organisations explained that they are first of all in need of understanding the issues they are facing related to interoperability and that after this understanding they will need technical support (e.g. during the DISASTER workshop in January 2014 and the BSSAR symposium on Crete in November 20014). Following this need the consortium identified that the very knowledge that was created and exists between the partners of the consortium will help these organisations to understand their challenges and after that the DISASTER solution will be able to provide sustainable support. Summarizing this, the first potential impact of the DISASTER project is the creation of a single point of contact for interoperability challenges in emergency management. This impact will be quite great and valuable since it assures that the collective knowledge of the DISASTER project is available at one place, although the consortium does not exist anymore on a formal basis.
Based on this first potential impact we will now create a structure of potential impacts following the exploitation model options. We will start naturally with the exploitation of knowledge as the option closest to the first potential impact, after that explain potential impacts arising from the technical exploitation and finally explain impacts arising from training and education, which is build upon the technical results.
Potential impact of exploitation of knowledge
The exploitation of knowledge is tightly linked to the exploitation of the consortium itself as described above. The exploitation of knowledge is the means by which the consortium knowledge will be exploited by individual partners. This can happen in two ways: The first one is consulting. Consulting services aim to improve the situation of the client by means of organisation and advice. Consulting services are created out of reusable best practices and information from former projects and from a comprehensive approach towards improvement. The business case here is the fact that the client does either not have the required knowledge or that the client is in need of an external opinion. Both points have been discussed above as a main challenge faced by many emergency management organisations as well as the industry. Thus the potential impact for consulting derived from DISASTER results is the improvement of efficiency and effectiveness of emergency management operations as well as the preparation of emergency response by assisting in identifying relevant interoperable areas (e.g. process interactions), defining this areas in a formal way and deriving improvements based on the DISASTER results. The second way of knowledge exploitation is by auditing and certification. Auditing and certification means to assess a clients organization, process or product according to a given standard and to confirm if this organization, process or product does comply with the standard or not. The value for the client is the certificate itself and the related possibility to prove compliance with the standard for either legal or competitive reasons. Auditing and certification services require a respected DISASTER standard and brand that they can refer to. The DISASTER consortium aims to create such standard and brand after the project lifetime. This creation process will be supported by the creation of a post-project website as a point of contact for all interested people and potential clients. Thus the potential impact for auditing and certification actions is twofold. On the one hand auditing and certification will improve interoperability by finding non-standard behaviour and suggesting improvements. On the other hand the creation of necessary standards will directly improve emergency management effectiveness and efficiency. Standardisation work has been done intensively during the DISASTER project, especially with regards to the EMERGEL ontology.
Potential impact of technical exploitation and software licensing
In terms of technical exploitation and related impact there are two main assets that can be exploited:
- The Emergency Elements Ontology (EMERGEL) and
- The DISASTER mediator solution, consisting of a core and individual mediator components.
For both mentioned assets as well as any related products (such as software that uses the ontology) there are several licensing options available. In selling software products there are three main options to choose from and, if possible, to combine. Software licensing models can be split into three main types:
- Commercial software licensing
- Free software licensing and
- Open source software licensing.
As mentioned before the main potential impact for both, the ontology as well as the mediator solution, is the support of interoperability processes in emergency management by abstracting mediation and translation work. Both technologies are already in use in end-user environments (e.g. VRK) and several other end-users as well as software developers such as TÜV (Germany) have declared interest in the results. In addition, the software results have been recognized and reused by other research projects such as FORTRESS, so that the scientific development is ensured. It can be seen that the potential impact of the technical results of the DISASTER project perfectly supports the other already identified impact areas. The technical solutions provide means for standardisation (Ontology) and direct interoperability (Mediation component) and are available for all interested users and researchers. With the single point of contact mentioned above the consortium aims to concentrate the discussion about the extension of the ontology to one point and thus will be able to enhance and further improve the ontology in a community process. This will ensure that the ontology is always up to date and offer the best support in terms of the identified impact.
Potential impact of exploitation by training and education
In contrast to consulting, auditing and certification the exploitation by training and education refers to exploitation tasks that aim to improve the clients knowledge and capabilities about interoperability procedures rather than interoperability itself. Training in this context refers to improving habits and operational skills. Education on the other hand refers to the transition of knowledge and the creation of understanding. Training services aim to improve the skills or extend the operational knowledge of a person in a particular area, by applying structured programs. The client in this case is often an individual person or a group of persons from a particular organization. The project DISASTER has produced a training tool that aims to improve the interoperability capabilities of such persons. In contrast to education, training is often provided by companies that have a clear interest in revenue. The training tool is created by the partner DBI and will be available for all partners after the project. In addition, the IP used to create the training tool can be used to create courses without using the tool itself. The potential impact of the exploitation by training, especially with the training tool, is the improved ability of individuals to handle situations that contain interoperability challenges. Thus this result is the basic building block to create the overall improvement of effectiveness and efficiency mentioned above.
Next to the training related results the research underlying principles and issues of interoperability as well at the connected solutions can be used in higher education as well as in educational activities of the partners for their own employees. Education aims to improve a clients (or in this case students) knowledge about a particular field of knowledge (e.g. interoperability) by creating understanding for the underlying principles and concepts. Although education is known as a non-profit area many if not most educational institutions need to constantly update their services and courses in order to get the needed number of students. From this perspective education can be seen as an exploitable asset. Of course the project partner CUAS is the main partner to exploit the DISASTER results in the education section. However, each partner might be interested in educating their own personnel in interoperability topics. In summary, the potential impact of the identified training and education exploitation is the improvement of the capabilities of an individual to deal with a) interoperability in various situations and b) systems and tools (e.g. the DISASTER solution) that help with interoperability challenges.
Ensuring the identified potential impact in all areas
It is important that the identified potential impact per exploitation is supported by concrete means to create this impact. This will happen both on a collective as well as an individual level. The deliverable D7.32 Exploitation Plan V2 explains in detail the various collective and individual exploitation activities. To ensure the mentioned impact on all levels the consortium has set up a post-project website that will serve as a single point of contact for all questions and challenges related to interoperability in emergency management. How this website is working in the overall exploitation setup can be seen in the mentioned figure in the attachments. This website supports the building of an interoperability community (which is necessary according to the first impact explained) and will also support the individual exploitation efforts of all project partners by providing a framework in which each partner can offer its unique exploitable assets.
Potential impact by target group
Based on the exploitation model options explained above the consortium has identified different target groups that will be addressed by DISASTER solutions and will be represented on the post-project website. The following passages describe the potential impact of the DISASTER project by target group. We will then have drilled down from the societal perspective of possible impacts at the beginning over individual DISASTER exploitation model options to specific target groups for exploitation that will benefit from the mentioned impact.
Incident Commanders: Incident commanders will first of all benefit from an enhanced common operational picture available in a shorter period of time to facilitate more informed decision making. This will possibly lead to quicker decisions and thus a more effective handling of the situation at hand. The DISASTER training tool will also offer new training options.
Emergency Planners: Creation of guidelines and assistance for implementing international cooperation in the emergency management sector in the form of planning and plan writing at a local level.
Emergency Management Authorities: These authorities will benefit from the creation of guidelines and assistance for implementing international cooperation in the emergency management sector (e.g. the post-project website), in particular the more overarching support needed to be more interoperable. They will also benefit from the standardisation and certification work since this will make interoperability solutions easier to implement and more reliable.
Governmental agencies: Governmental agencies will also benefit from the creation of guidelines and assistance for implementing international cooperation in the emergency management sector (e.g. the post-project website). They will also benefit from advice and guidelines of how to create a political interoperability environment to enable organisations to work together in a cross-border emergency operation.
The European Union: Also the European Union, as framework entity for all emergency management happening in Europe will benefit from advice and guidelines of how to create a political interoperability environment to enable organisations to work together in a cross-border emergency operation. This is not limited to EU administration but also affects EU research since the results from the DISASTER project will be available for future projects to be used.
Private (multi-country) companies: Private (multi-country) companies will be able to improve their means to cope with emergencies, especially if different organisations or departments are involved. This will improve efficiency and effectiveness of emergency reaction in the particular organisation, resulting in reduced losses. In addition, especially the DISASTER standardisation work as well as the certification and audition exploitation will offer improvement of market position by showing compliance to DISASTER standards in interoperability for each interested organisation.
Software companies: Software companies will be able to improve their market placement of the software companies’ products by implementing the DISASTER mediation components in the software. This will also cause a more harmonic market environment for emergency management software and thus lead to more effective emergency management. Software companies will then also be able to improve their market position by showing compliance to DISASTER standards in interoperability.
Emergency Management Educational Institutes: Such institutes (like CUAS) will be able to create new educational resources and research results regarding interoperability and cooperation of emergency management organisation in international operations and between different organisations. This of course will then proved a benefit for the whole society.
Students: Students of the mentioned institutes will benefit from an improved education and understanding of interoperability in emergency operations, leading to a better position on the job market.
A partners own personnel: Finally, each project partner might want to train it’s own personnel, leading to improved education and understanding of interoperability in emergency operations, and thus to more efficient and effective processes and to a better outcome in emergency situations or more effective emergency management handling in emergency management projects.
MAIN DISSEMINATION AND EXPLOITATION ACTIVITIES
NOTE: A full catalog of dissemination activities has been attached as a separate file (pdf).
Throughout the duration of the DISASTER project, all partners have been actively involved in dissemination activities. The first six months of the project were used for developing a dissemination plan for the entire duration of the project. The strategy we adopted was to first look into what we wanted to disseminate which was:
- Our developed data model and modular ontology for facilitating data exchange between first-responders in European countries.
- Our developed service oriented architecture (SOA) mediation algorithms facilitating interoperability between emergency management systems (EMS).
- Published material provided by our partners that aims to share the underlying scientific and technical basis, and project specific developments, that contribute to interoperability of EMS. This will include project reports and published scientific and technical papers.
- Published material provided by our partners that aims to share the conceptual and operational vision of improved communications between first responders in crisis management. This will include presentations, exercises, cases, and publications addressing the organizational and operational aspects of interoperable EMS usage.
- We also want to communicate the overall goal of the project, which is to improve communication between first responders on the scene. We will fulfil both of these objectives by informing the stakeholders at different stages in the project.
We also determined who we wanted to address, what would be the audience for our dissemination strategy:
- Public Administrations planning and implementing emergency response solutions.
- Emergency Management Agencies who are actively dealing with crisis and emergency, and who seek to improve capacity for ensuring public safety through maintenance of best technology solutions.
- Assistive agencies such as NGO’s (red Cross etc.) who may be engaged in providing specific support to disaster management agencies.
- Technology Companies developing EMS and related technologies.
- Research communities where scientific and technical developments can be shared as contribution to general progress in any EMS related areas of research. This will be achieved via conferences, journals and dedicated workshops. In particular, DISASTER targets scientific communities of the Semantic Web and Linked Data technologies, and Geographical Information Systems and Data management and integration.
- Standardization bodies that ensure common and appropriate solutions for geographic and other visual and underlying data and metadata, as well as standards for communication relevant to disaster management.
- Media channels who are relevant to the broad community of interest (Trade Magazines, Technical Publications, etc.), as well as media and any other information provider groups that could be present on a disaster scene (not being an EMS, but sharing information).
The third point of the strategy was to look into how we would disseminate:
A) Plan: Planning of the dissemination strategy and the exploitation of the results.
This includes clarification of target communities and stakeholders throughout the first phase of the project.
B) Design: Agree on the logos, templates and other details for the website and promotional material, as well as templates for our internal documents and various types of reports.
C) Create: Creation of the website and other promotional material like leaflets and emails.
D) Distribute: Use of the website, leaflets and publications to promote the project, send emails to stakeholders and look into possible use of other websites.
E) Represent: Participate and organize workshops, conferences and seminars.
F) Evaluate: Evaluate efficiency of the dissemination strategy by looking into number of visitors to the website, attendance to conferences, participants to our events, number of publications, etc.
G) Distribute: Marketing and distribution of the project’s results.
We also tried to look into when each of the named steps would be completed. Some of the activities described in the figure above were completed within the first few months of the project. Planning, designing, creating and distributing were steps we did start with in the beginning of the project. We created, distributed and represented during the entire duration of the project. We have now reached the evaluation and the final distribution step, where we are looking at the success of our dissemination strategy and how we will do the marketing of the results. In order to look at our successful we have been with our dissemination strategy, it is relevant to look at the activities we performed during the project.
Participation in conferences, seminars and workshops:
Conferences: The project partners have attended/participated in seventeen conferences including one organized by partners and two co-organized. Examples of the conferences are: the international conference on Geo-information for disaster management, Conference for Disaster and Risk reduction, BSSAR symposium, ISCRAM, BAPCO, World congress on Disaster and Emergency medicine, German Fire protection Association conference, etc.
Workshops and seminars: The project partners participated and presented to over thirty-five different events such as, FKB yearly meeting (Municipal fire brigades), FEU yearly meeting (Federation of European Fire Chiefs Association), end users workshops in Germany and Denmark, meetings with law enforcement, fire brigades, airports, etc. CEN meetings,
Website and social media:
Treelogic, who is coordinating the project, has established the project website, quickly after the start of the project (http://disaster-fp7.eu).
[See figure 1.4.2.A - DISASTER website - Home]
A second website, targeting the exploitation of the project’s results is planned to be designed in 2015.
As for social media, we did use LinkedIn as a primary media, since our target audiences include experts, professors, emergency managers, etc. We wanted to assure that we would have contact to professionals.
Our LinkedIn group has a hundred and twenty members and project partners are also members of other expert groups so we can disseminate the project results via other groups. These groups are for example: Crisis, Emergency &Disaster Recovery professionals, International Disaster & Emergency Resilience, Institute of civil protection and emergency management, Disaster & Emergency Management.
[See figure 1.4.2.B - DISASTER LinkedIn discussion group]
Training:
The DISASTER training program has been used throughout the project duration in order to raise awareness to the project. We also had several ends users/stakeholders participating in the development of the program which strengthened their knowledge of the project. The training program will be used as a dissemination tool for the DISASTER model since it can demonstrate how it can work in the field. And it will be an excellent tool for training first responders in crisis communication. A more detailed explanation of what the training tool can do, can be found in section 1.3 “Description of the main S/T results/foreground”, in particular 1.3.6 “WP7: Training program” of the document, or the deliverable D7.13.
Publications:
Conference abstracts, conference articles, posters, scientific articles and magazine article have been published since the beginning of the project. In total, we around twenty-one publications were produced including: 1 scientific article, xx conference articles, 5 magazines articles, two press releases, two conference posters,
Network:
Throughout the project we have use our existing networks to disseminate the progress /results of the project and/or get them involved in the project. Existing networks include: Copenhagen Fire brigade, Helsingør Fire brigade, Copenhagen Police, Danish Emergency Management Agency.
This project contributed to strengthen the existing networks, but also gave us the opportunity to develop some new connections such as: FEU (Federation of European Fire Chiefs Association), Arlanda region fire brigade (Sweden), Lund University Centre for risk assessment and management.
Newsletters:
We created six newsletters, which constitute two newsletters per year. In each newsletter, we updated the stakeholders on the progress of the project, conference and/or other types of event we attended or would attend in the future, and pieces of scientific information that was linked to our project. The newsletters were distributed amongst our networks and contact, published on the project website and also shared on our linked in group.
Other dissemination material:
Other dissemination material has also been produced such as PowerPoint presentations, leaflets and posters. In total, five flyers have been produced, which were adapted to the nee d the project partners had at the time. We also created over thirty-five different presentation for the project, all adapted to the audience we were addressing, as well as language. Two official posters were created, which were first used for presentations at conferences but were also used in other situations (presentations, meetings) as dissemination material. Finally, we also made one video, from the Schiphol exercise, which demonstrates clearly the use of the DISASTER model.
List of Websites:
A) PROJECT WEBSITE: http://www.disaster-fp7.eu
B) TWITTER: http://twiter.com/disaster_fp7
C) LINKEDIN GROUP: http://www.linkedin.com/groups/Disaster-Project-4327860
D) CONTACT: info@disaster-fp7.eu
