Using Simulation Tools for Embedded Software Development Class # 410 , Embedded Systems Conference , Silicon Valley 2008

ion 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 and Parallels 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, IC, 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 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. Network simulation can be applied at many levels of the networking stack. The picture below shows the most common levels at which network simulation is being performed. The two levels highlighted in green are the ones that are most useful for embedded software work on a concrete target model. Physical signalling Bit stream Packet transmission Network protocol Application protocol High-level application actions Analog signals, bit errors, radio modeling Clocked zeros and ones, CAN with contention, Ethernet with CSMA model Ethernet packets with MAC address, CAN packets, serial characters, VME data read/write TCP/IP etc. FTP, DHCP, SS7, CANopen Load software, configure node, restart Hardware/software boundary r r / ft r r The most detailed modeling level is the physical signal level. Here, the analog properties of the transmission medium and how signals pass through it is modeled. This makes it possible to simulate radio propagation, echoes, and signal degradation, or the electronic interference caused by signals on a CAN bus. It is quite rarely used in the setting of developing embedded systems software, since it complex and provides more details than strictly needed. 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 boards. The network simulation has no knowledge of the meaning of the packets. It just passes opaqu