There is a new international standard, and the world of automotive electronics must now change irreversibly. ISO 26262 was published a couple of weeks ago, and this means there is now a standard that covers “Road Vehicles – Functional Safety.” To quote from the standard:

ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of E/E [Electrical/Electronic] systems within road vehicles. This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic, and software elements that provide safety-related functions.

ISO 26262 is intended to be applied to safety-related systems that include one or more E/E systems and that are installed in series production passenger cars with a max gross weight up to 3.5 t.

We have looked at 26262 recently, so why am I returning to the topic?  Several reasons, really.

1)   It is now a fully published international standard.

2)   In the event of a legal case involving safety, it is likely that non-compliance with 26262 will be regarded as a serious issue.

3)   I have just sat through a day conference on the issues of Embedded Software in Automotive, which raised (or re-raised) some very interesting/concerning issues.

61508 has been around for a long time now – over 13 years – and people working within the standard have developed processes and methods for developing systems that can be shown to conform to the standards. But 61508 is for large, often one-off systems. Within the aerospace domain, there are standards, such as DO-178B, that deal with longer production runs, up to the hundreds of aircraft. And, in both cases, the operators of the end products, be they power stations or commercial aircraft, will have received many hours of training. But 26262 is the first safety-related standard that applies to a product produced in production runs of hundreds of thousands and that will be operated by almost anyone, with little or no specific model training – with only the ability to pass a low-level generic driving test.

And as well as being important, ISO 26262 is big. It comes in ten volumes, has over 350 pages, and there are more than 550 requirements. (To be honest, a lot of it is taken up with repetition: since the volumes are stand-alone, they all have a large amount of identical boilerplate – but there is still a lot of other material.) From the point of view of last week’s conference, the most important volume is Part 6: Product development: software level. This uses the classic V-model of the software development process, fitted into a larger V-model for the overall system development, and it accepts modelling a method of architectural definition.

The car industry has always been run by mechanical engineers. In the early days, factories, such as Ford at River Rouge in America and Dagenham in England, were fully vertically integrated: coal and iron ore in at one end and cars out at the other. Today, the industry is hierarchical, with the car companies, Mercedes, GM, and Toyota etc. (often called OEMs) served by Tier 1 suppliers, who in turn are supplied by Tier 2, and so on. Automotive builders are used to working to very tight cost constraints: a few pennies saved on just a single element in a car translates into better margins, and even better if a few pennies of saving are made on multiple items. Saving weight is also an issue, as fuel economy is more and more an element in increasing sales and complying with environmental legislation. It is in this environment that electronic systems are developed and deployed.

The electronic systems within a car are usually supplied to the OEM by Tier 1 companies, who have bought silicon and software from other suppliers. While the OEMs may specify the electronics, they are normally defined in detail and implemented further down the chain – or created down the chain and offered up to the OEMs. Some OEMs have reportedly been asking for 26262 compliance in designs since early 2011. Over time, the electronic content of cars has increased steadily, and, although hard to verify, there is a consensus that a mid-range luxury car may have up to 85 individual processors, and that in some cases a car may have in excess of 100 million lines of codes (LOC). One application frequently cited is the infotainment system. This can combine a satellite navigation system with traffic information and a radio and entertainment centre, and it may have a CD player, Bluetooth and USB connectivity, and iPlayer docking. It is no surprising that in some estimates an infotainment center may have around 20 million LOC.

All these applications and multiple lines of code normally have been developed in isolation. The automotive environment has created a range of standards for communication and platforms (LIN, CAN, FlexRay and MOST for communication, the GENIVI infotainment platform and AUTOSAR over-reaching architecture), but communication and co-operation between applications is not always simple, and there are interesting anecdotes about what happens when some applications are linked.

The cost and weight pressures in the industry are pushing electronics from one application per processor to running multiple applications on shared platforms, frequently multi-core, both heterogeneous and homogeneous. When the platform is heterogeneous, assigning tasks to specific cores is not simple, but it is straightforward: safety-related applications can be assigned a specific processor and can be developed to be deterministic. However, homogeneous multi-core chips, where tasks within the software are assigned dynamically to specific cores, provide a whole series of well-documented and widely discussed new challenges to the system developer. A significant problem, which requires very careful design and implementation, is determinism in real-time applications: it is not always possible to predict the state of the overall system when a specific action is required. This is clearly not a good thing for safety-critical applications, and many, if not most, real-time applications in automotive are safety-critical.

26262 is likely to bring some extra and interesting challenges to the industry, according to the speakers at the “Embedded Software in Automotive – the critical component” event organised by UK trade association NMI last week. There was near unanimous agreement that the formal framework for developing software that is required by 26262 will be a significant change to the way in which much of the software for automotive applications is developed, with a need to move from coding to engineering. Since many of the speakers were tools vendors, there was an emphasis on tools, but this emphasis also came from those who were in the industry.

Given the complexity of the standard and the complexity of requirements specifications, identifying how requirements mapped onto the standard and then tracing through the process that these requirements were satisfied is a complex task that will require specialist tools.

Moving to the software itself, 26262 explicitly permits the use of modelling and code generation, and this may be a growth area within automotive, since the code created from modelling tools may be “correct by construction”. If more traditional means are used, the standard again explicitly requires the use of coding guidelines, normally a sub-set of the language. Although ADA/SPARK is being used in some areas, the overwhelming majority of software is being developed using the C programming language. And guidelines for C from MISRA, originally developed for the automotive sector but now widely used in safety-critical applications, are under revision. MISRA-C3, which now covers the C99 version of the C language, will be available for review later this year/early in 2012.

Validating that the software conforms to the guidelines is offered by many of the suppliers of static code analysis tools, as part of the overall analysis process. Most, if not all, the major suppliers of static code analysis tools are claiming that their tools are certified as appropriate for 26262. (In a parallel industry, medical electronics, the US Food and Drug Administration is emphasising static code analysis of all software.)

Even vendors of tools for debugging were stressing the importance of spending time on specification and design before creating code and using analysis tools before compilation. It is a weird thing that, despite years of evidence that a disciplined approach to software development, leaving coding until as late as possible, produces fewer bugs; and despite the general understanding that bugs found earlier in the process are easier and cheaper to resolve, while bugs found in field deployment can be so severe as to damage a company’s reputation, perhaps irretrievably; there are still many millions of lines of code that are just written to a vague specification and introduced into service because they have compiled.

There is a strong feeling that the current software industry has yet to come to terms with the needs of a new era. Programmers often feel that structures and processes are constraints on their creativity, and, “I won’t have any bugs, as I write good code,” is an attitude frequently quoted. For them, creating the code is the end in itself. Its role in the larger system is irrelevant. Managers are reluctant to invest in tools for software development both because of budget constraints, and also, in part, because of the difficulty of enforcing a development discipline on their team.

As 26262 is increasingly demanded by the OEMs, we are faced with a number of problems.

1)   Social or cultural: Programmers will have to move from being artistic souls or solid craftsmen to become, instead, software engineers. They will also have to accept the discipline of working within a controlled and documented development process.

2)   Managerial: To make this work, management is going to have to accept that software engineers need tools. They will have to invest in the tools needed to manage the development process and provide the traceability needed to meet 26262. They will also have to invest in the tools that can make software engineers more productive and enable them to produce measurably better code.

3)   Technological: And the industry as a whole is going to need to continue to develop more tools that will cope with multiple processors within a single system (multi-core, heterogeneous, or homogeneous) and multiple applications with different levels of security running on a single core.

It’s going to be an exciting time.