Embedded software architects are defining the future generation of a medical, industrial, and/or other network-connectable pieces of equipment and they face a variety of challenges: Low power consumption, compatibility with legacy proprietary devices, functioning standalone versus connected, security, upgradeability, configurability, compliance to multiple standards, government regulations, manufacturing costs and more.  And once the major software and hardware components are “locked in stone,” they still have to wait, sometimes up to three years, for a regulator to approve the product before it can get into the users’ hands. That means potentially a component rejected today due to its prohibitive cost could have provided functionality that is going to be essential tomorrow.

This cycle of design today for future commercialization will continue to be a challenge. Given the trends in the IoT industry today of more data bandwidth, faster networking speeds, new protocols, and advancing functionality, this article discusses a few recommendations to consider in the design plan.

Field Upgradeability

Most likely, the product is going to be in the field for many years to come and the business will have to fix any defects, upgrade functionality (preferably remotely) and/or perform field support. The device will need to keep up with operating system (OS) patches and newer technologies. As devices are not always connected to the network, updating them every sprint is not an option. Unfortunately, there are presently no industry standards that ensure ease and security of field upgrades. Designers should consider the following:

• Authentication and integrity checks of the new code as it is transported
• Authentication of the user role that is allowed to perform upgrades
• Upgrades of specific components versus a full firmware upgrade. It helps to have microcontroller support partitioning of non-volatile memory, to build in the needed flexibility to logically separate portions of the code.
• Disabling or making inaccessible other methods of erasing and rewriting non-volatile memory (e.g., disabling JTAG interface when the device goes into production). At the very least, designing-in a tamper evidence that helps detect whether the interface was used.
• Additional non-volatile memory for storing a failsafe image

The availability of these items should also be discussed with the hardware and OS vendor to ensure alignment with their product line features is considered.

Random Numbers and Entropy Source

Modern cryptography and transport protocols rely on random numbers. An OS, such as Linux, may offer a convenient interface for generating one (e.g., /dev/random or /dev/urandom). However, one cannot assume that the environmental noise, which the OS aggregates to provide you a random number, is of sufficient quality or entropy. It’s important to discuss the requirements and design assumptions with the microcontroller and OS vendor. An independent source of entropy may be needed; a hardware True Random Number Generator (TRNG) device that acts in accordance with the Random Bit Generators Recommendation for the Entropy Sources Used for Random Bit Generation may be an option.¹

Second Processor

Consider the use of redundancy, such as using redundant microcontrollers or a microcontroller with two independent cores. This design option will enable the flexibility to do the following:

• Offload time-consuming operations to be done in parallel
• Have redundant implementations for functions that are critical and must not have a single point of failure
• Have the secondary processor be an independent “watchdog” for the primary one

Cryptographic Accelerators in Hardware

Cryptographic accelerators are needed because cryptographic algorithms are computationally intensive.  Cryptography is less efficient when implemented in software, causing increased latency in real-time communication. Consider this latency in the risk analysis and functional analysis to assure the intended use of the device is not compromised.

Diagnostics for the BSP

Many standards require a device to perform self diagnostics upon power-up and periodically during operation. IEC 62304, a medical device software lifecycle standard, requires consideration of self-diagnostics as part of a risk control strategy. FIPS 140-2 calls for self-tests of cryptographic functions and integrity checks of executable code. Discuss BSP diagnostics of the microcontroller and OS with applicable vendors to assure any identified risk control measures are suitable.

Coupling of Legacy Standalone and Modern Networking Components

This consideration is for devices that used to work standalone, but now have to be connected. Frequently, an extra board with WiFi functionality is added to the legacy device for this purpose. While this design may have started out as a workaround, it actually can have an advantage from a cybersecurity point of view: It can be used to limit the exposure of the critical control structures of the product to the network. Maintaining a minimal, well-controlled interface between the two can minimize the need to test the legacy components for cybersecurity.

Unique Identifiers for Devices

As the number of connected devices grows, asset management is becoming a necessity. FDA has recently mandated Class II and III medical devices to bear a Unique Device ID (UDI) with a 2018 deadline for Class I devices.² At the moment, it is a labeling requirement with minimal implications for the software. However, it may be appropriate to anticipate that other IoT decision-making bodies may also move towards standardizing unique identifiers (e.g., software ID tags) to be reported by software through an interface. Looking forward, building in a capability of placing a unique ID in protected memory during the manufacturing process may come in handy.

With Moore’s law holding true as strongly as ever, creating a product that will remain essential for the user for decades seems like a futile endeavor. However, regulated industries value safety and security more than they do the “coolness factor.” They also invest substantial resources into their infrastructure, which makes them reluctant to fix what is validated and not broken. Hopefully, the considerations outlined in this article will help businesses design devices that will keep up with the demands of a connected world for years to come.

References

1. Recommendation for the Entropy Sources Used for Random Bit Generation. (January 27, 2016). Retrieved from http://csrc.nist.gov/publications/drafts/800-90/draft-sp800-90b.pdf
2. FDA. Unique Device Identification. Retrieved from https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/

Resource

1. Chatwin, L. (September 2016).“Requirements for US FDA Unique Device Identification”. Retrieved from http://medicalsolutions.ul.com/requirement-for-u-s-fda-unique-device-identification/.