Using simulation tools for embedded systems software development: Part 1

Simulation is used whenever trying things in the physical world would be inconvenient, expensive, impractical or plain impossible. Simulation allows experimenters to try things with more control over parameters and better insight into the results. It reduces the cost of experiments, and makes it possible to work with systems that do not yet exist in physical form. It cuts lead times and improves product quality. In a sense, we use simulation and virtual systems because reality sucks.

Ironically, while simulation is almost universally implemented as software on computers, the use of simulation to develop computer software itself is still quite rare.

In this three-part series, we will discuss how simulation technology can be used to develop embedded systems and the software component of these projects in particular.

Part 1 will cover simulation of the world around a computer board, while Part 2 will cover the particulars of simulating a computer board and its software, as well as how to bring all the pieces together to form a complete solution. Finally, Part 3 will delve into some more concrete examples of simulation solutions in actual use and the benefits obtained from them.

Simulating a Computer System
An embedded computer system can be broken down into five main parts:

* The computer board itself: the piece of hardware containing one or more processors, executing the embedded software.

* The software running on this computer board. This includes not just the user applications, but also the boot ROM or BIOS, hardware drivers, operating system, and various libraries and middleware frameworks used to implement the software functions.

* The communications network or networks that the board is connected to, and over which the software communicates with software on other computers.

* The environment in which the computer operates and that it measures using sensors and affects using actuators.

* The user interface exposed to a human user of the system.

Figure 1

For the rest of this series of articles, we will refer to the system being simulated as the target system (common with traditional cross-compilation nomenclature), and the development PC or workstation as the host.

Obviously, not all target systems feature all of the parts listed above, but most feature most of them. A simulation effort for an embedded system can focus on just one of the parts. It is quite common to mix simulated and physical parts, to achieve "partial reality."

Abstraction vs. Detail
A key insight in building simulations is that you must always make a trade-off between simulator detail and the scope of the simulated system.
 Looking at some extreme cases, you cannot use the same level of abstraction when simulating the evolution of the universe on a grand scale as when simulating protein folding.

You can always trade execution time for increased detail or scope, but assuming you want a result in a reasonable time scale, compromises are necessary.

A corollary to the abstraction rule is that simulation is a workload that can always use maximum computer performance (unless it is limited by the speed of interaction from the world or users).

A faster computer or less detailed model lets you scale up the size of the system simulated or reduce simulation run times. In general, if the processor in your computer is not loaded to 100%, you are not making optimal use of simulation.

The high demands for computer power used to be a limiting factor for the use of simulation, requiring large, expensive, and rare supercomputers to be used.

Today, however, even the cheapest PC has sufficient computation power to perform relevant simulations in reasonable time. Thus, the availability of computer equipment is not a problem anymore, and simulation should be a tool considered for deployment to every engineer in a development project.

Simulating the Environment
Simulation of the physical environment is often done for its own sake, without regard for the eventual use of the simulation model by embedded software developers. It is standard practice in mechanical and electrical engineering to design with computer aided tools and simulation.

For example, control engineers developing control algorithms for physical systems such as engines or processing plants often build models of the controlled system in tools such as MatLab/Simulink and Labview.

These models are then combined with a model of the controller under development, and control properties like stability and performance evaluated. From a software perspective, this is simulating the specification of the embedded software along with the controlled environment.

For a space probe, the environment simulation could comprise a model of the planets, the sun, and the probe itself. This model can be used to evaluate proposed trajectories, since it is possible to work through missions of years in length in a very short time.

In conjunction with embedded computer simulations, such a simulator would provide data on the attitude and distance to the sun, the amount of power being generated from solar panels, and the positions of stars seen by the navigation sensors.

When the mechanical component of an embedded system is potentially dangerous or impractical to work with, you absolutely want to simulate the effects of the software before committing to physical hardware. For example, control software for heavy machinery or military vehicles are best tested in simulation.

Also, the number of physical prototypes available is fairly limited in such circumstances, and not something every developer will have at their desk. Such models can be created using modeling tools, or written in C or C++ (which is quite popular in practice).

In many cases, environment simulations can be simple data sequences captured from a real sensor or simply guessed by a developer.

It should be noted that a simulated environment can be used for two different purposes. One is to provide "typical" data to the computer system simulation, trying to mimic the behavior of the final physical system under normal operating conditions.

The other is to provide "extreme" data, corresponding to boundary cases in the system behavior, and "faulty" data corresponding to broken sensors or similar cases outside normal operating conditions. The ability to inject extreme and faulty cases is a key benefit from simulation.

Simulating the Human User Interface
The human interface portion of an embedded device is often also simulated during its development. For testing user interface ideas, rapid prototyping and simulation is very worthwhile and can be done in many different ways. One creative example is how the creator of the original Palm Pilot used a wooden block to simulate the effect of carrying the device.

Instead of building complete implementations of the interface of a TV, mobile phone, or plant control computer, mockups are built in specialized user interface (UI) tools, in Visual Studio GUI builder on a PC, or even PowerPoint or Flash.

Sometimes such simulations have complex behaviors implemented in various scripts or even simple prototype software stacks. Only when the UI design is stable do you commit to implementing it in real code for your real device, since this typically implies a greater programming effort.

In later phases of development, when the hardware user interface and most of the software user interface is done, a computer simulation of a device needs to provide input and output facilities to make it possible to test software for the device without hardware.

This kind of simulation runs the gamut from simple text consoles showing the output from a serial port to graphical simulations of user interface panels where the user can click on switches, turn knobs, and watch feedback on graphical dials and screens.

