Accelerate Industrial IoT Application Development—Part 2: Rapid IIoT Sensor Deployment

Editor’s Note: Embedded application development projects are often delayed as developers wait for availability of hardware implementations of new devices. Industrial Internet of Things (IIoT) application development faces a similar bottleneck, waiting for the sensor data required for applications like industrial predictive maintenance systems or facility automation systems based on machine learning methods. This two-part series explores alternatives for providing early data streams needed to accelerate IIoT application development. Part 1 described use of simulation methods for generating those data streams. Here, Part 2 discusses options for rapid prototyping of sensor systems for generating data.

Large-scale Industrial Internet of Things (IIoT) applications depend fundamentally upon analysis and response to streams of data generated by sensor networks deployed across the target environment. Without ready availability of those data streams early in development, IIoT applications can fall behind tight schedules or fall below company expectations.

Although simulation methods can address data requirements for many applications, others might require data that precisely matches the target environment. For these, the level of effort required to deliver effective simulation results may be impractical. Instead, the use of readily available sensor and gateway units offer a potentially easier path to rapid delivery of data. Specifically designed for industrial environments, these units support a wide variety of sensor types and connectivity options with little effort required by the user.

The second of a two-part series on accelerating IIoT application development, this article describes the multiple types of pre-configured IIoT sensors and gateways available for generating data required to accelerate IIoT application development.

The limitations of IIoT data simulations

Sensor data is central to IIoT applications, but full deployment of those applications depends on ready availability of both sensor systems intended to deliver that data as well as the software systems needed to transform that data into useful information. For some IIoT applications, simulation might not deliver sufficiently useful data. Without careful attention to the parameters of the simulation, simulated data streams could exhibit properties that bias the application toward a particular operating envelope.

For example, a data simulation configured to deliver a random temperature with a uniform distribution in the range -40°C to +125°C could bias the application toward extremes of temperature outside of the actual ambient range of the target environment. In addition, a naive simulation of this sort could also easily deliver temperature data that jumps dozens of degrees from one measurement epoch to the next. In a typical IIoT application, such radical and unrealistic changes in temperature could play havoc with process control loops and other application results.

The quality of the data and how well it represents realistic conditions are of particular concern if the application is expected to embed machine learning inference models. Data scientists understand that inference models trained on poor data will give equally poor results. Consequently, the level of effort required to create effective data simulations needed for these models can escalate quickly.

For most IIoT projects, delaying application development until sensor systems are deployed is simply not an option. In fact, waiting for sensor deployment might not even be feasible when execution of the software application is expected to reveal needed information or even justification for full deployment. For example, data scientists might need the results of complex algorithms to determine if higher resolution data, higher update rates or even different types of sensor data are needed to resolve ambiguities in the results or otherwise optimize the application.

For all these reasons, organizations might reluctantly decide that delaying IIoT application development is preferable to developing an application with simulated data that poorly represents the target industrial process and environment. Fortunately, the growing availability of pre-built IIoT sensor systems and associated gateway devices enables organizations to rapidly deploy, at a minimum, the most critical set of sensors required for application development.

Rapid sensor network deployment

IIoT sensors combine sensors, processors and connectivity interfaces in a package designed to withstand the stresses of a typical industrial environment. Besides individual sensors for temperature, vibration, pressure, and humidity, developers can find available multisensor units that package combinations of sensors required for specific application capabilities such as predictive maintenance.

Predictive maintenance methods monitor characteristics that serve as indicators of potential faults in equipment. In motors, for example, specific changes in vibration frequency and temperature reliably indicate very specific types of failures in motors. Designed to capture this data, IIoT sensors such as the National Control Devices (NCD) PR55-20A predictive maintenance sensor combines the required sensors with a low-power microcontroller and DigiMesh wireless mesh network connectivity (Figure 1).

Figure 1: The NCD PR55-20A predictive maintenance sensor combines multiple sensors with mesh networking connectivity required to deliver data to local wireless nodes. (Image source: National Control Devices)

To accelerate IIoT application development, developers can easily combine specialized sensors such as the NCD predictive maintenance sensor with other sensors such as the NCD PR49-24G wireless environmental sensor that integrates temperature, humidity and gas sensors in an industrial package powered by two AA batteries.

