[Manageable Affordances TF] Actions in Automation Systems

Lifecycle of actions in automation systems

Submitter(s):

Ganesh Ramanathan (Siemens AG)

Motivation:

In controls engineering theory (and in its practical application) , actions are distinguished as 1. delegation of control, 2. actuation (also known as "commands"), and 3. causing a change in the physical process. As an example, consider the distinction between "increase heat output to 100kW", "open fuel valve", and "increase combustion rate". For dynamic systems, actions cannot be considered to take effect instantaneously (i.e., are not events causing instantaneous transition in states) and consequently monitoring its progress is often essential. Such a monitoring may be required for either ensuring safety (i.e., the expected dynamics is followed) or for synchronization at supervisory control level. The monitoring agent would also be interested in one or more of the three perspectives and therefore the description of an action needs to convey this semantics of what the action denotes: is it the successful delegation of a control function ("increase output", "dim the lamp"), or is it the completion of a physical actuation ("fuel feed started", "increased the power to the lamp"), or is it achievement of the physical effect ("heat generated", "light output increased"). Therefore, 1. action affordances should be linked to models describing the dynamics of the underlying control, actuation, and physics, 2. an agent that has invoked or intends to invoke an action should have means to track current state of controls, actuation, and physical variables related (or affected) by the action., and finally 3. it should be possible to express the concurrency control requirements (e.g., parallel operation or wait conditions - e.g. what happens when "dim to 10% in 5 min" follows "dim to 30% in 3 min", or dimming will start only when input power meets a certain limit)

actions

Expected Participating Entities:

Automation agents which are responsible for system-level coordination, local or component-level control, sensing and actuating agents, and programs that can simulate the physical process.

Workflow:

Agents responsible for coordination of functions, invoke actions on the control agents, which in turn, use the sensors and actuators. The coordination and the control agents can both use the simulation agent to know about the process trajectory (and the dynamics). participants

Related Use Cases (if any):

OPC UA allows for creation of function description which can be linked to properties that represent the progress of a function call. In BACnet, a command object can be used for a similar purpose. In both cases, the semantics of the underlying controls, actuation and physics is abstracted away. For example, though the progress of a command can be monitored, modified, and canceled if required, the implication is not conveyed (what happens on cancellation? does the process return to initial state? is the progress solely uni-dimensional? etc.)

Existing solutions:

In an early implementation of WoT -based building automation controller, we created "ephemeral" Things which represented the control, actuation, or physical process (note: actuators being usually elector-mechanical devices, are also a physical process in a way -- for example, the positioning motor and associated gears of valve take a certain time to open the valve plunger). On invoking a TD action, the caller was returned a link to the "ephemeral" Thing which has property affordances to monitor the process progress and actions to modify the course. Pre- and Post-conditions (through proprietary extension of the TD ontology) were added as metadata of an action. Additionally, "reading" an action (e.g. GET on an action) would return the link to an ephemeral thing if an action completion is pending.

The following snippet of such a TD illustrates the extensions to the TD:Action which helps the caller understand the lifecycle of the action: (Note: the snippet below is a pseudo respresentation of the real TD -- this is to ease the understanding of the extensions):

  "baont:hasModel": "hvac:HotWaterBoiler",
  "actions": {
    "Generate": {
      "title": "Start Heat Production",
      "@type": "hvac:Action_DemandEnergy",
      "baont:actionModel": "baont:Asynchronous",
      "fsmont:hasStateMachine": "hvac:FSM_BoilerController",
      "fsmont:transitionAction": "hvac:onDemandSignal",
      "baont:hasPrecondition": "this.flow > 10 and airdamper.open",
      "baont:hasPostcondition": "(combustionActive and outletTemperature > history(this.outletTemperature, 600)) or Failure",
      "forms": [
        {
          "op": [
            "invokeaction"
          ],
          "href": "/generate"
        }
      ]
    }
  },

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.

w3c-cg / webagents