Bojan Božić
email: bojan.bozic@ait.ac.at

Mert Gençtürk

Refiz Duro

Yildiray Kabak

Gerald Schimak

Requirements Engineering for Semantic Sensors in Crisis and Disaster Management

Keywords: requirements, crisis and disaster management, semantic sensors

This paper describes the requirements engineering methodology used for the definition of semantic sensors in a Crisis and Disaster Management framework. The goal of the framework is effective management of emergencies which depends on timely information availability, reliability and intelligibility. To achieve this, different Command and Control (C2) Systems and Sensor Systems have to cooperate and interoperate. Unless standards and well-defined specifications are used, however, the interoperability of these systems can be very complex. To address this challenge, in the C2-SENSE project, a "profiling" approach will be used to achieve seamless interoperability by addressing all the layers of the communication stack in the security field. The main objective is to develop a profile based Emergency Interoperability framework by the use of existing standards and semantically enriched Web services to expose the functionalities of C2 Systems, Sensor Systems and other Emergency and Crisis Management systems. We introduce the concepts of Semantic Sensors, describe the characteristics of Sensor Systems in Emergency Management, and the methodology of requirements engineering for such a framework.

Introduction

Emergencies and disasters caused by nature and humanity do not recognize country borders and create international problems (see e.g. [START_REF] Seidel | Analysis of Historical River Floods -A Contribution Towards Modern Flood Risk Management[END_REF] and [START_REF] Ulbrich | The central European oods of August 2002: Part 1 Rainfall periods and ood development[END_REF], and references therein). These include flooding, forest fires, and industrial accidents, to name a few. The Emergency and Disaster Management hence needs cross border solutions, in order to facilitate communication, resource management and offer solutions to emergencies. This is one of the main motivations for the C2-SENSE 1 Framework, where the knowledge, capabilities and experience from a consortium of several European partners 2 is implemented.

Due to such a partnership, a specific approach in the framework development is needed, explored and implemented. Therefore, the partners decided to use a dedicated requirements engineering methodology, which is explained in Sec. [START_REF] Martinez | Sensor Network Applications[END_REF].

The development of an Emergency and Disaster Management tool, such as C2-SENSE, which will apply the current achievements in semantic sensor technologies, is a complex process requiring specific development methods. In our method for the C2-SENSE framework, there exist three different levels of requirements. The first level is the Emergency Domain Inventory, which uses existing standards, real life use cases of sensors, devices, C2 systems and Emergency Management architectures for different scenarios in the security field. The second level is the common Emergency Domain Ontology, which gathers the knowledge of all stakeholders in a unique and flexible data model. The final level is the Emergency Interoperability Profiles which are developed by using the concepts in this ontology and also by taking into account both functional and operational requirements, as well as different countries' cultural, linguistic and legal issues. This is especially important since such profiles include diverse users such as local authority representatives, activists from non-governmental organizations, and police departments.

Standardization activities that aim to evolve the C2-SENSE Emergency Interoperability Framework into a standard specification for interoperability between Sensor Systems and C2 Systems are also part of the requirements engineering process. The framework developed in the C2-SENSE project will assess its outcomes in a realistic pilot that will cover the Puglia region in Italy to ensure that the developed technologies are generic and applicable in a real life setting.

In the following sections, we describe the requirements engineering process in more detail. In Sec. 2, the importance of semantic sensors is discussed. The available and relevant semantic sensor technologies for the C2-SENSE project are presented in Sec. 3. The method used in the requirements engineering process is shown in Sec. 4, while the lessons learned and conclusions are in Sections 5 and 6.

Semantic Sensors and Interoperability

To achieve interoperability, sensors and humans need a common ground of communication and understanding, which is expressed in the ontologies.

Current State of Data and Semantics

Sensor technology is constantly evolving at a high pace; hence we face a constant increase in the amount of new available data. Such a situation asks for an integration of plethora of sensor types that provide diverse capabilities, such as range, modality and maneuverability. Networks with multiple sensors are becoming common ( [START_REF] Hart | Environmental Sensor Networks: A revolution in the Earth system science?[END_REF], [START_REF] Martinez | Sensor Network Applications[END_REF]) and can detect and identify objects of interest from great distances and under demanding conditions [START_REF] Werner-Allen | Deploying a Wireless Sensor Network on an Active Volcano[END_REF].

There is, however, a lack of proper integration of sensor data leaving us with large amounts of data, but with a low amount of knowledge about this data. For example, an air quality sensor can give us a measurement of the C02 level in the air (a datum), but will probably not provide us with the sensor calibration status or its geospatial location (additional descriptive data). To change this limitation in the field of e.g. the Emergency Management, the sensor data should be annotated with metadata. Technologies such as Semantic Web and Sensor Web Enablement (SWE, [START_REF] Jirka | Applying OGC Sensor Web Enablement to Risk Monitoring and Disaster Management[END_REF], [START_REF]Open Geospatial Consortium Sensor Web Enablement (OGC SWE)[END_REF]) are very suitable for this task. Metadata annotation will help us in order to provide contextual as well as situational awareness information. The basis for this is the concept of spatial, temporal, and thematic metadata for sensors, which is being standardized by the Open Geospatial Consortium (OGC, [START_REF]Open Geospatial Consortim[END_REF]) and the World Wide Web Consortium (W3C, [START_REF]World Wide Web Consortium (W3C)[END_REF]). Activities related to the extension of the existing standards with Semantic Web technologies have been initiated in both organizations in order to improve the description of and access to sensor data.

Sensor Interoperability

