infrastructure for a connected world

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.

Control Engineering
Herman Storey, Rick Bullotta, Daniel Drolet
2013-05-15
Copyright 2013 CFE Media LLC
Syndication Source: Control Engineering

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?

imageThe 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.

Architectural principles of I2oT:

 

  • ISA100.15 illustrates methods for segregating automation networks in zones and connecting the zones with conduits. The concepts for zones and conduits were developed by ISA99 for ISA/IEC 62443.
  • ISA100.15 illustrates methods for creating and enforcing policies that determine which entities can communicate over industrial networks, and the allocation of bandwidth or relative priority of those communications.
  • As a general principle, many automation nodes and networks have limited bandwidth and capability to serve data. The primary source of data from these nodes must be in separate buffers and caches with sufficient bandwidth for expected users. Direct access to nodes requires systematic limitation.
  • Local autonomous control and local history collection and compression are two techniques that are used in industrial automation systems to deal with low bandwidth and/or high or variable latency in networks. Many proprietary schemes are used to fill these needs, and there is an opportunity to standardize these features.

 

Common network management—ISA100.20 is starting work on a recognized need for common network management. This is a gap that needs to be filled. Common network management is intended to provide a way of managing multiple diverse networks with common tools. Some of the tools already exist, but many networks are not designed to work with external tools. Some networks are unmanaged. This is an opportunity.

Common security management—This aspect will also need work. It is not easy to separate this need from common network management, and it may be handled by the same effort. This will need to include provisioning procedures and tools. Most industrial protocols do not include sufficient security. They need to be upgraded to include this as a standard feature.

Specifications and profiles to support compliance certification—We need plug and play, not plug and pray. This means that we will need enough compliance profiles and specifications that a certification body can do compliance testing. Standards developed by a standards development organization may support this cause, but will not be sufficient to meet industry needs.

What does the future hold?

There are multiple paths and even multiple end points for this technology migration. It is not certain what path(s) or endpoint(s) will be the final result. The only certainty is that this technology will change, and so far the changes have led to more diversity.

Current state—Many organizations are involved in pieces of the communication problem, but no single organization is involved in all aspects of this problem and no organization is well positioned to take the lead in coordinating this technology drift.

Some standards organizations have taken on the task of standardizing horizontal layers of the communication stack. IEE writes standards for the PHY/MAC (or link) layers. IETF writes standards for network and transport layers. Coordination at the boundary between the link and network layers (which is also an organizational boundary) is informal at best and sometimes appears to be a turf war.

Many foundations have taken a vertical approach to communication stack specifications and have written full top-to-bottom stacks. Many of these support only one PHY and one application and have a single stack in between. Others have multiple PHY layers available but with restricted stacks in between. These foundations are generally market competitors.

All of the organizations fill a need whether they are working on a horizontal or vertical slice of the communication problem, or just a little piece of the problem. All of these organizations could slowly converge on best-in-class technology, or not. If market forces do eventually drive this convergence, it is safe to assume that the convergence will happen very slowly and chaotically under market conditions.

Lead organization—Building a positive outcome will need a lead organization or a consortium of organizations to make this effort successful. It will involve liaison work with too many organizations to name, and will need executive sponsorship from multiple entities including vendors, standards organizations, and foundations.

Herman Storey is chief technology officer of Herman Storey Consulting, LLC.

See additional voices on the topic on the next two pages:

The technology solutions we create must be easy, flexible, and powerful

Rick Bullotta

Any consideration of applying the concepts from the IoT to the industrial space would be incomplete without addressing the following:

 

  • Legacy systems and devices—How will they participate in this new architecture, at all levels of the stack? While IPv6 and 6LoWPAN are important moving forward, we need to embrace existing devices and endpoints as well.
  • The IoT and I2oT are not a communications/plumbing problem (or opportunity); they are about creation of useful applications. While standardizing some of the lower level networking is helpful, it will fall far short of truly unlocking the potential and represents only a tiny piece of the requirements. Other critical elements include:

 

1. A semantic model for discovering, addressing, and consuming the data, services, and events that the elements of the IoT/I2oT will provide. Although the “I” in the IoT stands for Internet, the reality is that the Internet wasn’t necessarily the source of the amazing innovations we’ve seen that have changed our lives. It was in many cases the WWW and related standards and protocols that ran on top of the Internet. The same will be true of the IoT.

2. Highly granular security models that can protect access to very specific device capabilities. This way, we can allow selective sharing and access control, better deal with cyber security implications, and so on.

3. Quality of service (QoS) and security at the network layer. Not all messages and bits that are passed on the IoT and I2oT are of equal importance, and this needs to be designed into the stack. IPV6 offers some capabilities in these areas, but more is required.

Let’s not forget the human side of the discussion. People still represent the sensors, actuators, and knowledge base for a huge amount of industrial processes. Failure to consider how humans will interact in the I2oT will lead to failure!

