To Develop Software without Hardware?

In embedded development this dilemma is encountered very often. Software development must start, but:

  • the target hardware does not exist yet
  • the "machine" to be controlled is not ready either
  • the user interface is unclear, many stakeholders are involved: marketing, management, software, hardware, mechanics, industrial design

Hardware and Mechanics out of the PC: Simulation

Instead of loosing a lot of time while waiting for the real world, electronics and mechanics can be simulated on a PC. In ASIC design, the approach is known as virtual platform.

How does this work?

Solcept has developed a framework based on  .NET/ C#/ managed C++. It can be used to simulate the operating system, drivers, hardware (down to the controller registers) and the underlying physics of the machine to be controlled on which the application is based.

The simulation is as accurate as needed and as simple as possible. This means the e.g. physical processes which are strongly influencing a controller design are modeled accurately. Other elements, e.g valves are simulated digitally (pass/ no pass).


The following results were achieved in several projects using simulation:

  • Integration of software and hardware is acomplished in one day (the drivers have been implemted and tested on evaluation-boards)
  • Simpler testing leads to better test coverage and better software quality (e.g. because erors can be injected more easily, time in the simulation can be slowed and accelerated)
  • The customer gets "exactly the user interface we wanted" (the PC simulation of the system can be evaluated by all stakeholders in an early stage which allows an iterative/ agile development style)
  • The industrial designer sees the interplay of the mechanical part (e.g. buttons) of the user interface with its software part very early in the project


The development engineers form a better understanding of the machine to be controlled, respectively its physics. In implementation and debugging PC development systems can be used which still offer more possibilities than most embedded tools.

A well programmed simulator allows to extract logs, call chains and offers other functions like alterable execution speed to complete stop at any point. Together with complete reproducibility, which is seldom in the real world, embedded systems can be developed very efficiently.

Error conditions which are diffcult or impossible (e.g. due to possible hazards) to create on a real machine, can be generated easily during tests. In addition automated tests can be conducted without modifications (e.g. test access ports, user interface exercising robots) of the target system, because it is simulated.

The supposed big disadvantage of course is the increased effort. According to our experience it is paid back over the duration of the project when more than three software test cycles are needed.

Make this work for me!