Design Robust Systems for the Industrial IoT

The Internet of Things (IoT) and Industrial IoT (IIoT) share common objectives for translating streams of sensor data to useful information. For developers, however, significant differences lie in basic requirements including power, connectivity, and design reliability and robustness.

For the IoT, the need for small size, battery operation, and wireless connectivity dictates use of low-power MCUs with integrated radio subsystems for Bluetooth or Wi-Fi communications. In contrast, the combination of harsh operating conditions, very large numbers of local sensors, and legacy systems drives the need for robust interconnect and the use of edge devices able to offload conventional PLCs.

This article will work through the unique set of requirements for IIoT applications, relative to consumer IoT. It will show that despite the extra demands, developers can find a broad array of solutions able to meet specific requirements for applications targeting either domain.

Differences between consumer and industrial IoT

Applications for the IoT and IIoT share a similar objective in seeking to derive useful information from streams of data acquired from sensors. Both rely on a multilayered approach where peripheral devices communicate with a high level application directly or through some intermediate resource. Beyond those similarities, however, the nature of their respective requirements drive substantial differences in peripheral device design and connectivity.

For example, IoT sensor designs for personal health and fitness often bear little resemblance to IIoT peripheral sensors and actuators needed to accurately monitor and reliably control industrial equipment in harsh environments. Similarly, connectivity for IoT and IIoT networks can present fundamentally different requirements.

Connectivity often stands as one of the distinguishing features between IoT and IIoT system implementations. As discussed below, the IIoT has traditionally relied on hardwired connections to programmable logic controllers (PLCs) and other hosts, and the rationale for that approach largely remains valid today. In sharp contrast, IoT applications for personal and home use typically revolve around apps running on the user's smartphone or other mobile device, and are connected via Bluetooth or Wi-Fi local-area networks to the IoT device or wearable.

Designed for home or office applications, IoT device designs often face significant constraints on power and size. For these applications, consumers expect most IoT devices and all wearables to operate on battery power for an extended period of time between charges. Intended for products worn or prominently displayed in the home or office, IoT designs often face additional product engineering requirements for ease of use, water and dust resistance, minimal design footprints, and other features associated with mainstream consumer products. At the same time, design cost and simplicity arise as critical concerns for organizations looking to deliver competitive products more quickly.

The emergence of low-power wireless MCUs provides a solution able to address these often conflicting requirements. By integrating a radio subsystem with a processor core, wireless MCUs offer a simpler approach that not only reduces part count, but also eliminates design challenges associated with RF integration, speeding overall development.

Wireless MCUs such as Dialog Semiconductor's DA1458x series devices integrate a processor core, Bluetooth radio subsystem, substantial on-chip memory, and an array of analog and digital peripherals. Built around a low-power 32-bit ARM^® Cortex^®-M0 processor core, the MCUs are designed to minimize power consumption in battery-powered products. The MCUs’ integrated Bluetooth low energy core and RF radio subsystem use only 3.4 milliamps (mA) for transmit (Tx) and 3.7 mA for reception (Rx), for an overall MCU typical power consumption of 4.88 mA and 5.28 mA, respectively.

Memory extension

Dialog delivers DA1458x MCUs in a number of variants optimized for particular operating requirements. For example, the DA14581 is optimized for wireless charging applications, while the DA14585 and DA14586 are intended for wearables and smart home applications requiring small size, low power, and plenty of memory.

The Dialog Semiconductor DA14585 includes 96 Kbytes of SRAM working memory; 128 Kbytes of ROM for boot code and Bluetooth stack; and 64 Kbytes of one-time-programmable (OTP) memory for application code, Bluetooth profiles, and configuration data. The DA14586 provides the same features as the DA14585 but adds a 2 Mbit on-chip flash memory block with little change in overall power consumption during normal operations.

If a design requires larger program memory, developers can easily add an external flash device such as the Winbond Electronics W25X20 2 Mbit flash or W25X40 4 Mbit flash using the MCUs’ SPI or I²C interfaces (Figure 1). Provided in a 2 x 3 mm small outline no-lead (USON) package, either flash device results in only a modest increase in design footprint. On the other hand, use of an external flash causes incrementally higher power consumption compared to use of the MCUs’ OTP or the DA14586’s internal flash. The increased power usage results from longer SRAM load times from external flash, higher external flash programming current levels, and higher current levels in external flash standby or even power down modes.

Figure 1: For IoT designs requiring more memory than that integrated in a wireless MCU such as the Dialog Semiconductor DA14585, developers can simply connect an external flash device through the SPI or I²C interface. (Image source: Dialog Semiconductor)

Sensor data

For sensor data acquisition, engineers can take advantage of analog-to-digital converters (ADCs) integrated in wireless MCUs such as the Dialog Bluetooth MCUs. In some cases, engineers might be able to feed sensor transducer outputs directly to the MCU's ADC ports, possibly buffered through a simple op amp.