One of these standardization activities is the development of the OGC Sensor Observation Service (SOS, [START_REF]Open Geospatial Consortium Sensor Observation Service (OGC SOS[END_REF]). This is a Web service specification defined by the OGC's Sensor Web Enablement group in order to standardize the way sensors and sensor data are discovered and accessed on the Web. Besides the main objectives, the standard is providing interoperability between repositories of non-homogeneous sensor data and applications that consume these data. As aforementioned, a lack of knowledge of what kind of environment these data represent is a serious obstacle for data handling applications and value extraction. To solve this, the data need to become smarter, which means that there should exist a more meaningful representation of sensor data. The Semantic Sensor Web initiative models the domain of sensors and sensor observations in a suite of ontologies. Semantic annotations are then added to sensor data by using the ontology models to reason over sensor observations and extend the SOS implementation with semantic knowledge. Such semantically enriched data can be queried by semantically enabled SemSOS [START_REF] Henson | SemSOS: Semantic sensor observation service[END_REF], i.e. the knowledge of the environment, as well as raw sensor data, can be extracted.

Sensor Systems in Emergency Management

An important element in the architecture of a (semantic) sensor network in Emergency Management is related to communication, since the Sensor Systems are based on several protocol messages at different levels. This implies that besides the sensors and hardware, the used communication protocols and standards on different levels are of high relevancy.

For the communication between Sensor Web Services we use Simple Object Access Protocol (SOAP, [START_REF]Simple Object Access Protocol (SOAP)[END_REF]), which is transported through HTTP, TCP, and IP packets. These are in return sent as Ethernet or WiFi messages. Other kinds of sensors and standards used in the development of C2-SENSE tools are:

• Seamless Communication for Crisis Management (SECRICOM, [START_REF]Seamless Communication for Crisis Management Project (SECRICOM)[END_REF]), which addresses the physical level interoperability for a pervasive and trusted communication infrastructure. • TErrestrial Trunked Radio (TETRA, [START_REF]Terrestrial Trunked Radio (TETRA[END_REF]), Worldwide Interoperability for Microwave Access (WiMAX, [START_REF]Worldwide Interoperability for Microwave Access (WiMAX)[END_REF]), GSM and WiFi. [START_REF]Alert Management Service (ALMAS[END_REF]), News Markup Language, or Events Markup Language (EML, [START_REF]Event Markup Language (EML)[END_REF]). • Situational Awareness Standards such as EDXL-Situation Reporting (SitRep, [START_REF]Emergency Data Exchange Language Situation Reporting (EDXL-SitRep)[END_REF]), Tracking of Emergency Patients (TEP, [START_REF]Emergency Data Exchange Language Tracking of Emergency Patients (EDXLTEP)[END_REF]), and Emergency Geospatial Data Distribution Standards such as OGC Web Services (OWS, [START_REF]Open Geospatial Consortium Web Services (OWS[END_REF]), OGC Keyhole Markup Language (KLM, [START_REF]Open Geospatial Consortium Keyhole Markup Language (OGC KML[END_REF]), OGC Geography Markup Language (GML, [START_REF]Open Geospatial Consortium Geography Markup Language (OGC GML[END_REF]) or compact GML.

Requirements Engineering Methodology

Well-designed and efficient coordination of ideas and implementations is required when involving several project partners. The requirements engineering methodology implemented in the C2-SENSE framework aims at providing this in a simple and sufficiently flexible way.

Requirements Engineering Process

The requirements engineering process used in the C2-SENSE project is shown in Fig. 1. Firstly, a state-of-the-art analysis of relevant projects, tools and technologies is prepared. The analysis is used as a primary basis for the second step, i.e. the extraction of C2-SENSE requirements. Further, the requirements in general can be subdivided into system requirements and pilot application requirements. Thus, there is an interchange between these two tasks. Pilot requirements and general requirements tasks cooperate in order to provide a common understanding of the project goals, as well as to synchronize the inputs of users and technical partners who are responsible for the implementation of software components. Concrete input for requirements engineering is provided by use case diagrams developed by each project partner. The diagrams define the functionality of the respective components, and templates for technical and user requirements, and for the requirements platform database.

The requirements platform database can be accessed via a Web platform interface and is used to categorize different kinds of requirements. It is also used to manage the requirements and their changes during the life-cycle of the framework. Finally, the requirements are used in the architecture and design tasks for defining the architecture of the C2-SENSE system.

Figure 1: Requirements Engineering Process

In the next section, a more detailed explanation of the engineering process steps is provided.

Disaster Management Requirements

The following general disaster management requirements are supported by the C2-SENSE platform:

• Collaborative Decision Making: Collaborative Decision Making supports different users, different command and control systems, and different doctrines and procedures.

• Tasking:

First responders and other units and resources need to be organized, i.e., tasked with assignments.

• Monitoring and Reporting:

Monitoring and Reporting provide position reports and reports on casualties and obstacles.

• Re-tasking:

Re-tasking may be required during a mission to allocate a unit which is available in a given period of time. An example of a functional technical requirement is the one that is related to the interoperability tasks central to the C2-SENSE framework: a development of protocol adapters that provide a standardized, common view of all integrated data sources and services. Such approach produces the framework where the data is linked automatically, as in Linked Data [START_REF] Bizer | Linked Data -The story so far[END_REF].

State-ofthe-Art Requirements

For non-functional requirements there are notions of independency, scalability, accountability, etc. For example, one of the requirements is that the user interface modules must not rely on proprietary APIs or services that pose the risk of exposing security and privacy sensitive information to third parties. Such requirements are carefully considered in order to make their implementation and usage as smooth as possible.

The user requirements are developed based on use cases that are defined by each partner for their respective component. Moreover, the use cases are directly related to the functional technical requirements, where one technical requirement can have several use cases. A use case describes a specific function required by the user or the user program/system. These are carefully chosen based on the domain user experience (i.e. a fireman, an NGO activist, or a local authority representative), the Emergency and Disaster literature and standards, and the technical requirements. An example of a use case is the "plug and measure" component, i.e. plugging in a sensor that immediately becomes eligible for measurement operations.

When considering responsibilities, each partner is given the possibility to provide the technical and user requirements that fit to that partner's domain and expertise. At the end, the sum of all requirements corresponds to the architecture of the whole system, which means that functional requirements are bound to the system components.

Templates

In order to collect technical requirements and use cases from all project partners, templates based on [START_REF] Cockburn | Writing E_ective Use Cases[END_REF] and [START_REF] Coleman | A Use Case Template: draft for discussion[END_REF] were provided. They were designed as forms and were also used to prepare partner input for the requirements database. The goal of this is to make the cooperation and planning simpler, to identify the possible issues at an early stage, and to ease the transition to the architecture and the implementation. The technical requirements template consists of a general, but concise description of the C2-SENSE component, a list of use cases implied by the component, a general function description of the component, and a description of the characteristics of the intended component's users, including educational level, experience and/or technical expertise.

The use case template is more extensive. The project partners provide the following information in the template: a description of what the specific use case does and in which context the use case is applied; the scope of the use case (i.e. which system component in the framework is considered); a list of actors involved in the use case, where the actor refers to a person, a role or a system that triggers the use case in order to reach the defined goal; a description of the goal that the actor pursues upon use case execution; a trigger event and the frequency of the use case realization (e.g. once daily, weekly, etc.). Additionally, UML use case and sequence diagrams are provided to explain the use cases in more detail.

Requirements Platform

The requirements platform is an ancillary way of increasing the efficiency of the requirements engineering process. It is developed to provide a simple method for technical and user requirements input. Moreover, it is meant for the long-term management of requirement changes, as well as for input of new requirements discovered in later phases of the project.

In short, the platform is a web page3 , on which each project partner has a possibility to log and submit the changes to the existing requirements, or to provide new requirements (see Fig. 2). The web platform is structured in a way that the distinctions and relations between the technical and user requirements are very clear. This should increase the efficiency and understanding among the project partners.

Discussion

Our experience with the proposed methodology for requirements elicitation is twofold. At first we started by defining a template in a text document and provided it to project partners based on their responsibilities. The problem, however, was to motivate every partner to participate to the collection of requirements and to show them the importance of having a complete set of framework requirements. The break-through idea was to initiate a web platform for requirements collection and visualize how requirements are related to each other and how the lack of information on a use case can lead to problems in the implementation phase. After understanding the linkage and the possible impacts, in addition to have an easy to use and intuitive platform for collection and management, the process of requirement engineering has improved significantly.

The feedback from all our partners was positive after the change in methodology and we managed to collect user requirements, technical requirements, and use cases in a quick and professional way. It is often very tough to decide when a list of requirements is complete; therefore pitfalls can arise when requirements management is overstressed. On the one hand one does not want to miss important requirements and have an incomplete specification, but on the other hand, putting too much effort in completing the specification phase is not only cumbersome and repetitive for the project team, but also does not lead to a lot of new insights.

Therefore, we recommend a requirement elicitation which supports a dynamic, iterative process and management of new requirements and update of already existing ones throughout the whole project phase.

Conclusions

This paper describes the work in the area of requirements engineering specifically applied to semantic sensors in the Emergency Management field. Our contribution is primarily in the proposed method for collection, management, and evolution of requirements, and the development of specific categories for Emergency Management sensor system requirements. We apply templates that cover the necessary information for technical and user requirements. This is thus more important since there are several international partners involved in the project. A template keeps the ideas concise and simple, which on the other hand increases the understanding in the communication process among partners. We also introduce a web platform, which covers the whole requirements engineering process and which can be reused for similar projects. Our experience with the platform shows that it is effective and efficient, and that it provides a simple way to manage requirements for all the partners involved.

Well-designed and implemented requirements engineering is one of the keys for the success of a project such as C2-SENSE. It is a founding ground for the remaining steps in a process of a system development, and as such is of high importance. It must, however, be simple and flexible enough to allow changes at later stages in the project, and to aid the exchange of ideas among partners. Our proposed method provides the mentioned, is implemented in the C2-SENSE project, and can thus be used in similar projects.

  requirements are divided into technical and user requirements. Technical requirements are further subdivided into functional and non-functional requirements.

Figure 2 :

 2 Figure 2: Screenshot of the Requirements Database platform of the C2-SENSE framework.

Requirements Database of the FP7 project is located at http://service.ait.ac.at/c2-sense/

Acknowledgements

The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement nr. 607729.


Gianluca Correndo

Banafshe Arbab-Zavar

Zlatko Zlatev

Zoheir Sabeur

Context Ontology Modelling for Improving Situation Awareness and Crowd Evacuation from Confined Spaces

Keywords: crisis management, decision-support, sensor data, semantics, context ontology modelling, crowd behavior

Crowd evacuation management at large venues such as airports, stadiums, cruise ships or metro stations requires the deployment and access to a Common Operational Picture (COP) of the venue, with real-time intelligent contextual interpretation of crowd behaviour. Large CCTV and sensor network feeds all provide important but heterogeneous observations about crowd safety at the venue of interest. Hence, these observations must be critically analyzed and interpreted for supporting security managers of crowd safety at venues. Specifically, the large volume of the generated observations needs to be interpreted in context of the venue operational grounds, crowd-gathering event times and the knowledge on crowd expected behaviour. In this paper, a new context ontology modelling approach is introduced. It is based on knowledge about venue background information, expected crowd behaviours and their manifested features of observations. The aim is to improve situation awareness about crowd safety in crisis management and decision-support.

Introduction

Advanced situation awareness, safety of crowd and their evacuation from large mass gathering venues during incidents is of paramount importance in crisis management. The crowd must be evacuated rapidly towards safer zones. However, the real-time monitoring of crowd during incidents is an enduring responsibility taken by security managers. Nowadays security personnel is able to observe venue spaces in real-time through using ICT based devices and use automated systems for their decisionsupport. The ICT devices and systems may include a large network of deployed CCTV cameras, multiple arrays of sensors and a Common Operational Picture (COP) of the venue of interest. Nevertheless, security managers can be overwhelmed by sheer volumes and complexity of observation data while making their decisions on crowd spatial evacuation in real-time. Further, they could potentially encounter risks of failure in their decisions since they may not be able to capture and interpret incident related situations critically on time.

The eVACUATE1 project specializes in crowd behaviour detection using multiple video observations under the visible, thermal and hyper-spectral light bands, which is also enhanced by high level crowd psychology and typology knowledge reasoning, modelling and fusion. This shall add value to existing crowd evacuation strategies with much improved situation awareness and decision-support. Four crowd evacuation pilot experiments are considered in the project. These include the following: 1-Evacuation of a Soccer Stadium -Real Sociedad de Futbol S.A.D (Spain); 2-Mustering and evacuation of passenger cruise ship -STX-FR ( France); 3-Airport Terminal evacuation -Athens International Airport(Greece); and 4-Metro Tube evacuation -Metro Bilbao S.A (Spain).

Crowd behaviour modelling is an established discipline in numerical phenomena simulation. Also, with more affordable and easy to deploy ICT devices to monitor crowd, it has become possible to analyze human behaviour with more degrees of spatial granularities and context to advance knowledge reasoning and crowd behaviour modelling. "Normative behaviour models" are based on established cognitive psychology theories, or "Script" (Schema) theories [START_REF] Schank | Scripts, plans, and knowledge[END_REF]. These postulate that human behaviour can mostly be described as a set of patterns, so called "scripts". These are basically comparable to the way a written script is set with its provision of a program for actions. For example, the stringent requirements on following safety procedures on board aircrafts or cruise ships is a typical attempt to set up appropriate temporary schema to be used during emergency [START_REF] Chang | Aviation occupant survival factors: An empirical study of the SQ006 accident[END_REF]. Therefore, it is highly desirable to investigate on the scripts which can be generated by crowd during a real evacuation event from a given venue. This will provide a good basis for understanding how crowd evacuation evolves in space and time and also learn from it for further improvement on future evacuation plans. It is worth noting that understanding usual (and unusual) behaviour in context of crowd types and gathering venues is essential to proceed with this study.

Automated usual (and unusual) behaviour detection aims at supporting security managers and decision-makers during normal crowd monitoring activities as well as during evacuation. In this paper, an ontological framework based on causality assumption on crowd behaviour is developed. This is in contrast to the traditional rigid approaches based on the creation of ad-hoc rules which describe crowd behaviour. Moreover, the proposed approach introduces context knowledge as a source of important information, to improve the crowd behaviour classification process and modelling.

Context Knowledge and Human Behaviour Detection

Research interest on domain knowledge usage for improving the performance of traditional machine learning based human behaviour detection classifiers from vision observation has been growing over the last few years. Concepts of ambient intelligence which are embedded in cognitive vision systems have also been explored. The use of context about crowd typology in accord with mass-gathering venue characteristics, including operational spaces and times are being researched for advancing the performance of crowd behaviour detection algorithms using vision in the eVACU-ATE project.

Contextual Knowledge in Cognitive Vision

In [START_REF] Gonzàlez | Human sequence evaluation: the key-frame approach[END_REF] it is presented an approach, named key-frame, for modelling human sequences within cognitive vision systems that allow the description and synthesis of human actions within spaces. The approach focuses on actions performed by individuals, segmenting them into key frames which are characterised by body posture configurations. At higher level of abstraction, human behaviour(s) are described in a lattice of symbolic templates, named situation graph trees. The graph trees describe the relationships between agents and the surrounding environment. Various types of semantic representations have been proposed within the framework of human sequence evaluation. Depending on the addressed domain of safety and security surveillance, they can support the classification of critical situations accordingly. Within the surveillance domain, an ontology has been proposed [START_REF] Fernández | Ontology for semantic integration in a cognitive surveillance system[END_REF], based on the key-frame approach. The core of this ontology is introduced with the following listed concepts: 1) Event (or situation): Characterized by a status, which encodes metric-temporal knowledge; 2) Contextualized Event: Describes higher level interactions among entities; and 3) Behaviour Interpretation: Specifies surveillance oriented behaviors of interest, i.e. "abandoned object". One of the main issues in applying such approach for monitoring crowd in EVACUATE's confined spaces is that it will be almost impossible to maintain the identity of the monitored entities and rendering the tracking of agent's activities through frames. Moreover, there is no design pattern that will support the creation of general behaviour(s). This approach seem to be too rigidly linked to the native domain of crowd surveillance and cannot be proposed as a reusable knowledge for modelling.

Context in Ambient Intelligence

Ambient intelligence concept ontologies are used to provide high level descriptions of situations in order to support context awareness in smart applications for decisionsupport. The term "context" is understood to be: "Any information that can be used to characterise the state of an entity" [START_REF] Dey | The context toolkit: Aiding the development of contextaware applications[END_REF]. The aim of ambient intelligence is also for recognising what users do so that they can be assisted in spaces around which they move. This aim somehow steps on the definition provided on "human behaviour" [START_REF] Remagnino | Ambient intelligence: a gentle introduction[END_REF].

Context here plays a key role for understanding not only the activities performed by agents within a spatial environment, but also how these activities can be interpreted within a broad framework of relationships between other agents, entities and unfolding events. These concepts have been modelled using ontologies such as: COBRA-ONT [START_REF] Chen | An ontology for context-aware pervasive computing environments[END_REF] and SOCAM [START_REF] Gu | A middleware for building context-aware mobile services[END_REF]. Nevertheless, such ontologies provide concepts only for user-oriented entities such as Location, Person, or Activity. They are solely focussed in personalised ambient intelligence but with less interest on the specificities of human behaviour detection.

Context Information in Crowd Evacuation Management

Context in ambient intelligence is understood to capture the amount of information that could characterize a situation of an entity at a given space of interest. It is partly given and/or acquired, while it remains user interactive and application centric. In eVACUATE, context information and sensor observations are kept separate. Nevertheless, Context is used in the interpretation of the sensor observation. With this in mind, context is defined as the amount of a priori knowledge information about expected crowd behaviour(s) at given venues of interest. This prior knowledge is assumed to give trade-offs on better interpreting and detecting crowd behaviour from video sensing. During the monitoring of crowd in real-time, it is important to model the expected interactions of crowd(s) at various spatial scales. These include macro-, meso-and micro-scales. They could represent overall people, finite number of people as a group and single individuals within the crowd respectively. These types of interactions can be modelled by representing them as causal connections across a prior known behaviour modes, contextual information and observed (detectable) features.

New Crowd Behaviour Contextual Modelling

Ontological models are used to describe crowd Usual (expected) behaviour(s) in context of venues. These models describe how behaviour manifests itself and how it compares with its detectable features through sensor observations. When discrepancies between the expected and detected behaviour occur, then the behaviour is classed as Unusual. Equally, when discrepancies do not occur, the behaviour is classed as Usual. The distinction between Usual and Unusual behaviour in this study is mainly dependent on the following: 1) Context; 2) The Model which describes the situation; and 3) The set of observations which are collected from a venue. Similarly, subdivisions of Context, Model, and Observations are found in logical problem definitions such as diagnosis and diagnostic in model-based reasoning [START_REF] Teije | An extended spectrum of logical definitions for diagnostic systems[END_REF]. For instance, Diagnosis is described with a set of assumptions that are joint with a logical model system (i.e. Crowd at a given Venue) and context to explain observations. For example, when monitoring a flow of spectators at different parts of a venue, like a football stadium during a match, usual behaviour is specifically characterised in accord with the place that is monitored (e.g. Entrance Gate; Ticket Counters, Bar, Club Fan Shop, Stands etc.). Usual behaviour is also characterized in accord with the various stages of the unfolding event (e.g. Pre-Match; Match in progress; Post-match).

