Device Gateway

As it was mentioned already in the General architecture, the DGW represents the so-called Device Integration Layer in the IoT terminology. It is used as a gateway between the low-level hardware access protocol and a TCP/IP network.

The main goals when designing DGW were:

• Pluggable devices support
• No modification/re-compilation/re-deployment of the DGW for a new device
• Exposure of device capabilities as network services by declaration/configuration

As a result, we came up with a concept of device agent, as depicted in the Figure below. A device agent is an executable (preferably platform independent, but in most cases they are dependent due to the different libraries for accessing the hardware), which implements the low-level communication with the actual device using its interface and protocol (e.g., talking via GPIO to temperature sensor, reading data via USB or detecting beacons via BLE). This is the left side of the communication in the Figure. The right side of it describes how the device agent communicates with a DGW that manages its execution: it is done using the most universal and ubiquitous interface - standard system input and output streams (stdin, stdout correspondingly). The standard system error stream (stderr) is used for logging purposes (data written into stderr will be forwarded to DGW for output in the debug console).

The device agent executable is not aware about Patchwork Toolkit and its interfaces. It is a standalone program that can be executed manually from a command line. In the DGW context, this program is executed and managed by the DGW's Process Manager, as depicted in the Figure below (a hight-level overview of the DGW architecture):

The core of the system is a Process Manager that reads devices/resources configuration and executes corresponding device agents and redirects the system streams (stdin/stdout/stderr). Process Manager supports 3 types of agent execution: task, timer and service.

• task execution means the device agent is executed only once per request coming from Services component. The last value is cached for a given TTL period.
• timer execution is similar to task execution but initiated by Process Manager periodically (using interval value from the configuration). The value is cached in between the executions.
• service execution means a device agent is running as a process and producing output into stdout constantly. The last value is cached as well.

The Services component is responsible for creating a corresponding RESTful endpoint for each device/resource (if configured) and establishing a MQTT publication connection for each device/resource (if configured). This component passes data from POST/PUT/DELETE HTTP requests to the corresponding device agent by writing it to its stdin and returning the (cached) value received from stdout to the related HTTP GET requests.