Despite some vendors’ claims to the contrary, the IoT and I2oT are not simply cloud device architectures. In fact, to be successful, secure, reliable, and capable of performing as required, we need to consider them as a distributed systems architecture. Those of us who come from the industrial automation world have been dealing with these types of problems for decades, and there is much to be learned from past experiences and applied to the IoT and the I2oT. Standards are important, but we need to consider carefully where in the stack to focus our energies first on standardization. For example:

 

  • Which areas have the most immediate impact/value?
  • How can we address the issue of legacy integration?
  • How can we “future proof” our standardization efforts so that when IPv24 and infinitely fast, zero gravity, powerless wireless communications are available, we aren’t starting from scratch?
  • Consider not only the use cases of the past, but the use cases of the future.

 

Moreover, how can we embrace some other key elements of the IoT in the I2oT?

 

  • Location awareness of assets, people, and even data. Data has time, value, quality, and location.
  • Contextualization of data via metatagging and other mechanisms, such as a move from dumb historians to smart historians,
  • Mobile devices and new modalities for interaction, including push-based notifications, search-based access to information, secure connections from anywhere, and so on, and,
  • Extend the concept of the social graph to the equipment, processes, systems, and people in the work environment.

 

We at ThingWorx are using our extensive experience in the industrial sector (the founders of ThingWorx brought experience from Wonderware, Lighthammer, and Cimnet) to apply those lessons and know-how to the IoT and the I2oT. We share the view that there is huge value to be unlocked. We also passionately believe that the value will be unlocked when we provide technology solutions that are easy, flexible, and powerful. Those elements need not be mutually exclusive. And security and reliability are a given. We also feel strongly that there is much to be gained from sharing experiences and technology in both directions—applying the lessons learned from the open, mobile collaborative, and composable world of the IoT to the industrial space, and leveraging decades of knowledge and experience in delivering reliable, performance driven, distributed systems that exist in the industrial sector.

Rick Bullotta is CTO and co-founder of ThingWorx.

Don’t miss the big space in the middle

Daniel Drolet

Over the past 25 years, there are two ends to the spectrum of thought related to this process in which the world needs to be viewed in order to properly launch both the IoT in general as well as the I2oT.

Industrial automation and control always needed to be mechanized through machines—such as manufacturing, processing, buildings, energy, transportation, etc.—and over time and through that evolution we began adding efficiencies and minimizing labor. We then progressed to distributed control, which led to distributed sensing, which then led to distributed intelligence for critical systems.

Meanwhile, on other end of spectrum—the consumer or human interface end—this group embraced all of the devices that were being produced from the factory (which were themselves utilizing automation equipment) whereby humans became interested, intrigued, and overly addicted to the great conveniences, comforts, and improvements to their overall quality of life.

This ultimately caused two interesting results; where one extreme improved the mechanism of production (i.e., industrial and factory floor), the other caused the benefits and value to be realized by human users which ultimately developed the residential and consumer markets.

As we all know, the consumer markets that developed for radios, televisions, and appliances led to the convenience of cell phones, tablet computers, smart devices, consumer GPS, and other intelligent devices that improve our day-to-day lives.

This created one very important and often overlooked realization—recognition of the two extremes often misses the continuum between the two extremes, and what that continuum represents—such as the entire commercial industry of services, products, point of sale, payment systems, security, and overall societal infrastructure that we use every day in our life and work.

This entire continuum IS the IoT which involves distributed control, distributed sensing, distributed intelligence, M2M communications, and human interface and interaction such as social media, which is driven from an underlying theme and infrastructure of e-commerce. This essentially relates to all activities that are important to a human or other entity. What Herman Storey describes is the two ends of the spectrum. PCN believes that focusing on the interconnectivity of the two ends by enabling intelligent infrastructure for the continuum in the middle is required to have a successful IoT or I2oT.

PCN has developed technology and products to enable rapid upgrade to “intelligent infrastructure” through repurposing and reusing existing legacy infrastructure. I2oT deployments can then be realized with linkage specific to the overriding goals and objectives of what I2oT is supposed to be, and allows the “industrial communication revolution” to finally take hold. Due to cost, timelines, operational shutdown, security, and capital expense requirements alone, society cannot simply shut down to replace legacy infrastructure with new IP based communication infrastructure in order to achieve its overall goals with IoT or I2oT. There are new technologies on the horizon and bleeding ones here today that are the stepping stones for deployment of multiple architectures on single communication or existing communication infrastructures.

By being able to use existing functioning infrastructure as is, and while simultaneously overlaying IP Ethernet networks anywhere within that infrastructure, network owners easily deploy new devices, applications, and systems without impacting those that are currently performing a required task. Managed migrations to the “industrial Internet” and I2oT can now be a global successful effort that ensures critical infrastructure upgrades within industrial systems, buildings, energy, oil and gas, transportation, and other industries.

Daniel Drolet is executive vice president of PCN Technology Inc.

Key concepts:

 

  • Internet protocol technologies are quickly moving to industrial applications.
  • The Internet of Things offers many potential benefits for industrial users, but only in the right contexts.
  • A careful and purposeful approach can make adoption more practical and avoid many pitfalls.

 

For more information, visit:

www.isa.org
www.pcntechnology.com
www.thingworx.com

Powered by ContentStream®, view the original article and related content on Control Engineering.