Building an IoT framework for industrial control: Part 2 – The IzoT framework
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.