The Industrial Internet of Things

Should industrial users embrace IP networking? It promises convergence of many technologies, but is it necessary or even beneficial? An examination of why and why not, what, and how.


Editor’s note: While the concepts related to the Internet of Things are much in the news for consumer applications and products, does this technology belong in the industrial space? Herman Storey sees potential for major benefits, but only if the technology is applied correctly. Storey is co-chair of ISA100 and has been involved in many networking standards groups throughout his career. He offers these thoughts as a starting point for an ongoing dialog. His comments are followed by views from two others.

Concepts referred to as the Internet of Things (IoT) and machine to machine (M2M) communications have attracted a lot of publicity, many interest groups, and many face-to-face meetings. IoT refers to the increasing connectivity of objects of all kinds, from home appliances to devices used in industrial applications, either to the Internet or some kind of Internet-like structure. The general idea behind this effort is that any smart devices should be able to communicate with each other or with human interfaces anywhere on the planet—thus driving improvements in productivity.

Industrial M2M networks are mature and widely deployed, even though some M2M publicity implies that the concept is new. These industrial networks can benefit from IoT technology if done correctly, but could also suffer if done with a lack of planning and caution. This discussion will propose some general principles for applying IoT to industrial automation systems. To differentiate this from the web-based efforts and call attention to industrial needs, this will be called the Industrial Internet of Things (I2oT).

I2oT must give priority to security, robustness, and timeliness requirements of automation networks while providing for remote access as a secondary requirement.

Why and why not

For the world of automation, I2oT represents the opportunity for partial convergence of industrial automation communication on a grand scale. It will allow improvements in functionality, security, flexibility, ease of use, and cost savings. In the long run, it will be good for vendors and users. It will be good for the whole automation industry, and all who embrace the technology will benefit.

In the short run, this is disruptive technology. It will require changes and will threaten entities that do not have the resources or leadership to make the changes. It will cross organizational lines and blur distinctions between foundations. The challenges of realizing the benefits of this technology will be more organizational in nature than technical. In fact, the technical challenges are minor by comparison. As of now, the effort to incorporate I2oT technology into the world of industrial automation does not have a home or a clear statement of reason for being. This is not for the faint of heart or the impatient.

What is it?

The intent of this discussion is to provide a model for I2oT. It is oversimplified but should form the basis for more discussion and definition. This is not a proposal for a massive amount of research into new communication technology. It is a plea to use what we already have in a rational manner. A lot of assembly is required and some gaps need to be filled.

Essential elements—I2oT will provide a means to integrate multiple physical media and multiple applications into a single system of industrial networks utilizing some common technology. I2oT is not a converged single stack with a single application layer or a single physical media. Indeed, one physical medium will not serve all installation requirements, and we need more than one application layer to serve all use cases.

This discussion may miss some elements but should serve to stimulate discussion to fill in the gaps. The major elements are shown in the following illustration and discussed below.

Applications—At the top of the communication stack, we have many application layers (and some user layers that may or may not be a part of the application layer depending on philosophical prejudice). It can easily be argued that we have many more application layers than necessary, but the argument is irrelevant because they now exist and constitute a large installed base. It is also arguable that one new application layer will not displace all of the existing application layers. Each application layer has strengths and weaknesses that allow each one to fill a market niche. It is simpler and more reasonable to assume that multiple interfaces are necessary and that we should expect to support all of them when considering the future of industrial communications technology.

IPv6—If I2oT supports all existing media and application layers (and it should), what is converged by I2oT? The answer is simple: in the world of I2oT, all protocols would use Internet Protocol version 6 (IPv6) as the network layer of the communication stack. IPv6 has an extension called 6LoWPAN that will allow this network layer to be used on low power and/or bandwidth-limited networks. It was originally designed for use with battery-powered radio networks, but is suitable for wired networks as well. IPv6 with 6LoWPAN literally gives a protocol the ability to address and route messages to and from any device on the planet to any other device on the planet. Any media should be able to support IP, and any application should be able to run on top of IP, and many already do.

Use of a common and capable network layer will allow the first phase of convergence including the sharing of media by multiple applications and the selection of the optimum media and application for any particular task without the need for separate infrastructure.

