Embedded C in cars: Top bug-killing rules

The software content of automobiles has grown phenomenally in the past few years. Estimates are that a modern luxury car may contain as many as 100 million lines of code. This code runs a host of interacting sub-systems from the infotainment systems, window controls, and air conditioning to the most critical engine control and safety systems. While many of these sub-systems are developed by the auto manufacturer, a good number of them come from third-party contractors as well as from independent aftermarket suppliers.

A number of standards are emerging in the auto industry such as the well established CAN bus, the AUTomotive Open System Architecture (AUTOSAR), the Media Oriented Systems Transport (MOST), and the ISO 26262 standard. While the first three standards address the external interaction and networking issues within automobiles, ISO 26262 is a set of requirements for safety and reliability. It is important for applications from different suppliers and groups within a manufacturer to conform to these standards, though only ISO 26262 calls for the use of well-defined coding rules to prevent bugs that can lurk within code and cause sometimes life-threatening malfunctions (figures 1 and 2).

An embedded C coding standard is therefore needed that can be followed and understood by all teams and members of teams developing these interactive, networked systems. This is especially important because different teams and different suppliers will be using different development tools, compilers, and analysis tools. Therefore it is imperative to establish a common ground at the coding level.

What's to gain from a coding standard?
The adoption of a coding standard by a team or a company has many benefits. For example, a coding standard increases the readability and portability of software, so that software may be maintained and reused at lower cost. A coding standard also benefits a team of software developers and their entire organisation by reducing the time required by individual team members to understand or review the work of peers.

However, one of the biggest potential benefits of a coding standard has been too long overlooked: a coding standard can help keep bugs out. It's cheaper and easier to prevent a bug from creeping into code than it is to find and kill it after it has entered. Thus, a key strategy for keeping the cost of firmware development down is to write code in which the compiler, linker, or a static-analysis tool can keep bugs out automatically—in other words, before the code is allowed to execute. While it is certainly important to use tools to verify and certify conformance to the standards mentioned above, such certification does not guarantee that the underlying code is bug-free.

That is because there are many sources of bugs in software programs. The original programmer creates some of the bugs, a few lurking in the dark shadows only to emerge months or years later. Additional bugs result from misunderstandings by those who later maintain, extend, port, and/or reuse the code.

The number and severity of bugs introduced by the original programmer can be reduced through disciplined conformance with certain coding practices, such as the placement of constants on the left side of each equivalence (==) test.

The original programmer can also influence the number and severity of bugs introduced by maintenance programmers. For example, appropriate use of portable fixed-width integer types (such as int32_t) ensures that no future port of the code to a new compiler or target processor will encounter an unexpected overflow.