A history of closing distances

Growing out of point-to-point hardwiring, serial communications, fieldbuses, wireless and Ethernet, the Industrial Internet of Things (IIoT) has the same mission as its predecessors—quickly bringing in faraway data, so users don’t have to go out and get it, and likewise relaying instructions, so they don’t have to be delivered in-person.

“IIoT started with wired connections and messaging protocols, and linked devices including controllers that were each in their own silos. Over time, however, it became more of a living system. And now, all of a plant’s processes, users and parts can know what’s going on with the others because IIoT-based functions can translate their languages and protocols,” says Manish Sharma, global business development manager for process and energy transition at Emerson. “The idea is still to have no siloes, filter out noise and interference, and take data from process A to B as easily as possible.”

The reason IIoT evolved towards streamlining? As always, to help its users achieve their performance and business goals. This is a consultative process, though lately, it typically includes some degree of digital transformation. Sharma reports these goals often include reducing costs, energy consumption and/or unplanned downtime, improving reliability, and throughput by resolving persistent bottlenecks, or overcoming combinations of other problems.

“Once users identify challenges like gaps and bottlenecks, they can start to shift focus and resources towards solving and plugging them, and do a tiered implementation that will advance their business goals,” explains Sharma. “We progressed from custom communications in the 1970s to PLCs and DCSs with proprietary protocols, and progressed to Ethernet-based protocols and OPC UA. However, the sensors and instruments at the device level that were always there are still delivering their data to controllers, historians and managers.

“Most recently, sensors are publishing their data to common areas via MQTT protocol and brokering functions, which allow multiple devices and users to subscribe to the data streams they want. This means sensors don’t have to talk to 50 clients, which used to cause a lot of data to get lost at the IT layer. Instead, this publish-subscribe structure lets participants relay data more efficiently, infer and predict conditions more easily, and operate more autonomously. Consequently, many processes in facilities can better navigate the workforce shortages leading to fewer people on the plant floor, and rely more on scanners, cameras and robots to perform rounds, detect conditions, and generate alerts, and alarms.”

Infrastructure gut checks goals

To develop a well-fitting IIoT solution, Sharma reports  potential users must decide what they want to accomplish, and should definitely do a site audit to determine high-fidelity data availability, and what data and operations need to be augmented. This includes checking what computing infrastructure they’re presently running, whether it’s industrial PCs (IPC), or hypervised PLCs like Emerson’s PACSystems RX3i CPE 400 or CPL410 which provides both real-time control function and edge computing in one box.

For instance, Dubai-based system integrator Drakken (https://drakken.co) recently worked with an oil and gas producer in Egypt to automate its flare-gas monitoring and emissions-reduction system, so its facility and offshore wellheads in the Gulf of Suez could generate carbon-offset credits (Figure 1). However, this automation system would be necessarily complex partly due to no broadband Internet access in its remote location. To earn carbon credits, the client also had to quantify and verify precise volumes of equivalent greenhouse gas (GHG) emissions reduced by its gas-conservation equipment in accordance with the applicable quantification method. This process required continuous flare-gas conservation data gathered by recording standardized, volumetric flow rates for the conserved gas, and storing the results in a cloud-computing application.

Get your subscription to Control's tri-weekly newsletter.

The oil and gas company picked GHG-reduction services provider CarbonAi to supply its data-management solution, so Drakken’s assignment was transferring data from an energy meter on a gas compressor and flowmeters to a remote, cloud-based data management system. Consequently, Drakken selected CPL410 edge controller, PACEdge software, PACSystems RSTi-EP network adapter, communication card, digital input card for alarm signals, and QuickPanel+ HMI. CPL410 combines real-time, deterministic control and an edge-enabled execution environment in one platform. It collects data from the client’s facility and wellheads via various communications protocols, and transfers data via a broadband cellular gateway and Azure MQTT to a cloud-based service.

In addition, CPL410 provides geolocation and real-time data tagged with relevant asset information, including datasheets, install and maintenance records, and photos. This enabled a robust data trail that increases the client’s chances for successful credit verification, and avoids costly, onsite visits, manual data recording and error corrections. It also allows CarbonAi’s data management platform to integrate and manage GHG reduction data for quantifying and verifying carbon credits in an auditable format. In case of intermittent communication failures, CPL410 also stores its data, and forwards it when a connection is available.

“Automating data transfers from remote sites minimizes potential human errors that can be costly to carbon-credit projects,” says Ben Watts, CEO at Drakken. “It also streamlines the process, and reduces time and costs.”

Based on the success of this project, Drakkar reports its oil and gas client decided to replicate the project’s solution at other wellheads.

Data tributaries join the main stream

“PLCs usually work with device-level I/O, other dedicated controllers and DCSs like DeltaV to perform core processes or command balance-of-plant tasks, but lately they’re also integrating to collaborate with larger, overall systems,” adds Sharma. “Information from siloed applications feed DCSs, which makes them aware of production processes and available materials.”

For example, turbines run on steam, so their controls tell the boilers supporting them when they need more or less. These physical entities and systems can’t run in isolation, but where they used to manually overshoot and hunt, blow down or evacuate steam, their DCSs are communicating more often via DeltaV and other supervisory control systems. Likewise, if a turbine isn’t performing optimally, CPE400 PAC can gather data about water resources, temperatures, turbine loads and RPMs, and run algorithms, interact with governors for turbine or burner control for a boiler and bring the system to an optimal state. These PACs can also be programmed to react automatically if and when specified conditions occur, though most users typically still want to maintain manual intervention at these times.

“Edge controllers arrived pretty recently, and they can close a loop in milliseconds, which is almost real time, compared to traditional devices with loop cycles that take five or 10 seconds. In the same way, IIoT is a loop, too, with sensors publishing data, and PLCs communicating and collaborating on tasks.”