How will the Internet of Things (IoT) actually be implemented in an industrial enterprise? Many of the separate elements have been in place for a couple of decades, so the challenge is to understand what needs to be done to pull them together to function as a whole.

Part 1 of this series defined IoT as a conceptual framework about communicating useful information between devices. Part 2 focuses on specific practice and begins with a definition from Tom Moore, IHS Analyst II, Industrial Automation, who says, “IoT is literally collecting sensor data from IP addressable sensors anywhere in the world for anything and transmitting the data.” An industrial example might be a message that a motor is overheating in a robot. That information can be transmitted to a service person who can be sent to deal with the problem, says Moore.

This seemingly simple example illustrates many of the complex issues inherent in the IoT.

For example, what sort of sensor will be used to collect temperature data about the robot’s motors? Such sensors have been around for decades, but monitoring temperatures on a robot presents some special problems. For example, will the robot’s communication link be copper or fiber cable? What type of cable will be used? Will it be Category 5 or 6 UTP copper, shielded or not, single mode or multimode fiber? Will the cable be stationary or moveable? Will the communication have to be wireless? If so, will it be Wi-Fi, Zigbee, cellular or Bluetooth? What communication protocol will it use: 4 – 20 mA analog, serial fieldbus or Ethernet? If the sensor is measuring a process variable, it will not necessarily be transmitting the data outside of the process loop. To retrofit IoT on top of that existing process, will the controller and network be able to handle the extra load?

Numbering the Sensors

Moore’s definition of IoT has at least one important assumption lurking within it. Saying that there will be addressable sensors anywhere in the world means that each one of these sensors must have an IP address that will uniquely identify it. The problem is that the number of devices is huge, so there has to be an equally huge number of available addresses.

This was anticipated by the Internet Society, which released the IPv6 addressing system in 1998 to provide an adequate supply of IP identifiers. It is generally accepted that it will be sufficient for the foreseeable future, and at 2¹²⁸ possible addresses, the assumption seems reasonable. The problem is that most existing devices have IPv4 addresses, which are limited to 2³² possibilities and are already starting to be used up. This poses a difficulty because IPv6 is not backwards compatible.

“It’s a problem that’s been predicted and solved for many years, in theory at least, but IPv6 is being adopted at a glacially slow pace,” says Graeme Caldwell, Inbound Marketer at InterWorx. “The reason for the gradual adoption is simple to understand: it’s expensive." Because the Internet is made up of tens of millions of servers, routers and switches that were designed to work with IPv4, upgrading that infrastructure entails a significant capital investment, he says.

Deluge of Data

It’s a safe assumption that eventually all sensors will have unique addresses, “but the big challenge is just the sheer amount of data,” says Moore. “You’re not looking at a few bytes from a smart home refrigerator; you’re dealing with terabytes.” This is a problem for several reasons. First is the amount of bandwidth needed to transmit the data at a reasonable rate. Once the data is transmitted, what do you do with it? Where do you store it? How do you manipulate it so it can convey useful information?

To return to the robot's overheating motor example, one way to reduce the amount of bytes being transmitted is to embed a microprocessor into the sensor, which could analyze the readings and send only important information instead of a continuous stream of data points. This means the sensor might take readings at intervals and transmit trends, preset warnings, and alarms.

In addition to smart IP sensors, the minimum requirements for establishing an industrial IoT system are networks that connect the intelligent devices using industrially hardened equipment, including HMIs, IP switches and routers. The basic networking protocol will eventually be Industrial Ethernet.
IHS research indicates that it will take 15 years, however, before Ethernet becomes dominant. And that's just for new nodes, not for the installed base. The reason for this slow pace is that industrial automation has a legacy of serial-based networking technologies, which were never designed to transmit data externally. This raises a security problem.

“Existing controllers have not necessarily been built with external networking in mind, so they were never built to include security safeguards," says Moore. "You don’t need security on internal networking. Hundreds of millions of nodes will still be on fieldbus and with product life cycles of 30–40 years, they’re not going away soon.”

Signs of Progress

Despite the difficulties there are important examples of progress.

Siemens offers two communication protocols: Profibus, which is a fieldbus technology, and Profinet, which is the Ethernet equivalent. A sign of Siemens' belief in the future of Ethernet is that Profibus was originally the company's standard offering and Profinet was an option. That is now reversed so that Profibus is the principal option.

ODVA, the association that manages several fieldbus protocols including DeviceNet, has established the Special Interest Group (SIG) for the DeviceNet of Things. Its goal is to provide seamless connectivity using blended DeviceNet-Ethernet/IP via ODVA’s Common Industrial Protocol (CIP). “Users will be provided with…systems engineered for the future that can evolve in step with the Internet of Things as the costs of Ethernet continue to decline,” says Katherine Voss, ODVA president and executive director.

Rockwell Automation and Cisco Systems have formed an alliance to connect factory floor “operations technology” (OT) with enterprise level Ethernet (IT). Rockwell is handling the automation equipment and Cisco is focusing on the IT equipment. To support that effort, Cisco recently undertook a reorganization to direct a large amount of its resources on IoT.

At the recent 2014 IoT World Forum in Chicago, General Motors said it is starting to collect sensor data and to gradually change control of its automated lines to Industrial Ethernet. GM's announcement may well cause other companies to think about following suit and adopting Industrial Ethernet.

Organizing the Enterprise Network

In order to build a factory automation network suitable for the IoT, the logical and physical structures of the network should be designed and installed according to Industrial Ethernet best practices. This is one more reason that it is easier to build the network in new, rather than existing facilities.
To start with, engineers have to specify the devices used in their process and how these devices need to logically interact. The network then has to be designed to support these bottom-line requirements. To help with designing the network, Cisco and Rockwell jointly published a set of guidelines called the “Converged Plantwide Ethernet (CPwE) Implementation Guide.” These guidelines are based on TIA Standards 568 and 1005.

According to Robert Elliot, senior product development manager at Panduit Corp., network design should begin with a logical architecture based on factors such as the number and types of nodes, a ranking of the importance of each node for process needs and safety, the characteristics of the data and requirements for security. Another design component is deciding which elements of the plant floor network should connect to the home office network and which to the Internet.

The next step is to design the physical network infrastructure to implement the logical architecture. A good design philosophy is to create sub-networks that take account of common functions, physical locations and environmental factors such as moisture, dust and electromagnetic radiation. For security, there should be “demilitarized zones” (DMZs). These are areas that include firewalls and virtual private networks (VPNs) to control access between office and plant Ethernet, and additional DMZs to control access between the enterprise network and the Internet.

Once the architecture and layout are designed, the physical media for different parts of the network must be selected. Depending on the required bandwidth, whether it’s real-time data for a process application or just data gathering, engineers could choose to use shielded or unshielded pair copper cable, fiber optic cable or wireless connections.

There also must be a clear chain of authority governing network installation and operation. No one person could possibly design the entire network, so it is a given that responsibility must be parceled out to a team. The team in turn has to be coordinated by someone having authority to make decisions when, for example, there are inevitable conflicts between IT and OT. A high-level authority must also be responsible for making decisions about the overall convergence of the various network sectors.

Logically, designing industrial automation using Ethernet to construct an Internet of Things makes perfect sense. For all of the reasons outlined, actually making it happen will be a long and difficult journey.

Coming in Part 3: How can a wide variety of networks be compatible? Coping with organizational resistance to change. And, what to do with legacy hardware and software?

More Resources:

IHS Technology

IHS Internet of Things