SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 181 of 233
be included into an OGC Catalogue Service 2.0.2 supporting the ISO Metadata application profile. This catalogue could be accessed directly from users or it could be included into a
cascading catalogue realized by the INSPIRE geo-portal.
The architecture also shows the integration with a SANY Catalogue Server according to the SensorSA Catalogue Service see section 8.4.1. A different mapping is performed in the
Catalogue Harvester to create the SANY metadata documents according to the SensorSA Application Schema for Meta-information AS-MI schema see section 7.7. These documents
can be published via the publication interface of the Catalogue Service.
10.2.5 Event-based Harvesting
The harvesting solution described above in section 10.2.4 requires that the update of the meta- information is triggered by a management interface of the client accessing the Harvesting
component. This may not be sufficient as people using the management interface might lack of knowledge about new developed services or changed data views in existing services. They need
to be informed about changes, such that they can adapt the configuration of the management interface. This can lead to outdated meta-information in the catalogue. The alternative is to apply
the event-based architectural style as it has been introduced as a SensorSA concept in section 6.4.
An event-driven processing system must be configured. The client of the harvesting component must provide a function which can be used for the subscription to the three event
types service created, service updated and service deleted. Figure 10-4 shows the subscription phase:
Figure 10-4: Event-based Harvesting - Registration Phase
After this configuration the system is ready for receiving events:
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 182 of 233
1. An event must be created. Typically the service automatically sends an event if the service has changed.
2. The notification broker receives the event and informs the interested party which subscribed for this event type. In case of the harvesting, the client of the Harvesting
Component will be informed when services have been created, updated or deleted. 3. The client of the Harvesting Component will update the service configuration list and
performs the meta-information harvesting function Figure 10-5 shows the operational phase. In this phase, all services contained in the service
configuration list are harvested according to a harvesting policy, e.g. periodically after a given time period that may be set by the client of the harvesting component. The service configuration
list of the harvester has to be updated depending on the type of the event received. In case of a “service creation” event, a new entry is added. In case of a “service deleted” event an entry is
deleted.
Figure 10-5: Event-based Harvesting - Operational Phase 10.2.6 SOS Resource Model
The resource model as specified in section 7.6 may be used to structure the discovery and the access to information provided by the SensorSA services. As an example SOS resource types
see section 8.2.2 are defined. These are oriented at the OM model section 7.2 and shown in Figure 10-6.
For each resource type an example identifier scheme is given as a constraint. The configuration of resource types in a resource type network is illustrated in Figure 10-6. The
directed links in Figure 10-7 represent the navigation possibilities between the representations of these resource types. Selected resource types are described in more detail in subsequent sub-
sections. The following resource types are defined:
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 183 of 233
-
SOS-instance : This resource type is a sub-type of the resource type ServiceInstance and
provides the description of the capabilities of an instance of the SOS. It provides access to procedures through a selection in a ProcedureList as a sub-type of a SelectionList and
makes offerings which may be selected by means of an OfferingList as a further sub-type of a SelectionList. An SOS-instance is access by the path .sos followed by the URL and
the local id of the SOS-Instance.
-
Procedure : This resource type reflects the OM concept of a procedure. A procedure is
linked to an offering and bound to a FeatureOfInterest. A procedure is accessed by the path {SOS-instance}procedures followed by the name of the procedure.
-
Offering : This resource type reflects the SOS concept of an observation offering. It
contains ObservedProperties to which may be navigated by means of a PropertyList as a sub-type of a SelectionList It is linked to an ObservationCollection that delivers all
observations of all procedures in one resource representation. An offering is accessed by the path {SOS-instance}offerings followed by the name of the offering.
-
ObservationCollection : This resource type reflects a collection of the OM concept of an
observation. An observation collection is accessed either by the path {ObservedProperty}observations or by the path {Offering}observations followed by the
name of the observation collection.
-
FeatureOfInterest : This resource type reflects the OM concept of a feature of interest.
It is linked to ObservedProperties. A feature of interest is accessed by the path {Offering}features followed by the name of the feature of interest.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 184 of 233
Figure 10-6: Resource types for the access to sensor observations
-
ObservedProperty : This resource type reflects the OM concept of an observed
property. An observed property is linked to an ObservationCollection that delivers observations of this property for a given time period. An observed property is accessed
by the path {SOS-instance}properties followed by the name of the feature of interest.
-
SelectionList : This resource type is an auxiliary resource type that is used to select a
resource representation out of a list. In this example, it is used to select properties, offerings, procedures and features of interest. The access path to a selection list is
dependent on the resource representation to be selected. For instance, for the selection of features of interest, it is the path {Offering}features.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 185 of 233
Figure 10-7: Resource type network for the access to sensor observations
Figure 10-8 shows an example of an SOS resource type network embedded in a Web-based application that allows one to navigate. Representations of observations in terms of diagrams,
tables or maps may be retrieved by a direct URL or by navigating through the resource type network.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 186 of 233
Figure 10-8: Example Representations of the SOS Resour ce Type “Observation Collection”
10.3. Policies for Sensor and Service Monitoring
Service monitoring is an important aspect of management which must be dealt with in a sensor network. This includes simple checks of the life status of a sensor or service as well as more
complex monitoring of tasks such as average load or uptime. From the SANY point of view the various monitoring aspects in a sensor network are considered to be observed properties. The
discrete monitoring results have a timestamp, can be associated to a featureOfInterest containing the location of the monitored resource, and have a procedure describing the measurement
process.
Thus we can safely say that the information resulting from the monitoring process can be modelled as an observation according to the OGC Observation and Measurement model Cox,
2007. A simple example would be monitoring the CPU temperature of a measuring station computer. Similarly event notifications can also be modelled as observations.
This view enables a harmonised integration of monitoring into the SensorSA. This approach implies the use of the OGC Sensor Observation Service see section 8.2.2 and Sensor
Alert Service see section 8.2.4 for the configuration of the monitoring process, storage and access to the observation data related to the monitored sensors.
Getting the observation data into the SOS is implementation specific, but two patterns can be identified, as depicted in Figure 5-17.
