Thing categories

To build IoT applications, you first need to understand how different "things" interact with software. When we talk about "things", they include sensors, actuators, devices and machines. We can collectively call them "devices", and in general, they interact in two ways:

Interaction Patterns

Request-Response

You expect the device to respond to your software only if you send it a request.  For every request you send, your software expects, and will be waiting for a response from that device coming back through the same communication channel. As a result, a "request-response" communication is "blocking" in that the same communication channel will not be available for any other communications.

ThingFacets and Actions:

ThingFacets that interact with such devices often have a mechanism to invoke a process to send the request to the device. This mechanism is called a "workflow" in TQL, which contains a set of tasks and are are defined in TDL within the Action part of the ThingFacet.

The runtime of the "workflow" is called a workflow instance. When the workflow instance's task is activated and sends the request to the device, the workflow instance will be in waiting mode until the response comes back from the communication channel. Once the workflow instance receives and processes the message, this instance is completed and removed, and a new copy (new instance) of the workflow is created, waiting to be activated. See workflow lifecycle.

In request-response type of ThingFacet interactions, the control of new workflow instance activation is given to the application, that is, every single request can only be triggered by a change from the application (in the ThingFacet attribute, i.e. actionable attribute).

In request-response type of ThingFacet interaction, it is important to have time outs for the workflows, which can be defined by the "Timeout" modifier.

Note that the lower level process that handles device interaction is often abstracted into a protocol handler and invoked from a workflow.

Asynchronous Interaction

Most of such devices send data intermittently without requests. The format of the data is predefined by the device. Your software will be receiving, or "listening" to the messages at time intervals/frequencies or points in time not control by your software itself. Asynchronous communication is "non-blocking" in that the communication channel will not be in the waiting mode for any subsequent messages. Most of the simple sensors are asynchronous-send devices.

Asynchronous send-and-receive: occasionally, there are devices that not only send data, but also can receive data asynchronously. the RFID reader & writer is an example. 

ThingFacets and Actions:

ThingFacets that interact with such devices often have a mechanism to always keep a process live, which continues to "listen" to the device. This is because the software does not know when the device will send a message. This mechanism is also defined by a "workflow", which contains a set of tasks and are defined in TDL within the Action part of the ThingFacet.

When a workflow instance's task is initially activated (initialized), the process will be listening but no communication channel will be used until the device sends a message. Once the message is transmitted, the communication channel will be freed. After the message is received and processed, this instance of the workflow is completed and removed, and a new copy (new instance) of the workflow is created, waiting to be activated. See workflow lifecycle.

However, in such asynchronous interaction, the next workflow instance cannot be activated from the application. This is because it will not be able to anticipate when the device will send a next message. Instead, the workflow needs to continue to activate its next instances every time an old one is completed. This is the role of the update="auto" modifier of the actionable attribute. This automation ensures that at any time, there is always a live workflow instance listening for the message coming from the device.

How things are built

By looking into today’s state of the hardware, electronics and software combination, things can also be put into three categories

Sensors and Actuators (Field Devices) - These devices are mostly analog and when digital, function remains singleton. Electronics is simple circuit to  actuate the function. Controllers are used to create a system of multiple field devices. i.e Temperature Sensor, Linear Actuator, etc.

To connect Sensors and Actuators to Application tier, Micro Controller Units (MCU) are used. MCU's connect on serial protocols (mostly) with computers (mostly gateways) where A-Stack runs.

Devices - These hardware have electronics and software inside the device. Device has fixed set of functions, which are exposed through messaging structures over serial or IP based communication protocols. Device maintains its logic internally by having a dedicated controller. i.e. Automatic sprinkler controller, Nest Thermostat, etc.

Devices can be connected directly to A-Stack (running on the gateway or through gateway running on the server).

Machines - are high end devices, which provide set of applications to interact with the devices in the machine. These applications are rich way to interact with machine. i.e. CTScanner, gas turbine, etc.

Machines are conversed with A-Stack through IP based protocols in general.

There are following message styles used in the things world