5 Techniques to Simulate Embedded Software

One of the biggest bottlenecks in the software development process for electronic products is that hardware is not available until late in the cycle. That means embedded software developers need to combine processors and sensors as soon as possible so that they can start working.

This solution is slow and error-prone, and developers often tightly couple their software to temporary hardware. Instead of using Frankenboards, embedded developers can adopt simulation techniques. 

Simulation is the process of creating a virtual model to test and verify software without the hardware. Simulation has many advantages, such as:

While there are many different technologies available for simulation, there are five primary techniques that embedded software teams should consider to help them accelerate their software development. 

Simulation technique #1: Virtual hardware

Virtual hardware, often called instruction set simulation (ISS), simulates the microcontroller or microprocessor you use at the instruction level. This means if you are using an STM32 microcontroller, you can compile your code for the STM32, launch a debug session, and run the code on a virtual STM32!

Related:5 Key Skills You Need to Build an Embedded Systems Career

Since virtual hardware simulates the CPU, verifying that your software will ultimately work on your target can be a powerful technique. You can optimize your software well before running it on your target. However, this approach often has several challenges that limit its usefulness. 

First, open-source solutions usually are not fully implemented. That means you might find an STM32 simulator, but the peripherals you use for your application are not supported, only the Arm core. You need to modify your simulation build or add custom support for your target. 

Second, you may find that your part isn’t even supported! That means you have to develop the simulation model yourself.

Finally, if you skip the open-source route and go to a production solution, you’ll find that the available solutions are not cheap. You get what you pay for, so if you want to simulate a microcontroller fully, you will have to pay the price for the value you receive. It’s only fair. 

Simulation technique #2: Functional simulation

Functional simulation is by far my favorite technique for embedded software development. Customers are paying for features that they will use, not for the low-level firmware that we all love and focus our attention on. Functional simulation helps you verify the functionality of your application code and business logic without the low-level hardware. 

Related:3 Tips to Automating Tests for Embedded Systems

I love this technique because it helps embedded software teams develop a flexible, scalable, hardware-independent architecture. From day one, they can focus on their customers’ features, allowing them to get them in front of the customer early for feedback. 

I can’t tell you how many times I’ve seen teams spend 6–12 months writing embedded software only to get to the application code and discover that they are building the wrong thing for their customer! Functional simulation lets you focus on the customer first, in a hardware-agnostic manner, which helps you save time and money by not having to rework the system because of customer feedback. 

Don’t get me wrong, the customer will make you change things, but it’s far cheaper to make those changes early in the development cycle before the hardware has been fully designed. Then, all the embedded team needs to do when hardware arrives is connect the dots and ship their fully validated application code.  

Simulation technique #3: Hardware-in-the-loop (HITL) simulation

For some systems, testing and validating the embedded software can be challenging. When these situations arise, using hardware-in-the-loop simulation may be the right solution. Hardware-in-the-loop simulation is designed to help you test the software with real hardware interfaces. 

Related:Will AI Replace Embedded Software Developers?

For example, you might have a flight computer with the software you are working with. Instead of connecting the entire system and trying to force sensors to generate the outputs you need to test your software, you create simulations of those sensors that can feed precisely the data you need to test and validate your system!

HITL simulation allows you to test interactions with virtualized sensors and actuators, bridging pure software simulation and full system testing. I often use this type of simulation to validate diagnostic routines. For example, I’ve been involved in developing flight software for propulsion systems that have taken satellites to the moon and beyond. To test failure cases, we simulate sensors and drive them to values that indicate an issue, like a high-temperature reading. 

HITL testing can allow you to test combinations of failures that you might not typically be able to recreate in the lab. Even though it’s entirely plausible to use a hair dryer to force an overtemp warning, if you use simulation, you can build automated tests, ensuring your software continues functioning correctly as it evolves. 

Simulation technique #4: System-level simulation

System-level simulation is a technique that I often see only used in systems requiring the highest reliability level. The goal of system-level simulation is to simulate the entire system. 

Simulating an entire system involves simulating every embedded component, processor, peripheral, and communication interface. It provides a comprehensive environment to thoroughly test the system’s behavior and interactions with its environment. 

While this technique is super cool, it can be time-consuming and expensive. So, if you aren’t working on anything safety or mission critical, this technique is probably not for you, but it’s good to know it exists. 

Simulation technique #5: Behavioral simulation

The last simulation technique that can help you develop your embedded software before the hardware is available is behavioral simulation. Behavioral simulation focuses on the high-level behavior of the system you're building. It doesn’t care about the underlying implementation, just the high-level behavior.

A perfect example of behavioral simulation are state machines! You might model a heater’s behavior in a state machine. For example, a heater might have the heater off, on, or idle. You could simulate the behavior of an overall system, which might have states like armed, disarmed, and various substates in each of those states. 

A behavioral simulation allows you to create and test a model of your system. You can think of it almost like design by experimentation. You model it, test it, see the results, and then tweak the model. Repeating the process until the system behaves in a way that meets the system requirements. 

There are plenty of inexpensive tools available for creating these types of simulations, including many UML diagramming tools—behavioral simulation borders on simulation and an exercise in software architecture development. 

Your next steps

Now that you understand some basic simulation techniques, I encourage you to consider which techniques you could apply to your own development cycle. Start small and work your way up. For example, I recommend looking at functional and behavioral simulation first. I’ve found that no matter how small an embedded systems project is, these two simulation techniques still provide a reasonable ROI and can help to improve time to market and costs if done correctly. 

Simulating your embedded system might sound scary, costly, or even unreasonable. However, if you try some basic techniques, you might be surprised at how much value some simple simulation can provide. Before you know it, you’ll be delivering faster, engaging customers earlier, and preventing bugs from ever occurring in the first place.  

Happy Coding!