5.4.3 Sensor Alert Service

From Geostandards

Jump to: navigation, search



Contents

Overview

The objective of the Sensor Alert Service (SAS) is to provide an push-based access to observations. The SAS can be compared with an event notification system, where the sensor is the object of interest. Each sensor has to register (advertise) the observations it will send to the SAS via the publish operation. A consumer interested in certain events may subscribe to alerts disseminated by the SAS. If an event occurs the SAS will notify all clients subscribed to this event type.

Operations

The operations of the SAS can be classified into operations that are used by a data producer (sensor) and into those operations, which are used by data consumers (clients). In contrast to other OGC service, the SAS does not only use the HTTP protocol. Some operations like the GetCapabilities operation use the HTTP protocol, but other operations like the subscribe operation use in addition the Extensible Messaging and Presence Protocol (XMPP) protocol.

Sensor interface

Advertise

The Advertise operation allows producers to inform the SAS about the type of information it will send to the SAS (publish). The SAS returns a Multi-UserChat room (MUC) using HTTP. The sensor will then register itself with this MUC to be able to publish data. This registration is in fact (that means in the terminology of the XMPP protocol) a subscription to the MUC and uses XMPP.

The advertisement contains the following information:

  • feature of interest
  • operation are
  • alert message structure

Example for an advertise request: 

  <?xml version="1.0" encoding="UTF-8"?>
  <Advertise xmlns="http://www.opengis.net/sas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" xmlns:swe="http://www.opengis.net/swe" 
  service="SAS" version="1.0.0">
     <FeatureOfInterest>
        <Name>52N</Name>
        <Description>The temperature is measured by a sensor which is mounted at a weather station located at 52N
        </Description>
     </FeatureOfInterest>
     <OperationArea>
        <swe:GeoLocation>
           <swe:longitude>
              <swe:Quantity>51.96</swe:Quantity>
           </swe:longitude>
           <swe:latitude>
              <swe:Quantity>7.607</swe:Quantity>
           </swe:latitude>
           <swe:altitude>
              <swe:Quantity>78</swe:Quantity>
           </swe:altitude>
        </swe:GeoLocation>
     </OperationArea>
     <AlertMessageStructure>
        <QuantityProperty>
           <Content definition="urn:ogc:temperature" uom="Cel" min="0" max="40"/>
        </QuantityProperty>
     </AlertMessageStructure>
     <AlertFrequency>0.1</AlertFrequency>
     <DesiredPublicationExpiration>2009-10-15T00:00:00Z</DesiredPublicationExpiration>
  </Advertise>

The advertise response comprises of the

  • subscription endpoint (MUC)
  • time until the option to publish will expire (advertisement time)
  • publication id

An example of a AdvertiseRespones looks like follows: 

  <?xml version="1.0" encoding="UTF-8"?>
  <AdvertiseResponse xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" expires="2007-01-01T00:00:00Z">
     <PublicationID>Pub161079</PublicationID>
     <XMPPURI>xmpp://52North.org/sas/publications/c301</XMPPURI>
  </AdvertiseResponse>

CancelAdvertisement

This operation allows producers to cancel an advertisement. Therefore the producer will send an CancelAdvertisement request using HTTP.

RenewAdvertisement

This operation allows producers to renew an advertisement. This operation is used by data producers if the advertisement time that was set by the SAS has expired.

Example of a RenewAdvertisement request: 

  <?xml version="1.0" encoding="UTF-8"?>
  <RenewAdvertisement xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" service="SAS" version="1.0.0">
     <PublicationID>Pub161079</PublicationID>
     <DesiredPublicationExpiration>2009-10-30T00:00:00Z</DesiredPublicationExpiration>
  </RenewAdvertisement>

Example of the response to the above listed RenewAdvertisement request: 

  <?xml version="1.0" encoding="UTF-8"?>
  <RenewAdvertisementResponse xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" expires="2007-06-01T00:00:00Z">
     <PublicationID>Pub161079</PublicationID>
     <renewalStatus>confirmed</renewalStatus>
  </RenewAdvertisementResponse>

Client interface

GetCapabilities

The GetCapabilities operation allows a client to request and receive bac service metadata describing the SAS instance. The structure and syntax follows the specification from OWS Common. This operation uses the HTTP protocol.

