“Internet of Things (IoT) and Industrial Internet of Things (IIoT) nodes are increasingly being used in increasingly secure systems. In these systems, the security of the entire network is more important than the functionality of individual devices on the network. This means that if an IoT node finds itself compromised, or an unrecoverable firmware error is about to occur, the safest measure may be for the node to power down as soon as practicable to avoid potential node and network failures Dangerous consequences.
“
Author: Bill Giovino
Internet of Things (IoT) and Industrial Internet of Things (IIoT) nodes are increasingly being used in increasingly secure systems. In these systems, the security of the entire network is more important than the functionality of individual devices on the network. This means that if an IoT node finds itself compromised, or an unrecoverable firmware error is about to occur, the safest measure may be for the node to power down as soon as practicable to avoid potential node and network failures Dangerous consequences.
However, once the node is powered off, all volatile memory contents will be lost. Storing debug data in non-volatile memory such as EEPROM or flash memory consumes time and power and increases the risk of potential damage. Additionally, if the power-up sequence is also compromised, the system may have been compromised to the point where reading back data at power-up can no longer provide trusted data.
This article describes how to easily connect an Electronic paper Display (EPD) to an IoT or IIoT node to Display the last known error, providing a visual indication of the cause of a power outage event so technicians can take appropriate action. The article then discusses how these displays can be interfaced with a microcontroller and configured to provide diagnostic information with little or no power consumption, using e-paper displays from Pervasive Displays and Display Visions as examples.
High Security IoT and Industrial IoT Nodes
IoT and Industrial IoT node designers are increasingly responsible, requiring increasingly sophisticated security methods to keep the host microcontroller up and running. In general, there are three security threats that must be guarded against:
・ Microcontroller firmware failure
・Invalid input data from sensors, keyboards, serial peripherals, or other devices
・ Behavior of malicious attackers
Microcontroller firmware failures can be caused by a variety of causes: errors in coding in the installed firmware; invalid computations that cause the failure; or, in extremely rare cases, hardware failures in the microcontroller. Often, well-written firmware can detect failures by sanitizing input to subroutines and functions. In extreme cases where the firmware is locked or stuck in a loop, the watchdog timeout will recover the firmware by jumping to the error control subroutine or performing a hard reset of the microcontroller.
In the event of invalid input data, such as a malfunctioning or tampered external sensor, out-of-limit data may result that may not be properly accounted for in the application code. For example, if in a occupied control room, the ambient temperature sensor incorrectly registers a high temperature of 250°F, this could be a faulty sensor or malicious tampering. A careless firmware programmer might not have coded such high temperature readings, which could lead to trivial things like incorrect data logging, or serious mishaps like allowing an intruder into a secure area, or it could cause equipment failure or critical control algorithm miscalculation for serious personal injury. There are many potential negative outcomes.
Malicious attackers are different in that they may intentionally cause IoT nodes to fail. A failure caused by a hacking attempt may be detected as an intrusion by security routines; however, it may also be disguised as a firmware failure or invalid external input data. In an example, an ambient temperature reading of 250°F could be due to a malicious attacker testing firmware behavior at such a high reading, with the intent of testing an intrusion method; May be unlocked automatically.
React to firmware failures
Whatever the source of the error, microcontroller firmware cannot tolerate errors in high-security IoT and IIoT nodes. Any and all failures must be coded and captured. Input to subroutines and functions must be sanitized, and all sensor input data must be validated. The watchdog timer must be programmed to detect excessively long locking or looping code based on known runtime.
When a firmware failure is detected in a high-security IoT or industrial IoT node, whether the failure is accidental or intentional, the firmware must capture the event as soon as possible. Common actions include attempting to compensate for failures. For a faulty sensor that is consistently out of range, firmware may set a “limp mode” for that sensor to compensate for bad data until the sensor can be replaced. Reinitialization may occur if the firmware routine returns an incorrect result. Typically, an error code is sent over the network to notify the network host of the problem.
However, in some high-security IoT or IIoT nodes, there is a special class of failures for which compensation or countermeasures cannot or should not be taken. This may include physical tamper detection, internal checksum failures, some built-in self-test (BIST) failures, and any failures that may be caused by compromised firmware or hacked systems. For these high-safety situations, the only option may be to immediately and safely power off the node. When a node fails to respond to a network request, the network host will determine that the node is powered off. If the node loses power without sending an error report to the host, and if the node ignores the network command to restart, then a fatal failure has occurred and a technician must be dispatched to physically inspect the node to find out why.
However, once the node is powered down, all volatile memory and state data will be erased immediately. This makes it very difficult, if not impossible, to diagnose the cause of the shutdown. Alternatively, diagnostic data can be stored to non-volatile memory such as EEPROM or flash memory before powering down the node. The problem is that writing to these types of memory takes time, during which time the node must remain alive, potentially causing additional corruption.
Diagnosing fatal errors with e-paper
EPD consumes little power and can be used to store and display error and diagnostic information just before the node is about to lose power. After a node is powered off, the EPD can maintain its display image for days or weeks without any power. From the information on the display, technicians can visually understand the reason for the shutdown to determine if it is safe to power up the IoT node or if it should be removed from the network for detailed analysis.
Pervasive Displays’ E2271CS091 EPD module is an example of an EPD suitable for displaying diagnostic information. The module connects to any compatible microcontroller via the SPI serial interface and features a 2.71-inch (in.) high-contrast display (Figure 1).
Figure 1: The E2271CS091 EPD module has a 2.71-inch high-contrast display with a resolution of 264 x 176 pixels. The module has a wide viewing angle and can be connected to any compatible microcontroller via the SPI interface. (Image credit: Pervasive Displays)
The E2271CS091 EPD module uses an active matrix thin film transistor (TFT) display with a native resolution of 264 x 176 pixels and 117 dots per inch (dpi). This allows the display to contain a wealth of information to assist the technician in diagnosis. The anti-glare screen has a wide viewing angle of nearly 180˚ for easy viewing of displays in unusual installation locations. This EPD requires a 3.0 V power supply.
The host microcontroller sends data to the EPD through the SPI interface on the display’s 24-pin ribbon connector. This SPI data communication is only unidirectional, from the host microcontroller to the EPD. The only way to communicate from the EPD back to the host microcontroller is the “device busy” pin on the ribbon connector, which greatly simplifies the interface and increases the confidence in the displayed diagnostic data.
If a bug or hack is detected, and the bug is severe enough to shut down the node, the bug must first be caught by firmware, watchdog, or other means. Then, control must be handed over to the error logging routine that sends data to the EPD. The error logging routine should be the highest priority task to prevent data interruption or corruption. For maximum reliability, it is recommended that the error logging routine be completely self-contained, with no calls to external subroutines or functions. Ideally, error logging routines should be in permanent write-protected flash to ensure code integrity, even after a firmware update.
Before updating the EPD with incorrect data, the host microcontroller should send a soft reset command to the EPD via the SPI interface to clear the display. It then sends the black and white display information in a sequence of bytes, each bit of which represents a pixel on the EPD. After the sequence is complete, the error logging routine can shut down the microcontroller. Microcontrollers from different manufacturers have different ways of shutting down because it depends on the architecture and the manufacturer. In some cases, due to safety concerns, the manufacturer may have an unspecified way of shutting down the microcontroller, which is only available upon request. Alternatively, external circuitry can be used to interrupt power to the microcontroller; however, this adds complexity to the system, resulting in reduced reliability. Therefore, the microcontroller’s firmware shutdown control is the best choice.
To aid development with EPD, Pervasive Displays offers the B3000MS034 EPD Expansion Kit (Figure 2). The kit has an expansion board with a connector for this 24-pin EPD display, and there are also connectors for other Pervasive Displays EPDs that require 40-pin and 26-pin connectors. The expansion board is compatible with Texas Instruments’ LaunchPad development and evaluation kit, but can also be used with other development kits. The 20-pin bridge cable can be connected to the 20-pin 90˚ header connector, and when soldered to the expansion board, the control signals sent to the EPD can be monitored during development.
Figure 2: Pervasive Displays’ E2271CS091 EPD Module Expansion Kit includes a 24-pin connector on the expansion board for a 24-pin ribbon cable to connect to the display. Also included in the kit is a bridge cable and a 90˚ 20-pin header. (Image credit: Pervasive Displays)
Another EPD option is Display Visions’ EA EPA20-A (Figure 3).
Figure 3: The EA EPA20-A EPD from Display Visions is a 172 x 72 display that maintains display status without a power connection. (Image credit: Display Visions)
The EPD has a 172 x 72 grayscale display and also communicates with the host microcontroller using the SPI interface. The EPD is extremely low power, requiring a single 3.3 V supply and only consumes 40 milliwatts (mW) of power during display transitions. Display Visions’ EA EPA20-A EPD can also hold the display without powering up.
Epilogue
High-security IoT and IIoT nodes sometimes have to be powered off in response to fatal firmware errors or detected threats. This can result in the loss of all volatile data, including the internal state of the host microcontroller. However, status and diagnostic data can be sent to the connected EPD prior to shutdown and displayed for days or weeks. This provides technicians with the information they need to determine the cause of the shutdown and, if necessary, take future preventive actions to protect and secure the node and network.
The Links: 2ED300C17-ST 6MBI450VM-170