Design Principles

SANY Sensor Service Architecture relies on following design principles:

Rigorous Definition and Use of Concepts and Standards

The SensorSA makes rigorous use of proven concepts and standards in order to decrease dependence on vendor-specific solutions. This helps to ensure the openness of a sensor service network and support the evolutionary development process.

Loosely Coupled Components

The SensorSA allows the components involved in a sensor service network to be loosely coupled, in which case loose coupling implies the use of mediation to permit existing components to be interconnected without changes.



Technology Independence

The SensorSA is independent of technologies, their cycles and their changes, as far as practically feasible. Accordingly it is possible to accommodate changes in technology (e.g. lifecycle of middleware technology) without changing the SensorSA itself. The SensorSA is independent of specific implementation technologies (e.g. middleware,
programming language, operating system).

Evolutionary Development – Design for Change

The SensorSA is designed to evolve, i.e. it shall be possible to develop and deploy the system in an evolutionary way. The SensorSA is able to cope with changes of user requirements, system requirements, organisational structures, information flows and information types in the source systems.

Component Architecture Independence

The SensorSA is designed in a way that service network and source systems (i.e. existing information systems, sensors and sensor networks) are architecturally decoupled. The SensorSA does not impose any architectural
patterns on source systems for the purpose of having them collaborate in a service network, and no source system shall impose architectural patterns on a SensorSA. Important here is that a source system is seen as a black
box, i.e. no assumptions about its inner structure are made when designing a service network.

Generic Infrastructure

The SensorSA services are independent of the application domain, i.e. they can be used across different thematic domains and in different organisational contexts. Ideally, any update of integrated components (e.g. sensors, applications, systems, ontologies) requires no or only little changes to the users of the SensorSA services.

Functional Domains

Services in the SensorSA are designed to support applications that serve the needs of users. They may call other services if this is required to fulfil the functions offered at their interfaces. In an extended situation, chains of service operation calls may be defined in order to realize more complex functionality. In a service network every service instance may call operations of any other service. The Service Viewpoint of the SensorSA categorises service types into functional domains expressing the area of concern for which they are basically designed:

• Services in the Sensor Domain cope with the configuration and management of individual sensors and their organization in sensor networks. They are abstractions from the proprietary mechanisms and protocols of sensor networks. An example is a take-over service in case of an imminent sensor battery failure.
  
• Services in the Acquisition Domain deal with access to observations gathered by sensors. This includes other components in a sensor network, e.g. a database or a model that may offer their information in the same way, i.e. as observations. The information acquisition process may be organised in a hierarchical fashion by means of intermediate instances, e.g. with data loggers
  
• Services in the Mediation and Processing Domain are specified independently of the fact that the information may stem from a source system of type ‘sensor’. They mediate access from the application domain
  to the underlying information sources. They provide generic or thematic processing capabilities such as fusion of information, the management of models and the access to model results. In addition, support for service
  discovery, sensor planning and the management of events and alerts are grouped in this domain.

• 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.
• The functionality of the User Domain is to support the interface to the end user, typically in a graphical fashion.

Implementation Platforms

The SensorSA concepts are realised following the guidelines and technologies of standard (Web) service platforms. However, there are competing Web service paradigms on the market with disparate protocol bindings (e.g. SOAP or HTTP) and capability descriptions (e.g. service-oriented or resource-oriented). The technologies for these service platforms rely upon specifications of W3C, OGC and OASIS.

In order to enable service interoperability, the SensorSA separates the platform specification into a core mandatory part and one or more optional platform specific parts. Three platforms are currently supported: W3C Web Services, OGC Web Services and so called RESTful Web Services for the resource-oriented approach.

The SensorSA core mandatory part refers to W3C Web Services which is, according to a decision of the OGC Technical Committee, also the strategic direction for all new specified OGC services. It requires a SOAP envelope embedded into an HTTP message as the transport protocol and WSDL as the service description language. Optionally, HTTP may also be used directly. This enables to also use the OGC Web services as they are specified today.

Optional, RESTful Web Service interfaces rely upon the principle of Representational State Transfer (REST) which means, that the call of service operation is considered as a transfer of state information of uniquely identifiable resources in form of resource representations. In the SensorSA, the resources are typically geospatial resources described in a resource model, e.g. a collection of sensor observations with a known geo-location reference, and their representations, which may be maps, tables or diagrams.

The multi-platform approach of the SensorSA facilitates the reuse and integration of existing software components and the evaluation of other service paradigms.

Interaction Patterns

SensorSA supports two main interaction patterns:

Request/Reply Interaction Pattern

In a classical request/reply interaction pattern, the consumer ‘knows’ the provider and initiates the interaction by "requesting" the information through direct call to a service interface. This interaction pattern is always synchronous, and the consumer has to keep listening until receiving the reply.

Event Driven Interaction Pattern

In "event driven" interaction, the consumer and the producer are linked through broker. In order to access the information, the consumer first declares interest in getting event notifications by issuing a subscribe operation with an event filter to a notification broker, usually together with a callback address. Independently of this action, the provider publishes events to the broker, e.g. in case of a state change of an underlying resource. The provider is unaware of the consumers that have subscribed to events. It is the task of the broker to analyse the event filters and to determine which consumer should be asynchronously informed by the broker about the event happening.

A-priory, any observation in SensorSA network may be communicated either in event-driven manner, or using the request/reply interaction pattern. Due to practical concerns, the event driven interaction pattern is primarily used in situations where request/reply interactions can not be used , or does not perform adequately. "Event-driven" use cases therefore often include some form of alerting, e.g. "new service/resource available", or "house on fire". However, the choice of interaction pattern may be also dictated by business reasons, e.g. because network configuration does not allow direct access to resources, or because the inexpensive hardware (e.g. smart sensor nodes) can not support relatively resources-hungry web services.

