Why this hunger to add an Ethernet port/WiFi or 3G/4G functionality to any device? Well, a so-called dumb instrument can be now transformed into something much smarter. Who would have thought a few years ago that we would be asking our speakers about the weather forecast and letting them control our music choices from our past music selection. Integration is also now possible into our lighting systems, our home entertainment (including TV choices) and much more.
Not to be left behind, the automation industry has jumped on this bandwagon. IoT has morphed into the Industrial IoT with cybersecurity a core component (see sidebar 1). A plant-wide integrated view is termed Industrie 4.0, led initially by the German government but now adopted by most European automation suppliers.
Diving into the details, you may ask how Industrial IoT (IIoT) differs from IoT. For starters, industrial devices already have some smarts (PLCs, automation controllers). They are built to survive many years in harsh environments and are usually already connectable either directly or through connection to a LAN (local area network). There is typically a window into the devices’ real-time operation through an HMI (human-machine interface), and those display units can have some form of the remote view that could be picked up by smartphones or tablets.
So why the fuss around IIoT? Quite simply, instead of a dumb device getting smarter (as with IoT) you now have the potential to make a smart device truly brilliant.
Imagine your automation controller making decisions on optimizing a process in real-time. Some controllers can do this, but before IoT was a concept these changes needed to be “hardwired” into the device with required firmware changes and software updates. These developments typically take months to initially program and test before finally loading into an industrial device. Today’s IIoT controllers have a cloud component, and this provides a layer to enhance a controller’s ability by adding features not available directly in the base unit. When augmenting the base controller’s ability, engineering enhancements can be done quickly in the cloud.
Example 1: Alerts When You Need Them
Adding SMS or e-mail capability to an instrument to alert (if deviating from the desired setpoint) is a complicated setup in most on-premise solutions to integrate into the local IT mail servers.
This situation is made more straightforward via the cloud due to native integration with cloud-based mail solutions. Time to add functionality: as fast as you can type your e-mail address (Fig. 2).
Example 2: Instrument Tests on Time
Many instruments require some form of maintenance plan (calibration, alarm tests, etc.), but few can automatically alert all interested parties when tests are due and can’t remind third-party test providers on required test schedules (Fig. 3).
Cloud-based systems with some form of instrument integration (e.g., QR Code link) can leverage the ability to give controlled access to both internal and external parties and allow a global view of test compliance.
Example 3: Analytics That Make a Difference
Most modern instruments are designed for multi-applications to give the manufacturer a broader addressable market and higher volumes, which enable a more attractive price to the customer. However, specific end-customer requirements may not be predicted in design, and the opportunity to derive even higher value from the instrument after development is lost due to the cost of specialized engineering. Some advanced applications need more computing power than the onboard processor can cope with, so either a more-powerful device is required or the customer compromises on his ideal solution.
The cloud opportunity offers a different solution. Leveraging the cloud platform and the immense computing power of server-farms, it is possible to not only achieve after-event analytics but also to provide stream (or real-time) analytics (Fig. 4). A typical example is a predictive-maintenance program that leverages machine-learning algorithms. The system self-learns the behavior of the plant or component on the plant and is searching for anomalies to alert against. Information not captured by the instrument may also be linked to the cloud directly from the sensor (e.g., environmental conditions – temperature, vibration, etc.).
Example 4: Quick Reaction to Issues
A simple alarm system will alert on a problem. A complex alarm system will give more of an indication of where the problem is, its duration, etc. This complexity needs programming into the system (Fig. 5).
A cloud solution can alarm (triggering the SMS as detailed before) and also direct the user to the source of the alarm, its trigger point, duration, and trends before and after the event.
Example 5: Data Integrity Protection
How do you link the instrument to the cloud, and what happens in the event of a blip in WiFi signal or the 3G network having a small outage? Most professional offerings in this category incorporate a buffer unit into the architecture. This unit becomes a central hub to receive data from the instrument and sensors and has onboard data storage in case of transmission failures.
Example 6: Third-Party Supplier Information
Commercial heat treaters, thermocouple providers and external maintenance providers: All these companies have systems that are remote to the end customer and typically require significant manual administration to provide the customer access to key documents or process information. This situation can slow down quality acceptance of externally treated components, put equipment uptime at risk due to a shortage of parts (certified thermocouples, etc.) or create delays caused by the uncertainty of conformance of maintenance checks. Modern-day cloud solutions can provide real-time access to this information and provide both service- and customer-defined views.
Many companies offer a form of IIoT, but few have taken this down to the instrument or sensor level with many still offering a top-down hierarchical architecture. This situation is where the term instrument IoT becomes relevant. As with instrument SCADA (on-premise), instrument IoT focuses on the instrument as the brain and the software (in this case cloud-based) to offer an overview as well as additional functionality. The engineering of specific applications is simplified when utilizing a prebuilt cloud platform and leveraging associated web technologies like APIs (application programmable interface).
Smart-hubs use data buffers, and a growing number of instruments have native cloud connection ability. Instrument IoT feeds into the grander Industry 4.0 offering by providing unique perspectives on the component level of equipment and its services.
Future Perspectives Hybrid Solutions
Today’s data routes are typically either on-premise or one-way to the cloud, and then information is dispersed to interested parties. New developments include hybrid solutions with hardware with special memory allocated to allow read/write into the instrument configuration based on intelligence created in the cloud.
One crucial development in home automation that could apply to industry (especially when looking to retrofit “smarts”) is the use of general-purpose or synthetic sensors. Rather than fit each piece of equipment with distinct special-purpose sensors, say for predictive maintenance, use a block of “supersensors” to blanket an area of the shop floor. This solution could give general information related to temperature, vibration, energy use and equipment use. It can also provide machine context via a learned fingerprint of a machine.
The views expressed in this article are entirely the author’s, and may not be representative of any specific organization.