• Pre-Match: The spectators are expected to enter the stadium through the Entrance Gates. From there they proceed to the Stands.

• Match in progress:

The expected behaviour at the stands is for spectators to be partly stationary on their benches (i.e. with oscillatory or occasional movements of small groups for toilet breaks and trips to the bar). Hence, any substantive movement of individual or groups of spectators towards opposite fans can be considered as unusual. • Post-Match: Groups of individuals are expected to leave the stadium and head towards the car parking spaces.

The above mentioned example of venue and crowd type clearly shows that the various stages of the football match event together with the various monitored areas around the stadium are by far the most important knowledge for defining the expected (Usual) behaviour of spectators(crowd or fans). Specifically, crowd physical motions related parameters such as the predominant crowd velocities (speed and direction) and densities (counted number of people per unit area) become important to measure. In this case, rules that model expected crowd behaviour at a football match can be simply defined as follows:

BehavioralMode(usual) ˄ Venue(stadium) ˄ Time(pre-match) ˄ Place(gate) ⊢ Expected(flow(X, gate, benches) ˄ velocity(X,V) ˄ V ≤ 5m/s) (

The above logical formula (1) involves the flow velocity V (including speed and direction) of detected groups X which are represented as predicates. It also includes the context information of Venue, Type, and Place. The BehaviouralMode term in [START_REF] Chang | Aviation occupant survival factors: An empirical study of the SQ006 accident[END_REF] does not belong to the context; its value (i.e. "usual") is the assumption made by the system when processing observations. Formula (1) represents the expected usual crowd motion conditions (i.e. usual behaviour). However, the spectrum of behaviour(s) can be formulated at various spatial scales of detected groups in the crowd. These concern the generic terms X and their respective estimated velocities. The system can use such formulas by adopting available contextual information and assuming usual behavior(s). Forward logical chaining can be then applied to get a set of expected values of observations. The expected values will be then matched against actual observed features that need to be detected computer vision based machine learning algorithms. (Equally, the system can use the concept of formula (1) for backward chaining observations and context to infer values of predicated behavior.

Ontology Design Pattern for Context Definition

In order to correctly interpret crowd sensor observations, a set of ontological behavioural templates needed to be developed against measured sensor properties (or features). The latter are extracted from crowd behaviour detection algorithms trained on vision sensor observation data sources (e.g. video feed). OGC standards on "Sensor Observations and Measurements" [START_REF] Cox | Observations and Measurements[END_REF] were adopted to develop the behavioural templates of eVACUATE. OGC ontologies such as SSN ontology [START_REF] Compton | The SSN ontology of the W3C semantic sensor network incubator group[END_REF] were specifically used to semantically enhance the concept of "Observation" in this research study.

4.1

Context for Defining Crowd Behaviour

Some crowd behaviour(s) are context agnostic (e.g. Crowd stampede). These do not need further contextual information to fully define them. However, most crowd behaviour(s) are context dependent. Their interpretation depend on a number of contextual factors which are described (with examples) below:

• Time The flow of spectators at a stadium change with the expected match schedules (pre-match, during the match, after match). Or, passengers motions at an underground station platform vary depending on the train time table (before, during, after train arrives)

• Space
Passengers in an airport tend to queue at desks; or at ticket kiosks of an underground station. Also, spectators at a stadium are usually orderly seated at stands.

• Venue

Passengers evacuating from a cruise ship are expected to behave differently from spectators evacuating a stadium.

• Other

Crowd(s) behaviour expectations from instructions (i.e. Audio guided evacuation at a given venue).

The behaviour templates associate the above behaviour-like modes in this study. These have key detectable features which can be observed through sensing hods, including video cameras At the heart of the context behaviour ontology describing behaviour templates lies the concept of causality which is used to match the interpretation of the collected sensor observations. The crowd contextual behaviour ontology distinguishes three main components (see Fig. 1): 1-Behaviours; 2-Effects; and 3-Features.

Sensor observations are modeled as the detected manifestations of the effects of unfolding behaviour(s). Crowd Behaviour(s) are described in templates of expected human interactions in a given venue. They are defined with a set of expected Effect(s) in space and time. Effect(s) are spatially tangible (or intangible) result, in terms their manifested detectable features. They are also conceptualized as spatially related to scheduled activities of crowd(s) at the venue. The manifested Feature(s) of such Effect(s) are sensory observed at the venue with specific measurable values. OGC O&M standards on "Observation & Measurements" [START_REF] Cox | Observations and Measurements[END_REF] define observation as:

"An Observation is an action whose result is an estimate of the value of some property of the feature-of-interest, at a specific point in time, obtained using a specified procedure".

Although our approach is inspired from OGC O&M standards, the crowd behaviour modelling template was developed distinctly in terms of its description of observations and features. In it, the Effect(s) are postulated as a collection of detectable Feature(s). Also, Feature(s) are constrained by a set of specific observations with detectable properties. For example, sensor readings of property, which concern crowd activities in a venue, may include crowd physical motion (Velocity: Speed and direction); and density (Number of individuals per unit spatial area) at various spatial resolutions and levels. The main distinction from OGC O&M standards in the construction of the behaviour template here, mainly concerns the restriction of the possible (and range of) values of observations of given Feature(s). This is greatly supported by the assumption that crowd(s) are expected to behave in a particular way within a given and venue and times. This new distinction enables good reasoning on observed and detectable Usual (or Unusual) crowd behaviour.

The inclusion of effects with no direct tangible features are required in order to model psychological states that involve single (or group of) individuals in the crowd(s). These are not directly detectable via sensing but undoubtedly influence the value and range of detectable features. In eVACUATE, the modelling of crowd behaviour(s), the spatial environment in which they unfold and their evolution in time, allows the abstraction of behaviour templates and instantiate them generically for different of venues and crowd(s). For example, in the expected behaviour at a stadium, which was introduced in Section 3, can be generalized using an abstract behaviour template (See Table 1) so that it can be used for different venues. (For a Stadium, the gathering places are the stands, the transition places are the gates and the internal corridors, while the exit can be the car park outside the stadium.)

Modelled Crowd(s) Features

The ontological modelling of detectable features is a process which is primarily driven by the type of information that can be collected from the deployed sensor networks at the venue. At this stage of the project, the primary source of information are CCTV cameras which are already installed at the venue. The included features in the modelling so far, include the ones which are available by the feature extraction algorithms in eVACUATE. These particularly focus on venues with the description of crowd(s) at various scales and levels. These are highlighted below:

1. Micro-scale: An individual is identified with measurable time-dependent position and velocity 2. Meso-scale: Although group of individuals are identified with measurable timedependent positions and velocities, these are represented as a statistical distribution in addition with other features. These are included as: a) Density which is measured as number of people per unit area. This is used to model levels of service as described by Fruin [START_REF] Fruin | Designing for Pedestrians: A Level-of-Service Concept. New York Metropolitan Association of Urban Designers and Environmental Planners[END_REF] and the expected presence of people within target areas in a venue; and b) Direction: A symbolic information which described that a group is intentionally moving towards an explicitly described target (e.g. an exit) with a certain degree of certainty. This is used additionally to model the expected flow of people 3. Macro-scale: Average quantities such as crowd density, dominant motions (Translations), structure and internal energies are determined in this scale. They specifically include the following features: a) Internal Energy: Normalized between 0 and 1, it estimates the amount of oscillations of elements within a crowd; b) Structure: Normalized between 0 and 1, it estimates the strength of the connections within a crowd; and c) Predominant Translation: Used to measure the degree of mobility of the crowd.