Example of a GetCapabilities request: 

  <?xml version="1.0" encoding="UTF-8"?>
  <GetCapabilities xmlns="http://www.opengis.net/sas" 
  xmlns:ows="http://www.opengeospatial.net/ows" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" service="SAS">
     <ows:Sections>
        <ows:Section>Contents</ows:Section>
     </ows:Sections>
  </GetCapabilities>

response for the GetCapabilities request listed above: 

  <?xml version="1.0" encoding="UTF-8"?>
  <Capabilities xmlns="http://www.opengis.net/sas" xmlns:swe="http://www.opengis.net/swe" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" version="1.0.0">
     <Contents>
        <AcceptAdvertisements>true</AcceptAdvertisements>
        <SubscriptionOfferingList>
           <SubscriptionOffering>
              <SubscriptionOfferingID>1</SubscriptionOfferingID>
              <AlertMessageStructure>
                 <QuantityProperty>
                    <Content definition="urn:ogc:temperature" uom="Cel" min="-10.0" max="40"/>
                 </QuantityProperty>
              </AlertMessageStructure>
              <FeatureOfInterest>
                 <Name>52N</Name>
                 <Description>The temperature is measured by a sensor which is mounted at a weather station located at 52N
                </Description>
              </FeatureOfInterest>
              <OperationArea>
                 <swe:GeoLocation>
                    <swe:longitude>
                       <swe:Quantity>51.96</swe:Quantity>
                    </swe:longitude>
                    <swe:latitude>
                       <swe:Quantity>7.607</swe:Quantity>
                    </swe:latitude>
                    <swe:altitude>
                       <swe:Quantity>78</swe:Quantity>
                    </swe:altitude>
                 </swe:GeoLocation>
              </OperationArea>
              <AlertFrequency>0.1</AlertFrequency>
           </SubscriptionOffering>
        </SubscriptionOfferingList>
     </Contents>
  </Capabilities>

Subscribe

This operation allows consumers to subscribe to alerts. Therefore the client sends a subscribe request including a SubscriptionOfferingID using HTTP to the SAS. The SAS checks the subscription condition and returns a corresponding MUC as well as the time at which this subscription will automatically terminate. The client has to subscribe to the MUC via XMPP in order to receive alerts.

The SAS supports the following filter capabilities:

  • spatial filtering:
    • at a location
    • In an area (bounding box)
  • By subscription offering ID
  • By feature ID
  • Content filter:
    • Smaller than
    • Greater than
    • Equals
    • Not equal to

Example for a Subscribe request: 

  <?xml version="1.0" encoding="UTF-8"?>
  <Subscribe xmlns="http://www.opengis.net/sas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" service="SAS" version="1.0.0">
     <ResultFilter ObservedPropertyDefinition="urn:ogc:temperature" uom="Cel">
        <isLowerThan>0.5</isLowerThan>
     </ResultFilter>
     <FeatureOfInterestName>52N</FeatureOfInterestName>
  </Subscribe>

Example for a Subsribe response: 

  <?xml version="1.0" encoding="UTF-8"?>
  <SubscribeResponse xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" SubscriptionID="Sub300389" 
  expires="2009-11-11T11:11:11Z">
     <XMPPResponse>
        <XMPPURI>xmpp://52North.org/sas/publications/c1</XMPPURI>
     </XMPPResponse>
  </SubscribeRespoinse>


An alert send for this subscription might look like this: 

  <?xml version="1.0" encoding="UTF-8"?>
  <SASAlert xmlns="http://www.opengis.net/sas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <Header>
        <AlertMessageStructure>
          <sas:QuantityProperty>
             <sas:Content definition="urn:ogc:def:property:OGC:Temperature" uom="Cel">-0.9</sas:Content>
          </sas:QuantityProperty>
        </AlertMessageStructure>
     </Header>
     <Body>51.96 7.607 70.0 2009-10-17T02:27:04Z 0 30</Body>
  </SASAlert>

CancelSubsription

This operation allows consumers to cancel a subscription. Therefore the producer will send an CancelSubsription request using HTTP. An example for the CancelSubsription request looks like follows: 

  <?xml version="1.0" encoding="UTF-8"?>
  <CancelSubscription xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" service="SAS" version="1.0.0">
     <SubscriptionID>Sub300389</SubscriptionID>
  </CancelSubscription>

