Prototyping peer-to-peer applications for the industrial Internet of things
Programming peer-to-peer (machine-to-machine) architecture is challenging for the broad application space of the industrial Internet of things. A unified programming environment provides an intuitive method for publishing and subscribing to data of interest over the network.
The industrial Internet of things, IIoT, is a very broad application space. The envisioned applications can be divided into three main architectures: A client/server architecture where a human, acting through a device (such as a mobile phone), interacts with the Internet, a machine-to-machine (M2M) client/server architecture where remote devices feed data to enterprise systems for analysis and decision support (such as a vehicle tracking system), and a peer-to-peer (machines-to-machines) architecture where the devices autonomously cooperate and make local decisions (only on exception or periodically connecting to an enterprise system to post alarms or significant data). These peer-to-peer applications often perform local control of a machine or process in response to local data. This programmatically challenging class of applications can be difficult to prototype.
The various protocols that make up the suite of Internet protocols are well suited to the client/server architectures, as nearly all Internet traffic today follows this architectural model. An area of our interest ,  is applying a peer-to-peer architecture and its required services above the UDP transport layer of the Internet Protocol (IP). The Python environment has an easy and intuitive method for expressing distributed functions that publish data and subscribe to data of interest over the network. The environment hides the aspect of communication from the application-making the peer-to-peer, distributed nature of the application implicit. The application program only needs be concerned with the data it manipulates-much as a noncommunicating application. Diverse applications that are compliant to this architecture can be prototyped in very little time.
I. Python environment
A simple library of classes turns a Python script into an IIoT device, and elevates a locally operating control application to a networked, IP-based solution. The library is designed for ease of use, centered on a single, main class. This application class and its subclasses are generally self-provisioning by computing useful default settings at initialization time. Application programming interfaces (APIs) are available to fine-tune the provisioning parameters to meet a specific application's demands where necessary. The design cycle is Python-centric and does not generally require any other expert tool. Information between the nodes on the network is exchanged via a publisher/subscriber data model where the unit of exchange is a datapoint. Datapoints are values with semantics. (See more details below.)
The Python script defines datapoints to interface to the network: Input datapoints obtain data received from the network, such as a temperature setpoint. Output datapoints communicate data to the network, such as the current thermostat position. Input and output datapoints implement datapoint types, supporting different physical or abstract data, such as temperature values or alarm conditions.
Additional provisioning data is provided with properties. A property is implemented as an input datapoint with persistent value storage. Properties expand on simple datapoints to include specific semantics: the upper alarm temperature threshold, the temperature alarm hysteresis, or similar descriptions.
Input and output datapoints and properties are generally grouped into profiles. Profiles are a collection of datapoints that form the network visible interface for a service, combined with well-defined behavior. In the example discussed, the service is a carbon dioxide sensor. The role of the service is to publish the amount of carbon dioxide present in the air. The frequency of this publication is determined by the properties embedded within the profile. The Python library allows implementation of a complete profile, including all related datapoints and properties, through a block object within one simple line of code:
Definitions of datapoint, property and profile can support and promote solutions featuring devices supplied by multiple vendors. Building on existing standards  and a rich collection of type and profile definitions , compatible devices can recognize each other and exchange data across different suppliers or hardware solutions.
II. A generic data model
Peer-to-peer control networks must handle data that arrives in a nondeterministic schedule, representing a diversity of physical, logical, or abstract entities. For example, one data item might represent a temperature value in Celsius, encoded in an IEEE 754 double-precision floating point value in big-endian byte order. Another data item might represent the number of beans in a bag using a natural number ranging 0 to 999, encoded in an unsigned 16-bit little-endian scalar, while other data might represent the complex definition of a lighting scene through a suitable structure of data, or a postal address in human-readable alphanumeric form using an UTF-16 unicode.
Within data representing a known entity, such as a temperature value, and using a known encoding, such as an IEEE 754 double-precision floating point value in big-endian format, control networks must also recognize semantics: a room temperature setpoint might have a valid value range between 15 and 28 Celsius, and is applied to a control algorithm that drives a thermostatic radiator valve, while another temperature value, encoded in the same manner, might represent a fire detector's hysteresis, or define the lower valid value for the room temperature setpoint.
Data must then be conditioned such that the local application can operate with the data. For example, the application may need to rotate the byte order of the 8-byte floating point value upon receipt and interpret the result as a double float value.
When the algorithm produces output data, this data also may need conditioning. For example, a current temperature value might be reported. This might be exchanged over the network as a big-endian 16-bit unsigned integer value, implementing a fixed-point variable ranging from 0 to 655.35 with a resolution of 0.01 C. This programming model conditions this data such that the application is presented with data in its natural form; a floating-point value in this example. Range and resolution limitations are automatically applied by this model, and transcoding between the application presentation and the network presentation of this data is handled transparently.
Peers in the control network must agree on the entity described by each data item, its encoding, and its semantics. Additional aspects (such as explicit range limitations, well-defined default values, or fallback behavior in the event of a fault) are also commonly agreed upon between peers.
To reach such an agreement, peers in a control network either carry all metadata required to enable receivers to fully understand any data they might encounter, or ensure that data only reaches receivers with a previously established contract and level of trust.
This poses a significant difficulty to the device developer and the person integrating multiple control devices into one distributed, peer-to-peer control network. The device developer generally needs in-depth knowledge in the processes, protocols, and procedures involved to write code that correctly conditions output data, and correctly identifies, classifies, and interprets incoming data. The person integrating multiple devices into one such network needs to understand each device's attributes and capabilities to combine only those devices that "speak the same language." For example, a generic switch may be able to control a generic lamp, but an industrial washing machine may require a more complex "on/off" signal than what the generic switch can provide.
This programming model includes methods and services that automatically evaluate and apply metadata to data interpretation and data conditioning processes, interfacing the application with appropriately conditioned data only. These methods greatly improve on existing technology by providing a transparent comprehensive data conditioning service.
Figure 1 illustrates the data conditioning services and network data flow provided by this programming model.
III. Data addressing
A peer-to-peer network consists of a number of independently operating devices, generally sharing data on a need-to-know basis. For example, a thermostatic radiator valve may need to receive the current room temperature setpoint from some other device. The same thermostatic radiator may not need to know when or why the setpoint changed, and it will not normally need to know about any control operation on the ceiling lights or the garden sprinkler.
That is, a new temperature setpoint value might be communicated from an input device to all thermostatic radiator valves in the same room. At the same time, other rooms' thermostatic radiator valves may receive other setpoint values from other sources, while the garden sprinkler is controlled as a logically separate unit on the same network.
To facilitate peer-to-peer communication in this manner, devices transmitting data (data publishers) need to know how to reach the applicable targets (data subscribers), and may need to know whether and how to accept or reject incoming data. This mutual knowledge includes knowledge of source and/or destination addresses, information to select the correct datapoint from multiple datapoints defined on the receiver node, routing details, and transport properties (such as service types, the time allowed to detect an outage or enable retransmission, and similar control data).
This programming model includes abstract services to facilitate contract offers and acceptances in the terms of the application script, concealing the required low-level details within the implementation of this model. This simplifies development of distributed control applications. By supporting intrinsic contract management services, this programming model also greatly reduces the need for, and in many cases eliminates the need for, dedicated integration steps when forming a network from distributed applications.
Figure 2 shows a simple control network featuring four distinct devices, each contributing one application. The figure illustrates the set of low-level addressing details required to establish and maintain such a contract, and the realm of application expertise.
- Events & Awards
- Magazine Archives
- Digital Reports
- Global SI Database
- Oil & Gas Engineering
- Survey Prize Winners