Ontology Modules and Sensor Data Ingestion Architecture

As mentioned in Section 4.1, behaviour templates can be generalized and reused for different domains (venues) and sub-classing. The behaviour template in Section 4.1 concerning the "Stadium domain" is further detailed. As depicted in Fig. 2, the Event Behaviour Template captures the pre-event period (i.e. before the event takes place) with the expected effect as a Gathering Effect. This effect manifests itself at the Gates and Corridors, while the crowd moves towards the stands. The Crowd direction of motion is depicted with a target  Stadium Stands. As a result, the expected usual crowd(s) Gathering Behaviour at a Stadium (Football match event) states the crowd(s) move without running, while they maintain a high structure. This is expected from groups moving towards shared destinations and not scattering around the venue.

Fig. 2. Crowd Behaviour Ontology modules and Architecture

It is clear from Fig. 2 that the described concepts of Gathering Behaviour, Effect, and Gathering Place in a general ontology can be imported by various domain ontologies that will refine their definition for specific venue types. Equally, the mentioned sensory video feeds and further context relevant information, such as time and event occurrences, need to go through abstraction steps with symbolic representations in the terms of the domain ontology used (i.e. pre-match symbol instead of a date time).

Fig. 1 .

 1 Fig. 1. Behaviour Template

Table 1 .

 1 Event Behaviour Template

				Time
			pre	During	post
		Gathering Place	People settling	People stably	People leaving from
			in	at place	the gathering place
		Transition Place	People moving	Mostly empty	People moving to-
	Space	Exit	towards gather-ing place People moving towards inside	Mostly empty	wards the exit People moving to-wards the outside of
			the venue		the venue