Physical media include:

  • Single and multiple twisted-pair wires
  • Coax cable
  • Single- and multi-mode fiber
  • Many types of radio
  • Acoustic, and
  • Infrared.

PHY/MAC specifications exist for these media types and do not need reinvention. All of these types of media should continue to be supported. However, many of these physical- and link-layer specifications are now tied to a single application layer by many protocols. This linkage needs to be broken, and it can be broken quite easily. Furthermore, the linkage should be broken in a way that any media can be shared by multiple applications.

Installations that have high latency and low bandwidth because of physical limitations (such as distance) will require some differences in the layers above IP as well as possibly placing limitations on the media that can be used. There are some shortcuts and simplifications that can be made when networks have direct high-speed/low latency links.

A communication stack model that has multiple options at the top and multiple options at the bottom but a single network layer is sometimes called an hourglass model, or a Hedy Lamarr model for history buffs who remember she invented and patented direct sequence spread spectrum technology during World War II.

Switching and routing—Switched networks are the technology of choice. Protocols that do not support switching and routing need to be upgraded, and the common network layer will aid in that step. Point-to-point and multi-drop busses will need gateways to communicate in the new world, but new networks should simply be able to connect to a switch or router. In this model, switches or routers can accomplish media conversion without a gateway.

With the right switching and routing technology, it may be possible to incorporate IPv4 as an additional option for the network layer. It is worth investigating.

Common sense of time—A common sense of time is necessary in real-time networks for event tagging, scheduling of communications and applications, and security. The best time to use is GMT or TAI (which can be converted to local time for human interface). A simple time counter or local time will lead to problems in system implementation and maintenance, and could degrade security. Some protocols need an upgrade.

Unfortunately, time synchronization is not so easily standardized because of differing needs of networks and applications. Where time synchronization requirements are fairly lax, SNTP can be used. Many networks and some applications require synchronization at the millisecond level, and a variety of methods are used for this purpose. This is an area of standards development.

Tokens should not be used for scheduling. A proper clock in each device will eliminate the need and allow more efficient and robust scheduling mechanisms. Tokens may be used for some non-scheduled bus control (TCP), but in general tokens and industrial communications should not go together. More networks will require an upgrade.

Architecture—ISA100.15 has published a document that gives models and terminology for architectures suitable for I2oT. It does not spell out in detail how elements of the architecture should be implemented; it just identifies and gives examples of what they do. More detail is needed if some degree of interoperability is to be achieved with I2oT.

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

Anonymous , 08/06/15 02:37 PM:

In my personal opinion, based on experience, the less disruptive we can make IIoT the faster it will be adopted. It is when disruption occurs that adoption is delayed (read “Crossing the Chasm”). For instance, if the lines between Instrumentation & Control (I&C) side and the IT side have to be blurred, there becomes much confusion and apprehension. If the lines of responsibility can be kept crisp, and where each has minimal dependency or interference on the other, the adoption will be faster. The same goes for the lines of responsibility between the instrument group and the control system group. If there is a clear line of responsibility between all then each group knows what to do to make the information flow unobstructed. For example, an instrument technician must be able to replace a transmitter in the middle of the night without consulting with the IT department and without getting help from a system engineer. Technology can evolve but it is more difficult to change established ways of doing things around the plant. Both business systems and control systems can use Ethernet and TCP/IP technology, but the way these two systems will be managed is different due to mutually exclusive requirements. Therefore, let each department manage their own infrastructure the way required by each application – they meet at a single well defined interface point. Avoid mixing IT network and I&C networks in the same box to enable each department to manage the network to their requirements. Just because the technology is the same doesn’t mean it has to be managed the same way. One might think that common management brings some benefits, but if there are more drawbacks then keeping them separate makes sense.

I personally agree with Herman that a single physical medium will not serve all requirements. Just like our home and office need both Ethernet and USB, and both Wi-Fi and Bluetooth, the plant environment needs both Ethernet and fieldbus, and Wi-Fi and WirelessHART.

IPv6 is not necessary for IIoT. What is required, by definition, is that each device (‘thing’) has a unique identifier. An IPv6 address is one way of uniquely identifying a device. FOUNDATION fieldbus and WirelessHART and other industrial protocols have unique IDs that work just as well. Plants built on these technologies are in a good position to move to IIoT when the time is right.