For most IoT applications, however, concerns about sensor loading, linearity, temperature compensation, signal swing, noise, and other considerations require more substantial analog signal chains. Even if built using available analog-front-end (AFE) devices, standalone sensor designs increase complexity and often delay project completion. By taking advantage of a growing array of smart sensors, however, developers can rapidly create an IoT design comprising relatively few components beyond a single wireless MCU and smart sensor.

Smart sensors combine appropriate transducers with full sensor signal chains. Optimized for the specific transducer type, these signal chains combine analog front-ends comprising power amplifiers, filters, and multiplexers, delivering conditioned signals to an integrated ADC. Often integrating a digital signal processing engine, these smart sensors can perform extensive sensor signal processing operations independent of the host MCU. For example, the TDK InvenSense ICM-20789 integrated measurement unit (IMU) integrates a digital motion processor designed to execute motion processing algorithms independent of the host processor. The device handles all aspects of data generation – acquiring data from the sensors, processing the data, and saving it in a FIFO for later access by the host MCU.

As with all smart sensors, the ICM-20789’s high level of integration and standard I²C and SPI ports ensure rapid design implementation. Developers need only add a few additional components, including a voltage regulator such as a Texas Instruments TLV702 series low-drop out (LDO) regulator (Figure 2). When data acquisition is complete, the smart sensor can wake a sleeping MCU to process the data.

Figure 2: Thanks to the high level of integration in smart sensors such as the TDK InvenSense ICM-20789 IMU, developers can implement a complete wireless sensor device with only a few components. (Image source: TDK InvenSense)

The combination of efficient MCU low-power modes and independent smart sensor operations provide developers with a powerful platform for power efficient IoT device designs.

Harsh environments

As with IoT applications, the IIoT uses multiple data streams to provide useful information. With the IIoT, however, developers building out sensor networks can find themselves dealing with a combination of harsh operating conditions, limitations on sensor placement and maintenance, and legacy sensor devices and host systems.

Unlike most IoT applications, battery powered devices are often impracticable in the industrial environment. Busy operators have little time to replace batteries. Even physically handling these tiny devices in a dusty, noisy environment can be problematic. As with any electronic device intended for this environment, developers need to create robust mechanical and electrical designs able to cope with dust, liquid, physical stress, electrical interference, and more.

To address these conditions, industrial automation designers have evolved solutions using sensor modules hardwired to PLCs through robust interconnect and communications protocols able to withstand harsh environments. Among interconnect systems, M12 has emerged as a preferred interconnect solution for industrial Ethernet, analog interfaces, and digital serial interfaces.

Available in a wide variety of assemblies and pin configurations, the M12 interconnect system provides a standard, robust solution for maintaining reliable connections with peripheral devices across a wide range of voltage and current levels. For example, M12 cable assemblies such as the Molex 1200700156 feature IP67 protection along with voltage and current ratings of 250 V and 4 A per contact.

Among communications protocols, IO-Link has similarly emerged in industrial automation and IIoT deployments. At the signal level, IO-Link provides a standard connection protocol able to support both legacy analog sensor systems and current digital sensors. With the availability of dedicated IO-Link devices, developers can implement IO-Link connectivity simply by connecting the peripheral device MCU to a dedicated IO-Link transceiver such as the Maxim Integrated MAX14827A, and adding an IO-Link master such as the Maxim Integrated MAX14819 to the local host system or PLC. Developers complete the IO-Link connection between peripheral sensor and host/PLC using a standard four-contact M12 interconnect assembly such as the Molex 1200700156, mentioned earlier.

Distributed gateways

The use of robust M12 interconnect and IO-Link communications address fundamental requirements for data and signal connectivity in industrial environments. The IIoT not only inherits the requirements of conventional automation systems but also extends them significantly with typically much larger numbers of sensor devices. In turn, the explosion of peripheral sensors and IO channels creates at the very least a tremendous logistical challenge in industrial environments. Not only are existing PLCs threatened with IO overload, but the dramatic increase in the number of cables can overwhelm facility cable runs.

To address the growing sensor load associated with the IIoT, organizations are looking for more flexible approaches that complement traditional PLCs. Among alternatives, compact I/O processing systems offer a ready solution for coping with I/O expansion associated with the IIoT. In their simplest role, these compact systems serve as micro PLCs, providing a quick solution for handling a sudden growth in sensor feeds beyond the capacity of a facility’s existing PLCs. In the industrial environment, organizations can distribute these small systems across the facility placing them near equipment to reduce cable runs, or in tandem with legacy PLCs to expand I/O channel capabilities.

