Optimizing Firmware: The Key to Shipping IoT Devices on Time

Every product manager knows the complexities involved with shipping a device on time- complexities that result in 45% of products missing their launch date. Orchestrating mechanical engineering, electrical engineering, manufacturing, test automation, marketing, and more is difficult. Each one is challenging on its own, but all are made more complicated because most of these don’t move forward on the same timeline. 

Following a new product introduction (NPI) timeline while simultaneously focusing on firmware processes can help streamline development and increase the likelihood of meeting development goals. Inspired by Apple engineers, the NPI is a helpful guidepost consisting of six milestones and associated timeframes for teams aiming to ship a well-understood product as quickly as possible. Teams that fall into this category can expect that the timeframe from prototype to launch will be about 12-18 months, depending on the complexity of the device.

Within that model, there are additional elements in firmware development that pave the way to optimize the NPI process. Why focus on firmware? The firmware supports your overall hardware roadmap dynamically, and by ensuring best firmware practices, you can reduce production challenges at each development stage – and get your product out the door, on time. 

Below we’ll touch on the key milestones, then explore four ways to disentangle your hardware and software to save time and create a timeline less likely to slip.

Proto Phase, 12 weeks 

In prototype–the first and longest stage–engineers are mainly determining what exactly they want to build. There are a lot of iterations, maybe 3D printing prototypes or a dev board for electrical and firmware engineers to work on. While this is the phase with the greatest latitude, twelve weeks isn’t very long as it requires many decisions, such as which sensors you need and how everything integrates. The goal is to come up with a functional product architecture. 

From a firmware perspective, before a proto build is ready, a team will have to get the software to a milestone I call “Bring up Complete”. This milestone requires teams to have written the minimal driver code for every major subsystem to verify—at a command-line level—that each is working and that the product’s software enables clean communication to each one. 

By the end of the proto phase, teams will likely end up with a few “works like”  and “looks like” prototypes. While not final, these prototypes can be shown to executive teams and some customers to roughly represent the final product. 

8 Weeks Between Each

The next three milestones essentially fall into equal timeframes, and dev teams can expect to spend roughly the same amount of time in each phase: engineering validation testing (EVT), design validation testing (DVT), and production validation testing (PVT). For each phase, account for at least two weeks for the actual build, and a minimum of three weeks between each phase for engineers to take in the data from the build, make changes, iterate on the design, troubleshoot any issues, and submit a design for the next build. Realistically, expect to spend around eight weeks between each milestone. 

EVT (8 Weeks)

After exiting the proto, teams will have a handful of configurations, and EVT is the time to finalize engineering designs. EVT is a crucial phase to shipping on time; a successful exit from EVT typically means an on-time launch. The product won’t be cosmetically perfect – likely being manufactured with some soft tools, with test stations that are not final, and with low yield– but an EVT device should look and feel roughly like it will in the end. It should have a couple of configurations that derisk the major subsystems of the program and the overall success criteria that one configuration works.

Before exiting EVT, the firmware will need to reach HW test complete, which is when there is minimal firmware that can let a user try every major functionality of the device. It probably isn’t going to work very well, and it doesn't have all the bells and whistles, but if the device has a display, a user can look at the display and see a simple UI. If the device has audio, you can play an audio file, etc. 

Remember that as you iterate, you may have to pivot and spin up again, leading to EVT 1, EVT 2, EVT 3, etc. Each EVT design iteration will require, at minimum, four additional weeks, which can lead to significant delays. 

Design Validation Test (DVT), 6–8 Weeks

During DVT, a team will not be running at production yields or manufacturing as fast as they want, but they will have one final configuration that’s making it through all the manufacturing stations and passing all tests. 

Between EVT and DVT, manufacturing software needs to be locked. DVT is when production lines will be operating more or less as they will be during ramp. Therefore, whatever software is running on the device as they go through the manufacturing line has to be completed by DVT. 

Production Validation Test (PVT), 6–8 Weeks

The PVT phase is used to optimize manufacturing. Ultimately, the goal is to get the yields and the speeds required to hit your ramp targets.

In PVT, teams will be doing the pre-run for the ramp, and launch firmware needs to be complete.  PVT units are “revenue-able” and can sometimes be sold to the market, provided they have no major issues. It’s critical they have the firmware that will go on the device that gets sold. 

Ramp, 4+ Weeks

Exiting EVT/DVT/PVT, teams will be manufacturing at the ideal speed and yield. The next phase is to enter into ramp—manufacturing enough of your product to launch.

Often there’s a short pause for final tweaks and to ensure that the right parts are in the factory. And during a ramp, you’ll be accumulating inventory by running your line 24/7 and shipping devices to resellers. 

Day 0 firmware is the final milestone, a release that you do after the device has shipped, but before it’s unboxed by the customer. 

Launch

The product is final, in stock at retailers and resellers, and available to end-users to purchase. 

Considering the timing variables and the design and engineering complexity, many product managers look to optimize this process. However, since firmware supports the overall hardware roadmap differently depending on the development phase, here are four ways to disentangle your hardware and software to save time and create a timeline less likely to slip. 

1. Deploy test-driven development: building software and firmware against a software test harness rather than real hardware. For example, you might use unit testing frameworks like CppUTest, or simulation, like Renodes, to simulate your hardware and do your software development against that. This approach has many benefits: it lets you start software development even when your hardware isn’t ready, it speeds up iteration, and it creates a robust set of tests that can be used to support development.
2. Implement Day 0 updates: techniques meant to prepare a software update that’s applied to devices at unboxing. A Day 0 update shifts the timing; rather than having final firmware completed at the manufacturing stage, it extends the complete time to when customers have devices in hand. This approach lets you decouple dependency between ramp and software GM and extend your software development schedule for four weeks or more. 
3. Use a strong hardware abstraction layer (HAL): use of a cross-platform operating system and hardware abstraction layers that can be easily ported to new hardware. Zephyr Project is an excellent open-source RTOS option with strong backing from semiconductor and device manufacturers. While this is a little more work up front, it offers three key benefits. First, it allows you to decouple firmware from the underlying hardware, making it easier to do test-driven development and build in isolation. Second, it creates optionality, a critical feature in the event of supply chain constraints. If you need to change out a microcontroller, or another component, using a HAL allows you to make the change with less pain. Lastly, it allows you to lay the ground for code reuse on future programs. Being able to carry the software you build from program to program is highly valuable, and using a HAL enables you to build multiple programs out of the same code base. 
4. Split manufacturing and app firmware: use of purpose-built firmware on the manufacturing line that changes very rarely and is completely separate from the application firmware. While this is very tactical, its impact shouldn’t be underestimated. Manufacturing firmware runs on the assembly line and on the devices during calibration and other tests. Application firmware isn’t loaded until the very last test station on the line, letting you iterate on the application firmware without impacting the manufacturing firmware. Splitting the two allows you to make changes to things like UI display without the risk of introducing a regression on the manufacturing firmware. It also lets you continue working on application firmware after you’ve locked manufacturing in the DVT stage.  And it allows you to save code space because you don't carry your manufacturing code inside of your main application. One caveat is that you may discover dependencies between manufacturing and app firmware, and you need to have a way to manage the dependencies, like a sensor configuration. 

Shipping on time is the top concern for device engineers everywhere. By deploying these firmware tools and techniques, you can reduce the likelihood of missed milestones without risking product quality.