I agree that many industrial protocols already exist in plants connecting millions of devices. These devices lay the foundation for the IIoT so any developments in IIoT need to be backwards compatible with these devices and networks to ensure speedy acceptance of IIoT paradigm where these devices are accessed remotely from other offices.

What is required to make data flow freely from sensors to the enterprise is communication without barriers. This requires that the application protocol which is used over IP networks is the same as the fieldbus application protocol used by devices that sit on automation networks like FOUNDATION fieldbus, WirelessHART, Modbus/RTU, PROFIBUS-DP, and DeviceNet etc. That is, the corresponding application layer protocol used across Ethernet and other IP network are FF-HSE, HART-IP, Modbus/TCP, PROFINET, and EtherNet/IP respectively. By using the underlying fieldbus protocol with the corresponding Ethernet protocol the data can flow freely and unobstructed without gateways, drivers, and data mapping etc. A simple linking device is all that is required to connect Ethernet to a fieldbus. This in turn enables intelligent device management (IDM) remotely:

Upgrading fieldbus protocols to use IP at device level would mean all the fieldbus protocols would have to be changed. Manufacturers would have to maintain two concurrent versions of the fieldbus device (in addition to the 4-20 mA/HART and WirelessHART versions) since existing plants already use these. At the instrument level IP adds little or no value (since devices already are uniquely identified and can be accessed remotely through an IP linking device) so it may not make sense to change all these protocols creating new versions of all of them.

I agree we should use the existing application layer protocols rather than creating new protocols. Indeed it is possible to create IP devices that support multiple application protocols. For instance one application communicates with the device using HART-IP, another application uses FF-HSE, a third application using PROFINET, and a fourth application using Modbus/TCP – all from the same device, all applications getting the same data but through a different IP port. This requires the multi-protocol solution is implemented as intended, like on Ethernet and Wi-Fi, where the application protocols access the device directly through their assigned IP ports, not by “tunneling” across another application protocol of some type.
Anonymous , 08/06/15 02:38 PM:

I personally agree with Rick that backwards compatibility and integration with existing network technologies and devices is important. These devices are the foundation of IIoT. There are linking devices available for connecting all fieldbuses to IP-based networks: WirelessHART to HART-IP, FOUNDATION fieldbus H1 to FF-HSE, Modbus/RTU to Modbus/TCP, PROFIBUS-DP to PROFINET, and DeviceNet to EtherNet/IP. The same application protocol is used on the IP side as on the fieldbus side meaning data flows freely without barriers such as data mapping.

The way whereby devices are identified to humans in the industry is by “tag” name. So device tag is the logical way whereby devices shall located in the IIoT. Existing industrial networks like FOUNDATION fieldbus and WirelessHART already support locating devices using device tag. That is, a device is identified as for example 51-PT-101; humans do not need to know the address of the device. These protocols are the foundation of the IIoT. Plants built on these technologies are in a good position to move to IIoT when the time is right.

Modern protocols like FOUNDATION fieldbus already support communication of real-time and non-real-time data in separate timeslots such that non-real-time data does not delay real-time data.
Anonymous , 08/06/15 02:38 PM:

I personally agree with Drolet that existing industrial networks cannot be replaced by IP-based communication. Instead, continue use of fieldbuses, connected to higher level Ethernet and IP through linking devices. A key element is that the Ethernet application protocols be the same as the application protocols for the underlying fieldbuses: Modbus/RTU<>Modbus/TCP, DeviceNet<>EtherNet/IP, PROFIBUS<>PROFINET, FOUNDATION fieldbus H1<>FF-HSE, and WirelessHART<>HART-IP. This ensures data flows unobstructed without undue integration effort.
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.
Robot advances in connectivity, collaboration, and programming; Advanced process control; Industrial wireless developments; Multiplatform system integration
Sensor-to-cloud interoperability; PID and digital control efficiency; Alarm management system design; Automotive industry advances
Make Big Data and Industrial Internet of Things work for you, 2017 Engineers' Choice Finalists, Avoid control design pitfalls, Managing IIoT processes
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!

Big Data and bigger solutions; Tablet technologies; SCADA developments
SCADA at the junction, Managing risk through maintenance, Moving at the speed of data
Flexible offshore fire protection; Big Data's impact on operations; Bridging the skills gap; Identifying security risks
click me