An Open Distributed Architecture for Sensor Networks for Risk Management.

Sensors provide some of the basic input data for risk management of natural andman-made hazards. Here the word 'sensors' covers everything from remote sensingsatellites, providing invaluable images of large regions, through instruments installed on theEarth's surface to instruments situated in deep boreholes and on the sea floor, providinghighly-detailed point-based information from single sites. Data from such sensors is used inall stages of risk management, from hazard, vulnerability and risk assessment in the preeventphase, information to provide on-site help during the crisis phase through to data toaid in recovery following an event. Because data from sensors play such an important part inimproving understanding of the causes of risk and consequently in its mitigation,considerable investment has been made in the construction and maintenance of highlysophisticatedsensor networks. In spite of the ubiquitous need for information from sensornetworks, the use of such data is hampered in many ways. Firstly, information about thepresence and capabilities of sensor networks operating in a region is difficult to obtain dueto a lack of easily available and usable meta-information. Secondly, once sensor networkshave been identified their data it is often difficult to access due to a lack of interoperability between dissemination and acquisition systems. Thirdly, the transfer and processing ofinformation from sensors is limited, again by incompatibilities between systems. Therefore,the current situation leads to a lack of efficiency and limited use of the available data thathas an important role to play in risk mitigation. In view of this situation, the EuropeanCommission (EC) is funding a number of Integrated Projects within the Sixth FrameworkProgramme concerned with improving the accessibility of data and services for riskmanagement. Two of these projects: 'Open Architecture and Spatial Data Infrastructure forRisk Management' (ORCHESTRA, http://www.eu-orchestra.org/) and 'Sensors Anywhere'(SANY, http://sany-ip.eu/) are discussed in this article. These projects have developed anopen distributed information technology architecture and have implemented web servicesfor the accessing and using data emanating, for example, from sensor networks. Thesedevelopments are based on existing data and service standards proposed by internationalorganizations. The projects seek to develop the ideals of the EC directive INSPIRE(http://inspire.jrc.it), which was launched in 2001 and whose implementation began this year(2007), into the risk management domain. Thanks to the open nature of the architecture andservices being developed within these projects, they can be implemented by any interestedparty and can be accessed by all potential users. The architecture is based around a serviceorientedapproach that makes use of Internet-based applications (web services) whose inputsand outputs conform to standards. The benefit of this philosophy is that it is expected tofavor the emergence of an operational market for risk management services in Europe, iteliminates the need to replace or radically alter the hundreds of already operational ITsystems in Europe (drastically lowering costs for users), and it allows users and stakeholdersto achieve interoperability while using the system most adequate to their needs, budgets,culture etc. (i.e. it has flexibility).

Introduction

In today's rapidly changing world the correct management of risk from natural and hazards with a human origin is becoming more and more important. Increasing urbanization and the undertaking of high-value projects means that, in some areas, risk is increasing. In addition, due to climate change there is some evidence that the hazard level due to weather-related perils is becoming larger. As in all aspects of modern life, information technology (IT) is playing an increasing role in risk management since it allows the undertaking of certain tasks and makes others easier to perform.

However, risk management in Europe and elsewhere is made more difficult by interoperability problems due to IT systems that cannot easily communicate with each other. Even those in organizations concerned with the same risk, e.g. two institutes concerned with different aspects of earthquake risk, may be running different computer systems. The problem is even worse when viewed across risk domains, e.g. IT systems concerned with industrial risk cannot often communicate with those concerned with earthquake risk, limiting the ability to undertake true multi-risk analysis. Multi-risk analysis is being increasingly recognized as an important tool because it gives a better overall picture of the level of and the interactions between risks in a region [e.g. 3]. In order to overcome these problems, users often must spend valuable time reformatting files, for example, to the detriment of undertaking more fundamental risk management tasks. In addition, this effort is, in some sense, wasted since, in all probability it will need to be repeated when data is sourced from another organization or when a new IT system is developed. These interoperability problems limit the work that can be achieved since it is difficult to access and use existing data; data which cost much time and effort to collect.

In Europe, these problems arise not only across different types of risk, but also across regional and national borders. In addition to interoperability difficulties, language differences also become an issue. It is often important to undertake risk management across borders because impacts of events are not limited by human borders and actions undertaken to mitigate risk are also not contained by political boundaries.

