Industrial IoT (IIoT) requires edge computing

It is, in fact, fast becoming a must-have for manufacturing companies - as there is a direct and easy-to-measure return on investment (ROI) based on the higher cost efficiency of their operations. Asset condition monitoring, predictive maintenance to minimise production down-time, and improved production process efficiency are just a few of the key benefits of the IIoT.

A new IDC report looks at IoT use cases and states the ones that will see the most investment in 2019 are driven by the industry spending leaders: manufacturing operations ($100bn), production asset management ($44.2bn), smart home ($44.1bn), and freight monitoring ($41.7bn).

There is an important difference between the two – and that involves computation on the edge of the network. In the IIoT, a higher level of computation has to be done on the edge. There are business reasons for this – the main ones being real-time response and efficient use of bandwidth. For many IIoT applications, edge computing is the most reliable and cost-effective way to optimise the production line in real time. Other considerations also matter, such as the amount of data that needs to be transferred to the cloud and the type of data that needs to be analysed.

As Gartner’s blog by Ron van der Meulen notes, ‘Edge computing promises near real-time insights and facilitates localised actions.’

Understanding edge computing

Edge computing refers to computing that happens where the data is being generated. Data is generated primarily by sensors. There are a lot of sensors in a large oil and gas project, in a coal mine, and in any production line per se. The amount of data generated by all these sensors in aggregate is huge, and a lot of this data is not really actionable except in real time. There are some examples of this below:

• Think about a light curtain that limits human access to a potentially hazardous robot or assembly line. The data collected by this light sensor may just be proximity-related, in which case the system needs to take action immediately in case of a breach. Or, the data collected may also include distance of a potential breach – in which case the data could be analysed to determine optimum placement of the assembly line, perhaps once a quarter or even once a year.
  There is no need for real-time data upload to the cloud. Also, there is an argument to be made for just analysing the data at the sensor level with an existing or an inexpensive MCU, and either displaying or sending the analysed data to the cloud once a quarter or once a year.
• A vibration sensor on a motor that is used to detect anomalous vibration that can be a sign of impending failure provides another example. The vibration data collected may be huge and not all of it is important to consider. A simple vibration sensor can perform a fast Fourier transform (FFT) on the vibration data and flag frequencies which may indicate required motor maintenance.
  A summary of the data can be sent to the cloud for later analysis. But the wrong frequency must be flagged immediately by the vibration sensor to avoid any serious damage. A case study done by IHS Markit on a Duke Energy industrial IoT system notes that, ‘to collect vibration information, it can be necessary to capture anywhere from 10,000 to 100,000 samples per second for several seconds to obtain a good measure of the machine condition’. This data must be processed in real-time using edge processing systems, which can then narrow down the data to that pertaining to the health status of the machine.
• Another scenario involves a pressure sensor that measures the pressure against a set range that would constitute normal operation. Such a sensor would do a comparison locally and would immediately alert the operators or take some corrective action if the pressure is outside a set range. The data communicated to the cloud may just be the instances when the pressure was outside the set range or maybe not at all.
• A level sensor that would open a relief valve in an oil/corrosive liquid container if the level was too high is an example of a scenario where there is really no need for cloud communication. Ideally the sensor would indicate the level trip (maybe via an alarm) and take the appropriate corrective action.

In all these cases, the edge device needs to have some, or in other cases significant, computing resources. If there is a requirement to communicate with the cloud, then there may be a need for a communication interface as well – this can be a fieldbus directly to a programmable logic controller (PLC) or a local connection to an edge server.

Above: Figure 1. The hierarchy of an Industrial IoT system, with the intelligence moving to the edge

The network structure in a factory or any manufacturing or processing plant would be as shown in Figure 1.

While so far, we have discussed mostly the factory and process industry type of solutions, the same criteria holds true for building automation – HVACs, lighting control, etc. These applications also need the IIoT to improve efficiencies and facilitate better operation. The sensors deployed in these applications are even more cost-sensitive and, as such, not every sensor would have an IP connection to the cloud. Nor do they need to for the same reasons discussed above.

