I personally agree that the requirements for Internet of Things in industrial "things" such as in process plants are different from consumer and office "things". The secure connection through the Internet at the higher level is the same, but the sensors and other "things" at the lower level at the interface between the cyber and physical world is different since the physical world of process control and other industrial applications have different requirements.
I also agree that many, but not all, of the sensors in the industry used for IoT are also used for closed loop real-time control.
Sensors used in closed loop control require very fast update period unsuitable for battery power and will therefore likely be powered by the wired communication network; two-wire "bus power". Real-time control will be done by a local controller, or in the actuator itself. Existing plants will be modernized by adding wireless sensors.
I concur communication among "things" themselves; the sensors and actuators, has to be peer-to-peer, in real-time several times per second, precisely time synchronized, and in the process industries often takes place in hazardous areas requiring intrinsically safe networks. This contrasts with data for supervisory of these loops and management of the sensors and actuators (things) which is less demanding. This need not be real-time. That is, a local real-time loop (function) can be supervised remotely across the Internet. And intelligent devices (things) can be managed remotely across the Internet,
If you envision this in the Purdue reference model, you can see real-time communication at the sensor & actuator level, and non-real-time at level 2 and above.
International standards such as IEC 61158 already define standard protocols for the lower layer sensors and actuators in diverse application areas like process control, motor control, motion control (robots), and factory automation. These protocols can easily integrate across the Internet through IP-based devices such as the controllers they are usually connected through. This integration is transparent and does NOT require any gateway or manual data mapping because for every fieldbus there is already a corresponding IP-based "application protocol" for Ethernet and other IP-compatible media.
· Fieldbus <> Industrial Ethernet
· PROFIBUS-DP <> PROFINET-IO
· FOUNDATION fieldbus H1 <> FOUNDATION fieldbus High Speed Ethernet (FF-HSE)
· Modbus/RTU <> Modbus/TCP
· DeviceNet <> EtherNet/IP
· WirelessHART <> HART-IP
That is, Modbus/RTU devices integrate across the Internet using the Modbus/TCP protocol without manual data mapping. WirelessHART devices integrate across the Internet using the HART-IP protocol without manual data mapping. FOUNDATION fieldbus H1 devices integrate across the Internet using the FF-HSE protocol without manual data mapping. PROFIBUS-DP devices integrate across the Internet using the PROFINET protocol without manual data mapping. DeviceNet devices integrate across the Internet using the EtherNet/IP protocol without manual data mapping. And so on. That is, once on the Internet, these industrial protocols coexist with the thousands of standard and proprietary protocols that exist on IP medial.
I also agree that wireless and wired networks will continue to coexist also in process applications. Wired networks primarily in digital closed loop control on the P&ID connected to the control system, and wireless mainly beyond the P&ID connected to the asset management system (AMS) or plant historian.
It is important to remember that IP alone does not create interoperability. Not everything IP is open. More important is the "application protocol". There are literally thousands of application protocols for various functions, most of which are proprietary:
There are likely many non-registered protocols too.
The first few application protocols such as FTP, SMTP, and HTTP are open standards used every day for file transfer, email, and web browsing etc. The fieldbus protocols I mentioned above with their corresponding application protocols (Modbus/TCP, PROFINET, EtherNet/IP, etc.) used over IP-compatible media are also open standards. Conversion between standard fieldbus and the corresponding application protocol for transport over IP is totally transparent and automatic, requiring no gateway. Any conversion between application protocols (e.g. Modbus to Profibus) would require gateways and data mapping (even if they are transported over IP) and I personally suspect we therefore will continue to see multiple fieldbus networks with different characteristics at the sensor-actuator level, with corresponding mix in application protocol over IP across the Internet connections.
Keep in mind that enterprise systems don't understand the many different application protocols (Modbus/TCP, PROFINET, EtherNet/IP, etc.) or underlying fieldbus protocols (Modbus/RTU, PROFIBUS-DP, and DeviceNet etc.). From what I have seen, data tends to be aggregated in a plant historian that relies on OPC servers for each protocol to access the data from the various application protocols. "Big Data" analytics will be done from data in the historian. In my personal experience, the use of OPC is far more common than use of gateways. OPC servers can be configured automatically using the EDDL files for the devices it is connected to.
It would be great if there was a "common format" (single application protocol) for all automation needs, but there isn't. It looks like process control will use one; motor controls another, motion control a third, and so on. I guess the best users can do is to limit to a single protocol in each automation area; for example FOUNDATION fieldbus for process control, PROFIBUS/PROFINET for motor controls, and WirelessHART/HART-IP for asset monitoring etc.
So indeed it will be multiple application protocols on multiple different physical media platforms. The communication across the Internet will be over IP. Sensors and actuators may or may not use IP depending on the application. Between wireless or wired sensor-actuator network (fieldbus) and the Internet the bridging is transparent without the need for manual mapping.
But first of all, digital communication has to take the place of 4-20 mA and on/off signals used by sensors and actuators today
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...