While most of the building blocks necessary to build a viable Industrial Internet of Things (IIoT) with the features described in Part 1 are widely available, pulling all the elements together will be a challenge even for experienced embedded developers .
To simplify the process, we have developed the IzoT stack (Figure 1 ), available as a free software download. It is a set of higher-level protocol services that can run on top of any IPv4 or IPv6 UDP socket interface and is designed to meet the communication needs of the peer-to-peer IIoT. When running on top of IPv4, the features of IPv6 such as stateless auto-configuration and neighbor discovery are not available. If possible, use IPv6 for its ease of installation.
Figure 1: IzoT features
A version of the IzoT stack runs on the Raspberry Pi platform and allows developers to prototype on the Pi using either the Ethernet or Wi-Fi interface for the communications.
Rapid detection of packet failures
The IzoT stack supports end-to-end acknowledgements and responses so that if a packet is lost in traversing the network across multiple links, the loss is discovered and the packet is retransmitted. This feature is available with both unicast and multicast services.
When using acknowledged multicast or request/response multicast services, retry messages are encoded with only the nodes that must respond. This limits congestion by informing the nodes whose responses or acknowledgements have already been received by the sender.
No single point of failure
The IzoT platform supports multiple PHYs that, if they fail, only the node connected to the PHY will fail. For example, twisted-pair PHYs are transformer-coupled, so if the drivers fail in a state where they are stuck high or low, it will have no effect on the other nodes on the link. The twisted-pair PHYs are true multi-drop so there are no single components that could fail and take down the link.
In the case where IzoT uses Ethernet, this level of reliability may be achieved with redundant switches. When using IEEE 802.15.4 or IEEE 802.11 b/g/n, the PHY protects itself from denial of service attacks via a process of white listing MAC IDs. When using Power Line communications, the interfaces may be transformer-coupled and a watchdog timer can protect a node from having the transmitter constantly energized.
In the IzoT network, the devices are all autonomous with no central controller dictating their actions. Fully distributed systems, such as the IzoT network, can survive multiple, individual node outages and still operate, or gracefully shut down with operator notification. A system consisting of clients and a server does not have this property, because when the server goes down, the entire system fails.
When an IzoT packet is sent, it is assigned a transaction ID number. Nodes that receive the packet create a record of the communications transaction based upon the source, destination, priority attribute, and transaction ID. At the time of initial creation of the record, a timer for the maximum time of the transaction is started. This timer is based on information encoded in the packet or provisioned in the receiver node.
If a subsequent packet is received that matches this record, that packet is detected as a duplicate, and the previously sent response gets re-sent. If a new packet arrives with a transaction ID greater than the currently active transaction, but matching in all the address and priority attributes, the receiver assumes that a new transaction has begun and re-initializes the receive timer.
A packet that arrives with a previously used transaction ID – a smaller value than the currently active transaction, but matching in the address and priority attributes – is considered stale and is discarded.
A sender of an IzoT packet can mark the packet as high priority. This can give it priority at the MAC layer if that feature is supported, and will also give it priority through any intervening routers to its destination. This allows emergency messages to be propagated through the network ahead of non-emergency messages in router queues.
Multiple simultaneous communications transactions
Nodes with more memory can use a version of the IzoT stack with the ability to support many outgoing transactions and correlate the responses. This is done by having a larger outgoing transaction record memory pool, and with some additional logic to correlate responses to the correct initial transaction.
Multiple link support per network
The IzoT stack has been proven on many different links: low-power wireless (IEEE 802.15.4)/ 6LoWPAN, Wi-Fi, Ethernet, multi-drop, free topology twisted-pair (ISO/IEC 149082), consumer band power line (ISO/IEC 14908-3), a new standard for power line communications (IEEE P1901.2), and can be ported to any MAC/PHY that supports a UDP socket. IzoT routers can seamlessly route packets between these links to create a network spanning multiple physical media.
There are many examples in IIoT market where support of multiple physical media on a single network is needed. For example, in a building the communications backbone is often Ethernet, while lighting may be wireless for the convenience of placing switches, and the HVAC system uses multi-drop twisted pair for speed and reliability.
Similarly, in a process control system, multiple battery-powered wireless sensors can be placed without regard for local power or hardwired network access to provide additional inputs to a high-speed, wired control system.
The IzoT stack supports NSA Suite B algorithms for public and private key cryptography. Specifically, the stack uses AES-GCM for symmetric key encryption and authentication with 128-bit keys. Elliptic Curve cryptography is used for public key encryption and authentication with key agreement using ECHD and authentication using ECDSA.
The IzoT stack can secure the application portion of the packets so that only the receiver, and not any intervening infrastructure, need have the credentials to decrypt and authenticate the packet. IzoT security is available for multicast communications transactions as well as unicast, making the use of security equivalent to the IzoT application whether a packet must be sent using unicast or multicast services.
FIPs 140-2 Level 1 Certification. Echelon’s new generation of the IzoT SoCs will be certified by NIST to FIPs 140-2 level 1, allowing developers to more easily incorporate state-of-the-art security into their networks.
IoT control services
The IzoT stack is fully implemented in all nodes with the exception of the multiple, simultaneous outgoing transactions feature. This feature consumes more memory and is not needed by nodes that are acting as peers on a network. It is available optionally and typically used for a supervisory nodes that must communicate rapidly with most or all other nodes on the network. With complete implementation, compatibility between the communications services in each node is ensured, leading to simpler integration of the network.
Scalability. Because the IzoT device stack (Figure 2 ) runs on top of the Internet Protocol, it inherits the scalability of IP. However, a key decision to base the stack on UDP rather than TCP reduces memory and communication bandwidth requirements, allowing more constrained nodes to work on slower, more error-prone links. This extra scalability allows system designers to optimize the solution so that IP can be economically extended to the simplest of control nodes.
Complete Multicast Support. Both confirmed and non-confirmed multicast is supported on the IzoT stack. This allows IzoT applications to work the same whether they are communicating to a single device or to many devices with a single message.
Peer-to-Peer Operation. In the classic Internet world, there are clients and servers. Servers tend to be larger, more capable nodes and can maintain state for thin clients. In a peer-to-peer network all devices are both clients and servers at the same time, and the relationship between clients and servers is many-to-many rather than one-to-one for a given communications operation.
IzoT supports peer-to-peer communications as well as client/server communications in a way that is transparent to the IzoT application. IzoT applications do not need modification to run in either mode.Tuning response time
The timers for retrying packets, theretry counts, and the time of the upper bound for a communicationstransaction consisting of the initial message and the receipt of allreplies to that message are all configurable. This configurabilityallows the timers to be tuned not only for the application needs, butalso for the network topology and bandwidth of the links that a messagemust traverse.
Node and application discovery
In theIIoT market, nodes will come from many suppliers. Integrating thesenodes onto a network will require that the capabilities as well as theaddresses of the nodes be discoverable over the network. The IzoT stacknatively supports probing the network to get not only node addresses butalso application interfaces, e.g., what data is published, what data anode may subscribe to, and what a node’s type is. For example: is a nodea switch? A temperature sensor? A supervisor controller? In this way,networks that embed the IzoT stack in each node may be created frommultiple suppliers.
File transfer and firmware upgrade. The IzoT stack may be upgraded over the network, so as the IoT marketevolves, nodes can be upgraded with new stack features. Because IzoT isbuilt on top of the Internet Protocol, support for large data transfersis supported.
Backward compatibility. The IzoTstack encodes a version number in every packet. This allows the protocolto evolve in a backward-compatible manner. Additionally, IzoT supportsmultiple adaptation layers that reside just above the MAC interface.This allows IzoT packets to be compressed and reformatted to fullyinteroperate with existing ISO/IEC 14908-1 networks. IzoT routers canthen seamlessly route IzoT packets and ISO/IEC 14908-1 packets on thenetwork.
In cases where the IzoT MAC and PHY selection is thesame as the MAC/PHY selection for the ISO/IEC 14908-1 nodes, both nodescan share the link and exchange application information transparently,even though the IzoT nodes are IP-compliant while the ISO/IEC 14908-1nodes are not.
Application-level interoperability. The IzoT stack uses and builds upon the Application Interoperabilitymodel developed by Echelon and the LONMARK Trade Association. Based upongroupings of standard data into functions, called Functional Profiles,nodes from many sources have been proven to integrate and work togetheras peers on a network.
RESTful API Support. IzoT server stacks (Figure 3 )support a RESTful API for easy integration with web-based userinterfaces running on PCs, tablets, and smart phones. This API allows anIzoT network and its data to be visualized, provisioned, and managedusing standard browsers.
Interoperable self-installation (ISI)
ISIenables IzoT devices to form a network without a network tool. Fullyintegrated with the IzoT Device Stack and enabled by default, ISIprovides three key services to an IzoT application and the peer-to-peercontrol network of IzoT devices.
- ISI enables devices to allocate a unique logical network address to themselves, and to maintain its uniqueness. Logical addresses support network segmentation and routing, are generally more efficient, and support transparent replacement of a physical device.
- ISI services related to logical device addresses are transparent to an application.
- ISI provides services that help applications establish connections between datapoint objects. These connections are key to a peer-to-peer control network.
Using ISI requires the use of assembly objects,enrollment objects, or related event handlers. Once a datapointconnection is established, ISI maintains this connection and therequired resources. These services are transparent to an application.
ISI'smodel of datapoint connection is simple: every datapoint involves oneor more applications, where each application contributes one or moreinput or output datapoints to the connection. Once established,connections can be deleted, individual participants of a connection mayleave, and new participants may join through a connection extension.
Connectionsare established and extended through an enrollment process. Atemperature sensor application can offer the temperature output value tothe network with the value izot.resources.datapoints.temperature. Otherapplications may subscribe to this data and join the connection.
Offeringdata connections and decisions about enrollment can be made fullyautomatically by an application, or might involve local input (forexample, through a push button).
Once enrollment data has beenexchanged and accepted, participating devices implement this enrollmentby creating the connections. An application needs to instruct the devicestack about the mapping between the enrollment and one or more input oroutput datapoints to be enrolled in the connection.
Applicationsthat initiate enrollment need to create one or more enrollment objects.Enrollment objects are used when initiating an enrollment process andare used to describe the data connection to other applications in thenetwork.
Putting IzoT to work: Creating an IzoT Python app
Thefollowing example python3 code defines an interface for an IzoT device,initializes the ISI engine with the appropriate values, and then startsthat device. The device in this example will automatically enrollitself.
Example: IzoT Code listing for lamp controller
from izot.examples.common.framework.framework import Framework
from izot.examples.common.framework.framework import FrameworkMenu
from izot.examples.common.framework.framework import ApplicationType
from izot.resources.profiles.iotKeypad import iotKeypad
from izot.resources.profiles.iotAnalogOutput import iotAnalogOutput
PROGRAM_ID = '9F:FF:FF:05:00:70:00:01' # Program Id for Keypad application
APP_NAME = 'keypad_example'
APP_DESCRIPTION = 'The IzoT Keypad example application'
APP_TYPE = ApplicationType.KEYPAD
def main ():
framework = Framework (APP_NAME, APP_TYPE, APP_DESCRIPTION, PROGRAM_ID)
app = framework.app # get the app object from the framework
keypad = app.block (profile = iotKeypad())
lux = app.block (profile = iotAnalogOutput())
# for automatic ISI connections
# – the keypad is an ISI host for the 'Light Level' function
# – the keypad is an ISI client for the 'Keypad' function
def on_user_interface(sender, argument):
framework.isi.state = argument.event_code # update the isi engine 'state' in the framework
if argument.event_code == izot.device.isi.IsiEvent.WARM:
# event handler registration
app.isi.OnUserInterface += on_user_interface
def on_enrollment (sender, argument):
“”” Checks whether incoming enrollment invitation is acceptable “””
if argument.enrollment.type_id == lux_assembly.enrollment.type_id:
argument.result = lux_assembly
elif argument.enrollment.type_id == keypad_assembly.enrollment.type_id:
argument.result = keypad_assembly
# event handler registration
app.isi.OnEnrollment += on_enrollment
# ISI Assembly objects
keypad_assembly = izot.device.isi.Assembly(
assembly = (keypad.nvoLoadControl, keypad.nviLoadStatus),
enrollment = izot.device.isi.Enrollment (
direction = izot.device.isi.IsiDirection.VARIOUS,
type_id = keypad.nvoLoadControl))
lux_assembly = izot.device.isi.Assembly (
assembly = lux.nviAnalog,
enrollment = izot.device.isi.Enrollment (
direction = izot.device.isi.IsiDirection.INPUT,
type_id = lux.nviAnalog))
framework.assembly1 = keypad_assembly
framework.assembly2 = lux_assembly
# Configure, and start, the IzoT application
# Run the application
done = False
while not done:
app.service(0.100) # allow the IzoT stack time to service its events
app.stop () # stop the Izot application
Ifa lamp controller device is later added to the network, this willhandle the connections of the datapoints such that changing the value onthe keypad will update the light level on the keypad device, and alsoon the connected lamp controller device.
The example code listingabove connects the lights only to a lamp controller; the fullimplementation also connects a temperature and a humidity sensor to anenvironmental sensor device.
Robert Dolin ,Echelon system architect as well as Vice President and Chief TechnologyOfficer, has worked for the company since 1989. He is the principal orco-inventor of fourteen Echelon patents, and is one of the designers ofthe LonWorks protocol, the network development system environment, theNeuron C programming model, and LonWorks network management. In 1995 hewas named chief technology officer. Before joining Echelon, Dolin spent11 years at ROLM Corporation, where he was one of the main developers ofits fully distributed PBX telephone system. He also held positions offirst- and second-line management as well as system architecture. Dolinhas a B.S. degree in Electrical Engineering and Computer Science fromthe University of California at Berkeley.