Simulating Embedded Devices

SIMULATIONS AND EMBEDDED devices

A simulation generally refers to a computer program that models a system of some kind, for example, an embedded device. An embedded device is a computing device that is highly specialized for one or very few tasks (please see Diagram A). Simulations can be used to model events that are difficult or impossible to validate in the real world. They are widely used to study and come up with solutions to possible problems that could occur in these systems (please see Diagram B). If a simulation accurately models an embedded device, it can effectively be used to masquerade in place of the embedded device itself. This can prove useful when the embedded device is:

• Not-available (i.e. still under development) or scarce
• Costly
• Not performing correctly

In these situations, a simulation model may allow:

• Software development to proceed
• Testing of other devices that interface with the embedded device
• Comparison of baseline functionality for verification or debugging purposes
• Possible cost savings

Thus, the simulation model can be used in numerous phases from pre-production to post-production applications.

Benefits of Simulating an Embedded Device

Increased Efficiency

Developers can use a simulation to increase efficiency and accelerate the schedule by allowing them to test their program independently of the hardware. In most cases, the developer would be working on the program for embedded software before

they have access to the hardware, and without the actual device, the software operation cannot be tested. With a simulation, the program’s algorithms can be tested for errors before testing on the actual device. By testing the embedded software with a simulator, the logical parts of the algorithms can be debugged and the testing with the device can be more focused on the possible physical limits and/or errors. This process improves efficiency and accelerates the schedule, as it allows for in-depth testing to be independent of the device.

Controlled Test Environment

Simulating embedded devices can also be used to test repeatedly without user input. Since the simulation is another program, it can be reset or have new test values generated upon command. This allows the developer to rapidly test the software without needing to reset or change the physical device to the state they want to test. By testing with a simulation, developers can control what results to look for. Due to the fact that the simulator is a computer model, it will not be affected by environmental errors. This feature allows the developer to test the software in a controlled environment. 

By testing in a controlled environment, the functionality of the program, when the device is in perfect condition, can be tested.

The developer can also manipulate the simulation to test what the program would do if an error occurred.

For example, you can test what the embedded software would do if:

• Not enough information was gathered
• A connection was broken or lost during operation
• The operation was interrupted partway through
• Invalid or corrupt data is input

Ability to Test Malfunctions

Developers can also use a simulation to test where a malfunction is occurring, whether it be in the hardware, firmware, or software. As the simulation will have a constant state and will not be affected by physical errors, it can be used to test if an error is occurring because of the software or the hardware. If an error occurs when testing with both the embedded device and the simulator, it could be an indicator that there is something wrong with the algorithm. If the error only occurs when testing on the device, it could be an indicator that there is something wrong with the hardware or firmware.

Possible Problems a Simulation Could Create

While a simulation is a great tool to use for embedded software development, if the simulation does not accurately represent the device, it could decrease efficiency by creating more errors. Without the simulation properly representing the embedded software, any testing done would be counterproductive, as using the simulation will create more errors. Also, the simulation is not able to be used to test malfunctions with the device, as any problems that occur in an inaccurate simulation may not exist in the actual device. Additionally, if the simulation accidentally ignores a physical limit of the device, the software development may not work and could potentially break the device. It would be difficult to catch the ignored physical limits, due to the simulation being another program, which is not hindered by physical limitations unless they are coded into it. This would cause the errors to remain unnoticed until the program is tested on the device. By continuing embedded software development in order to match an inaccurate simulation, the developer could end up behind schedule, as there is more work required to redo the testing and debugging with the actual device.

Please see below for some examples of problems that could be overlooked:

1. Movement Range: Telling a motorized device to move outside of its movement range will not have any obvious effect on a simulated system that does not limit the range, but when the real device tries to move to the same location it will not be able to.
2. Movement Position: Telling a robotic arm to move to a position and then consulting a camera what color ball it sees will return the expected color with the simulation because the simulation knows where the arm is moving, but the real arm will take time to move before it will reach the ball it is supposed to look at.

When developing software for embedded computing devices, a simulation is a great tool to use - as long as it is accurate! If the simulation is accurate, this may help to accelerate the project schedule, but if the simulation is inaccurate, it could potentially lengthen the schedule. Therefore, when using a simulation to develop software for an embedded device, it is important to make sure the simulation accurately represents the device you are developing.