IIoT Smart with Automation Standards
Ordinary IIoT is dumb. Meaning most IIoT solutions are not smart from end to end. They require custom code development to get the measurement data. You must redo the custom coding when a sensor is replaced by another. Sensors cannot be configured remotely. You only get data on a set interval - you cannot request for it when you need something sooner. No on-demand detail diagnostics. More sensors mean more apps required. Measurements cannot reach servers in the plant. The way IoT is done for parking meters and vending machines does not work for plants. Imagine instead smart IIoT getting measurement data without custom coding. Replacing a sensor without rewriting software. Remote sensors can be configured centrally. Measurement data and detail diagnostics any time as needed. A common app to manage all sensors. Measurements into servers in the plant. Since 14th October is the World Standards Day and since automation is a leading example of standardization I again take this opportunity to celebrate those that develop standards. Since many plants are now investing in IIoT automation for transformation of work, I will share some important recommendations. Here are my personal thoughts:
IIoT Basics
Industrial IoT is simply application of the IoT approach in industrial use-cases using industrial grade technologies and automation components.
IIoT Use-Cases
IIoT is about equipment (‘things’), monitoring their condition and optimizing their performance: monitoring & optimization (M+O). Internet of Things (IoT) involves the internet (as the name suggests). If the ‘thing’ is not monitored across the internet, it is not IoT, it is on-premises, but it can still be about digital transformation (DX) of work. Note that IIoT is not about process control and supervision. This monitoring can be done in three basic ways:
IIoT Components
An IIoT system is a chain of automation components linked together:
The thing is the equipment being monitored. In the case of industrial IoT this refers to industrial equipment like a pump, control valve, or a heat exchanger etc.
IIoT sensors are also referred to as “M+O sensors” are the sensors mounted on the equipment bring monitored (‘thing’) that pickup leading indicators of problems before failure. This includes industrial grade sensors for vibration, acoustic noise, wall thickness (corrosion/erosion), multiple temperature points, differential pressure (DP), pressure, fluid level, and flow etc. In the case of industrial IoT this refers to industrial grade sensors using an industrial standard networking protocol. This usually refers to wireless sensors because that is most practical to install, but could also be wired sensors, or wired sensors fitted with wireless adapters. This can also be a larger device with many sensors such as a smart valve positioner on a control valve. Note that the sensors themselves are not the ‘thing’.
Sensor gateway is the device that converts from the sensor protocol to IP-based backhaul protocols over Ethernet media. In the case of industrial IoT this refers to industrial standard application protocols such as HART-IP and OPC-UA. Since IIoT sensors are usually wireless, a wireless gateway also includes the radio used for the wireless communication. Note the distinction between a wireless ‘gateway’ which converts the protocol, versus a simple wireless ‘base-station’ which is simply the radio passing sensor measurement data direct onto Ethernet without converting the application protocol.
Edge gateway is the device that routes data from the backhaul network to the Internet over a mobile/cellular network such as 3G/4G/5G or fiber optics if available. It can be as simple as a regular IP-protocol router. Some solutions may require internal conversion to a messaging protocol like AMQP, MQTT, or CoAP.
Software is the analytics for predicting failure and monitor the performance. In the case of industrial IoT this refers to industrial analytics software. Software often comes with a webserver using standard HTTP/HTTPS protocol to display information as standard HTML5 web pages. Ideally the software setup should also include intelligent device management (IDM) software.
Cloud is the data center that operate the servers that run the virtual machines (VM) that runs the analytics software.
Client is the user interface software for the analytics. These days this is usually a regular web browser or a dedicated mobile app.
What makes IIoT ‘industrial’ is that it involves industrial equipment, sensors, gateways, and software:
IIoT Problem
IIoT has now been around for 10 years or more. Several common challenges have been reported. Some problems surface at the time of IIoT project execution and other problems surface during the long-term support of IIoT systems. IIoT project challenges include long and costly implementation periods including proof of concept (PoC) or pilot, sometimes referred to as ‘pilot purgatory’. Long-term IIoT support challenges include breaking changes when replacing sensors or upgrading software. Many of today’s IIoT problems are interoperability related. Most current IIoT offerings are proprietary on multiple levels end-to-end from sensor to cloud. Interoperability is lacking, resulting in limited capability, lots of manual data conversion coding/scripting work, and reworking all the above when replacing one of the automation components with that of another. It is easy to overlook or dismiss these challenges when doing the first small-scale IIoT project trial, but they will come back and bite you during project execution, when scaling out, or during operations if not tackled right from the start. But there is a better way.
IIoT Standards Solution
A standards based IIoT solution solves the interoperability problems seen with ‘ordinary’ IIoT solutions. An IIoT solution based on interoperable industrial standards end-to-end along the entire data flow is smarter, a better way of doing IIoT using industrial standard protocols and industrial standard software interfaces. The plant I&C team is familiar with the industrial standards for interoperability so let them take the lead on IIoT projects.
IIoT Sensor Integration
All wireless sensor protocols (except one) do not have a well-defined data format. For instance, even within the same protocol one vendor use 16-bit floating-point values, another use scaled integers, some vendor uses 8-bit status, another use 16-bit status, or no status at all etc. and the message format such as number of values sent, and metadata is different in a myriad of combinations. Therefore a gateway for all but one sensor protocols cannot automatically convert the sensor measurement data to industrial standard protocols like OPC-UA and HART-IP. Indeed such wireless network technologies have a “base station” rather than a “gateway”. Due to this it is necessary to manually code/script data conversion from the sensor protocol to OPC-UA or other protocol. This requires a team with programming skills to be involved in deployment of a new sensor. This is not practical. Moreover, every sensor model has different data types and message format, so a lot of scripting/coding must be developed. Additionally, the more data from the sensor you want to use, the more scripting/coding is required. Usually only the basic measurement value gets converted. Any other information gets left behind because the coding is too much work. Sure, the system vendor takes care of this for the initial project, but the cost is high, there are delays, and custom coding creates dependencies on developers. The most important point to remember is that once the project is deployed, you must then make sure the custom code/script is maintained for years as it may break as operating system and software is upgraded and patched.
Instead the smart IIoT vision is wireless sensor data automatically converted to industrial standard protocols accepted by industrial software without manual coding or scripting. You shouldn’t have to develop scripts or do programming to connect a sensor.
The recommendation is to use standard WirelessHART (IEC62591) wireless sensors which thanks to universal, common practice, and device family commands have well-defined data types and message formats so decoding and conversion to OPC-UA, HART-IP, and other protocols is automatic. Since just about all modern industrial software such as historians, data lakes, and analytics support OPC-UA, the integration with automation software is now very easy. Similarly, all modern intelligent device management (IDM) software supports HART-IP, the integration here too is very easy. Note that IP allows multiple protocols to exist in parallel.
As a result, sensors can easily be integrated by an instrument technician without programming skills without calling the system integrator thus reducing deployment cost and time. And as a bonus it also becomes practical to access more of the data in each sensor enabling additional analytics on auxiliary measurements which otherwise would go unused, and this can translate into additional benefits such as for safety, quality, and reliability.
IIoT Sensor Replacement
For other wireless sensor network technologies, when you then change wireless sensor make or even if you change wireless sensor model when you replace a failed sensor, you must redo the data conversion coding/scripting as explained in IIoT sensor integration above because the sensor data types and message format is different. If you have had an ‘ordinary’ IIoT system for a few years where wireless sensors are aging and started to fail, you will recognize this problem.
Instead the smart IIoT vision is replacing sensors without having to redo coding/scripting because data/message format does not change.
The recommendation is to use standard WirelessHART sensors as explained for IIoT sensor integration.
As a result, sensors can easily be replaced by an instrument technician without programming skills without calling the system integrator thus reducing support cost and downtime, just like for IIoT sensors integration above.
IIoT Sensor Gateway Integration
Most wireless sensor gateways are not gateways but “base stations” not converting the wireless sensor protocol to a standard application protocol for the backhaul network but instead just pushing data in the same data/message format out over IP. This is a similar issue as for “wireless sensor integration”. The data conversion coding/scripting must instead be done in the server or cloud. It is simply kicking the data conversion problem further down the data stream.
Instead the smart IIoT vision is wireless sensor data automatically converted to industrial standard protocols compatible with industrial software without requiring manual coding or scripting as explained for wireless sensor integration.
The recommendation is to use a standard WirelessHART gateway automatically converting from WirelessHART to OPC-UA and HART-IP in the sensor gateway as explained for the wireless sensor integration.
As a result, a sensor gateway can easily be integrated without having to call the system integrator to do integration in the software-end thus reducing deployment cost and time.
IIoT Sensor Gateway Replacement
For other wireless sensor network technologies, when you then change wireless gateway brand or even if you change wireless gateway model when you replace a failed gateway, you must redo the data conversion coding/scripting as explained in sensor gateway integration above. If you have had an ‘ordinary’ IIoT system for a few years where a gateway has failed for whatever reason you will recognize this problem.
Instead the smart IIoT vision is replacing a gateway without having to redo coding/scripting because data/message format does not change.
The recommendation is to use standard WirelessHART gateways as explained for IIoT sensor gateway integration.
As a result, a sensor gateway can easily be replaced without having to call the system integrator to redo the integration in the software-end thus reducing support cost and downtime like sensor gateway integration above.
领英推荐
Intelligent Device Management (IDM)
Many wireless sensor protocols are publisher-subscriber (PubSub) communication only, meaning only transmitting a process value (PV) from the sensor, possibly with status. There is no option to ‘write’ data back to the sensor, not even a request to read sensor data. Hence there is no remote wireless sensor configuration and other ‘smart’ features. That is, if you have installed the wireless sensor in a remote location like an offshore platform and then when you get back onshore and suspect the configuration such as sensor type is wrong, you cannot change the sensor configuration centrally. You cannot even check the configuration. You must travel back to the offshore platform to change the configuration at site. Devices appear “dumb”. This is not practical.
Instead the smart IIoT vision is to be able to check and change sensor configuration and perform other intelligent device management of wireless sensors in remote locations from a central location.
The recommendation is to use the industry standard WirelessHART protocol for sensors because it supports both Pub-Sub communication of PV as well as client-server read and write communication for sensor configuration, such as from a central location. And you can check (read) the configuration any time. Note that most configuration is done through universal, common practice, and device family commands so a software app can enable basic sensor configuration even without loading a “DD file” for the device. Also note that as per NAMUR NE175, remote configuration may only apply to M+O sensors (“IIoT sensors”), not to sensors on the core process control system, as a protection feature to ensure the robustness of process control loops.
As a result, you can check and change the configuration of remote sensors centrally without traveling to remote sites like offshore platforms thus saving support cost and time.
Device Management (Infrastructure)
Many backhaul protocols (like MQTT, AMQP, CoAP etc. messaging protocols) are pub-sub communication only, meaning only transmitting a process value (PV) from the sensor, possibly with status. There is no option to send data back to the sensor. That is, you can have a wireless sensor network protocol that supports remote sensor configuration, but if the backhaul protocol does not support writing data back to sensors, central configuration of remote sensors is still not possible. Hence there is no remote wireless sensor configuration and other ‘smart’ features. This is a similar issue as for “device management” above. That is, if you have installed the wireless sensor in a remote location like an offshore platform and then when you get back onshore and suspect the configuration such as sensor type is wrong, you cannot change the sensor configuration centrally. You cannot even check the configuration. You must travel back to the offshore platform to change the configuration at site. Devices appear “dumb”. This is not practical.
Instead the smart IIoT vision is to be able to check and change sensor configuration and perform other intelligent device management of wireless sensors in remote locations from a central location.
The recommendation is to use HART-IP as one of the backhaul protocols because it supports both Pub-Sub communication of PV and client-server writes of configuration of other data as explained for the device management.
As a result, you can check and change the configuration of remote sensors centrally without traveling to site thus saving support cost and time.
On-demand Measurements
Again, many wireless sensor protocols are pub-sub communication only, also meaning data only comes on a fixed period. You cannot centrally request to get a measurement reading on-demand from remote sensors if you need an update between publications. For instance, when the pub-sub update period is set to 1 hour (to conserve battery in wireless transmitters such as those for vibration) you only get new data once an hour. You cannot request a fresh new sample on demand. You must wait up to an hour for that next update. Imagine you made some mechanical adjustments to “the thing” (e.g. a pump) and want to see if it works better after the adjustment, you must wait up to 1 hour to see the result. The underlying reason is that for pub-sub protocols, the host cannot send an on-demand data request to the wireless sensor.
Instead the smart IIoT vision is being able to get a measurement reading on-demand when needed.
The recommendation is to use standard WirelessHART sensors. Even when the pub-sub burst period is set to 1 hour, you can still read the value at any time and get an immediate update, without the wait, because the user interface can poll for data.
As a result, you can see the effect of adjustments made to the “thing”, the equipment, sooner and thus finish work faster reducing maintenance time.
On-demand Detail Diagnostics
Once again, many wireless sensor protocols are pub-sub communication only, meaning only transmitting a process value (PV) from the sensor, possibly with status. There is no on-demand detail diagnostics such as vibration waveform and spectrum. The reason being these are large datasets which cannot be transmitted in every publication because it would overload the wireless sensor network and drain the battery quickly. When you want vibration waveform and spectrum you must travel to site, such as an offshore platform, carrying a portable tester to collect data the traditional manual way. This is not practical.
Instead the smart IIoT vision is being able to get detail diagnostics and other large datasets available on demand.
The recommendation is to use standard WirelessHART for sensors. You can read large datasets like vibration waveforms and spectrums on demand at any time. This reduces network loading, extends battery life, yet information can still be accessed on-demand.
As a result, time and cost is saved not having to travel to site like an offshore platform with a portable tester to get vibration waveforms and spectrums, or with a laptop to get radar level transmitter echo curve etc. Moreover, battery life for wireless sensors is extended, and data plan cost for metered connections like the mobile/cellular network is also reduced.
Unified App
Most “IIoT sensors” come bundled with their own apps where you can see the device status. However, if you have wireless sensors from 10 vendors, you must open 10 apps to see the health of all of them, each one with a different look and feel. This is not practical. The reason, again, is that all wireless sensor protocols (except one) do not have a well-defined data format (some use 8-bit status, other 16-bit status, and the meaning of each status bit is different etc.) in a myriad of combinations so an app from one vendor cannot automatically display the status of wireless sensors from other vendors in plain text.
Instead the smart IIoT vision is that one common software app can be used to see the status and detail diagnostics of all wireless sensors regardless of vendor.
The recommendation is to use standard WirelessHART for sensors because device status has a standard format which is the same for all vendors and device types. Moreover, the measurement value comes with an associated status (quality, limit, etc.) also in a standard format which is the same for all vendors and device types. Also for the more detailed device diagnostics there are many standard data fields which are the same for all vendors and device types. That is, you get a good amount of status and diagnostics from WirelessHART sensors. Optionally advanced IDM software can use a standard EDDL file (IEC61804-3) for the device to get the rest of the detail device diagnostics.
As a result, you can quickly see the health of all wireless sensors in the same single IDM software at the same time. No need to spend time opening multiple apps.
Edge Gateway Integration
Some edge gateways may convert to massaging protocols (like MQTT, AMQP, CoAP etc.) not compatible with industrial software running in the cloud which typically uses OPC-UA, such as for equipment condition analytics, equipment performance analytics, and energy management etc. This requires gateway software to be added in the cloud to convert from messaging protocols to standard industrial protocols supported in industrial software. Moreover, the messaging protocols do not have a well-defined data format. Again measurement value can be 32-bit floating-point values, 16-bit float, or scaled integers. Status might be 8-bit, 16-bit status, or no status at all etc. in a myriad of combinations. Therefore decoding of messaging protocols require data mapping configuration.
Instead the smart IIoT vision is data straight into industrial software apps without the need for conversion and data mapping.
The recommendation is to run OPC-UA all the way from the sensor gateway to software in the cloud. This way the edge gateway can be a simple IP router. Note that IP allows multiple protocols to run in parallel, so you can run OPC-UA and HART-IP through the edge gateway IP router at the same time.
As a result, time and money is saved not having to buy and configure software to map data from messaging protocols for use by industrial automation software.
Cloud and Edge
For many IIoT solutions the measurement data only goes to wireless sensor vendor’s, equipment vendor’s (e.g. pump), or service provider’s own cloud, and thus is only accessible manually through web browser or phone app. There is no way to tap into the measurement data and use it in third-party apps such as analytics, notifications, and dashboards in the plant. This is like “sensor gateway integration” above in that the sensor gateway provides no data access at all.
Instead the smart IIoT vision is sensor measurement data accessible both on-prem and in cloud.
The recommendation is to use a sensor gateway supporting OPC-UA as explained for the wireless sensor integration. OPC-UA runs all the way to the cloud apps but can also be used in apps on a server on premises.
As a result, sensor measurement data can also go into analytics, notifications, and dashboards in the plant when there is a need correlate with, use with, or display with data from other plant data sources.
Action Plan: Standards-Based IIoT
The Industrial Internet of Things (IIoT) is all about industrial automation. Get all the IIoT benefits of reduced equipment downtime, lower maintenance cost, and greater energy efficiency without the drawbacks of ‘ordinary’ IIoT. Invest in industry standards based on smart IIoT infrastructure to reduce deployment cost and time, reduce support cost and downtime, as well as reduced data plan cost for mobile/cellular backhaul. IIoT system specifications must include these four points:
Lead the way. Schedule a meeting for 14 October, the World Standards Day or today.
Share this essay with your I&C manager now.
Well, that’s my personal opinion. If you are interested in digital transformation in the process industries click “Follow” by my photo to not miss future updates. Click “Like” if you found this useful to you and to make sure you keep receiving updates in your feed and “Share” it with others if you think it would be useful to them. Save the link in case you need to refer in the future.
with sharing and discusion to elavate the knowledge
1 年dear Jonas Berge is the IIoT Smart with Automation standards can be applying at Prescriptive Maintenance strategy as a Prescriptive Analytics and Predictive Maintenance ?.Thank and regards.