Along with a variety of specific sensor types, IIoT sensor manufacturers provide pre-built communications gateway units designed to simplify integration of sensors into locally connected networks. In fact, developers can find available gateway units that are pre-configured to connect with specific commercial clouds or support communications protocols commonly used to connect with IoT cloud platforms.

For its DigiMesh wireless sensors, the NCD PR55-21 gateway series uses a Wi-Fi connection to connect to specific cloud services including Microsoft Azure IoT (PR55-21_AZURE), Amazon Web Services IoT (PR55-21_AWS) or the Losant IoT platform (PR55-21_LOSANT). In addition, its PR55-21_MQTT gateway supports communications with any host using the ISO standard MQ Telemetry Transport (MQTT) protocol. As with the other members of the PR55-21 series, the PR55-21_MQTT gateway combines a low-power industrial microcontroller with subsystems for local DigiMesh wireless connectivity and for an encrypted Wi-Fi backhaul connection to a local or remote MQTT server (Figure 2).

Figure 2: The NCD PR55-21_MQTT gateway combines wireless support for a local DigiMesh mesh network and MQTT message exchanges with a server over a Wi-Fi connection. (Image source: National Control Devices)

Developers can quickly configure the DigiMesh local network and MQTT Wi-Fi connection using a menu-based tool provided through the gateway's embedded Web server. For example, a device screen shows DigiMesh connected devices as well as their signal strength and activity and provides a central point for managing their configuration (Figure 3).

Figure 3: The NCD PR55-21_MQTT gateway's embedded Web server allows users to change settings and examine activity of sensors connected to the local network. (Image source: National Control Devices)

DigiMesh mesh networking offers an effective approach for extending the effective range of low power transceivers required in battery-powered sensor systems. It is, of course, only one of several connectivity options likely encountered in industrial environments, and manufacturers offer similar combinations of sensors and gateways for many of those. For example, Laird’s Sentrius RS1xx series includes industrial sensors designed to support Bluetooth and LoRaWAN connectivity. The company's Sentrius RG1xx series comprises complementary gateways designed to support regional frequency requirements for LoRaWAN deployment. In addition, the gateways support local Bluetooth connectivity and Wi-Fi backhaul Internet connectivity.

In some applications, strong sources of electromagnetic interference (EMI) can degrade signal integrity in wireless communications. For these situations, the ability to separate sensor and communications functionality can be an important advantage. Along with its own wireless industrial sensors, Banner Engineering offers sensors designed to connect over an RS-485 or 1-wire serial interface to a separate wireless node. As a result, operators can place the wireless communications node at some distance from a sensor attached to a strong EMI source such as a high-speed motor (Figure 4).

Figure 4: For situations with significant electromagnetic interference such as motor vibration measurement, developers can connect a Banner Engineering vibration sensor mounted on the motor with a wireless node placed some distance from the noise source. (Image source: Banner Engineering)

Supporting this type of configuration, the Banner Engineering DX80N9Q45VTP wireless node is designed to connect with the company's QM30VT1 1-wire vibration and temperature sensor, while the DX80N9Q45TH wireless node connects with the M12FTH4Q 1-wire temperature and humidity sensor. For broader sensor interface requirements, the company's DX80N9Q45U serves as a universal 1-wire wireless node, and the company's DX80G9M6S series of wireless nodes supports RS-485 sensor connections to multihop networks.

Local processing

Even with rapid deployment of IIoT sensor networks, developers might need to anticipate some degree of local processing to reduce data volume or relieve processing load on downstream resources. In fact, advanced industrial sensors such as the Banner Engineering QM30VT2 vibration and temperature sensor enables users to split the measured vibration frequency into as many as 20 frequency bands. This capability is particularly important in predictive maintenance applications, where changes within separate frequency bands are known to indicate specific types of faults.

Besides preprocessing by the sensors, it may be the case that early deployment of sensor networks will levy a range of requirements for local processing. Banner Engineer provides this capability with its DXM700 controller and gateway. Measuring only 70 x 86 x 55 millimeters (mm), the DXM700 provides multiple local wireless and wired connectivity as well as Ethernet backhaul to host servers (Figure 5).