In order to address these difficulties on a large scale considering the whole range of geographical data, an EC directive called INSPIRE (http://inspire.jrc.it) was launched in 2001. It is planned that this directive will be fully implemented by 2013 (implementation began in 2007). The directive is concerned with the setting up of a European Spatial Data Infrastructure, to implement metadata rules for data and services, to implement rules for harmonized spatial data specifications (exchange and update, ID systems, thesauri, key attributes, etc.) and to implement rules for network services (upload, discovery, view, download, transformation, etc.).

To develop these ideas into the field of sensors and risk management, a Framework Programme 6 Integrated Project (FP6 IP) called Open Architecture and Spatial Data Infrastructure for Risk Management (ORCHESTRA, http://www.eu-orchestra.org) was launched in September 2004 and a FP6 IP called Sensors Anywhere (SANY, http://sany-ip.eu/) was launched in September 2006.

This article begins with a summary of the use of sensors within all stages of risk management, with a focus on earthquake, industrial, flooding, forest fire and coastal risks (particularly studied during the ORCHESTRA project). Sections 3 and 4 then introduce the two European projects ORCHESTRA and SANY and the problems that they are trying to overcome. The main purpose of this article is the presentation of the developed architecture for sensor networks, which is discussed in Section 5. The article ends with some conclusions.

The use of sensors in risk management

Due to their various purposes, sensor networks employed within risk management take many forms and cover various geographical and temporal scales. This section briefly introduces the role of sensor networks in the pre-event phase of risk management, which is the particular focus of the ORCHESTRA project. Earthquake, industrial, flood, forest fire and coastal risks are considered in detail since these were studied in depth within the ORCHESTRA project. A discussion of the types of sensors used in these considerably different risks provides an overview of variety of data sources used in risk management today; however, this section does not seek to provide a comprehensive review of sensor networks for risk management.

Within the period before a potentially damaging event an important role for responsible agencies, such as governmental agencies, (re)insurance companies and operators of large concerns, is risk mitigation and planning for the occurrence of possible events, in order to be prepared if and when they arrive. Most natural hazardous events do not reoccur frequently at the same location, for example the return period of damaging earthquakes along the same fault is generally many hundreds or thousands of years, therefore these planning and mitigation activities are generally based on extrapolated information coming from models. The input to such models is usually provided by sensors operating in the vicinity but also in other analogous locations, in order to increase the quantity of data available.

Since risk is composed of the combination of hazard (coming from the peril itself) and the vulnerability of exposed elements (such as residential buildings, hospitals and lifelines) to the hazard, both these aspects need to be monitored by sensor networks. Table 1 briefly summarizes the types of sensors and information that are vital in the preparation phase for the five considered risks (earthquake, industrial, flood, forest fire and coastal). Much of the data coming from sensors needs to be processed and combined with additional information from elsewhere in order to be usable for risk management purposes therefore the interoperability of the processing and combination steps should be considered as important as the data collection stage. Currently some of the data used in different stages of the risk management procedure is collected in a visual and non-routine way through field surveys, which are not considered here. However, due to the rapid developments in the capabilities of sensor networks and significant reductions in their costs it is likely that in the near future sensors will be used to undertake at least part of these surveys. For example, there are fast reconnaissance methods for the assessment of building damage following an earthquake using airborne laser-scanning data [8]. However, currently the assessment of building damage is normally performed by teams on the ground.

Table 1.

Summary of data from sensor networks useful for risk management purposes.

Risk	Remote sensing	In-situ
Earthquake	Permanent ground displacements, deformations and strain measurements (through, e.g., the Global Positioning System, GPS, interferometry and triangulation)Location of faults (through, e.g., aerial photographs and satellite images)Geological mapsDigital elevation and terrain models (through, e.g., satellite images)Information on the urban environment and population density (from, e.g., aerial photographs and satellite images)Land cover map from satellite images	Ground movements (through seismometric, accelerometric and GPS networks) Geological mapsBorehole data (e.g. wave velocities, soil types and densities)Water well logsGeophysical data (e.g. gravimetric measurements)Geophysical laboratory test data (e.g. from triaxial tests)Data from structural tests from, e.g., shake tablesGeotechnical laboratory test data (e.g. particle size and fines content)Hydrological data (e.g. on the level of the water table in the region)
Industrial	Information on transport networks (from, e.g., aerial photographs and satellite images)Information on the urban environment and population density (from, e.g., aerial photographs and satellite images)	Chemical test dataMedical test dataAir pollution monitoring systemsRadiological monitoring systems
Flood	Large scale meteorological information (e.g. cloud cover) from satellite images and aerial photographsGeological mapsDigital elevation and terrain models (through, e.g., satellite images)Information on the environment and population density (from, e.g., aerial photographs and satellite images)Information on the soil roughness (from, e.g., aerial photographs and satellite images)SAR PRI images (weather invariant)Multi-spectral images for land cover evaluation and flood mappingLand cover map from satellite images	Meteorological information (e.g. temperature, rainfall, humidity, pressure and wind speeds and directions) from weather stationsHydrometric data (on the level of rivers and streams and the discharge rates)Geological mapsWater well logsRain radars for short-medium range rain forecasting and measurements of rain density
Forest fire	Large scale meteorological information (e.g. cloud cover) from satellite images and aerial photographsGeological mapsDigital elevation and terrain models (through, e.g., satellite images)Information on the environment and population density (from, e.g., aerial photographs and satellite images)Land cover map (e.g. from satellite images)After-event burnt area maps (e.g. from aerial photographs and satellite images)	Meteorological information (e.g. temperature, rainfall, humidity, pressure and wind speeds and directions) from weather stationsRain radars for short-medium range rain forecasting and measurements of rain density Networks of automatic fire-detecting cameras
Coastal	Information on the coastal environment (from, e.g., aerial photographs and satellite images)	Information from water quality monitoring networks

Table 1 shows that a number of data sources are common to many risks, e.g. the use of remote sensing data to produce digital elevation models, and also that there are also information coming from sensor networks that a specific to a particular risk, e.g. data from seismometer networks to assess earthquake hazard.

ORCHESTRA

ORCHESTRA involves 15 partners both from the risk management domain and from the IT industry. The purpose of the project is to design a platform-independent open service-oriented architecture (SOA) for risk management purposes, and implement it for Internet-based applications (web services) that can be called via the web to provide a given functionality. They could be seen as subroutines located on the web to be used when needed by any user. In this context, ‘open’ refers to the fact that the specifications of these services are being made publicly available free of charge so that they can be implemented by any interested party and can be accessed by all potential users. The actual procedure followed by the web service to perform the required task is not considered and is not specified; however, the inputs and outputs to the service and the actions it must undertake are specified. The philosophy behind this approach is that if the specifications are followed then risk management systems using these web services will be fully interoperable without all needing to be created by a common entity. This philosophy has key advantages with respect to other approaches. For example, it is expected to favor the emergence of an operational market for risk management services in Europe, it eliminates the need to replace or radically alter the hundreds of already operational IT systems in Europe (drastically lowering costs for users), and it allows users and stakeholders to achieve interoperability while using the system most adequate to their needs, budgets, culture etc. (i.e. it has flexibility).

Interoperability of IT systems is a subject of much research and development in many countries. For example, the Open Geospatial Consortium (OGC, http://www.opengeospatial.org/) is an organization that seeks to develop software standards in the field of systems concerned with geographical information. In addition, there are existing and under-development ISO and CEN standards. ORCHESTRA bases its architecture on these standards and seeks to influence their development in order to make them applicable to risk management applications.

One advantage of the SOA approach in the risk management domain is that it allows applications to be updated with minimal effect on the services that call them. Procedures involved in risk management change often as experience is gained through disasters. Consequently it is important that the systems developed are agile allowing developments to be rapidly implemented in practice.

In the second half of the ORCHESTRA project four pilot projects concerned with different aspects of risk management in various European regions were completed. The aim of these pilot projects is to validate the services and architecture developed during the course of the project and to demonstrate the results of the project to potential end users. The four pilot projects undertaken were:

Pan-European assessment of natural hazards.

Forest fire and flash flood risk assessment in the Tordera basin (Catalonia, Spain).

Assessment of the effects of road network disruptions due to multiple risks in the French-Italian border region.

Assessment of risks from heavy ship traffic in the German Bight area (Wadden Sea).

To summarize, the results of the ORCHESTRA project encompass the following elements [11]:

a process model compliant with the ISO Reference Model for Open Distributed Processing [4] that has been interpreted for the design and engineering of geospatial service-oriented architectures;

a reference model for the design of geospatial service-oriented architectures [9];

an open abstract architecture containing design rules for information and service models;

specifications, on both the abstract level and specific to the W3C Web services platform, of the most important generic architecture services derived from but not restricted to the needs of environmental risk management applications;

software engineering components for the development of service networks including:

a Java-based software framework that comprise APIs for common service functionality (e.g. the service capabilities, access control and source system integration), including indispensable architecture services upon which higher-level services may be built;

adapters to industry standard services (e.g. the ORCHESTRA Catalogue service [12] with adapters to both the ebRIM and the ISO Application Profile);

design support for the mapping of service and information models from the abstract level (UML) to the Web services platform;

utility applications (e.g. for user management, service monitoring, catalogue navigation); and

specification and implementation of risk management services based on clear end-user requirements and validated in real-world pilot applications.

SANY

What was mentioned about interoperability and standardisation in the introduction is also valid for the SANY (Sensors Anywhere) project. Due to the uncountable number and types of sensors monitoring our environment and regarding the vision of the EC for a “Single Information Space for the Environment in Europe” it is specifically necessary to rigorously base the development of sensor networks on standardized open architectures that are of an utmost generic design and provide serious added value for end users. This is the starting place of the SANY project.

Sensors Anywhere (SANY) is an FP6 IST-5 Integrated Project dealing with sensor networks research for environmental applications. It aims to contribute to the joint European Commission (EC) and European Space Agency (ESA) “Global Monitoring for Environment and Security” (GMES) initiative by improving the interoperability of in-situ sensors and sensor networks, and allowing quick and cost-efficient reuse of data and services from currently incompatible sources in future environmental risk management applications.

Therefore SANY addresses in its objectives the following challenges: (1) specifying a (generic) standard open architecture for fixed and moving sensors and sensor networks capable of seamless “plug-and-measure” type of environmental risk sensor networks, and sharing of data and messages between sensors networks. Furthermore, this architecture must be generic, so that any existing and future sensor-like data source can be accessed in a standard-compliant way. In particular, the standard must be applicable to all kinds of in-situ sensors, existing sensor networks, emerging ad-hoc sensor networks, virtual sensors, roving sensors and airborne sensors, and to ensure interoperability between ground sensors and in-orbit sensors; (2) developing and validating re-usable data fusion and decision support service building blocks and a reference implementation of the architecture; (3) closely working with end users and international organisation to assure that the outcome of SANY contributes to future standards applicable to GMES.

A general goal is that all SANY architecture specifications shall be publicly available, validated by experts through OGC and compatible with EU and ESA infrastructure initiatives, such as INSPIRE.

Structure / Pilots

The setup of the SANY project is twofold. Firstly, there are numerous projects developing IT architectures (such as ORCHESTRA) which are taken into account in the design phase in order to build on this work. Figure 1 shows some of the inheritance of the SANY project. Secondly, the SANY sensor service architecture (described in the next section) is being developed. Through the concepts of data fusion and decision support the outputs of this architecture and services are studied within the project. Finally, the project's results are validated in three independent domains: air pollution, marine risks and geological hazards (geohazards), which also provide valuable information on user requirements for sensor networks.

Figure 1.

SANY inheritance and relationship diagram. SSE refers to the European Space Agency's Service Support Environment and i-MARQ is a previous project funded by the EC under their Information Society Technology Programme (1998-2002).

Air pollution risk validation exercise

In this validation exercise, an application that combines different types of air pollution sensor networks from different vendors with air pollution models and meteorological data using development results (services) of the architecture and data fusion group is built. With SANY-enabled sensor network and fusion capabilities, this application will produce a detailed, integrated 3D picture of air pollution; allow integrated, online dispersion modelling; make it possible to better quantify background pollution; support cross-border information exchange and alert functionality; try to become vendor independent and validate plug-and-measure capabilities.

Marine risk validation exercise

For this exercise, an application for use in a coastal water management is built. Existing sensor networks and observation facilities are used together with access to meteorological services. In addition, a virtual sensor network will be created through which what-if scenarios can be evaluated. This will allow users to define potential crisis scenarios and explore how these would propagate, and which intervention responses might be appropriate.

This marine risk pilot shall be designed in order to validate key features of SANY core developments in a realistic application. The following challenging requirements are dealt with in this development: area size of up to 10 000 km2, enclosing a major port and other coastal zone activities; measurement parameters may include: meteorological and oceanographic (sea temperature, turbidity, salinity, chlorophyll, dissolved oxygen, microbial concentration); access to meteorological forecasts; several in-situ real-time monitoring stations (at least one ship-borne station); an airborne surveillance capability for dedicated campaign; availability of historic data (e.g. for up to five years) for the principle measurements; river current and urban treatment works data measured online (where available); and central station with dedicated tools (such as data processing, alerts management, information broadcasting).

Geohazards validation exercise

Here an operational application for the use of a geo-hazard monitoring service in a complex urban context is created. This application will take the opportunity of existing classic monitoring systems in European cities, with a final demonstration in the Barcelona area, where large urban works are impacting the environment.

Architecture for Sensor Service Networks

Reference model

The architectural design for sensor service networks follows one of the core results (see section 3) of the ORCHESTRA project: It applies the Reference Model for the ORCHESTRA Architecture (RM-OA) [9] and extends it to geospatial service networks. The RM-OA is is built upon two main pillars: a process model and a conceptual model [11].

The ORCHESTRA process model applies an incremental, iterative approach for the analysis and design phases. Usually, a multi-step breakdown process across several abstraction layers is necessary to analyze user requirements and map them to the capabilities of a service platform. ORCHESTRA distinguishes between an abstract service platform that is specified independently of a given middleware technology and a concrete service platform (see Figure 2).

Figure 2.

Abstract and Concrete Service Platforms.

The abstract design phase leads to platform-neutral specifications following the rules of the abstract service platform provided by the ORCHESTRA Reference Model. They represent the functional, informational and non-functional requirements of the problem domain.

The concrete design phase maps the abstract specifications to a chosen concrete service platform. In the current ORCHESTRA project this is the ORCHESTRA Web Services platform consisting of the rules of the W3C Web services and a profile of the Geography Mark-up Language (GML) as the current mainstream service platform technologies for geospatial applications.

In the engineering phase the platform-specific components are organised into service networks taking into account the qualitative requirements and translating them into operational policies.

In practice, these individual phases are often interlinked and repeated in an iterative fashion. Sometimes the abstract design phase is not required. Furthermore, existing service and OGC service standards for Web services make a pure top-down approach impractical. Thus, in practice, a middle-out design approach is often the appropriate method.

However, what is required is a clear structure for the documentation of the ideas and the results of the design phases. ORCHESTRA has adopted ISO/IEC 10746 ‘Reference Model for Open Distributed Processing’ (RM-ODP) [4] for this task and has interpreted it for the design of geospatial service architectures [9].

Sensor model

When planning an architecture that permits to access information provided by sensors of various types (from water monitoring stations up to cameras mounted on satellites) it quickly becomes obvious that it has to abstract from the physical characteristics of the individual sensors and their communication networks. However, the style of this abstraction is dependent on the purpose of the application that requires access to the sensors. If the purpose is to select the best-suited sensor device in terms of cost, accuracy and availability in order to fulfill a particular environmental observation task, there is a need to search for and compare descriptions of sensors. In short, access to sensor meta-information is required. If the purpose is to obtain a reading for an environmental parameter at a certain place and time, one may not be interested in the sensor as a device itself but in the information it provides. Finally, if the purpose is to influence the behavior of a given sensor device, e.g. to move it to a certain area (for mobile sensors), the externally accessible functionality of the sensor is important.

The SANY approach to solve this problem is to define a Sensor Model by looking at sensors from the RM-ODP viewpoints [10]:

The enterprise viewpoint analyses the business context, the system and user requirements for environmental monitoring in terms of functionality, information demand and quality. It identifies the environmental phenomena that have to be observed with their temporal and spatial resolution and reflects this need with the types of sensors and models that are available. This activity may encompass a cost-benefit analysis if there are several options and offers from service providers. Furthermore, from the set of requirements basic patterns of sensor topologies have to be abstracted. For instance, it is necessary to distinguished between sensors that are spatially fixed, i.e. fixed at a given location, and mobile sensors such as cameras on aircraft or in satellites.

The information viewpoint discusses a sensor with respect to the semantics behind a sensor or sensor system. Here, SANY basically adopts the OGC Observations and Measurements model [2]. We speak of a sensor as a source that produces a value within a well-defined value space of an observed property, which may represent a physical, biological or chemical environmental phenomenon. Sensors and sensor systems as well as simulation models fulfill this definition. In the information viewpoint, SANY abstracts from the source of observation data and concentrates on the data that are provided in the form of observation results. In addition, information about the observation procedure, spatial-temporal context, and organizational characteristics has to be provided.

The computational viewpoint (in ORCHESTRA and SANY referred to as the service viewpoint) is concerned with the functional decomposition of the system into a set of services that interact over interfaces. The external perspective represents the view of a software developer or a designer who aims at integrating a sensor into a network of services. From this perspective, a sensor may be seen as a component in a service network with two major interfaces:

one interface to access the data representing the property observed by the sensor (see the information viewpoint above;, and;

a management interface that allows one to configure and monitor the internal behavior of the sensor (see the internal perspective).

The engineering viewpoint links the sensors to a communication network. The network might be the Internet or any other open communication network.

From a technology viewpoint, we consider a sensor to be a device that responds to a (physical) stimulus in a distinctive manner, e.g. by producing a signal. This means that a sensor device converts the stimulus into an analogue or digital representation, the latter being of more interest within the IT domain. SANY distinguishes between different forms of such a sensor. The simple form of a sensor provides information a single observed property (e.g. a temperature). A complex form of sensor combines several simple sensors and provides information on multiple observed properties. A sensor system (e.g. a satellite), allows the management of the system holding the sensors in addition to the management of each individual sensor separately.

In summary, the SANY approach to access to sensors and sensor information is to define a SOA, the SANY Sensor Service Architecture [9].

SANY sensor service architecture

The major architectural heritage of the SANY Sensor Service Architecture is the ORCHESTRA Architecture specified in [8] as an “open architecture that comprises the combined generic and platform-neutral specification of the information and service viewpoint as part of the ORCHESTRA Reference Model”. Consequently, the SANY Sensor Service Architecture builds upon the components of the ORCHESTRA Architecture which comprise:

Rules and guidance on specifying information and service models in the context of international standards.

Basic re-usable specification units for information models (e.g. pre-defined feature types) and service models (e.g. re-usable interfaces).

A series of textual descriptions and formal specifications of generic ORCHESTRA Architecture Services that are application and technology independent.

It is the objective of the project SANY to re-use and apply these components in the context of the SANY Sensor Service Architecture to the extent that they fulfill the requirements to build service networks based on sensor information and higher-level sensor information processing.

Functional domains

SANY services are designed to serve the needs of applications and users. Although there is no prescribed hierarchy of services, the SANY services may be grouped into functional domains matching their design purposes. The SANY Sensor Service Architecture distinguishes between the following functional domains for SANY services (see Figure 3).

Figure 3.

Functional Domains of SANY Services.

Sensor Domain

SANY services in the sensor domain cope with the configuration and the management of individual sensor devices and their organization into sensor networks. Examples are services that support the interaction among the sensors themselves, e.g. a take-over service in case of an impending sensor battery failure. Services in this domain are abstractions from the proprietary mechanisms and protocols of sensor networks.

Acquisition Domain

SANY services in the acquisition domain deal with access to observations gathered by sensors. This includes other components in a SANY Sensor Network (e.g. a database or a model) that may offer their information in the same way (as observations) as sensors do. They explicitly deal with the gathering and management of information coming from the source system of type “sensor”. The information acquisition process may be organized in a hierarchical fashion by means of intermediate sensor service instances (e.g. using data loggers).

Mediation and Processing Domain

SANY services in the mediation and processing domain are not specific to the sensor service architecture. They are specified independently of the fact that the information may stem from the source system of type “sensor”. They mediate access from the application domain (see below) to the underlying information sources. They provide generic or thematic processing capabilities such as fusion of information (from sensors and other information sources), the management of models and the access to model results. In addition, service support for the discovery of sensors, data and services, naming resolution or service chaining are grouped in the mediation and processing domain.

Application Domain

Based on services of the acquisition and processing domain, SANY services in the application domain support the rendering of information in the form of maps, diagrams and reports such that they may be presented to the user in the user domain.

User Domain

The functionality of the user domain is to support the interface to the end user. SANY will not specify dedicated services to support the user interface. However, when building real systems and applications, such functionality is essential. SANY considers this functionality to be specified in a dedicated implementation architecture that also may take proprietary components and products into account.

Service overview

In Table 2 an overview of the combined set of services from ORCHESTRA and SANY is given as it currently stands. For the basic interfaces and the services in the mediation and processing domain, their abstract [6] and their implementation specifications [7] are available. The services in the acquisition domain are selected from the OGC Sensor Web Enablement (SWE) initiative.

Table 2.

Architecture Service usable in a SANY Service Network

Service and interface type	Overview
Basic interfaces	Interface types enabling a common architectural approach for all ORCHESTRA Services: self-description of service instances (capabilities) synchronous and asynchronous interactions transactional support predefined exception types
Mediation and processing domain
Authentication Service	Proves the genuineness of principals (i.e. the identity of a subject that may be a user or a software component) using a set of given credentials. The selected authentication mechanism is up to the implementation specification.
Authorization Service	Provides an authorization decision for a given authorization context.The selected authorization paradigm is up to implementation specification.
Catalogue Service	Ability to publish, query and retrieve descriptive information (meta-information) for resources (i.e. data and services) of any type: not tied to a particular meta-information standard (e.g. ISO 19115) supports application schemas for meta-information that are designed according to the ORCHESTRA rules; May be used as a data catalogue, service registry or both;. may be cascaded with OGC catalogues or OASIS UDDI; includes an adapter to Internet search engines (e.g. Yahoo); includes an option for ontology-based query expansion and result ranking.
Document Access Service	Supports access to documents of any type (textual documents, images,). A document is referenced by a document descriptor that is considered to be a specific kind of feature type.
Feature Access Service	Selection, creation, update and deletion of feature instances and feature types1 available in a service network. Features provided are instances of a certain feature type defined in an ORCHESTRA Application Schema. Interface may be re-used by more specific access services using interface inheritance.
Map and Diagram Service	Enables geographic clients to interactively visualize geographic and statistical data. Transforms geographic data (vector or raster) and/or numerical tabular data into a graphical representation using symbolization rules. The main output of this service is an image document that may be a map, a diagram or a thematic map (visualization of the spatial distribution of one or more statistical data themes).
Ontology Access Service	Supports the storage, retrieval, and deletion of ontologies as well as providing a high-level view on ontologies. As an optional Knowledge Base interface, it provides operations to query and update models contained in a knowledge base
Name Service	Encapsulates the implemented naming policy for service instances in a service network, e.g. creates globally unique service instance names using a defined naming policy. Important if several service networks across different platforms are to be interconnected.
Service Monitoring Service	Provides an overview about service instances currently registered within a service network, e.g.: Actual status (e.g. running, stopped, offline) Statistical information (e.g. average availability, response times)
User Management Service	Creates and maintains subjects (users or software components) including groups (of principals) as a special kind of subjects.
Acquisition Domain
Sensor Observation Service	Provides access to observations from sensors and sensor systems in a standard way that is consistent for all sensor systems including remote, in-situ, fixed and mobile sensors. An SOS organizes collections of related sensor system observations into Observation Offerings.
Sensor Alert Service	Provides a means to register for and to receive sensor alert messages. The service supports both pre-defined and custom alerts and covers the process of alert publication, subscription and notification.
Sensor Planning Service	Provides a standard interface to task any kind of sensor to retrieve collection assets. It is a service by which a client can determine collection feasibility for a desired set of collection requests for one or more sensors/platforms, or a client may submit collection requests directly to these sensors/platforms.
Web Notification Service	Service by which a client may conduct asynchronous dialogues (message interchanges) with one or more other services. This service is useful when many collaborating services are required to satisfy a client request and/or when significant delays are involved in satisfying the request.

As in (RM-OA, 2007), SANY adopts the ISO 19101 definition of a feature as being an “abstraction of a real world phenomenon” but explicitly subsumes hypothetical worlds under the term “real world”, too. Thus, for instance, a “model” may also be understood to be a feature type.

Outlook

The focus of the ORCHESTRA and SANY Architecture as specified today is based on syntactic interoperability. A thorough analysis of user requirements has led to the specification of a series of generic services that provide powerful and indispensable functionality for the design of geospatial SOAs in the domain of environmental risk management and sensor service networks. As real service platforms, W3C Web services and GML have been chosen as the current mainstream technology. However, the chosen architecture has already opened the door towards enhancements. More powerful service platforms currently being specified by the Semantic Web Services community are emerging [5]. Ongoing activities in the ORCHESTRA architecture group aim at extending the ORCHESTRA Reference Model such that these new technologies may be embedded and exploited. The application of semantic ORCHESTRA services in pilot test beds [1] are first steps in this direction and will provide important feedback about how semantics may be used in real world use cases. Furthermore, the SANY project will investigate additional services supporting event processing, sensor network management and configuration and, in case of ad hoc sensor networks and resource discovery, including sensors and observation offerings [10].

Conclusions

Citizens and the environment are exposed to an increasing number of risks and critical situations originating from natural and man-made hazards. The number of crises, as well as their associated human and economic losses, seems to follow at a world-wide scale an increasing trend. This fact has been acknowledged by experts and authorities, and appropriate measures are being sought to improve the risk and crisis management cycle at the different administrative levels. Special attention is being paid to the basic requirement that stakeholders need to collaborate and interoperate in order to improve their own performance (by sharing experience and information) and improve joint efficiency and efficacy when confronting multi-risk or cross-border situations. All fields of activity, including risk management, are in turn increasingly dependent on ICT systems, which may act as enablers or inhibitors, so special attention must be paid to the underlying technology. Unfortunately, in general, existing IT systems have not been designed to interoperate (that is, to efficiently exchange information without external intervention).

Sensors, and especially sensor networks, play a critical role in risk management and their use will probably increase in the future. They allow vast amounts of relevant information to be collected in (nearly) real-time in locations that are remote, inaccessible, or lack the necessary resources to acquire such information in a different manner. Current research in the field of sensors focuses, at the sensor level, on important aspects such as size, cost, disposability or power efficiency. Complementary efforts are being carried out at the sensor network level, in order to tackle issues such as sensor data fusion and interoperability among networks and between these and their connections to ICT systems.

Service-oriented architectures (SOAs) are currently the choice for enterprise applications. These can be built by orchestrating different existing, distributed and loosely-coupled services according to new business requirements. The ORCHESTRA project has designed a service-oriented architecture that is open, free of charge and based on existing standards (ISO, OGC and W3C) in order to enable interoperability in risk management. The ORCHESTRA architecture has been defined first at an abstract (technology- and policy-independent) level, and later specified for the case of W3C web services. The rationale behind this two-level approach is to ensure that architectural principles providing, among others, interoperability are durable, allowing the same architecture to be defined for future technologies of choice. SANY builds on the results of ORCHESTRA and focuses on the development of sensor networks based on standardized open architectures.

These efforts will ultimately result in the availability of an open distributed architecture for sensor networks for risk management, based on the necessary standards to ensure interoperability among the relevant actors in the field. Both projects are coupling the scientific and technical decisions outlined above with a realistic and open business perspective. In this sense, there are several aspects worth noting. The architecture resulting from these projects accommodates the use of open-source or proprietary software, according to users' needs and preferences. This architecture takes into account the existing legacy systems, therefore providing a technological solution that does not force users to replace their IT systems and applications or to embark on long, costly and – worst of all – repeated integration efforts. In addition, they offer an increased possibility for specialized and enhanced service provision, thus favoring the emergence of a risk management application and service market in which big and small players are able to co-exist.