SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 67 of 233
Figure 6-4 illustrates the different verbosity levels for different phenomena.
Figure 6-4: Event generation verbosity levels of type binary upper row and nominal lower row
Figure 6-4 illustrates the two extremes of binary and nominal scales. Other scales, such as ordinal or interval, work analogously.
The upper row illustrates events generated by an intrusion detection system. This binary system knows only two stati, i.e. “intrusion detected” or “no intrusion detected”. The lower
row represents a temperature sensor. The y-axis represents the temperature value and is of type nominal scale. The sampling rate of both systems is identical. In both rows, the x-axis
represents time, the y-axis observed values. The bold black line represents the current value. The sampling rate is indicated with vertical black lines. Generated events are labelled with a
red “E” above the sampling lines. We see that the number of generated events is considerably higher for the temperature observation system than for the intrusion detection system, because
the temperature may change its value above or below the threshold, whereas the intrusion detection system only knows two statuses.
6.4.2.5 Form of Events
Complex Event Processing, or CEP, is one of the major concepts of event processing. It deals with the task of processing multiple events with the goal of identifying the meaningful events
within event clouds.
One of the key aspects of Complex Event Processing applications is the aggregation of event objects and the derivation of new information, reified as new events or event objects,
respectively. SensorSA adopts to a large extent the concept developed by Luckham and Schulte 2008. According to them, an event, which is neither an abstraction nor a
composition of other events, is a Simple Event. Whenever an event is an abstraction of other events, it is called a Complex Event see also the specification of the vent information model
in section 7.5. Complex events can but do not have to list the member events of which they
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 68 of 233
provide an abstraction. Furthermore, whenever an event is generated as a result of applying a well-defined procedure to one or more other events, we refer to a Derived Event.
The verbosity of events is an essential criterion in event messaging systems. It is the information model that defines the power of notification messages, i.e. which amount of
information a notification may provide. In some cases a notification may only indicate that something of interest has happened, but no details - then clients would have to pull the
additional information from a service; in other cases the notification itself might already contain all relevant information so that no additional service-request is needed.
6.4.2.6 Roles in Event Relationships
Events may have relationships to other features and thus also to other events. The specific relationships between events are domain dependent. However, some roles serve a general
purpose and are thus defined in SensorSA. We can identify relationship roles for related events in general see Table 6-1 and for events that are members of a complex event see
Table 6-2.
Role Identifier Meaning
supersedes The target event is superseded by the source event. This means that the target
event is deprecated. revokes
The target feature is revoked which means that the target event object should be considered as not having been issued.
caused The source event caused the instantiation of the target event. More specifically,
the source event is one of the reasons why the target event was instantiated.
Table 6-1: Roles implemented by a related event
Role Identifier Meaning
causedBy The source event was caused by the target event. More specifically, the target
event is one of the reasons why the source event was instantiated.
Table 6-2: Member Event - defined values of the role property in an EventEventRelationship
Superseding an event object with another is the preferred way to implement changes applied to an event object. Let us explain this in more detail. Any modification of an event
object can always be critical for other applications. When transmitting an encoded representation of an event object to other systems, what they get is only a snapshot if the
event object has modifiable dynamic properties. Computations that are based upon this snapshot will need to be repeated when a change to an event object is made later on. In the
worst case this would lead to a rollback of the whole computation, possibly involving a rollback on other systems as well. This situation is unavoidable and applies to all systems that
base their computations upon given information. At least we can make it easier for event processing systems to detect a change of a previously received event object by implementing
such a change in a new event object that has a relationship to the original event with the role supersedes
. If it is recognized that an event was wrongly detected, initialized and distributed or the
event object released on mistake, then this happening of recognizing the failure can be
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 69 of 233
represented by a new event and an event object be distributed which relates to the wrong event, which shall be revoked.
How an application reacts when receiving an event that either supersedes or revokes is up to the application and not defined here.
Whenever an event is detected based upon the information contained in other events then there exists a causal relationship between the detected event and the base events. A base
event caused the detected event maybe multiple other events. From the perspective of the detected event, it was causedBy one or more other events. The set of member events that
caused a complex event is sometimes referred to as the causal vector of that event.
6.4.3 Event-Driven Processing System
