The Internet of Things (IoT) is radically changing the way embedded systems are designed. In the past, devices were often designed to provide specific software functionality, and that functionality pretty much stayed unchanged for the life of the system. A minor update or two might be performed to fix a few critical bugs, but new features typically weren’t added once the device was deployed. And notably, these devices often had little to no security concerns. Never change a running system, right?
This approach to design means that the first priority is to get things working, and then begin optimizing to reduce resources available to the minimum needed for operation. If the amount of memory needed was initially overestimated, it would then be possible to swap in a smaller – and cheaper – memory to reduce the bill of materials (BOM) cost. Any potential future (and limited) updates could simply be done from a USB stick with minimal fuss.
A lot changed now that we’re connecting everything to each other and to the Internet: security has become a must-have both to keep interlopers out of the system and off the network that system is connected to, as well as to protect the data that’s being shared. The challenge is that security changes constantly, whether it’s necessary cryptographic technology advances or maintenance of the core components used in many connected systems throughout the world.
Consider the recent OpenSSL-related issues that require a somewhat frequent update cadence to address the vulnerability of the day. It’s inevitable that today’s strong security will look weak in a few years. If a system will be deployed for the extended life cycles of a typical industrial or medical embedded device (7-10 or more years), the system should be designed with the goal of including regular critical system updates to ensure that users are always protected by the latest technology.
This also includes how devices in the field are upgraded, whether it’s the actual delivery using a device’s wired or wireless network connection, or through secure local upgrade methods. Another key element to consider is that the software/firmware itself should be authenticated to avoid malware being installed in the guise of a sanctioned update.
The big change that this often brings about is how design and specification of systems is handled. This includes traditional hardware related aspects and their respective BOM-related impacts, such as memory population and processor platform choice. Another consideration is the type of network technology being integrated for connectivity purposes. It also extends to the software-related aspects of the design effort and the suppliers’ expertise.
This future-proofing affects not only design, but also the many partners that organizations work with. Suppliers, for example, must provide a sound security strategy for embedded devices. This includes software and hardware frameworks, as well as the ongoing support that can be built on with confidence. The connected world drives changes with many benefits for all involved, but it also means that your organization and its partners must work differently. It’s absolutely paramount to align with organizations possessing the expertise and building blocks for secure connected systems both now and in the future, and that partners have a proven track record and the performance to keep them around long-term. So, it’s possible to change the running system, in this case for the purpose of giving customers the confidence that their systems won’t be compromised now or in the near future.