TECHNOLOGY IN SYSTEMS
Managing the Internet of Things
Enabling Multi-Industry Interoperability for the Industrial Internet of Things (IIoT)
As the IIoT evolves and spans across multiple industries, each with their own control networking protocol standards, translation markup technologies will bridge the divide to providing access to the required information.
BY MIKE GIBSON AND BARRY HAASER, LONMARK INTERNATIONAL
Page 1 of 1
The technology world is abuzz about the Internet of Things (IoT). Analysts are forecasting billions of connected smart IP devices in a wide range of applications. Whether the market is ten billion or a hundred billion is largely irrelevant. What is important is the transformation of smart devices from traditional control and device networks to IP-based networks.
It is difficult to define the IoT since it means different things to different people. For our purposes, we will focus on a specific segment of the market known as the Industrial Internet of Things or IIoT. IIoT refers to industrial objects, or “things,” that automatically communicate over a network—without human-to-human or human-to-computer interaction—to share information and take action, often autonomously. As these are largely non-consumer applications, they require a level of robustness, security and reliability not typically found in the general IoT solutions provided by consumer products.
The primary problems facing IIoT solutions today are that they are limited to a particular Mac and Phy combination, tend to be application-specific, or are based on a proprietary platform. As we’ve witnessed over the past 20 years, the most successful communication technologies are based on open standards and support multi-vendor interoperability. What is missing from the IoT and IIoT marketplace today is a common framework for enabling multi-vendor interoperability across multiple applications, supporting different communication media such as wireless, power line and wired. In order for IIoT to be truly effective and widely adopted, we must enable connectivity and interoperability between diverse products and applications. Without this interoperable framework, we risk industry going back in time and re-adopting proprietary platforms, severely limiting widespread market acceptance.
Fortunately, the semiconductor industry is delivering dramatic advancements in low-cost communication transport technologies. By steering industry toward open systems technology, companies can deliver exciting new applications, while better access to data opens up new horizons in the control systems marketplace.
Control Networks and ISO/IEC 14908-Based Systems
Today, most industrial systems are comprised of distributed intelligent devices communicating over a control network. Control network technology provides intelligent devices with peer-to-peer communications ability. This enables direct M2M interactions without the need for centralized control or human interaction.
These intelligent devices are optimized for their application domain as well as their network transport method. Control networks often support mixed media solutions. They offer a choice of transport media such as twisted pair, power line, radio and Ethernet. Network management and device configuration services are standardized to simplify the installation process, and provide a common platform for multiple manufacturers’ configuration tools. Finally, the application layer is standardized to provide interoperability between devices from multiple manufacturers.
A popular control network standard providing this interoperable framework is ISO/IEC 14908-1. The 14908 suite of standards provides both a rich seven-layer network protocol optimized to the needs of control systems, and an application layer standard designed to bring interoperability to device functional behavior. The protocol is optimized for networks of devices sending small control messages (typically less than 277 bytes) reliably to tens or thousands of devices. Taking a lesson from Ethernet collision detection, the standard supports p-Persistent CSMA with Collision Avoidance and optional Collision Detection to optimize performance in networks with “short, bursty” messages. The ISO 14908 standards suite provides multiple Mac/Phy layer standards, ISO/IEC 14908-2 for twisted pair communication, ISO/IEC 14908-3 for power line communications and ISO/IEC 14908-4 for IP communication. The application layer standard ISO/IEC 14908-5 ISO/IEC 14908-6 includes a common framework for device profile definitions, common data type definitions and standard configuration properties.
Device Interoperability Example: How Profiles Work
Device interoperability allows devices from different manufacturers to integrate and operate without any custom programming. A simple example of how 14908 provides this interoperability is revealed in the examination of the LonMark functional profile variable air volume (VAV) Controller (profile # 8010). This profile provides many fundamental features common to all VAV controllers. If we exam in detail the basic feature of determining a temperature set point for a zone under control, we can see how interoperability is accomplished. First, of the twenty standard network variables/data points and twelve standard configuration properties in the VAV controller, five of these elements play a role in determining the zone’s temperature set point (Figure 1).
Figure 1: LonMark functional profile #8010 for a variable air volume controller.
In a real-world control network, information in the interoperable device header identifies this device as an Object Type #8010, a VAV Controller. The fifth network variable (nviApplicMode) in the profile or template, is an input from the network containing the Application Mode of the VAV box. The mode value is stored in a standard interoperable format called SNVT_hvac_mode and is equal to one value in a pre-defined enumerated list. There are twenty possible values including: HVAC_OFF=6, HVAC_HEAT=1 and HVAC_COOL=3. For instance, when the VAV controller is commanded to COOL, the nviApplicMode data point is set to HVAC_COOL=3. So this is the first step in determining the zone’s temperature set point.
The next step is determining the occupancy mode for the zone. This can be provided locally by an internally wired occupancy sensor, or perhaps via nv8-nviOccCmd, the profile’s standard source for receiving the occupancy from the network. The network source for occupancy could represent a scheduler object, an occupancy sensor shared with the lighting and security system, or any reasonable combination of sources for occupancy state. In any case, by knowing the application mode (COOL) and the occupancy state (OCCUPIED), the set point operation is completed by looking up the appropriate value from a standard configuration property defined in the VAV profile. This configuration property is “programmed” during the commissioning process to contain the end users heating and cooling set points for occupied, unoccupied and standby modes. A final interoperable feature for changing the zone set point is provided by a standard network input, nv2 (nviSetPoint) in the profile. This is a network sourced override for the set point. It can be used to override the preprogrammed temperature set points stored in the VAV configuration properties.
Profile Markup Language and Advanced Transport Services
Successful implementations of the IIoT will require an interoperability framework supporting multiple transport layers and multiple application domains. While the convergence on IPv6 is clearly moving forward, the MAC/PHY layers are on a treadmill of continuous evolution. To adopt to this landscape, LonMark is updating its interoperable framework to include Advanced Transport Services (ATS), a means to support multiple standard transports; Profile Markup Language (PML), a representation standard for interoperable device profile definitions; and Translation Markup Language (TML), a markup for data encoding rules and object addressing (Figure 2).
Figure 2. LonMark 2.0 overview.
Advanced Transport Services provide a foundation for intelligent IIoT devices to support a variety of data transport options. ATS defines a set of communication services required to facilitate the 14908 application layer. ATS is a framework for implementing these services over multiple transports. To maintain compatibility with existing devices, ISO/IEC 14908 layers 1-6 remains one of the defined transports. The ATS framework allows for an unlimited number of specific implementations embracing multiple IPv6 Mac/Phy silicon such as low-power Wi-Fi, 6LoPAN, power line, 802.15.4 RF and others.
For example, one technology provider already developed a method to compress and decompress a standard IPv6 header into an existing 14908 packet. Standardizing this compression/decompression method allows the design of systems using a mixture of the older FT-10/14908 devices along with any IPv6 supported device including newer Wi-Fi devices. ATS abstracts the delivery of the bits from the context of the bits. Moving forward, industries can choose their favorite flavor of Mac/Phy to exchange interoperable data.
The Profile Markup Language (PML) provides a transport and encoding neutral schema for defining interoperable application profiles common in open systems. An application profile receives data inputs, processes the data and sends data outputs. Like the VAV profile described above, a profile may receive inputs from the network, from hardware attached to the device, or from other profiles inside the device.
What makes a Bluetooth headset plug-and-play with hundreds of different phones, a mouse and keyboard work on multiple computers, and with multiple operating systems? The answer is simple: common device profiles. Application developers learned long ago that having data exchange capability is essential, but what makes the interoperability really work is standard device profiles (Figure 3).
Figure 3. Device Profiles provide plug-in interoperability.
Human machine interface and enterprise application developers look for a common device interface across multiple suppliers. Just as phone application developers require a standard headset profile, control system software providers need a common application interface.
In the IIoT, semantics provided by application profiles will be even more important. As the levels of connectivity increase, the ability to use those connections will be determined by the careful design of those devices’ sematic interface. As such, a robust language that allows one to define profiles, query profiles, and execute operations across the sematic definitions that make up profiles is needed. Profile Markup Language will provide this capability.
The Translation Markup Language (TML) is a companion standard to PML. TML contains the data encoding and protocol-specific addressing information in a well-defined schema. By incorporating the rules of encoding and transporting PML objects in a separate abstraction layer, TML provides a protocol-specific interface to the physical devices. A TML object will define how data is represented and what elements are needed to access that data. For example, while a PML profile element could define a space temperature and how it relates to the functional behavior of the VAV application, the TML element specifies how the bits represent a temperature with a range of -273.17° to 327.67°C with a resolution of 0.01°C and what protocol-specific addressing elements are needed to read and/or write the element.
Today’s control networking marketplace is made up of a wide assortment of industry and region specific standards. DALI, BACnet, LonMark (ISO 14908), Fieldbus, KNX, Modbus, and others make up the current universe of intelligent networked devices. A translation markup language provides a method to define rules for accessing and translating data from one control network standard to another.
Today’s LonMark resource file definitions in XML format provide a solid foundation for this development. An ISO/IEC 14908 TML schema will evolve to support a standard translation layer schema that provides a much-needed standard for gateway implementation to other industry standard control protocols. These developments should make it much easier for developers and system integrators to implement and install control systems involving multiple protocols.
San Jose, CA