In their simplest role as I/O channel expanders, micro PLCs such as the Maxim Integrated Pocket IO system provide a substantial set of digital, analog, and IO-Link interfaces. The Pocket IO platform provides 30 I/O channels comprising a combination of analog IO, digital I/O, RS485 channels, encoder motor control ports, and four IO-Link master channels. The platform’s control program runs on an Intel Edison board mounted on the main board in the platform’s three-board set (Figure 3).

Figure 3: The Maxim Integrated Pocket IO combines diverse IO channels controlled by software running on its Intel Edison processor, providing a drop-in micro PLC solution for IIoT networks or serving as the foundation for custom IIoT gateway designs. (Image source: Maxim Integrated)

With its wealth of IO and program features, the Pocket IO platform not only provides an immediate drop-in solution but also provides a reference design for custom requirements.

Platforms such as the Pocket IO not only alleviate the increased IO burden on PLCs but also provide a simpler alternative to program development. Traditional PLCs use a specialized programming language such as ladder logic that can complicate PLC program migration between different PLC platforms.

Because small systems such as the Pocket IO are based on conventional processors, developers can program their micro PLCs and other edge devices using standard languages such as C/C++ and familiar development environments. For example, in the Pocket IO reference design, developers can use an Arduino sketch and its integrated development environment (IDE) to quickly implement functionality to process signals (Listing 1).

// Makes Pocket IO analog input API available

//

#include // no init() method

PioAi pioAi; // instances an analog input interface object

pioAi.init(); // always needed for analog input

// Loads a previously stored calibration for that channel,

// usually done once at setup

//

pioAi.restoreCal(AI0);

while (XXX)

{

// Reads one sample as a raw binary code

//

uint32_t code = pioAi.readCode(AI0, AI_RATE_1_9_SPS);

// The returned code is in offset binary, where 0V is

// 2^23, 12V is 2^23+2^23 = 2^24, and -12V is // 2^23 – 2^23 = 0

//

// In the case of current, the calibration is done is

// firmware, so the returned code is not relevant

// float toVolts = (float) (code – 8388608) * 12.0 / 8388608;

// Or you can do it easier this way, for reading current,

// this is the best way.

// float volts = pioAi.readFloat(AI0, AI_RATE_1_9_SPS);

}

Listing 1: Unlike typical PLCs, small gateway systems such as the Maxim Integrated Pocket IO execute code written in familiar programming languages, enabling developers to quickly write simple programs such as this snippet for analog input processing. (Code source: Maxim Integrated)

Edge flexibility

Micro PLCs and other IIoT edge devices serve a role that rarely exists in IoT applications. In the IoT, Wi-Fi routers (and proprietary hubs) largely serve simply to provide local connectivity between peripheral devices and the Internet. In contrast, IIoT edge devices also serve a critical function in providing local processing for peripheral devices.

With their local processing capabilities, edge devices enable developers to loosen the tight coupling between sensors on the factory floor and higher level application hosts or cloud-based resources. By running applications on the edge, developers can eliminate round trip delays to the cloud and back. Thus, developers can implement faster control loops and reduce reporting latency on user interfaces located close to critical equipment and their operators.

The ability to decouple the periphery and cloud provides additional advantages when it comes to maintaining availability for critical operations. Cloud service providers use capabilities such as shadow devices to maintain application availability. Located in the cloud, shadow devices are models of corresponding peripheral devices, tracking their state during normal operations and providing a representation of the device if cloud connectivity fails.

Conversely, services such as Amazon Web Services (AWS) Greengrass, allow edge devices to provide a local version of some cloud-based services, including machine learning services. As a result, higher level services can continue locally despite changes in cloud response times or even availability.

At a more fundamental level, edge devices can also enhance availability by providing diversity options such as narrowband cellular services in remote locations with poor or no Internet connectivity. To provide an effective wireless option for IIoT connectivity, cellular service providers are moving rapidly to deploy narrowband cellular services such as LTE Cat-M1 and NB-IoT.

Designed specifically for IoT applications, these LTE variants provide sufficient throughput while using simpler protocols consistent with low-power implementations. Cellular transceiver modules such as the Pycom G01 and NimbeLink NL-SW-LTE-SVZM20 implement these narrowband LTE protocols, providing complete cellular subsystems and using standard serial interfaces for simple hardware integration in host systems such as IIoT gateways.

On the software side, implementation is just as simple. Developers can open cellular sessions and transfer data using simple MicroPython commands for the Pycom G01. The NimbeLink NL-SW-LTE-SVZM20 module offers an even simpler software interface comprising a few AT commands delivered over the shared serial link. As a result, engineers can add cellular connectivity to edge devices with little incremental effort in hardware design or software development.

Conclusion

The IoT and IIoT share common objectives for translating streams of sensor data to useful information. For developers, however, significant differences lie in basic requirements including power, connectivity, and design reliability and robustness.

As shown, by working through their unique set of requirements for IoT or IIoT applications, developers nevertheless can find a broad array of solutions able to meet specific requirements for applications targeting either domain.