From an embedded software engineer’s point of view, a car has become a mobile box full of embedded systems. This article reviews all aspects of embedded software in cars, including operating systems, protocols, development tools and international standards.
Until around the turn of this century, there were very few electronic systems in vehicles. A few high end models had “electronic ignition”, cruise control and climate control, but that was quite primitive analog electronics that barely counts. That has all changed. Modern cars – even basic models – have dozens of microprocessors and microcontrollers, which span the complete spectrum of power/complexity from tiny 4-bit controllers to monster 32-bit (maybe 64-bit) supercomputers on a chip. Every system is electronic and a variety of design approaches are applicable.
Just about every newsworthy development in cars today has its roots in electronics. That electronics is mostly embedded systems and that means that software is a critical issue. The automotive industry is culturally inclined to the wide utilization of standards to an extent not seen in many other industries with which software developers may be familiar. This comes about because, apart from being good business practice to take standards-based approaches to design when possible, the auto industry has a complex supply chain, so compliance with standards is easier to manage than individual, very detailed specifications. Some of the standards that apply to electronic systems in cars (not an exhaustive list):
- CAN Bus – a means to reliably connect numerous systems together whilst minimizing the amount of wiring.
- MISRA C (and C++) – a detailed set of guidelines in the use of this language in a safety critical system, like a car.
- OSEK/VDX – a standard for real time operating systems used in such systems in cars.
- Genivi – a standard for Linux based systems used for in-car infotainment systems.
It is worth exploring each of these from the perspective of the software developer.
The wiring in cars was traditionally point to point. So, for example, a cable would run from the battery, to a switch and on to the headlights. This scheme is simple to understand and maintain, but rapidly becomes overly complex as the number of electronic systems increases. At some point, a bus system starts to make sense. A bundle of wires is routed from one device to another and each device is controlled by having a unique bus address and only responds when it sees this address on the bus. A number of bus systems are used in automotive systems, but CAN is the most well known.
From a software developer’s point of view, using CAN is a matter of getting some appreciation of the protocol and obtaining drivers for the CAN interface chips that are in use.
Embedded developers often bemoan the fact that no programming language is ideal for their particular needs. In a way, this situation is unsurprising, because, although a great many developers are working on embedded applications, they are still only quite a small subset of the world’s programming community. Nevertheless, some languages have been developed with embedded in mind. Notable examples are PL/M, Forth and Ada, all of which have been widely used, but never universally accepted.
The compromise, that has been adopted almost universally, is C …
The C language is compact, expressive and powerful. It provides a programmer with the means to write efficient, readable and maintainable code. All of these features account for its popularity. Unfortunately, the language also enables the unwary developer to write dangerous, insecure code that can cause serious problems at all stages of a development project and into deployment. For applications where safety and/or security are a major priority, these shortcomings of the language are a major concern.
It was against this background that, in the late 1990s, the Motor Industry Software Reliability Association (MISRA) introduced a set of guidelines for the use of C in vehicle systems, which became known as MISRA-C. Since then, the guidelines have been steadily refined, with a new update being published in recently. A similar approach to the use of C++ has also been established. Although the guidelines were aimed at developers of software for use in cars, it was quickly realized that they are equally applicable to many other application areas, where safety is critical.
OSEK/VDX is a standard for RTOSes destined for use in automotive control systems. It was designed from the ground up for this purpose and incorporates the key characteristics needed for a safety critical system. The key feature is a lack of dynamic objects; everything is created statically at build time. The intrinsic simplicity of this implementation does not constrain the software designer significantly and eliminates a significant potential source of system failure. It is unsurprising that other industries are taking an interest in the standard. OSEK/VDX RTOSes are available from a number of vendors; it is also encompassed by AUTOSAR, which is a broader standard covering automotive systems.
Most of the driver-facing systems in a car are not hard real time and do not have harsh safety requirements. So Linux is a good choice, as it opens up the availability of a wide range of off-the-shelf software components.
Genivi is a standard for the implementation of Linux in this context.
Hypervisors and Automotive Systems
As the complexity of automotive systems increases, a couple of situations arise where careful design is needed to avoid problems. First, multicore systems are common, with many popular system-on-chip devices being targeted at this market. The multiple CPUs need to be marshalled in some way and an effective approach is to use a suitably configured hypervisor.
Another challenging context is when one operating system has been selected for a specific purpose and a different one is deemed more suitable for another job and they need to run on the same chip. A hypervisor can also be the solution in this situation, as it can manage resources between the multiple OSes.
Software is a dominant design feature in modern cars. As a result, an increasing number of embedded software developers may find themselves working in this industry. A basic working knowledge of the standards and approaches to automotive software development is, therefore, useful.
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor Embedded [the Mentor Graphics Embedded Software Division], and is based in the UK. His regular blog is located at: http://blogs.mentor.com/colinwalls. He may be reached by email at firstname.lastname@example.org