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.


Figure 1 shows a network data flow and data conditioning services. Courtesy: Echelon Corp.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 [1], [2] 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:

co2Sensor= application.block(co2Sensor())

Definitions of datapoint, property and profile can support and promote solutions featuring devices supplied by multiple vendors. Building on existing standards [6] and a rich collection of type and profile definitions [7], 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

Figure 2: A simple control network shows low-level addressing details needed for contracts. Courtesy: Echelon Corp.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.

<< First < Previous 1 2 3 4 Next > Last >>

No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Big Data and IIoT value; Monitoring Big Data; Robotics safety standards and programming; Learning about PID
Motor specification guidelines; Understanding multivariable control; Improving a safety instrumented system; 2017 Engineers' Choice Award Winners
Selecting the best controller from several viewpoints; System integrator advice for the IIoT; TSN and real-time Ethernet; Questions to ask when selecting a VFD; Action items for an aging PLC/DCS
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.
Motion control advances and solutions can help with machine control, automated control on assembly lines, integration of robotics and automation, and machine safety.
This article collection contains several articles on the Industrial Internet of Things (IIoT) and how it is transforming manufacturing.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Big Data and bigger solutions; Tablet technologies; SCADA developments
SCADA at the junction, Managing risk through maintenance, Moving at the speed of data
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Jose S. Vasquez, Jr.
Fire & Life Safety Engineer; Technip USA Inc.
click me