New Generation SWE 2.0

To recap, BT Research’s Sensor Virtualization project began in 2007 and all the SWE service and encoding specifications were released as version 1.0 in summer 2007. New Generation SWE 2.0 was released in March 2011, therefore a comparison of the SWE 1.0 and 2.0 frameworks is provided to highlight which key specifications have been upgraded or discontinued since the previous version.

SWE Standardization

The main OGC Standards in the SWE framework are as follows [175]:

 O&M - The general models and XML encodings for observations and measurements;

 PUCK Protocol Standard - Defines a protocol to retrieve a SensorML description, sensor ‘driver’ code, and other information from the device itself, thus enabling automatic sensor installation, configuration and operation;

 SensorML - Standard models and XML Schema for describing the processes within sensor and observation processing systems;

 Sensor Observation Service (SOS) - Open interface for a web service to obtain observations and sensor and platform descriptions from one or more sensors;

 Sensor Planning Service (SPS) - An open interface for a web service by which a client can 1) determine the feasibility of collecting data from one or more sensors or models and 2) submit collection requests;

 SWE Common Data Model - Defines low-level data models for exchanging sensor related data between nodes of the OGC SWE framework;

 SWE Service Model - Defines data types for common use across OGC SWE services. Five of these packages define operation request and response types;

 The Pub/Sub Standards WG is working to produce a version 1.0 implementation standard that clearly defines a standard way to enable publish/subscribe functionality for OGC Web Services. This will be applicable to sensors.

Table 4 compares SWE 1.0 and 2.0 specifications to highlight key improvements [176] and [177]:

Table 4 - Comparison of SWE 1.0 and 2.0

Advantages of SWE 1.0: Disadvantages of SWE 1.0: Resolved in SWE 2.0:

SWE exposes sensor data and allows reuse for multiple applications, hence connecting diverse sensor networks. SWE approach to sharing sensor objects is good.

Security is not within the scope of SWE.

Security layers - transactions was unavailable.

SWE is part of system, security must be addressed separately. SOS lacks access control. Encryption required for sensitive data.

Improved security external to SWE (e.g. IPv6, E2E security)

Major changes to SWE 2.0 Information Model and Service Model.

Added support in SWE Common Data for disparate messages, nil values, extensions (e.g. security tagging, UncertML) and required tagging to semantic definitions. SOAP implementation supporting security and web notification. Extensible – current approach of

getting a basic level first and a

At the time of writing, registration of sensors (CS-W) could not be

Sensor registry upgraded, discovery of sensors supported by Sensor

process where extensions can be adopted.

done as that part of the work was not completed, but WIP.

Instance Registry (SIR) and Sensor Observable Registry (SOR). SWE standards are more precise and testable.

Integration of sensor data and encodings.

Not necessarily real-time and

certainly not “RT integration”. SWE 2.0 specs provide functionality to integrate sensors into Spatial Data Infrastructures (SDI).

Improved specs and encodings e.g. EML supports CEP (EPL for CEP) (e.g. Aviation)

CEP has potential to enable data fusion aspect for projects (e.g. SAPHE, BRIDGE) which SWE alone does not provide. Interoperability - reusing existing

architecture/technology,

interoperable WS & data encoding models (e.g. developing open standards applicable to

environmental monitoring networks (e.g. SANY).

Lack of tool-kits for development purposes.

Not surprising since many specs had barely been ratified, while others were in draft.

SWE 2.0 enhanced functionality. Extended tool-kit to aid

interoperability more suited to building BT’s vision of a reusable Generic Architecture.

More consistent use of SWE Common Data and SWE Common Services throughout SWE standards.

Some of the implementations of SWE (e.g. 52° North specs) are open source.

The standards are not open source and may be proprietary (OGC).

More WSN projects are adopting SWE specs for applications. Refer to SWE-enabled Apps, p.95. OGC compliant - standard

interfaces and encodings compliant with standards – uses and builds upon existing OGC standards.

Many standards may relate and subject to being ratified or change.

Introduction of SWE Service Model (SWES) specification which defines a common model consisting of basic types for requests and responses and Capabilities document of SWE services. SWE Common data model extracted from SensorML. SensorML (XML schemas) – rich

description language which is self- describing since it is used to describe the semantics, tolerances, ranges, units, etc.

SensorML may not be required before applying other SWE standards, such as SOS and SAS. (e.g. SAPHE use case)

SensorML supported and simplified profile for discovery.

Better support for inheritance and configuration in SensorML. TML discontinued. OX-Framework used for

visualizations.

Integration - GML/KML viable alternatives to visualize data.

Visualization performed by graphical apps not SWE framework, since SWE won’t work on its own, it’s part of larger system.

52° North Sensor Web Community develops various client apps for different SWE services. Most are built on top of the generic OX- Framework, which facilitates the accessing and utilization of OWS. It provides adapter plug-in for various OGC services. Client projects include:

- Rich OX Client - Sensor Web Client - ArcGIS SOS Extension - uDig Plugin

- SOS for R. Scalability - replicate any sensor

system.

Requires much knowledge and time, so has to be worth the effort.

Specs and encodings upgraded to improve scalability.

Conformance classes allow for partial uptake and implementation. SWE apps can be retro-fitted to

provide SWE services.

Geographically static nature of FoIs – people are mobile. 1.0 static only – no mechanism to allow location of FoI to be associated with another sensor providing location details.

Latest WSN projects using SWE framework and “easily” able to upgrade to SWE 2.0.

Mobile sensors supported in SWE 2.0.

Proprietary feeder framework had to be used to integrate sensor data into SOS.

Major improvements to SOS. SPS enables tasking of sensors. Better support for data streaming.

SOS request/response pattern not sufficient.

SAS not evaluated because not stable implementation

SAS superseded by SES (Sensor Event Service) interface spec. SensorML underused, not required

by SOS nor any tools to take advantage of model.

Sensor Interface Descriptor (SID) may influence SensorML development.

Current status of standards, implementations, supporting tools too immature.

SWE 2.0 enhanced functionality and will enable Semantic Sensor Web in future.

Number of issues to address in specs and support by developers.

Higher level of support via OGC / 52°N / iGSI developers & websites. Publish/subscribe and OGC Web

Services is currently done by OWS pub/sub standards WG at OGC.

Working towards common pub/sub functionality across all OWS, using established IT standards to realise the pub/sub functionality as appropriate.

Due to the number of non-compatible communities of sensor types, with stovepipe solutions for discovery, accessing observations, receiving alerts, and tasking sensor systems. Interoperability is expensive due to incompatible encodings and services. To realise the vision of a ‘plug-and-play’ web- based sensor network, the following functionality is required:

 Discovery of sensors and sensor data that meet applications’ or users’ immediate needs;

 Determination of sensors’ capabilities and quality of measurements;

 Access to sensor parameters that allow software to process observations automatically;

 Access to real-time measurements and time series in standardized encodings;

 Tasking of sensors and simulations to acquire observations of interest;

 Subscription to and publishing of alerts to be issued by sensors based upon certain criteria (Event based notification) [178].

SWE Future (i.e. SWE 3.0)

 Development of Service interfaces and encodings;

 Integration of Security layers;

 Integration of Visualization components;

 Integration of Catalogue / Registry;

 Data Fusion / Processing / Analysis;

 OGC compliance, interoperability, testing & evaluation (CITE). The development team evaluate OpenGIS specification conformant interfaces and products to implement them [179].