IIoT at the IO level

Really look at the Industrial Internet of Things (IIoT): How will device-level communication work using this developing technology? What is IIoT? Learn four IIoT misconceptions, five ways IIoT is new, and six reasons why the disruptive technology of IIoT will be slow to catch on.


The Industrial Internet of Things (IIoT, also designated I2oT) has been getting much discussion lately, as if it has burst on the scene fully formed and ready for immediate use. A closer examination shows that, at least where we are in mid-2015, much of what is being billed as IIoT is either not industrial or not Internet.

The IIoT communication stack is very complex and has a huge variety of implementation possibilities made necessary by the variety of devices that will use it, the variety of applications, and the variety of communication media, wired and wireless. The sli

Common machine-to-machine (M2M) communication techniques that have been in use for some years are now being rebranded as IIoT whether any Internet protocol is involved or not. This is causing some confusion to say the least.

Four IIoT misconceptions

Common misconceptions about the IIoT include:

  1. All process control functions will move to the cloud.
  2. Any field device will be able to communicate with any other field device anywhere in the world.
  3. Enormous amounts of new data will be created.
  4. Everything will be wireless.

These misconceptions tend to emerge from much of the current discussion because it fixates on the benefits expected to emerge from adoption rather than understanding the technology itself. It's more fun to talk about the benefits of "big data" than to pull apart the communication stacks. Once the underlying concepts are better in hand, the benefits will be easier to understand. Rather than talking about what IIoT might be able to do, it is more useful to discuss what IIoT is and how it will work. In that way it will be easier to recognize the real thing and possibly reduce the level of hype.

First and foremost, the IIoT is infrastructure—it enables and supports communication, and that is the extent of IIoT capabilities. Maybe that doesn't sound very exciting, but don't underestimate what IIoT implies. New networks will be faster and will offer more sophisticated connectivity.

What IIoT isn't

The Internet part of IIoT is the use of IPv4 or IPv6 for its addressing, so communication that doesn't use Internet Protocol (IP) is really not IIoT. The IIoT does not create data nor will it change the way we deploy instrumentation in a typical process manufacturing environment. (Much, if not all, of the data promised is available today using conventional technologies, but users aren't collecting it for a variety of reasons. It remains to be seen whether or not new infrastructure will somehow make data more compelling.)

Implementing the IIoT will have a major impact on the way control systems communicate with field devices, which is, of course, the basic input/output (I/O) function. If IIoT succeeds in making device-level communication easier and less expensive, users will likely find opportunities to deploy a larger number of sensors (some of which might be wireless), though field instruments will still have to pass the same evaluations for safety and robust construction. All the other costs of deploying a new sensor still will apply, such as adding it to plant databases, adding it to control room human-machine interfaces (HMIs), process unit piping and instrumentation diagrams (P&ID), etc. A consumer-grade, smart, Internet-enabled thermostat will not be attached to the side of a refinery distillation column.

IIoT connections

In the May 2013 issue of Control Engineering, Herman Storey offered some thoughts on the technical side of where the IIoT was heading and what would be needed to make it practical and effective. Since then, the discussion has certainly intensified, although actual technical progress has been limited.

The updated information presented here revisits the topic, offers an update, and discusses how IIoT will be used at the device level. Below, Storey wrote his comments using a question-and-answer format (in education, known as a catechism). Since the IIoT has become almost a religion to some, this approach seems particularly appropriate.

Learn more about five ways in which the IIoT is new and six reasons why it will be slow to catch on.

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

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

I agree with the push for IIoT. I personally believe the most common IIoT misconception is that devices must have an IP address – which is not the case. All they need is digital networking and some form of unique identifier. An IPv6 address is one form of unique identifier. However, there are other ways. For instance, FOUNDATION fieldbus and WirelessHART devices also have a unique identifier so plants built on these technologies are well positioned to adopt the IIoT philosophy whenever they like.