Figure 5: The Banner Engineering DXM700 controller and gateway offers multiple connectivity options for local and Internet connectivity as well as supporting local ScriptBasic processing. (Image source: Banner Engineering)

As it receives data from local sensor networks, the controller can execute programs written in ScriptBasic to examine input data, activate outputs based on input data, or perform simple transformations of the data. Banner Engineering documentation includes ScriptBasic samples illustrating typical actions such as responding to changes in sensor data (Listing 1).

Copy
 
.
.
.
'Function to read the T/H sensor
FUNCTION GetTempHumidityData
   LastValueTempC = TempC
   LastValueHumidity = Humidity
   Humidity =GETREG(SensorHumidity_reg, TH_SID, MBtype) 
   TempC = GETREG(SensorTempC_reg, TH_SID, MBtype)
   IF Humidity > 65535 or TempC > 65535 THEN 
         PRINT "Read Error - humidity / temp reading...", Humidity,"  ",TempC,"\n\r"
   END IF
   WrErr = SETREG (Humidity_reg, Humidity, LocalRegSID, MBtype)
   WrErr = SETREG (TempC_reg, TempC, LocalRegSID , MBtype)
 
FUNCTION StateMachine
'State machine definitions for the periodic reading of temp/humidity
' TH_State = 0  current state of the state machine
' TH_Idle= 0  initial state
' TH_Wait= 1  wait time between samples
' TH_Sample= 2  get samples from remote sensor
' TH_Error= 3 error state - unknown condition

   LOCAL StartState
   StartState = TH_State
   WrErr = SETREG (SM_reg, TH_State, LocalRegSID, MBtype)
   
   IF TH_State = TH_Idle THEN
          StartTime = NOW
          TH_State = TH_Wait
   ELSEIF TH_State = TH_Wait THEN
      IF NOW >= (StartTime + WaitTime) THEN 
         TH_State = TH_Sample
      ELSE 
         TH_State = TH_Wait
      END IF 
   ELSEIF TH_State = TH_Sample THEN
      GetTempHumidityData
      TH_State = TH_Idle
   ELSE 
      TH_State = TH_Error
   END IF 
   IF StartState <> TH_State THEN
      PRINT "\r\n Time ",NOW,"  SM Started-> ",THState[StartState],"  End->",THState[TH_State]," \r\n"
   END IF

END FUNCTION 

