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
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.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.