The Internet of Things (IoT) and Industrial Internet of Things (IIoT) nodes are gradually being applied in systems with increasing security. 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 detects that it has been compromised or that an irreversible firmware error is about to occur, the safest measure may be to power down the node as quickly as possible to avoid dangerous consequences for the node and the network.However, once the node is powered down, all volatile memory contents will be lost. Storing debug data in non-volatile memory like EEPROM or flash memory can be time-consuming and power-consuming, increasing the risk of potential damage. Additionally, if the power-up sequence is also compromised, the extent of the system’s compromise may reach a point where reading data upon power-up cannot provide trustworthy data.This article discusses how to easily connect an E-Paper Display (EPD) to an IoT or IIoT node to display the last known error, providing a visual indication of the cause of the power-down event so that technicians can take appropriate action. Then, the article takes the EPDs from Pervasive Displays and Display Visions as examples to discuss how these displays can be connected to microcontrollers and configured to provide diagnostic information with minimal or no power consumption.
High-Security IoT and IIoT Nodes
The responsibility of IoT and IIoT node designers is increasing, requiring increasingly complex security methods to ensure the proper operation of the host microcontroller. Generally, three types of security threats must be prevented:
Microcontroller firmware failures
Invalid input data from sensors, keyboards, serial peripherals, or other devices
Malicious attacker behavior
Microcontroller firmware failures can be caused by various reasons: coding errors in the installed firmware; invalid calculations leading to failures; or, in extremely rare cases, hardware failures of the microcontroller. Typically, well-written firmware can detect failures by sanitizing the inputs to subroutines and functions. In extreme cases where firmware is locked or caught in a loop, a watchdog timeout will recover the firmware by jumping to an error control subroutine or executing a hard reset of the microcontroller.In the case of invalid input data, such as a failure or tampering of an external sensor, it may lead to out-of-bounds data, which may not be appropriately considered in the application code. For example, if an environmental temperature sensor erroneously records a high temperature of 250°F in a control room with people, this could be due to sensor failure or malicious tampering. A careless firmware programmer may not have coded for such a high temperature reading, which could lead to minor issues like incorrect data logging or serious incidents such as allowing an intruder into a secure area, or critical control algorithm computation errors that could cause equipment failure or severe personal injury. The potential negative outcomes are numerous.What sets malicious attackers apart is that they may intentionally cause IoT node failures. Hacking attempts to cause failures may be detected by security routines as intrusions; however, they may also disguise themselves as firmware failures or invalid external input data. In the example, the 250°F environmental temperature reading could be due to a malicious attacker testing firmware behavior at such a high reading, intending to test intrusion methods; for example, if the 250°F environmental temperature reading is incorrectly assessed as a fire, the door may automatically unlock.
Responding to Firmware Failures
Regardless of the source of the error, firmware in high-security IoT and IIoT nodes cannot afford to fail. Any and all failures must be encoded and captured. The inputs to subroutines and functions must be sanitized, and all sensor input data must be validated. Watchdog timers must be programmed to detect excessive locking or looping code based on known run times.When a firmware failure is detected in high-security IoT or IIoT nodes, regardless of whether the failure is accidental or intentional, the firmware must capture the event as soon as possible. Common actions include attempting to compensate for the failure. For sensors that are always out of range, the firmware may set that sensor to a ‘limping mode’ to compensate for bad data until the sensor can be replaced. If the firmware routine returns erroneous results, it may be re-initialized. Generally, error codes are sent over the network to notify the network host of the problem.However, in some high-security IoT or IIoT nodes, there exists a class of special failures for which no compensation or countermeasures should be taken. This may include physical tampering detection, internal checksum failures, some built-in self-test (BIST) failures, and any failures that may be caused by compromised firmware or a hacker-invaded system. For these high-security situations, the only option may be to safely power down the node immediately. When the node fails to respond to network requests, the network host will determine that the node has powered down. If the node powers down without sending an error report to the host, and if the node ignores restart network commands, it indicates a fatal failure, and technicians must be dispatched to perform a physical inspection of the node to determine the cause.However, once the node is powered down, all volatile memory and state data will be immediately erased. This makes it very difficult to diagnose the cause of the shutdown, even if it is possible. Alternatively, diagnostic data can be stored in non-volatile memory, such as EEPROM or flash, before powering down the node. The problem is that writing to these types of memory takes time, during which the node must remain active, potentially leading to additional damage.
Diagnosing Fatal Errors with E-Paper
EPDs consume very little power and can be used to store and display error and diagnostic information just before the node powers down. After the node powers down, the EPD can maintain its display image for several days or weeks without any power. By displaying information on the screen, technicians can visually understand the reason for the shutdown, allowing them to determine whether it is safe to power the IoT node back on, or whether it should be removed from the network for further analysis.The E2271CS091 EPD module from Pervasive Displays is an example of an EPD suitable for displaying diagnostic information. This module can connect to any compatible microcontroller via the SPI serial interface and features a 2.71-inch (in.) high-contrast display (Figure 1).The E2271CS091 EPD module uses an active matrix thin-film transistor (TFT) display with a native resolution of 264 x 176 pixels and 117 pixels per inch (dpi). This allows the display to contain a wealth of information to assist technicians in diagnostics. The anti-glare screen has a nearly 180˚ wide viewing angle, making it easy to view the display content in unusual installation positions. The EPD requires a 3.0 V power supply.The host microcontroller sends data to the EPD via the SPI interface on the 24-pin ribbon connector of the display. This SPI data communication is unidirectional, meaning it is from the host microcontroller to the EPD. To transmit back from the EPD to the host microcontroller, the only communication method is through the ‘device busy’ pin on the ribbon connector, which greatly simplifies the interface and enhances the credibility of the displayed diagnostic data.If an error or hacking attempt is detected, and the error is severe enough to require the node to be powered down, the error must first be captured through firmware, watchdog, or other methods. Then, the control must be handed over to the error logging routine that sends data to the EPD. This error logging routine should be the highest priority task to prevent data interruption or corruption. For maximum reliability, it is recommended that this error logging routine be completely self-sufficient, without calling external subroutines or functions. Ideally, the error logging routine should reside in permanently write-protected flash memory to ensure code integrity, even after firmware updates.Before updating the EPD with error data, the host microcontroller should first send a soft reset command to the EPD via the SPI interface to clear the display content. It then sends a series of byte sequences representing the black and white display information, where each bit in the byte represents a pixel on the EPD. After the sequence is completed, the error logging routine can power down the microcontroller. Different manufacturers have different shutdown methods for microcontrollers, depending on architecture and manufacturer. In some cases, for security reasons, manufacturers may have undocumented shutdown methods for microcontrollers that are only available upon request. Alternatively, external circuits can be used to interrupt the power to the microcontroller; however, this adds complexity to the system, potentially reducing reliability. Therefore, firmware-controlled shutdown of the microcontroller is the best choice.To assist in the development with EPDs, Pervasive Displays provides the B3000MS034 EPD expansion kit (Figure 2). This kit includes an expansion board with a connector for the 24-pin EPD display and several 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 toolkits but can also be used with other development toolkits. A 20-pin jumper cable can connect to the 20-pin 90˚ socket connector, and when soldered to the expansion board, it allows monitoring of the control signals sent to the EPD during development.Another EPD option is the EA EPA20-A from Display Visions (Figure 3).This EPD features a 172 x 72 grayscale display and also communicates with the host microcontroller via SPI interface. The power consumption of this EPD is extremely low, requiring a single 3.3 V power supply and consuming only 40 milliwatts (mW) during display content transitions. The Display Visions EA EPA20-A EPD can also maintain the display content without power.
Conclusion
High-security IoT and IIoT nodes sometimes must power down to address fatal firmware errors or detected threats. This may result in the loss of all volatile data, including the internal state of the host microcontroller. However, state and diagnostic data can be sent to the connected EPD before power-down and displayed for days or weeks. This provides technicians with the necessary information to determine the cause of the shutdown and take future preventive measures when necessary to protect and ensure the security of the nodes and the network.Author: Bill GiovinoSource: Digi-Key
Disclaimer：This article is original by the author, the content of the article is the author’s personal opinion, and the electronic enthusiast network reprints it only as a means of conveying a different viewpoint, which does not represent the electronic enthusiast network’s endorsement or support of this viewpoint. If there are any objections, please feel free to contact the electronic enthusiast network.
