The Industrial Internet of Things


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. 

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 Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
A cool solution: Collaboration, chemistry leads to foundry coat product development; See the 2015 Product of the Year Finalists
Raising the standard: What's new with NFPA 70E; A global view of manufacturing; Maintenance data; Fit bearings properly
Sister act: Building on their father's legacy, a new generation moves Bales Metal Surface Solutions forward; Meet the 2015 Engineering Leaders Under 40
Cyber security cost-efficient for industrial control systems; Extracting full value from operational data; Managing cyber security risks
Drilling for Big Data: Managing the flow of information; Big data drilldown series: Challenge and opportunity; OT to IT: Creating a circle of improvement; Industry loses best workers, again
Pipeline vulnerabilities? Securing hydrocarbon transit; Predictive analytics hit the mainstream; Dirty pipelines decrease flow, production—pig your line; Ensuring pipeline physical and cyber security
Upgrading secondary control systems; Keeping enclosures conditioned; Diagnostics increase equipment uptime; Mechatronics simplifies machine design
Designing positive-energy buildings; Ensuring power quality; Complying with NFPA 110; Minimizing arc flash hazards
Building high availability into industrial computers; Of key metrics and myth busting; The truth about five common VFD myths

Annual Salary Survey

After almost a decade of uncertainty, the confidence of plant floor managers is soaring. Even with a number of challenges and while implementing new technologies, there is a renewed sense of optimism among plant managers about their business and their future.

The respondents to the 2014 Plant Engineering Salary Survey come from throughout the U.S. and serve a variety of industries, but they are uniform in their optimism about manufacturing. This year’s survey found 79% consider manufacturing a secure career. That’s up from 75% in 2013 and significantly higher than the 63% figure when Plant Engineering first started asking that question a decade ago.

Read more: 2014 Salary Survey: Confidence rises amid the challenges

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.