FUNCTION LED_driver  
IF LastValueTempC < TempC THEN    WrErr = SETREG (TempGoingUp_LED2_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (TempGoingUp_LED2_reg,0,DisplaySID, MBtype) 
   END IF
   
   IF LastValueTempC > TempC THEN    WrErr = SETREG (TempGoingDown_LED3_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (TempGoingDown_LED3_reg,0,DisplaySID, MBtype) 
   END IF
   
   IF (Humidity > 65535 ) OR (TempC > 65535) THEN    WrErr = SETREG (CommsError_LED4_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (CommsError_LED4_reg,0,DisplaySID, MBtype) 
   END IF 
   
   IF GETREG(ScriptRunnning_LED1_reg, DisplaySID, MBtype) THEN
      WrErr = SETREG (ScriptRunnning_LED1_reg,0,DisplaySID, MBtype) 
   ELSE 
      WrErr = SETREG (ScriptRunnning_LED1_reg,1,DisplaySID, MBtype) 
   END IF
   
END FUNCTION 

‘Main program loop
BEGIN:
   PRINT "Script Starting\r\n"
   ITERATE:
      'PRINT "\r\n Time = ",NOW," \r\n"
      StateMachine
      LED_driver
      Sleep(1)
   GOTO ITERATE
END

Listing 1: This ScriptBasic snippet from Banner Engineering shows how developers can program the Banner Engineering DXM700 to respond locally to sensor data, in this case turning LEDs on and off in response to changes in temperature and humidity sensor data. (Code source: Banner Engineering)

Gateways such as Multi-Tech Systems’ MTCAP-Lxxx series provide even greater flexibility for local processing. Designed to meet diverse connectivity requirements, this series supports local LoRaWAN connectivity on the sensor side, as well as Ethernet and optional wideband LTE connectivity for backhaul channels. For its operating environment, this gateway series is based on the open-source Multi-Tech Linux (mLinux) operating system. As a result, developers can create local processing software routines using a familiar development environment. In addition, these gateways support Node-RED, offering a low-code development option that is useful for event-driven applications such as IIoT. See more on Node-RED later in this article.

Low-code rapid prototyping

Rapid deployment of physical sensor networks can help accelerate IIoT application development by providing an early source of critical data well before design, development, and commissioning of full-scale sensor networks. Rapid deployment can stumble if it brings significant collateral requirements for software development. The pre-configured IIoT sensor units and gateways described previously will in many cases avoid that situation, but unique data requirements beyond the capabilities of drop-in sensors and gateways can bring associated software requirements.

In meeting unique data requirements, rapid prototype platforms such as Arduino and Raspberry Pi offer a wide range of specialized sensors and actuators as add-on boards. By mixing and matching these add-on boards, developers can rapidly build a prototype to meet virtually any requirement for sensor data.

For IoT applications, manufacturers have made application prototyping easier with the release of multisensor boards designed with the minimal footprint and functional capability typically required in those applications. Development boards such as the ON Semiconductor RSL10-SENSE-GEVK evaluation kit or STMicroelectronics’ STEVAL-STLKT01V1 SensorTile development kit integrate a high-performance processor with a broad array of sensors typically required in wearables and IoT devices. For example, the SensorTile combines an STMicroelectronics STM32L4 processor with an STMicroelectronics BLUENRG-MS transceiver and a sensor array that includes the company's LPS22HBTR microelectromechanical systems (MEMS) pressure sensor, LSM6DSMTR MEMS inertial measurement unit (IMU) with accelerometer and gyroscope, and LSM303AGRTR MEMS e-compass with linear acceleration and magnetic sensors (Figure 6).

Figure 6: Based on an STMicroelectronics STM32L4 processor, the STMicroelectronics SensorTile provides a flexible hardware platform for building sensor systems able to meet unique requirements beyond those supported in off-the-shelf IIoT sensor systems. (Image source: STMicroelectronics)

A popular low-code development environment, Node-RED, allows developers to program these boards and other hardware systems such as NCD devices and Multi-Tech gateways by drawing graphs (flows) that connect functional elements (nodes). These flows correspond to interactions among nodes corresponding to specific functional capabilities including reading sensor data, performing operations on the data, transferring the data to other functional elements such as cloud gateways, and displaying the data (Figure 7).

Figure 7: The Node-RED development environment enables developers to create applications by connecting nodes drawn from an extensive open-source repository. (Image source: National Control Devices)

With over 225,000 modules available in the open-source Node-RED flow repository, this environment offers a rich ecosystem for developing event-driven applications like sensor data acquisition and transfer to the cloud. Although Node-RED provides methods for integrating the resulting flows in production applications, its reliance on Node.js might not be suitable for some applications or production environments.

DigiKey’s DK IoT Studio offers another low-code development environment that largely removes the need for manual software development while still providing C language source code. Using DK IoT Studio, developers create the required functional capabilities by dropping components associated with each feature of the SensorTile on the DK IoT Studio canvas (Figure 8).

Figure 8: The DigiKey DK IoT Studio automatically generates code (left side) from applications created by connecting functional components placed as icons on the canvas (center) and modifying associated characteristics (right side) as needed. (Image source: DigiKey/STMicroelectronics)

Besides support for specific hardware components, this environment provides similar droppable functional components that represent data transfer to the cloud or operation of cloud resources. After drawing the graph describing data flow and operations, developers can download generated code for uploading to the SensorTile. When building typical prototypes, this process requires little or no extra code development. For more about this rapid prototyping development flow, read, "Rapidly Deploy a Battery-Powered Bluetooth 5 Certified Multi-Sensor IoT Device".

Conclusion

Development of large-scale IIoT applications depends critically on availability of data that faithfully represents the target environment. As seen in Part 1 of this two-part series, simulation methods can address data requirements for many applications, while others might require data that precisely matches the target environment. For these, the level of effort required to deliver effective simulation results may be impractical. Instead, readily available sensor and gateway units offer an even simpler solution for rapid delivery of data.

As shown here in Part 2, these units support a wide variety of sensor types and connectivity options with little effort required by the user. Using these products, developers can rapidly deploy sensor networks able to deliver data required to accelerate IIoT application development.