[Manageable Affordances TF] Events in Automation Systems

[codepasta]

Events in Automation System: Beyond Notifications

Submitter(s):

Ganesh Ramanathan (Siemens AG)

Motivation:

Traditionally, events are considered (at least in the IoT community) as asynchronous notifications of perhaps some interesting state changes which might be relevant for an observer. For example "lamp overheated" or "fuel level low" are modeled as events because transition to certain states are considered to be worthy of notification because they in some way exceptional (as compared to say "lamp switched on"). However, in automation of real-life electro-mechanical machinery, such exceptional events result in triggering of a workflow. The common term used for this "alarm or incident handling". For example, the failure of a pump results in an incident being "opened" or "active". The plant operator then needs to "acknowledge" this event (i.e., the human operator has taken notice). Further, the event may be "silenced" because some event kinds are designed to be repeated periodically. Finally, when the underlying cause of the event has been fixed, it is "reset" or "released". These event handling states are important because they play a role in the control program (e.g., as long as an event is not released, the plant may stay is shutdown mode).
Additionally the control system programmer can define steps that the agent receiving the events should/can undertake.
In summary, events can spawn some sort of handling program in the control system which offers interactions ("silence", "release", "acknowledge", etc.).

Expected Participating Entities:

Events are raised by a control program and received by monitoring programs which may further notify human agents. There are also automated event handlers which can process the event workflow based on pre-defined rules (e.g. "on overheating event, shutdown the lamp, wait for 1 hour, and then restart").

Workflow:

The control program of the device raises the event and starts a handler process internally. It provides the interface description of the handler process to the event receiver so that further actions may be invoked on it.

Existing solutions:

Currently, in a proprietary implementation of WoT servient, we create a new TD to represent the event handler program in the controller. A client can also "read" the state of an event, in which case it is redirected to this temporary "event Thing".

Identified Requirements by the TF:

To be filled after submission. Examples of requirements include usage of specific communication protocols, media types, platforms, security and privacy mechanisms, or accesibility.

Comments: