SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 72 of 233
Naturally, all components can be included arbitrary chains. The following figure illustrates a realistic scenario. Here, a wireless sensor is connected to a gateway that forwards
events generated by the sensor to other Internet nodes. Due to the limited capacities of the sensor, it is preconfigured to send all events to a dedicated event sink Internet Gateway. The
Internet Gateway doesn‟t provide any additional capabilities other than forwarding the events to a broker. Such a chain of components is often used to match dedicated security
requirements. An additional router subscribes to the offerings of the broker. This router serves as an intermediate to the client. The router may only act as a protocol transducer, i.e. events
received using Internet protocols might get forwarded using automated phone calls.
Figure 6-7: Event Processing Chain
Principally, brokers and router serve as mediators between event sources and event sinks and don‟t provide any further event processing capabilities. Though, both may
implement further processing capabilities. The OGC Sensor Alert Service see section 8.2.4 is an example of such a broker: Sensors register with the service and publish events or simple
observations. The SAS instance acts as a complex event processor and analyzes all incoming data. Based on its internal settings, the service generates other types of events then it receives.
An example is a blizzard warning services. The service receives data streams and events reporting various weather parameters. Based on the actual constellation of the various
parameters in time and space, it then generates events of type “Blizzard”. The generation of those new event types might be transparent or opaque to subscribers.
6.4.3.3 Event Role Interfaces
The components described in the Event Role Model section 6.4.3.2 are differentiated by their functionalities. The SensorSA organises these functionalities in four orthogonal
interfaces as illustrated in Figure 6-8. These interfaces can be implemented by components in order to take on a specific role within a distributed event-driven processing system.
Note: These interfaces are specified in section 8.5 of the SensorSA Service Viewpoint in an abstract, i.e. platform-independent form.
Figure 6-8 illustrates the four interfaces and the provided functionalities using UML notation. The interfaces relevant to publishersproducers are shaded in blue; those relevant to
receiversconsumers are shaded in purple. All possible implementations are shaded in light yellow.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 73 of 233
Figure 6-8: Event Processing Interfaces 6.4.4
Exemplary Event Types
The following list of event types has been identified as being of major importance for SensorSA applications
11
:
-
Sensor Available: generated by a sensor or sensor system when a new sensor is connected to the sensor network.
In general, it‟s useful for “Plug and Measure” scenarios, especially for event triggered catalogue harvesting
-
Sensor Unavailable: Generated by a sensor or sensor system when an existing sensor is unavailable, e.g. disconnected from the sensor network. It may be used for event
triggered catalogue ha rvesting and “Plug and Measure”.
-
Sensor Timeout: Generated by a sensor or sensor system when a sensor has not responded since a defined period of time.
-
Sensor Properties Changed: Generated by a sensor or sensor system when sensor properties change e.g. recalibration, location change in the case of mobile sensors.
11
This is a non-exhaustive list without any claim of completeness or lack of redundancy.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 74 of 233
-
New Sensor Data: Generated by a sensor or sensor system when the sensor acquires new data, e.g. new data is inserted into a Sensor Observation Service.
-
Service Trigger: Generated by a service orchestration environment in order to trigger other services, e.g. in service chains.
-
Service CreatedDeleted: Generated by a service in case of creation or deletion of a service. It may be used to trigger the harvesting of service capabilities.
-
Service Capabilities Updated: Generated by a service when the capabilities of a service have been changed. It may be used to trigger the harvesting of service
capabilities.
-
Threshold Exceeded: Generated when a value has exceeded a given threshold. It may be used in environmental monitoring applications.
-
Sensor Battery Low: Generated when the remaining power of a sensor energy supply system e.g. a battery has fallen under a given level.
6.5. Resources and their Identification
6.5.1 Resources
In general, the SensorSA denotes by the term “resource” anything that‟s important enough to
be referenced as a thing itself RichardsonRuby 2007. Examples of resources in the SensorSA may be sensors, functions possibly provided by means of services, data objects
possibly but not necessarily modelled as feature types, views upon data objects or descriptions of data objects or services capabilities.
The SensorSA focuses on a service-centric computing paradigm and puts the services and their interfaces into the foreground. However, these services access and manipulate
underlying resources with quite complex schemas e.g. the elements of the observation and measurement model described in section 7.2. Typically, these resources provide views
subsets upon data sources driven by the needs of the user. The effects of the service operations heavily depend on the meaning and the status of the underlying resources that are
selected by the caller of an operation when setting the operation parameters. An alternate paradigm would be to focus upon these resources and their representations when defining a
service platform. This approach is followed by the resource-oriented architecture ROA realised by so-called RESTful Web services RichardsonRuby 2007.
The SensorSA aims at conceptually linking a service-oriented and a resource-oriented view upon a sensor service network in order to gain flexibility. This approach follows the
architectural principles of “technology independence”see section 4.1.3 and “component architecture independence” see section 4.1.5.
The concept “resource” is covered in the SensorSA by considering the following aspects:
-
The identification of resources is defined below in sections 6.5.2 to 6.5.3.
