Event Detection from Observation Data

Task: Event Detection from Observation Data

 

Aim: Detect relevant situations in time-series of sensor observations provided in near real-time.

Prerequisites:

  • Access to a Sensor Observation Service (SOS) that provides observations in near real-time
  • Domain ontology or vocabulary suitable for a scenario, e.g. http://purl.org/ifgi/water/flood for flood monitoring
  • Event Processing Service (EPS) deployed in a server and running (WSDL of prototype service available here)
  • Client able to send HTTP or SOAP requests, e.g. Eclipse’s Web Service Explorer

Brief Description:

The purpose of the EPS consists in analysing time-series of observations and creating event instances when relevant situations are detected. The meaning of the term relevant here is highly dependent on the domain and application. In the context of flood monitoring, a relevant situation could be the water level of a river increasing above the allowed threshold.

First step consists in assuring that our domain ontology contains a representation of the event type we want to detect. The ontology used for this example is available online [1]. The figure below contains a concept map with some event types that can be found in there:
The definition of an event pattern describing a high water level situation requires domain knowledge. We used a language called Event Pattern Language (EPL) [2]. This is an example that we use for the project of a high water level event in a specific location of the Danube River:

SELECT obs1, obs2
FROM pattern [every (obs1 = SOSObservationEvent( observer.id = 'sensorAtPointX',
observedProperty = 'urn:ogc:def:phenomenon:OGC:1.0.30:waterflow',
value < 20500) ->
obs2 = SOSObservationEvent( observer.id = 'sensorAtPointX',
observedProperty = 'urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel',
value > 41))]
WHERE obs2.time.between(obs1.time, obs1.time.plus(23 hours 59 min))

We expect first a discharge observation (obs1) above 20.500 m3/s. If this happens, then we look for a water level observation (obs2) which follows in time (that is the meaning of the arrow ‘->’) the discharge observation and which is above 41 meters above the Adriatic Sea. Normally, discharge observations are updated once a day that is the reason why domain experts suggested considering periods of 24 hours (see WHERE clause). This pattern can be annotated with the event type http://purl.org/ifgi/water/flood#HighWaterLevel and registered to the EPS using the registerStatement call

registerStatement(String eventPattern, String eventType)

Last step is to connect the data source to the EPS so that time-series of observations are pushed to the event processing engine. This can be done via the registerService method. For the event pattern we defined above, we need to register a data stream for water flow and another for water level measurements. The parameters we have to fill to register a service are: service URL, service offering [3], property being measured, and interval to request data, i.e. time unit (seconds, minutes, hours, etc.) and number of time units.

registerService(String serviceURL, String offering, String observedProperty, String timeUnit, String numberOfTimeUnits)

When an event is detected, the EPS publishes and RDF/XML event instance to an event bus. Different applications can listen to the bus and consume the events, e.g. the Event Visualizer.

 Concrete example:

A concrete example on how to register an event pattern and schedule sensor data requests with the EPS can be found in sections 5.2 and 5.3 of D4.7.

 


[1]The flood monitoring domain ontology is available athttp://purl.org/ifgi/water/flood.
[3]The available service offerings and observed properties can be found in the service capabilities.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>