How much detail should a simulation model have?

Testing software on real hardware can be tedious and slow. With Studio Technix, you can abstract the hardware and program against a virtual mockup of the system, that is, a simulation model with virtual sensors, actuators and other external devices.

But how accurate should such a simulation model be?

How much detail should a simulation model have?

A model is an abstraction

A model is an abstraction, and when you make an abstraction, you leave out certain details. That is ok, because in many cases you don't need the uncessary details when looking from a specific viewpoint of the system.

From a software point-of-view, many pheripherals and external components do not need to be simulated using a detailed physical model to get accurate results. Instead, a functional model that describes the behavior of the component at a higher, more abstract level is accurate enough.

By simulating at the functional level, the simulation can run in real-time, and the software developer only needs to be aware of the component properties that are relevant to their program.

An example, please?

Let's make the discussion more concrete.

Assume you are developing a smartwatch. This smartwatch contains an accelerometer and when there is a sudden high peak in acceleration that can mean that the person made a severe fall. In that case the smartwatch should automatically call the emergency services in case the person is unconcious.

Smartwatch Assistence

An accelerometer is a small chip composed of tiny vibrating materials and an electronic circuit consisting of transistors, resistors, capacitors, etc. Moreover, it communicates with the microcontroller over a communication bus, like I²C, which happens over two wires (in addition to the ground and power wire).

Like all real-world devices the accelerometer obeys the laws of physics, such as the laws of motion and electromagnetism.

The question is: when trying to simulate the fall and emergency call scenario, do we need all this level of detail?

The answer is probably clear: you do not. As a application programmer, we are only interested in the functional behavior of the accelerometer, that is, a device that provides an acceleration value in the x-, y-, and z-direction. We also don't need to know that the I²C is a bus with two wires with an open drain design requiring a pull-up resistor. We only have to know that I²C is a bus with an addressing protocol over which we can send bytes.

Functional versus physical level

These two abstraction levels are often refered to as the functional versus the physical level. From a software point of view, the functional level is most relevant.

The distinction is further visualized on the following figure. Move the slider left and right to compare a physical with a functional model of an accelerometer that is connected to a microcontroller.

A functional simulation model A physical simulation model Drag to compare

Simulation models of Studio Technix

Since Studio Technix is a tool to help programmers develop more functionality faster and add more intelligence to IoT and other smart devices, it is mainly aimed simulating the higher, functional level.

So the components you can find in the libraries of Studio Technix are functional models. For example the Push Button component has a single output port of type bool indicating that it is pressed or not. Similarly, the Character LCD component has a single input port of type byte, through which it receives byte commands to write characters to the display, clear the display, move the cursor, etc.

The component library of Studio Technix


By design, Studio Technix abstracts the hardware at a higher level and provides a series of components to virtually simulate sensor devices, actuators, or other output devices.

For this reason, Studio Technix is an appropriate tool to simulate the functional logic of the application. For example to test scenarios like the emergency fall, or other scenarios involving the processing of multiple sensors and controlling of multiple output devices.