http://www.evacuate.eu/

Acknowledgments

eVACUATE is co-funded by the European Commission under Grant FP7-EC-313161. One of the Authors (ZAS) would especially like to thank project partners for cooperation, including AIA S.A (Greece) for data sample acquisition; and Katholieke Universiteit Leuven (Belgium), for assisting in the use of work-package11 recommendations on data Ethics, Legal and Regulatory Activities.

Conclusions

This early research describes an approach for semantically enhancing the ingestion of sensor data which may describe the links to crowd behaviour, context and detectable sensor observations. The approach is inspired from script theory which suggests that humans follow scripts which are linked to past experience and observed situations. The paper presents an approach which models such scripts as causal chains in an OWL ontology language. The ontology can be reused to describe domain specific behaviour(s) at different venues. Moreover, a general schema is introduced on how sensor data is processed prior to behaviour classification using the ontology.


Jiří Kalina
email: kalina@mail.muni.cz

Richard Hůlek
email: hulek@iba.muni.cz

Jana Borůvkova
email: boruvkova@recetox.muni.cz

Jiří Jarkovský
email: jarkovsky@iba.muni.cz

Jana Klánová
email: klanova@recetox.muni.cz

Ladislav Dušek
email: dusek@iba.muni.cz

Three Levels of R Language Involvement in Global Monitoring Plan Warehouse Architecture

Keywords: R, JSON, JSONIO, jsonlite, ODBC, statistical computing, web application, system architecture, POPs, GMP

Three different options for involving R statistical software in the infrastructure of the data warehouse and visualization tool of the Global Monitoring Plan for persistent organic pollutants are presented, all differing in their demands with respect to data transfer rates, numbers of concurrently connected users, total amounts of data transferred, and the possibilities of repeating statistical calculations within a short period. After the development stage, two of these options were used at different levels of the system, demonstrating the specificity of their use and enabling the deployment of the powerful features of R statistical software by a system created using conventional programming languages.

Introduction

The ongoing collection of data on environmental pollution within the second campaign of the Global Monitoring Plan (GMP) concerning persistent organic pollutants (POPs) is benefiting from the experience gained during the first collection period (2003-2008) [START_REF] Hůlek | Global Monitoring Plan of the Stockholm Convention on Persistent Organic Pollutants: visualization and on-line analysis of data from the monitoring reports[END_REF], which allowed the design and development of a system for the collection, statistical evaluation and visualization of data in order to achieve maximal efficiency of statistical processing while maintaining the highest possible information value hidden in the data. The Global Monitoring Plan was established to provide the comparable monitoring of POPs listed in annexes of the Stockholm Convention (SC), i.e. their presence in the environment as well as their regional and global environmental transport. GMP implements this in the form of a worldwide overview of compliance by the monitoring and evaluation of SC 22 POPs concentration levels and their trends.

The data reporting model suggested in the updated Guidance involves compiling and archiving primary GMP data within a "regional data repository" in each of the five UN regional groups. In addition, regional data centers and a single GMP "data warehouse" should be established to compile and archive aggregated data, data products and results, including supplementary data that would be used in the Stockholm Convention effectiveness evaluation.

Based on the facts stated above, a multi-modular, on-line working data warehouse has been developed for data collection, processing and reporting within the second and future GMP collection campaigns. It is based on fully parametric data sheets for data input, supplemented by a possibility to utilize all data contained within the Global ENvironmental ASsessment Information System (GENASIS) repository [START_REF] Jarkovský | Multi-matrix online data browser for environmental analysis and assessment[END_REF]. It has been designed especially to improve the quality of the collected global data sets on POPs concentrations in order to determine their fate in the environment.

2

Architecture of R Involvement in the GMP Data Repository

The comparability of reported data is one of the elementary principles of GMP and also an essential condition enabling the use of a single set of methods for processing truly global data from all five United Nations Environmental Program (UNEP) regions, collected by dozens of individual (national) providers. The GMP principles of comparability became the elementary requirement for the development of the second generation of data collection and analysis tools. This comparability consists not only in the unification of all code lists used in reporting, but also in the standardization of physical units, the unification of the handling of missing values, the mutual conversion of the results of different methods of measurement and the fractions of substances measured, and the unification of the period for reporting, which was established during the previous decade with a one-year period.

The principal requirement imposed on the system for the collection and visualization of GMP data is the possibility of the simultaneous input of data either by transfer from existing databases (especially the GENASIS), or by the manual import of primary and (annually) aggregated data. Based on the data type and their input into the warehouse, the data undergo different-length sections of a sequence of mathematical and statistical operations, culminating in final outputs and visualizations with high added information value.

Since implementation of the statistical operations performed is very complicated and practically impossible using standard main and database programming languages (PHP and SQL in case of GMP), the series of analyses following logically in sequence demands the use of these languages only as an interface to the server version of the powerful statistical software R [START_REF]The R Project for Statistical Computing[END_REF].

During development, three options for the involvement of the R language in the environmental pollution data assessment infrastructure of the GMP data warehouse system were tested (the transfer of data between the data warehouse and the specialized R server as a text file and procedure calls of R language using the HTTP protocol; data transfer between servers using JavaScript Object Notation (JSON) and direct access to the R procedures using Open Database Connectivity (ODBC)) [START_REF] Hůlek | Integration of R Statistical Environment into ICT Infrastructure of GMP and GENASIS[END_REF]. The advantages and disadvantages of different approaches have been shown to be specific in relation to the purpose for which the R script is used and the amount of data that is transmitted. Thus, the result of the development was mainly the differentiation of methods of integrating scripts of the R language into the rest of the GMP data warehouse systems according to the level at which this involvement occurs.

On their way through the GMP data warehouse system from their input in the form of primary data to the resulting plots and summary statistics, the data go through three levels:

1. The lowest level (data input): input and transformation of primary data inside the Genasis repository. Primary data go through the following four sub-steps: (a) Conversion of values measured by passive air samplers to atmospheric concentrations of pollutants using the method developed in the framework of the Global Atmospheric Passive Sampling network (GAPS) and implemented as a separate recalculating R package (genasis) [START_REF] Kalina | genasis: Global ENvironmental ASsessment Information System (GENASIS) computational tools[END_REF]. (b) Calculation of the parameter sums, defined as the sum of a large number of different parameters, including the calculation of the detection/quantification limits (LoD/LoQ) (e.g. sum of indicator PCBs). (c) Calculation of toxic equivalents for selected groups of substances defined as the weighted sum of concentrations of substances measured at the same time in the same locality, and the treatment of censored values (LoD, LoQ). (d) Aggregation of separately measured fractions of identical analytes to the general fractions (e.g. gaseous phase and dust for air sampling), and the treatment of censored values (LoD, LoQ). 2. The testing of prerequisites for the aggregation of measured values over time to mutually comparable annual averages, the aggregation itself, and the treatment of censored values (LoD, LoQ).

Real time calculations of descriptive statistics and trends while browsing individual

analyses on the website.

Primary data enters into this sequence at the lowest level (1), the aggregated data at level 2. The necessity to implement the R script language in order to execute the calculations exists over the entire sequence (i.e. in all three steps and the four sub-steps):

Data Input Level

A specialized R package "genasis-recalc" was invented for elementary operations on primary data on persistent pollution in the atmosphere, water, human blood, and milk. Specific demands at different levels of aggregation (over fractions of the environmental matrix, groups of similar compounds and/or sets of toxic equivalent compounds, according to different toxic equivalents and factors schemes (TEQs & TEFs) of the World Health Organization), the substitution of left-censored data (LoD, LoQ) [START_REF] Van Den Berg | World Health Organization Reevaluation of Human and Mammalian Toxic Equivalency Factors for Dioxins and Dioxin-Like Compounds[END_REF], and temperature-dependent coefficients of recalculations of passive air sampling were adopted inside the package and are used at the moment when the data enter the repository.

In this level, data transfer was implemented using txt files. Because the backend consisting of an R-server for statistical computing is, for safety reasons and for reasons of achieving better performance, separated from the DWH server as well as from the primary data source server GENASIS, the task of data transmission has become a key problem in terms of speed and stability. The numbers of individual records in primary databases range from thousands to millions, while each record contains tens of numerical and text values describing, besides the measured concentrations, also the site and date of measurement, the method used for the determination and recalculation of the values, the parameters of the measuring devices, data ownership, and the id of the measured substance and its chemical specification etc.