Sensor architecture

As we know, the IIoT promises to make manufacturing smarter and more agile by imbibing within the flow the digital smarts that we so take for granted in other spheres. There is a massive amount of data in a manufacturing process that can be harnessed to achieve very substantial goals – predict faults, optimise equipment lifetimes, derive new revenue streams, and even optimise the production process to better align with market needs.

Collecting this vast amount of data drives a sea change in industrial automation system design. At the most basic level, we are witnessing a dramatic increase in the number of sensors deployed. In addition, the architecture of the sensors is gaining more computation and communication capabilities. In effect the sensor is becoming the edge-computation device. While sensor size and form factor remain the same, the electronics inside the sensor have to be upgraded to make them capable of edge computation. A simple architecture change is shown in Figure 2.

Above: Figure 2. Sensor architectures change as they morph into edge-computing devices

Sensors need to incorporate a higher level of computation for data analysis and comparisons as well as to run the communication stack protocol if they’re connected to the cloud or to the PLC. These microprocessors and/or FPGAs would need a complex power tree. This means a more thoughtfully designed power architecture using switching regulators and LDOs. A communication requirement would necessitate transceivers of some type. What is not shown here is that some sensors may also need to incorporate digital isolation to protect the microprocessor or the FPGA from the real-world signals.

All these extra electronics have to be incorporated within the existing form-factor and generally in an enclosed fan-less environment. That’s why size and heat dissipation as well as extended temperature capability matters a lot in the design and development of new sensor architectures.

Choosing electronic devices

Let’s take a look at power, since that is the most widely used subsystem in any application. The size of a regulated power supply is not dominated just by the integrated chip - rather, it is mostly a function of all the discrete devices, such as the inductor and capacitors around the IC.

As switching regulators have gotten more integrated over the years, the number and size of the discrete devices have come down. In the last few years, we have even seen the emergence of power modules in very small form factors. These integrate the inductor, the MOSFETs, as well as the compensation elements. All that is required are the input and output capacitors. This level of integration has significantly reduced the size of the power solution as illustrated in Figure 3.

The newest power modules employ a stacked package methodology that places the inductor above the IC to reduce the size even further, as shown on the far-right illustration of Figure 3.

Above: Figure 3. Higher levels of integration reduce the total size of the power solution

In cases of building automation systems like HVACs that are mostly connected using BACNET (based on a venerable RS-485 physical layer), there is a need to integrate as much as possible with the required RS-485 transceivers. This can include simple power devices like a transformer driver, an LDO, and also data isolation. These transceivers have been integrating a host of these functions to reduce the overall size of the system, requiring only an external transformer. The latest technology now even incorporates the transformer within the IC package, reducing the footprint even further.

Figure 4 shows an example of this, where including the transformer along with a transceiver that already incorporates the data isolation, the transformer driver, and the LDO reduces the system footprint by 40%.

When choosing the electronics to build the sensor/edge-computing device, designers have to look at the integrated solutions that will help fit the design into the requisite form factor.

Above: Figure 4. An integrated RS-485 module that provides both power and data isolation shrinks the required PCB area

Also, it is important that these components have extended temperature ratings that allow them to operate in the rugged industrial environment. It is not unusual to see components that are rated to work up to +105°C or even +125°C operating temperatures.

Conclusion

Business reasons drive why data must often be processed closer to where it is created. Most of the data in an industrial setting comes from a myriad of sensors in the assembly line, buildings, and/or processing facilities. So, it is natural that the computation and communication capabilities be included within the sensing system as far as possible.

As sensor designs are upgraded to include such capabilities, the architecture and the electronics required become complex, requiring careful selection of components that combine both the rugged capabilities and the smaller size. With higher levels of integration and high temperature ratings, new chips now available are suitable for many of the newest edge-computing devices.