The Internet part of IIoT is that device data can be accessed across the Internet. To achieve this an IP address in the device itself is not required. By definition, an IoT device only needs a unique identifier. This could be an IPv6 address, but doesn’t have to be. There are other ways of unique identification that works just as well. USB devices don’t have IPv6 addresses but the possibilities are endless. I can see a person on the other side of the world though their USB web cam – no IPv6 address. The web cam is connected to a laptop that has an IP address, and that’s all you need. Similarly, plants already use devices networked using FOUNDATION fieldbus and WirelessHART and can access these devices from the other side of the planet over a secure Internet connection. Between the IP-based networking and the fieldbus there sits a linking device that connects the Ethernet to the fieldbus. I personally believe that key to achieving this is to use an Ethernet application protocol which is the same as the application protocol in the underlying fieldbus. For instance, if the fieldbus is Modbus/RTU the Ethernet application protocol shall be Modbus/TCP. For WirelessHART it shall be HART-IP, for FOUNDATION fieldbus H1 it shall be FF-HSE, for PROFIBUS it is PROFINET, and for DeviceNet it is EtherNet/IP. This way any data mapping etc. is not required. By using the same application protocol, the media conversion from fieldbus to Ethernet becomes totally transparent.

I personally believe key to make instrument level communication easier is the use of “profiles”; a set of minimum requirements for device types like pressure, temperature, and flow transmitters as well as valve positioners and discrete on-off valve controls and so on. In the case of FOUNDATION fieldbus and PROFIBUS-PA this is achieved by standard function blocks and transducer blocks. Other bus technologies have other ways to do it. This enables host systems to be implemented in such a way that devices can be integrated or interchanged with their basic functionality with little or no effort, yet all advanced device functionality can still be accessed later by loading the DD file.

The kind of real-time control necessary to run a refinery or chemical processing plant safely and efficiently using an on-site on the “ground” such as in intelligent devices themselves like in the control valve positioner as opposed to in the “cloud” is referred to as “fog computing” as opposed to “cloud computing.”

I personally agree multiple physical media will continue to be required to meet different conflicting requirements such as speed, distance, device power, intrinsic safety, and low cost etc. No single solution meets all criteria.

Rather then converting existing protocols, linking devices are now provided to enable IP-based Ethernet to connect to these fieldbuses. The application protocol in the Ethernet variety of the technology is the same as in the fieldbus variety thus making the integration transparent so data flows unobstructed.

We see frequent firmware upgrades for IP-based products to fix security issues. Since there are tens of thousands of instruments in a plant, I personally believe a solution to manage such upgrades without undue burden on the instrument department would be required before instruments IP-based instruments are adopted.

I personally believe the best way to ensure that installed base of devices and host system is not a barrier to IIoT implementation is to ensure that IIoT solutions are backwards compatible with all the stuff that exist in plants to day. It is much easier to adopt a new technology if you don’t have to throw away what is already there. For instance, linking devices between Ethernet and fieldbuses takes care of that. Existing fieldbus devices are ready for IIoT because FOUNDATION fieldbus, WirelessHART, and some other protocol devices have unique identifiers which are all that is needed for IoT.

Linking devices ensures existing devices using fieldbus protocols can continue to be used for years to come yet the benefits of IIoT can be achieved. Devices can moved to IP-based solutions when issues like patch management and certificate management has become totally transparent to instrument technicians.

I personally agree IIoT should be open but there is no guarantee it will be. There are many thousands of proprietary application protocols running over IP-based networks like Ethernet and Wi-Fi etc. Most vendors embraced openness concept 20 years ago with 4-20 mA/HART and fieldbus while others resist open standards and will cling to proprietary protocols wherever they can. This continues with devices using Ethernet and IEEE 802.15.4 etc.

I personally believe fieldbus instruments will be easier for the instrument technicians to manage than IP-based devices considering the firmware upgrades and security certificates associated with IP-based devices. Until that is automatic I believe instrumentation will be networked using fieldbus.

This way IIoT need not be difficult. Indeed many plants are already accessing their fieldbus and WirelessHART devices remotely across a secure Internet connection for Intelligent Device Management (IDM):
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.
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
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.
Controller programming; Safety networks; Enclosure design; Power quality; Safety integrity levels; Increasing process efficiency
Additive manufacturing benefits; HMI and sensor tips; System integrator advice; Innovations from the industry
Robotic safety, collaboration, standards; DCS migration tips; IT/OT convergence; 2017 Control Engineering Salary and Career Survey
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
This article collection contains several articles on how automation and controls are helping human-machine interface (HMI) hardware and software advance.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Infrastructure for natural gas expansion; Artificial lift methods; Disruptive technology and fugitive gas emissions
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Jose S. Vasquez, Jr.
Fire & Life Safety Engineer; Technip USA Inc.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me