Best Practices for IIoT Firmware
Connected sensors are becoming increasingly ubiquitous across all sectors, and industrial and scientific products are no different. This category is becoming known as the industrial internet of things, or IIoT. When designing an IIoT device, engineers must consider a range of criteria that may not apply to other product categories. Industrial products are expected to be reliable, rugged, and able to serve their purpose for an extended period of time. And the environment these products operate in is particularly intense, with many environmental stresses and unique challenges for human-machine interaction. The goal of this post is to give an engineer new in the IIoT space a checklist that can spur consideration for product requirements from a new perspective.
1. Model the system first
As a team sits down to begin the design of a connected device, it can pay dividends to simply make a system model first. The goal shouldn’t be to make a perfect architecture but rather to spur the designers to consider the important aspects of the device’s data transfer model, logging schema, and operational states. This may already be the first step for many new projects, but focusing on the following topics might aid in creating a solid IIoT product.
Typically the design process begins with modeling the operational (or non-operational) states of a device. Knowing where the device should go when any given event happens helps to make a device that will not easily go into an unknown state, something that is unappetizing for IIoT applications. This state model does not have to be complex, a diagram of circles (states) and arrows (events and errors) will suffice as long as it covers all of the anticipated states of the firmware and the hardware. Devices may commonly have ubiquitous states, like power-up, initialization, and operational, as well as error and firmware update states. Next, engineers should consider what data will be sent by the device and other parameters such as data size and transmission frequency. Knowing these factors can help engineers write better requirements, and it could even allow for certain communication protocols to be eliminated due to constraints they may violate. With a state diagram and a solid idea of the communication for an IIoT device, engineers will end up already with a pretty good idea of what their product will look like upon completion.
A simple example of a state diagram
2. Design for security from the start
The topic of security almost always bubbles up to the top in conversations regarding good practices for IoT devices. Security may have been the topic of IoT news coverage lately, considering some of the high-profile exploits which have been uncovered in recent years. It also gets the spotlight due to the exposed nature of most devices in the category. Engineers need to understand that effective security is something that must be talked about and designed for at all stages of development, not something that gets bolted onto a product at the end. Engineers should also accept that no security is scheme is perfect, so a device that has security in mind at every layer is better than an otherwise insecure device hiding behind one big show of defense. This section will certainly not be exhaustive, but might hopefully hit on some of the big items that can be designed into a product. One good source of security information and practices for embedded devices is the IoT Security Foundation.
Bigger security items for the design team to consider using early on cover a large portion of the device lifecycle after it leaves the engineering teams hands. Provisioning and authentication are two ways to make sure that IoT devices are really who they say they are when they’re talking to other nodes or gateways. If the team decides to use these methods, there should be a secure way to manage device security keys so that the same key doesn’t end up getting used for every device out of convenience. With these keys, an authentication scheme can be created which will tie into the device state diagram that’s already been created. To mitigate the risk of exposed devices operating in the field, encryption should definitely be considered for the main communication channels of the device but also for any important information that will be transferred internally between the processor and peripherals. Many secure options exist which take up a small memory footprint and can be dropped into code easily. With an IIoT device up and running, it is also valuable to be able to monitor and detect threats to the device as they appear. Third-party fleet management tools exist to do just that, and can allow customers to identify and deal with compromised devices safely, while simpler tactics like software trip wires can be used to send notifications to the user that something’s up or lock down the device. With these measures in place, designers will be on the road to a modern and secure product.
3. Firmware Updates
Firmware updates are an inevitable part of designing and building IIoT devices, even before a prototype device is built there will likely be at least a few revisions of firmware produced for it. This process can be hard enough when there is only a handful of devices floating around the lab during design, but it gets even harder once there are devices deployed out in the field. These updates are essential for connected devices as they can improve reliability, increase product lifetime, as well as maintaining product security as new threats are produced seemingly weekly. It comes as no surprise then that engineers should have a plan when it comes to updating their devices in the field. This update path should take into account the installation conditions for the end customer and the accessibility limitations that may be a result. A good update path will be a win for engineers due to ease of development and a win for customers due to a more seamless product experience. There are a number of methods for updating devices, so engineers must pick the one that best suits their device. For wireless updates, there are even backend services that can handle updates for you and may ease the development burden. Given the number of avenues one can take, you’re sure to find an update method that works.
Update Failure Detection and Recovery
Another aspect of firmware updates to consider in-depth is what will happen to an IIoT device in the case of a failed firmware update. There are many moving parts to normal firmware updates and they don’t always run smoothly. Device uptime is important for all connected devices and this is especially true when those devices are part of a control or monitoring system for a company. Having a failed firmware update result in your fleet of devices bricked at a customer site is not acceptable, and engineers should develop ways to minimize results like that. A few ways to do that are to have devices accept updates and boot from separate regions of memory, or to validate incoming code before running the update using checksums or CRC checks to abort if portions of the update are corrupted.
Summary
IIoT and connected devices in general run the gamut in terms of functions and performance, and that variance can make designing their firmware seem complex. While there may not be one set of absolute design rules for engineers to reference they may benefit from these basic best practices. Systems may be able to prioritize only parts of what was discussed here, but engineers who model their device execution and at least think about the topics above will be more likely to improve the design process and end product. A device designed with these guidelines in mind will run reliably, be more secure, and be easier to continue developing and improving as it gets used in the field.
For those who are unfamiliar with some of these ideas, Dojo Five is excited to help engineers looking to design new devices. These best practices come from the experiences that we’ve had designing for customers, both good and bad. If this post gives an engineer some solid first steps on their own device then that’s great. If Dojo Five can help you with your next device, even better, check out our site and see how our embedded experts can help bring your IIoT device from design to production. Don’t hesitate to reach out and chat with us on LinkedIn or through email!