Example for a CancelSubsription response: 

  <?xml version="1.0" encoding="UTF-8"?>
  <CancelSubscriptionResponse xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd">
     <SubscriptionID>Sub300389</SubscriptionID>
     <Status>OK</Status>
  </CancelSubscriptionResponse>

RenewSubscription

This operation allows consumers to renew a subscription that has expired. Therefore the producer will send an RenewSubscription request using HTTP. An example for the RenewSubscription request: 

  <?xml version="1.0" encoding="UTF-8"?>
  <RenewSubscription xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" service="SAS" version="1.0.0">
     <SubscriptionID>Sub300389</SubscriptionID>
  </RenewSubscription>

Example for a RenewSubscriptionResponse: 

  <?xml version="1.0" encoding="UTF-8"?>
  <RenewSubscriptionResponse xmlns="http://www.opengis.net/sas" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sas ../sasAll.xsd" expires="2007-06-01T00:00:00Z">
     <SubscriptionID>Sub300389</SubscriptionID>
     <Status>OK</Status>
  </RenewSubscriptionResponse>

Concept of Operation

Data Producer Perspective

In a first step the data producer invokes the GetCapabilities operation in order to get service level metadata. Especially, the SAS declares whether it accepts new advertisements or not. In the case that the SAS accepts new advertisements the data producer will use the Advertise operation to inform the SAS about the type of information it will send to the SAS. The SAS returns a MUC using the HTTP protocol. After the data producer has registered with the MUC, it is able to publish observations.

Every time the advertisement time expires the data producer has to renew the advertisement by calling the RenewAdvertisement operation. In the case the data producer shuts down the sensor, he will send a CancelAdvertisement request to inform the SAS that no further observations will be published.

Consumer Perspective

A sensor data consumer is interested in retrieving observation data from a SAS instances. The consumer then performs service-level discovery on the SAS instance by means of the GetCapabilities operation. The consumer chooses a certain SubscriptionOffering and defines by means of the Subscribe operation the subscription condition (e.g. send me an alert if waterlevel greater 200cm). The SAS returns the subscription endpoint (MUC). In the next step the consumer will register with the received MUC in order to get alerts. If the sensor has published observations that meet the subscription condition, the SAS will publish the alerts in the MUC to which the consumer has subscribed. The data consumer has to renew his subscription before the subscription time has expired. If the data consumer is not interested any more in receiving alerts, he can cancel the subscription by means of the CancelSubscription operation.

Outlook on future developments

The SAS was the first step towards a OGC service providing an event-based access to sensor data. The shortcomings of the SAS are the limited filtering capabilities. The specification defines only the following filters:

  • isSmallerThan
  • isGreaterThan
  • equals
  • isNotEqualTo

The SAS does not support complex filters build up using logical operators.

The OGC SWE working group is working on a new service, the so called Sensor Event Service (SES) that is dedicated to filtering streams of incoming observations based upon user defined filter criteria. The SES is published as OGC Discussion paper.

The SES specification defines three different filter levels. Level one filters act upon the syntactical level of sensor data whereas level two and three filters act upon the information contained in sensor data:

  • level 1 filters (mandatory) use XPath statements to define the filter. These filters are based on the syntax of the incoming observations and allow defining filters to receive only data from certain phenomenon or sensor.
  • level 2 filters (optional) use the Event Pattern Markup Language (EML) for the definition of filters, which allow for the combination of logical, spatial, temporal, arithmetic, and comparison operators. Unit of measurement conversion may also be performed.
  • level 3 filters (optional) are also based on EML, but in contrast to level 1 and level 2 filtering level 3 filters can handle queries on data streams. Thus, they may operate not only on one incoming notification at a time but rather on the whole cloud of events that arrive at the SES.

The following table provides a comparison of the SAS' and SES' filter capabilities:

functionality SAS SES
spatial filters partly supported supported
temporal filters not supported supported
comparison filters partly supported supported
aggregation not supported supported
topics not supported supported
unit conversion not supported supported
complex event processing not supported supported
event stream processing not supported supported
← previous 5 Sensor Web Enablement next →
Retrieved from "http://geostandards.geonovum.nl/index.php/5.4.3_Sensor_Alert_Service"
Personal tools