Recalculations of primary data are triggered manually by a data manager in logically defined batches containing up to tens of thousands of records, which is the equivalent of up to one million transferred numerical and text values. For building service-oriented infrastructure, the only viable solution, one necessitated by the conditions, is to use the text HTTP protocol, which raises the need to wrap different data structures (single values, vectors or numerical matrices) on the one hand, and expand them somehow on the other.

As a suitable language for both processes, the JSON notation for writing data structures was adopted, which was already used in the system. It is also involved within the relatively large OpenCPU computational platform used for the development of DWH. The JSONIO package was used on the R-server side, which, however, proved to be extremely memory-consuming for the order of thousands of records -on a server with limited memory, this approach led to overflow even at about 200,000 integer values and the increase in memory consumption appeared to be exponential.

The limiting factor was, therefore, not the complexity of the recalculations of the records on the chemicals themselves, but the coding of data into JSON notation, requiring extreme memory infrastructure regardless of the form of the extracted data (for the stated number of tens of thousands of entries, overflow occurred even in the case of a single vector, which itself would be insufficient for the transmission of real data).

A solution to extreme memory consumption was found by not using the JSONIO package but sending plain txt files with numerical and text values separated by a simple separator (a comma). It was, however, necessary to resolve the coding of complex structures (such as nested lists, matrices, etc.). In any event, such an approach solved the problem of memory consumption by large volumes of data. On the R-server side, the data were loaded from the file issued on the main language side using the scan() function, which excludes the use of the memory-consuming JSONIO package. The problem which arises from this approach is the need for the complicated coding of a more complex data structure to a simple text notation, which leads to inefficiency, instability, and a high frequency of errors. Furthermore, the time required by this approach is also relatively high.

As the most appropriate solution, the option of giving the R language direct access to the database was adopted, enabled by the RODBC R language package version 1.3-9 [START_REF] Ripley | ODBC Database Access. R package version 1[END_REF], published in late 2013 and implementing ODBC database connectivity. All R scripts are strictly separated from the GMP warehouse main language layer (there are no direct data transfers between the main language and R scripts) and involved in the system using ODBC.

This form has proven to be the most effective in terms of memory consumption and acceptable in terms of time consumption. Because the four recalculations are performed on the primary data only once, and following steps work only with the results, the time consumption of the algorithm was not a crucial parameter.

The versatility of the ODBC connection also significantly increases the efficiency of the database solution from the perspective of experts from non-IT disciplines (especially environmental chemists and statisticians), who may develop computational algorithms in R completely separately and independently of IT developers and with only a limited knowledge of the language SQL.

The implementation of primary data recalculations was then performed in the form of a pair of buffers, represented by database tables (a properly constructed DB view and table) within the GMP DWH, between which the four resulting computations run according to the following cyclic procedure:

1. The data manager selects a batch (containing at most tens of thousands of records) for recalculation and, using a data management application, starts the filling of the input buffer (DB view), which is performed in the main programming language layer in DWH. 2. Directly from SQL, using the EXEC command, the appropriate procedure is called by R language on the R-server. Deploying the RODBC package function sqlQuery(), all necessary data is loaded into the R environment in the form of a data.frame structure.

3.

If the loaded data.frame passes through a check of data completeness, it is recalculated and the results are stored, using RODBC again, in the output buffer (plain database table). 4. Still using the RODBC package and EXEC command, a follow-up procedure is called in the SQL database language. It is performed comprehensively in the main language layer of DWH, in addition to other necessary database operations, and finally the result is written back to the primary data structures.

Since the recalculations are performed in a predefined order, the data iteratively pass through all four steps when repeating this procedure for each recalculation (the calculation of passive measurement results of air pollution, the calculation of sums and toxic equivalents, and the calculation of fractions).

If the RODBC option of data transfer is used, the algorithms are less timeconsuming, with a typical duration of units of minutes for the recalculation of each batch consisting of less than 1 million numerical or text values.

Aggregation Level

Once the data are recalculated and transformed to comparable scales, a selection of representative samples is carried out. In this step, the regularity of individual measurements over time (within one year) and the number of primary data are assessed and, taking into account local specific conditions of monitoring, the representativeness of the primary data is checked. At least 3 samples within one year and a form of monitoring regularity in which the longest gap between subsequent measurements is no more than 3 times longer than the smallest one are required in order for data to pass automatically through the selection process; in other cases, a manual check of representativeness is required.

Appropriate selected datasets are subsequently transformed to annual aggregations, which will culminate in achieving the maximal comparability of data from different data sources.

Since there are several specific aggregation functions within process of annual aggregation, the R with ODBC connection to the DWH database was again used to avoid the complicated and unreliable constructions of computing values by means of SQL.

As in the previous case, the RODBC package is used for inputting and outputting R script data included in another special package "genasis-aggr". In addition to the usual statistics such as arithmetic and geometric mean and standard deviation, also maximum and minimum concentration values in each year, number of primary records, and several advanced statistics are computed:

• 5 th and 95 th percentiles as concentration values taken at regular intervals from the inverse of the estimated cumulative distribution function of the values within each year, which serves as a description of data variability without extreme values, • the smallest, typical and largest gap between the start of the year, dates of subsequent measurements, and the end of the year, used for determining the regularity of the measurements, • the number of values below detection/quantification limits. These statistics cannot be computed directly by SQL without creating complicated procedures involving the complicated maintenance of special cases such as incomplete data records, low numbers of records etc., resulting in the low reliability of such a solution.

The use of direct access to the DWH database and the utilization of SQL commands within the R environment enable the determination of the optimal distribution of aggregation tasks between elementary steps, conducted with higher effectiveness by means of standard SQL commands and more specific computations.

Visualization Level

Another principle of R script involvement is implemented at the highest level of data visualization. The short response times and large number of multi-user operations associated with the use of a web-based data browser require a more flexible solution compared to working with ODBC data inputs and outputs. Moreover, a typical selection of parameters and localities for visualization inside a browser is highly restrictive and limits the amount of data to smaller values of hundreds of records, which can be rapidly transferred by the HTTP protocol between the components for processing individual tasks.

Another R package called "datavis-platform-gmp-r" was invented for this level of the visualization tool. JSON notation turned out to be the best transfer option for relatively small numbers of records. Both the input and output data of the R scripts used for visualization are translated to JSON notation using appropriate libraries (the jsonlite package on the side of the R-server is used [START_REF] Ooms | jsonlite: A Robust[END_REF]) and sent by the POST method of the HTTP protocol.

There are two visualizations where the use of R scripts was necessary due to complicated computations which cannot be implemented in either the SQL or PHP languages:

1. horizontal box and whisker plots of the descriptive statistics of selected measurements with different measures of central tendency and data variance (similar statistics as in the aggregation step are computed here using standard R statistical commands), 2. time series plots including linear and exponential interlacing curves and their confidence intervals, using several parametric statistical techniques not present in main level programming languages.

A data structure of nested data lists is the most appropriate for both these visualizations. This structure is highly suitable for translation to JSON by the jsonlite package, with the exception of singleton lists, which are translated as simple elements. This unsystematic property necessitates the special measure of adding one zero element to each level of the nested list to obtain a minimum length of two elements for each list.

Conclusion

There are different demands with respect to data transfer rates, numbers of concurrently connected users, total amounts of transferred data, and the possibilities of repeating statistical computations within a short period at different levels of the GMP data warehouse and visualization system. During the development of second generation GMP data browsers, three different options for involving R statistical software were tested and assessed for final use. The method of using JavaScript Object Notation (JSON) for coding data transferred between a database running on a data warehouse server and a separate R-server for statistical computations was shown to be fast but unsuitable for larger amounts of data (the order of millions of values) due to its extreme memory-consuming properties (using the RJSONIO package in the R environment).

A different method of data transfer in the form of specially devised coding within txt files, which should have solved the problem, exhibited problems with more complicated data structures such as matrices and nested lists; in addition, it was also more time-consuming.

As the best option for huge amounts of data, direct access from the R-server to the data warehouse database was implemented, using the Open Database Connectivity (ODBC) standard, made available by means of the RODBC package. This solution allows SQL and R functions to be combined within one script and provides a simple, effective and comfortable environment for the development of enviro-statistical structures separate from the rest of the IT infrastructure.