Service Interfaces

SensorSA service model considers service interfaces to be the unit of reusability on specification level whereby an interface is structured into operations. Operations access underlying data sets which are often related to attributes of features defined in application schemas according to the general feature model

Service types are specified in terms of one or more interfaces, whereby one interface may be attached to several service specifications. For instance, the meta-information of services, their so-called capabilities, is specified in a dedicated capabilities interface which is common to all SensorSA services. Supported service interfaces include:

Basic Interface Types	Enable a common architectural approach for all architecture services, e.g. for the capabilities of service instances
Annotation Service	Relates textual terms to elements of an ontology (e.g. concepts, properties, instances).
Catalogue Service	Ability to publish, query and retrieve descriptive information (metainformation) for resources of any type. Extends the OGC Catalogue Service by additional interfaces for catalogue cascade management and ontology-based query expansion.
Feature Access Service	Selection, creation, update and deletion of features available in a service network. Corresponds to the OGC WFS but is extensible by schema mapping.
Identity Managementand Authentication Service	Creates and maintains identities. Supports the management of groups (of identities) as a special kind of identity. Proves the genuineness of identities using a set of given credentials and issues session information.
Map and Diagram Service	Enables geographic clients to interactively visualize geographic and statistical data in maps (such as the OGC Web Map Service) or diagrams.
Ontology Access Interface	Supports the storage, retrieval, and deletion of ontologies as well as providing a high-level view on ontologies.
Policy Enforcement Service	Handles authentication and sends authorisation requests to the Policy Decision Point for non-security enabled Web services.
Policy Management and Authorisation Service	Provides a decision on whether some identity (e.g. a user or a service) is authorised to access a certain resource.
Profile Management Service	Creates and maintains (user) profiles and their associations to identities.
User Management Service	Creates and maintains subjects (users or software components) including groups (of principals) as a special kind of subjects.
Web Processing Service (WPS)	Start, stop and result retrieval of information processes (e.g. statistical calculations).
Sensor Observation Service (SOS)	Provides uniform access to observations from sensors and sensor systems that is consistent for all sensor types including remote, in-situ, fixed and mobile sensors.
Sensor Alert Service (SAS)	Provides a means to register for and to receive sensor alert messages.
Sensor Planning Service (SPS)	Provides a standard interface to task any kind of sensor to retrieve collection assets.
Web Notification Service (WNS)	Service by which a client may conduct asynchronous dialogues (message interchanges) with one or more other services.
OASIS Web Service Notification interfaces	Family of related interfaces that define a standard Web services approach to notification using a topic-based publish/subscribe pattern.

Uncertainity and Quality Assurance

Within the SensorSA, the uncertainty of data sets is described using the UncertML. UncertML allows the information modeller to describe the uncertainty of a specific data set in an interchangeable way using an XML document conforming to the UncertML schema. This XML document can be embedded in a SensorML document to express information about the uncertainty of some process. In addition, UncertML can also be embedded in an O&M document to express the uncertainty of a specific sensor observation.

All data in SensorSA has an associated uncertainty depending on the available meta-information on how the data was observed (measured) or derived from other data sources.

Uncertainity of Measurements

In the case of data measured by sensors, the uncertainty can be classified into two categories:

• Type A: uncertainty arising from a random effect; evaluated by statistical methods, e.g. by computing the standard deviation of the mean of a series of independent observations or by analysing the variance and random effects in data in dependence of experimental parameters.

• Type B: uncertainty arising from a systematic effect. A typical cause of Type B uncertainty is is measurement bias due to the calibration of the measurement instrument or its behaviour in given environmental conditions (e.g. temperature, air pressure), or over time (deterioration of instrument, measurement drift). It is evaluated based on information about the instrument and environment. The measurement values may be corrected to compensate for known systematic effects.

Uncertainity of Processing

In addition to data arising from sensor measurements and observations, SensorSA also handles the results of various processing algorithms, such as spatial and temporal interpolations, or predictions arising from plume modeling. The results of such data processing steps are themselves uncertain, on the one hand due to the uncertainty of the
input data, on the other hand due to the probabilistic or approximate nature of the processing itself. The uncertainty of data arising from processing is typically expressed with one of the following:

• Probability density function, e.g. a normal distribution with known mean and variance. The data value would then lie within one standard deviation of the mean with probability 68% and within two standard deviations with probability 95%.

• Intervals (the data value lies in [a,b]). This does not a-priori assume a uniform distribution on this interval; this would however be the case if the distribution of maximum entropy were chosen. An important special case is when then the measurement instrument can assert that the data value is below or above a given threshold, but can provide no further information.
  
• Statistics such as standard deviation and moments, or quantiles (the data value lies in [a,b] with probability 95%)

Quality Assurance

In many environmental domains, the results of the measurements, observations or processing are subjected to one or more automatic, semi-automatized and manual "quality assurance" procedures. In the course of data quality assurance, the original data is usually annotated, and parts of the data may be declared invalid, or even corrected. The resulting "quality assured" data typically has lower uncertainty than the raw data,

SensorSA and OGC SWE foresee mechanisms for presenting the annotated data, e.g. by mean of the O&M "composite phenomena", but the quality assurance process itself and the type of annotation is domain dependent and therefore can not be fully specified on a generic level. In SANY, the feasibility of SensorSA-compliant quality assurance has been demonstrated within the Air Quality (SP4) pilot application.