A typical example is Nokia's Series 60 development kit, which provides a virtual mobile phone with a keypad and small display. Another example is how virtual PC tools like VmWare, Parallels, and VirtualPC map the display, keyboard, and mouse of a PC to a target system.

In consumer electronics, PC peripherals are often used to provide live test data approximating that of a real system. For example, a webcam is a good test data generator for a simulated mobile phone containing a camera.

Even if the optics and sensors are different, it still provides something better than static predetermined images. Same for sound capture and playback " you want to hear the sound the machine is making, not just watch the waveform on a display.

Simulating the Network
Most embedded computers today are connected to one or more networks. These networks can be internal to a system; for example, in a rack-based system, VME, PCI, PCI Express, RapidIO, Ethernet, I2C, serial lines, and ATM can be used to connect the boards. In cars, CAN, LIN, FlexRay, and MOST buses connect body electronics, telematics, and control systems. Aircraft control systems communicate over special bus systems like MIL-STD-1553, ARINC 429, and AFDX.

Between the external interfaces of systems, Ethernet running internet standards like UDP and TCP is common. Mobile phones connect to headsets and PCs over Bluetooth, USB, and IR, and to cellular networks using UMTS, CDMA2000, GSM, and other standards.

Telephone systems have traffic flowing using many different protocols and physical standards like SS7, SONET, SDH, and ATM. Smartcards connect to card readers using contacts or contact-less interfaces. Sensor nodes communicate over standard wireless networks or lower-power, lower-speed interfaces like Zigbee.

Thus, existing in an internal or external network is a reality for most embedded systems. Due to the large scale of a typical network, the network part is almost by universally simulated to some extent.

You simply cannot test a phone switch or router inside its real deployment network, so you have to provide some kind of simulation for the external world. You don't want to test mobile phone viruses in the live network for very practical reasons.

Often, many other nodes on the network are being developed at the same time. Or you might just want to combine point simulations of several networked systems into a single simulated network.

Figure 2

Levels of Simulation
Network simulation can be applied at many levels of the networking stack. The picture in Figure 2 above shows the most common levels at which network simulation is being performed:

Bit stream simulation looks at the ones and zeroes transmitted on a bus or other medium.
It is possible to detect events like transmission collisions on Ethernet and the resulting back-off, priorities being clocked onto a CAN bus, and signal garbling due to simultaneous transmissions in radio networks. An open example of such a simulator is the VMNet simulator for sensor networks.

Considering the abstraction levels for computer system simulation discussed below, this is at an abstraction level similar to cycle-accurate simulation. Another example is the simulation of the precise clock- by-clock communication between units inside a system-on-a-chip.

Packet transmission passes entire packets around, where the definition of a packet depends on the network type.
In Ethernet, packets can be up to 65kB large, while serial lines usually transmit single bytes in each "packet". It is the network simulation equivalent of transaction-level modeling, as discussed below for computer systems.

The network simulation has no knowledge of the meaning of the packets. It just passes opaque blobs of bits around. The software on the simulated system interacts with some kind of virtual network interface, programming it just like a real network device.

This level is quite scalable in terms of simulation size, and is also an appropriate level at which to connect real and simulated networks. Common PC virtualization software like VMware operates at this level, as do embedded-systems virtualization tools from Virtutech, Virtio, and VaST. A deeper discussion can be found here.

Ignoring the actual structure of packets on the network.
Networks are often simulated at the level of network protocols like TCP/IP. The simulated nodes use some socket-style API to send traffic into a simulated network rather than a real network.

Such a simulation becomes independent of the actual medium used, and can scale to very large networks. The network research tool NS2 operates at this level, for example. It is also a natural network model when using API-level simulation of the software, as discussed below.

Application protocol simulation simulates the behavior of network services and other nodes.
Tools simulate both of the network protocols used and the application protocols built on top of them. Such simulation tools embody significant knowledge of the function of real-world network nodes or network subsystems. They offer the ability to test individual network nodes in an intelligent interactive environment, a concept often known as rest-of-network simulation. Vector Informatik's CAN tools are a typical example of such tools.

Some high-level simulations of networked systems work at the level of application actions.
In this context, we do not care about how network traffic is delivered, just about the activities they result in. It is a common mode when designing systems at the highest level, for example in UML models.

Figure 3

The level of abstraction to choose depends on your requirements, and it is often the case that several types of simulators are combined in a single simulation setup. The picture in Figure 3 above shows a complex setup that forms a superset of most real-world deployments and which includes:

* Some simulated nodes running the real software for the embedded system.

* A rest-of-network simulator providing the illusion of many more nodes on the network.

* A simple traffic generator that just injects packets according to some kind of randomized model.

* An instrumentation module that peeks on traffic without being visible on the network, showing the advantage of simulation in inspection.

* A connection to the real-world network on which some real systems are found, communicating with the simulated systems.

* Real-world network test machines are the types of specialized equipment used today to provide testing of physical network nodes. Thanks to a real-network bridge, they can also be used with simulated systems.

To read Part 2 go to Bringing all the pieces together
To read Part 3, go to Real world examples of software simulation

Jakob Engblom works as a business development manager at Virtutech. He has a PhD in Computer Systems from Uppsala University, and has worked with programming tools and simulation tools for embedded and real-time systems since 1997. You can contact him at jakob@virtutech.com. For other publications by Jakob Engblom, see www.engbloms.se/jakob.html.