The main disadvantage of the ODBC approach, namely lower speeds of multiuser access to the database, was solved by using JSON whenever smaller numbers (in the order of hundreds) of values are transferred, such as in web-based visualizations.

adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011


Tomáš Ludík
email: tomas.ludik@unob.cz

Tomáš Pitner

Process Design Patterns in Emergency Management

Keywords: emergency management, process framework, process modelling, contingency plans, design patterns, directed interviews

Emergency management is a discipline of dealing with and avoiding risks. In case of any emergency the immediate and fast intervention is necessary. It is possible only because of well-prepared contingency plans and adequate software support. Therefore, the aim of this paper is to focus on the common characteristics of process modelling within emergency management and to define the design patterns that are typical of this area. These Design Patterns enable faster and simpler generation of emergency processes and contingency plans as well as subsequent software support. They result from the current documentation and legislation. Each design pattern does not represent a final emergency process, but only a certain structure which is necessary to further customize according to current user requirements. Specifically, 16 design patterns have been identified and described on more management levels. The present form of design patterns is a result of the consolidation of many real processes of emergency management that arose and were verified within several research projects or set of directed interviews with emergency management experts.

Introduction

Process management is an implemented and often used approach in business practice which enables a variety of organisations to achieve better results from a long-term point of view [START_REF] Weske | Business Process Management, Concepts, Languages, Architectures[END_REF]. On the other hand, the functional management approach often predominates in public administration [START_REF] Smith | An Inquiry into the Nature and Causes of the Wealth of Nations[END_REF]. With regard to the poorer utilisation of an organisation's sources and assets, the functional management approach does not enable the achievement of these results. It achieves the set objectives more slowly and handles constantly ongoing changes only with great difficulty. These properties can be seen especially in the area of emergency management, where a fast and efficient intervention will enable not only the rescue of assets and the environment, but above all human life. There is an unambiguous necessity to gradually reduce using the functional management approach to emergency situations and to start coping with these situations in a process manner.

In case of process management, it is not only a change in the management approach, but also the entire information support of processes. This differs from the classical rigorous development of information systems. Process-oriented systems must react to the dynamic environment in an organisation quickly and be capable of adapting themselves to current needs and priorities [START_REF] Pekárková | A Framework for Monitoring and Evaluation of Learning Processes[END_REF]. For this purpose, a lot of new approaches, methods and instruments have appeared in reaction to this trend [START_REF] Barta | The Use of Simulations for the Need of Environment Protection[END_REF]. Moreover, emergency management is specific because of the distrust of information technologies, because of necessary interoperability with other information systems and because of the emergency information system's complexity and the necessity to develop resistance to breakdowns and crashes [START_REF] Hiltz | The Domain of Emergency Management Information[END_REF][START_REF] Haddow | Introduction to Emergency Management[END_REF].

Based on the abovementioned description, there are two principal requirements for emergency management. First, there must be a change from the functional to the process management approach and, at the same time, support for the new method of coping with emergency situations with information through advanced information technologies. For this purpose, the Process Framework for Emergency Management has been defined. It provides well-arranged, unambiguous and complex instructions of how to achieve this complex change in the management method as well as in the information support in the area of emergency management.

Process Framework for Emergency Management

The Process Framework for Emergency Management consists of five main components which describe the problems of different areas. In specific terms, it is process methodology, reference architecture, factors for implementation, design patterns and quality assurance processes.

Fig. 1. Process framework for emergency management

Process methodology -the methodology contains the instructions of how to identify and describe the user roles and processes in the field of emergency management. For this, it recommends the appropriate recording forms of emergency management processes, which is the Business Process Modelling Notation combined with the Use Case diagram from the UML. If in need of automation, the methodology provides the instructions of how to further configure processes, how to add required data and services and subsequently how to interpret them through the workflow engine. For more information about process methodology, see (Ludík and Ráček, 2011a).

Reference architecture -this provides a view and recommendation concerning the particular software components which can be used in process automation and, at the same time, it reflects the requirements resulting from emergency management processes. The entire design is based on the Workflow reference model. Then this conceptual model is completed with specific tools and components which can be found in the sphere of information support of processes in organisations, whereas stress is laid on the independence of specific software from a particular provider. For more information about reference architecture, see (Ludík et al., 2011).

Factors for Implementation -the issue of emergency management processes is so comprehensive that the standard approaches used in the area of software engineering cannot be used. On this account, this part focuses on the description of factors and specific characteristics of emergency management. The identified factors can be divided into two groups, i.e. internal factors and external factors. For more information about factors for implementation, see (Ludík and Ráček, 2011a).

Design Patterns -these enable faster and simpler generation of emergency processes. They result from the current documentation and legislation and are defined based on many years' experience of emergency process modelling. No design pattern represents a final emergency process, but only a certain structure which it is necessary to further customise according to current user requirements. For more information about design patterns, see Section 4 of this paper.

Quality Assurance -this provides methods and tools to assure the quality of simulated processes that must be in compliance with not only legislation and current emergency plans, but especially in compliance with the requirements of bodies active in emergency management. For more information about quality assurance, see (Ludík and Ráček, 2011b).

Design Patterns State of the Art

In software engineering, a design pattern represents a general reusable solution to a commonly occurring problem within a given context in software design [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

In the same manner, it is possible to approach the design of process diagrams (workflow) and to define design patterns in this field. The Workflow Patterns Initiative is the greatest one in this field which is a joint effort of Eindhoven University of Technology and Queensland University of Technology and which started in 1999. The aim of this initiative is to provide a conceptual basis for process technology. In particular, the research provides a thorough examination of the various perspectives that need to be supported by a workflow language or a business process modelling language [START_REF] Russell | Workflow Control-Flow Patterns: A Revised View[END_REF]. There are a few similar efforts. As an example, a chapter in the book Designing Business Processes with Patterns [START_REF] Glushko | Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services[END_REF] or a paper entitled Applying Patterns during Business Process Modelling [START_REF] Gschwind | Applying Patterns during Business Process Modeling[END_REF]) can be mentioned.

The design patterns can serve the purpose only in the event that they are comprehensible and described sufficiently. There is no single, standard format for documenting the design patterns. Rather, a variety of different formats has been used by different pattern authors. However, according to Martin Fowler, certain pattern forms have become more well-known than others, and consequently become common starting points for new pattern-writing efforts [START_REF] Fowler | Writing Software Patterns[END_REF]. One example of a commonly used documentation format is the one used by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in their book entitled Design Patterns [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. It contains the following sections:

• Pattern Name and Classification -a descriptive and unique name that helps in identifying and referring to the pattern; • Intent -a description of the goal behind the pattern and the reason for using it;

• Also Known As -other names for the pattern;

• Motivation (Forces) -a scenario consisting of a problem and a context in which this pattern can be used; • Applicability -situations in which this pattern is usable; the context for the pattern;

• Structure -a graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose; • Participants -a listing of the classes and objects used in the pattern and their roles in the design; • Collaboration -a description of how classes and objects used in the pattern interact with each other; • Consequences -a description of the results, side effects, and trade-offs caused by using the pattern; • Implementation -a description of an implementation of the pattern; the solution part of the pattern; • Sample Code -an illustration of how the pattern can be used in a programming language; • Known Uses -examples of real usages of the pattern; and • Related Patterns -other patterns that have a relationship with the pattern; discussion of the differences between the pattern and similar patterns.

Design Patterns for Emergency Processes

The process approach is applicable in different domains whereas each of them has certain specific characteristics. The aim of this section is to focus on the common characteristics of process modelling within emergency management and to define the design patterns that are typical of this area. The design patterns described in this section are an essential part of the process framework for emergency management in the Czech Republic which was presented in Section 2.

Analogous to other parts of the process framework, it is possible to independently use the design patterns already created, without any links to the designed framework. Even in this example, the defined design patterns will enable a faster and better identification, analysis and emergency processes design at all levels of emergency management.The identified design patterns are divided into three groups according to the level of management at which emergency processes occur. These are strategic, operational and tactical levels.

Strategic Patterns

The strategic level represents the top-level management view of the solution of extraordinary events and emergency situations. Emergency-related legislation and other strategic documents defining general strategic procedures of coping with emergency situations on the territory of the Czech Republic are among the most fundamental documents influencing the design patterns. On the basis of these documents, it is possible to derive generally valid procedures used in coping with emergency situations, and to define them in a process way. Higher level processes develop in this manner and describe a general level of intervention management. This level is suitable for further decomposition. Emergency Management Process, Solving an Extraordinary Event, Solving an Emergency and Solving a Flood Situation are included among the strategic design patterns of emergency management. Each design pattern is identifiable unambiguously through an Identifier. The Title, Motivation, Description, Structure, User Roles, Known Uses, Related Patterns and Regulations have been selected as further attributes for describing a design pattern.

SP-2: Solving an Extraordinary Event.

Motivation -The aim of the design pattern is to show how to efficiently solve an extraordinary event in compliance with legislative requirements within the shortest possible time. An extraordinary event that occurs in a certain environment is usually solved by the Integrated Rescue System (IRS) components in a regular way.

Description -The solution of an extraordinary event proceeds in a few basic steps. First of all, the emergency operational centre receives a notification of the occurrence of an extraordinary event such as a fire, road traffic accident or leak of a hazardous substance. Based on the received information, the situation is analysed. According to its extent, the particular rescue components are activated. Their task is to come to the intervention site as fast as possible. After the arrival of particular components, the intervention commander who is responsible for coping with the emergency situation is appointed. First of all, he analyses the intervention site and assigns tasks to subordinate units. Afterwards, he monitors and evaluates the situation and responds to the development of the situation as a whole. The individual rescue components, such as firefighters, ambulance services and the police perform rescue and clean-up works. At the end of the intervention, the activities connected with finishing the intervention as well as evaluating the extraordinary situation that took place.

Fig. 2. Solving an extraordinary event (SP-2)

User Roles -Emergency Operational Centre, Intervention Commander, Integrated Rescue System.

Known Uses -Extraordinary events in the Czech Republic are solved every day. It may be e.g. a road traffic accident on the motorway, a hazardous substance leak, fire, explosion or other situations which need the assistance of the IRS. The entire process is initiated by an emergency call and subsequently it continues based on the type and characteristics of a given event.

Related Patterns -The described design pattern specifies the Response activity in the Emergency Management Process (SP-1) pattern in case of an extraordinary event.

Regulations -The defined process as such is primarily based on the Act on the Integrated Rescue System (Act No. 239/2000 Coll.).

Operational Patterns

The processes at the operational level are among the group of design patterns that have to be customised most, as they are markedly dependent on the site and characteristics of an extraordinary event or an emergency situation. The emergency plans of particular regions and municipalities have been developed with regard to local knowledge, e.g. the specific experience of emergency components or available resources in a given region. The IRS operational plans, which also are a basic starting point for creating the design patterns, describe the so-called ideal case of how to solve a given situation. However, it is necessary to take into account the fact that a real solution of a situation may be affected by other facts in practice. The operational design patterns serve primarily as a general starting point for process modelling at the operational management level. It is necessary to further adapt these processes according to specific user and territorial requirements. In the next part, one of seven specific operational design patterns within emergency management is presented.

OP-1: Reception of Information on an Extraordinary Event.

Motivation -Each extraordinary event or emergency situation is dealt with as soon as it is reported to the IRS operational centre. Here, it is very important to recognise the character of the extraordinary event quickly and correctly, and to respond to it through intervening components. It is also necessary to find out which of the reported situations are of an emergency character and in which cases the emergency call number was abused.

Description -The emergency operational centre operator receives a report on an extraordinary event. He must find out the necessary information from a reporting person, especially the address and type of the event. In case of suspicion that the information is false, the operator calls back to the reporting person. Afterwards, the operator evaluates the extraordinary event; he selects a unit or units and sounds the alert. The unit for which the alert was sounded must confirm the alert and subsequent departure up to a certain time limit or may cancel the alert or departure for e.g. a defect on intervention equipment.

Fig. 3. Reception of information on an extraordinary event (OP-1)

User Roles -Operator of Emergency Operational Centre, Rescue Units. Known Uses -The process is executed not only in the emergency operational centre of emergency calls 112, but also in other operational centres of the IRS components. The process is initiated by an incoming call, through which an extraordinary event is reported and completed by the departure of particular IRS components.

Related Patterns -The presented design pattern specifies the method of acquiring the information on an emergency situation which is a part of both the Solving an Extraordinary Event design pattern (SP-2) and Solving an Emergency design pattern (SP-3).

Regulations -Design pattern is based on the Combat Order of Fire Security Units. As another starting point to define the design pattern, the Act on the Integrated Rescue System and the Emergency Management Act were used.

Tactical Patterns

The design patterns at tactical level describe the activities of the intervention commander and other IRS components intervening in the scene of an extraordinary event.

The defined tactical design patterns are based on the general low-level standardised procedures which describe the activities of intervening components in the intervention site. It is necessary to state that these procedures are not formalised sufficiently in some of the basic components of the IRS. For this reason, the designed tactical patterns are primarily based on the Combat Order of Fire Security Units. This is a set of documents containing standardised procedures for the Fire Rescue Service units in the intervention site. The following tactical patterns have been defined: Issue, Confirmation and Fulfilment of Order, Information Exchange, Management of Intervention, Establishment of Crisis Staff and Organisation of Intervention Site.

TP-1: Issue, Confirmation and Fulfilment of Order. Motivation -The design pattern defines the general procedure of issuing, confirming and fulfilling the orders. Order, command, direction and instruction are control acts for conducting an intervention through which every commander discloses his decision to his subordinates to perform a definite task. To issue orders, commands, directions and instructions in the intervention site is not only an authorisation, but also a task of each management level.

Description -The superior issues an order to the addressee (subordinate). The order must be confirmed or, if need be, repeated by the addressee, which proves that the addressee understands the order. It is necessary to make sure that the order has really reached the addressee. If the addressee does not understand or does not confirm the order, the order is repeated again. When the order is issued, the subordinates follow it and the superior checks its fulfilment. After that, the subordinate reports the fulfilment of the order to the superior who issued the order and the design pattern is completed. In issuing an order, the principles apply as follows: an order must be performable and structured logically so that it is evident what its aim is. It is also important to stress the purpose of the order. It must be apparent that the commander is convinced of his decision. The content of the order must be clear, unambiguous and understandable. In case of an urgent situation, the order must be brief and must be issued rapidly. Known Uses -The design pattern is applied regularly within coping with every extraordinary event or emergency situation. Emergency management is based on the clear hierarchical structure of management. The particular intervening persons are obliged to fulfil orders and instructions of their unit commanders in the intervention site. The unambiguous responsibility for fulfilling all the activities is allocated in the intervention site.

Related Patterns -The design pattern supplements the operational design patterns which primarily describe rescue and clean-up works in the intervention site.

Regulations -The design pattern is defined based on the Code of Practice of Chapter Ř which is a part of the Combat Order of Fire Security Units.

Interviews with Experts

Set of directed interviews with emergency management experts, was used as method for verifying the process framework as well as design patterns applicability in practice [START_REF] Pitner | Constructive Communication in International Teams: An Experience-Based Guide[END_REF]. The experts answered 8 questions. The addressed experts were chosen to cover the field of handling extraordinary events and emergency situations. For this reason, the key areas of emergency management, within which the application of the process framework is relevant, were identified. Out of these areas the experts were addressed and asked for assessing the defined framework. The experts are introduced in the alphabetical order as follows:

• Emergency management and its impact on the environment -Assoc. Prof. Vladimír Adamec; The performed directed interviews can be sum up as follows. The presented process framework provides sufficient instructions for using the process management approach in solving emergency and extraordinary situations. It is a logical and correct approach which is usable in practice. The framework is easy to understand for the workers in the field of emergency management. It can be stated that, currently, the process framework becomes a necessity and an actual trend. Individual parts of the framework are divided logically and their description provides information about their relevance. The description of individual parts is wellarranged, adequate and accurate. Some of the experts have recommended emphasising the strengths of the designed system, refining the terminology and describing the framework to be easy to understand for the lay public.

The identification of emergency processes, their subsequent optimisation and visualization can be considered as the main contributions of the process framework. The automation of processes and the information support to cope with emergency situations have been evaluated as the biggest contribution. The emergency processes defined clearly will enable a relative independence of the human factor. Further contributions can be seen in the savings of time, personnel and finance.

Conclusion

The process design patterns are defined based on the authors´ many years´ experience with modelling the emergency management processes. The present form of design patterns is a result of the consolidation of many real processes of emergency management that arose and were verified within several research projects, directed interviews with emergency management experts or within the development of bachelor´s and master theses. The aim of this paper is not only to create a basic set of design patterns for the area of emergency management, but also to show the method of how the design patterns can be defined in this area and, subsequently, to use them in modelling the emergency management processes.

Fig. 4 .

 4 Fig. 4. Issue, confirmation and fulfilment of order (TP-1)User Roles -Superior, Subordinate.

adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011