There are times when you shouldn’t really think too deeply about things. Last week I was driving along the motorway from London to Winchester. While accelerating to overtake, I saw the engine pass through 4,000 rpm, and I wondered about each piston moving from stationary at top dead centre to stationary at bottom dead centre and then back to top dead centre 50 times a second. (Geeky? Moi?) Sadly, I can’t perform in my head the sum that would calculate the speed at which each piston was moving at its fastest, but it must be pretty speedy, and that cycle of movement would be putting all sorts of stresses on all sorts of metal parts. I eased my mental stress by consoling myself that, at least in my 15-year-old Golf, there wasn’t software running on silicon to control the engine.

So I didn’t have to worry that the software could be like that in the Toyotas that may have suffered unintended acceleration. There has been no resolution on whether the software caused the issue. The evidence of software guru Michael Barr was so damning that, while he couldn’t say that the software caused the incident, he had the Toyota lawyers worried. Add to this the way in which the opposing legal team were being successful in throwing dust into the eyes of the jury and sowing doubt into their minds, and it is clear why Toyota settled out of court.

There is plenty on the web about the issues with the code, including Barr’s own presentation but, in theory, problems like those with the Toyota software should no longer be happening. We have ISO 26262: 2011 Road Vehicles – Functional Safety, which is the functional safety standard for electrical and electronic (E/E) systems for volume production cars. I have written about ISO 26262 before and make no apology for returning, for several reasons:

1) Cars are increasingly reliant on silicon. In modern cars, there are hundreds of silicon components, many of which are programmable. This adds up to many million lines of code. Bowl of spaghetti anyone?

2) Chip companies have identified automotive as a key market, and at electronica earlier this month, they were pushing their products.

3) Cadence has announced tools aimed specifically at chip companies who are designing devices for ISO 26262 applications.

4) There are rumours that China is going to make a functional safety standard mandatory, either ISO 26262 or one based on it.

5) Now that the standard exists, in a court case it would be regarded as state of the art for product development. A company would have to come up with pretty good arguments for not following it.

Firstly, a quick overview of the standard. In a massive ten volumes, it provides a risk-based approach to determining levels of safety. These are ASIL (Automotive Safety Integrity Level), with ratings of A to D, with D being a system capable of causing the most harm to the driver and to others should it not work properly. It also recommends a product lifecycle, from requirements through to end of life, including how to validate and confirm that the system meets the ASIL level.

So it is not just “Does this windscreen wiper system meet the appropriate ASIL level?” but includes “Were the tools that were used to design and test the system appropriate for the ASIL level?” and “Are the components of this system suitable for this ASIL level?”

This last is what I am going to look at. Now it must be clear from the start that a chip cannot itself “Meet ASIL D” or whatever. It can only be claimed to be appropriate for use in an ASIL D system.  But to make this claim requires a great deal from the chip company: they have to meet the requirements of the product lifecycle methodology. In talking to the different companies (there is a list at the end of some of the companies I spoke to), it is clear that this was not a simple box-ticking exercise, but they were required to undertake an end-to-end review of the procedures and processes needed to specify, design, manufacture, and test their automotive products.

One problem that several identified is that some of their customers had not yet begun to build an ISO 26262 process. The day is long gone when Henry Ford brought in coal and iron and other raw materials to build cars from scratch. Today’s car manufacturers assemble cars from elements built by a range of suppliers. The OEM’s (car manufacturers) buy from the Tier 1 suppliers. Behind them there is a supply chain of Tier 2, Tier 3 etc and it is here that the chip company is selling. While many of the OEMs and the Tier 1s have a full appreciation of the standard’s requirements, further down the chain, the knowledge is less clear. This leads to complications right from the start.

Before a chip design can start, someone needs to carry out a risk analysis of the target system to identify safety goals for the system. This is an assessment of the overall consequences if things go wrong with the system, i.e. will the car crash, burst into flames, or just slow to a halt? This uses an array of analytical tools, and the results determine the ASIL for the system. Once the goals are established, a more detailed analysis of the safety requirements is carried out. This identifies in minute detail the things that could go wrong within the system – for example, what can go wrong with the steering control unit. In turn, this is used to create a specification for the system, identifying the different requirements that need to be satisfied if the system is to be safe. This specification may then be decomposed, perhaps into hardware and software requirements, and then passed down the supply chain, eventually arriving at the chip company.

Today, however, it is often only the chip company that has the ISO 26262 knowledge, so many of the first chips entering the market are the result of analysis carried out by the chip company in consultation with their customers.

The chip companies supplying the automotive market have been preparing for ISO 26262 for a long time and have already gone through the task of putting into place the design and manufacturing process flow needed.

This has not been an easy task. The ISO 26262 process flow follows the traditional V model, which is also used by chip designers. This means that companies already have experience and the tools in place to test and verify the final chip design against the requirements, and, as was pointed out to me, chip companies have become more sophisticated in using these tools over the last few years. The need to get a design right the first time has become stronger, as the cost of a new mask set has increased dramatically.

However, even with the tools that were already in place, every chip company said that there was much more work needed. While no one I spoke to would even estimate an overall price on it, it clearly has been time consuming, and it has required management buy-in and support from the highest level. One thing that changes with a 26262 flow is the amount of work needed before starting the design. The safety requirements have to be identified and the ways in which these can be satisfied defined. These all have to be documented, and so do any later design decisions. Establishing the safety requirements and discovering how to meet them means that an ISO 26262 design cycle is heavily front-end loaded compared to a normal design.

Tracking requirements and then verifying needed more detailed work. And the verification task itself requires documentation to prove that the device fulfills the requirements. Cadence launched an ISO 26262 expansion to its Incisive verification platform. The company’s explanations of the product summarises why the task of setting up a design flow has proved complex. Cadence claims that Incisive now fulfils the standard’s ISO 26262 requirements of traceability, safety verification, and tool confidence level.  It also automatically generates regression profiles and results, creating traceable audit trails.

This allows the chip manufacturer to turn round and say to the customer, this is what our verification says about how the chip meets the requirements, this is what we tested and how, and this is the tool we used and how it meets ISO 26262 requirements.

That last is also an issue with software. Many of the software development tools guys are working with certification agencies to get an endorsement that their tools are appropriate for developing software for a specific ASIL.

Altera and Xilinx are providing design flows certified as being appropriate for ISO 26262 (TUV Rhineland for Altera and TUV SUD for Xilinx.

Freescale has also announced that it will make available software (an AutoSAR OS and complex drivers amongst others) that has been developed for ISO 26262 applications.

In one conversation, a processor manufacturer suggested that the changes for 26262 were going to be more demanding on the software teams within his customers. As well as having to work within the confines of a strict development process flow, they are no longer writing for an abstract target: they need to have a clearer idea of the different parts of the target devices and write specifically to match the structure.  This should mean farewell to the spaghetti bowl.

On thing that came out of the conversations was that even those silicon companies who thought they had pretty good development processes in place have learned a lot in implementing ISO 26262-compliant procedures.  The phrase “culture change” was used, and in some cases there are views that the lessons learned in this area are leaking into other application areas.

The developers of ISO 26262 were auto companies who were concerned about the safety of their cars.  The result of their work has been to create a shake-up across the board of the electronics industry, in both hardware and software.

Acknowledgements: Among the people who provided input to this piece were representatives of Analog Devices, Freescale, Infineon, Micronas, NXP and Renesas. Earlier discussions have been with a number of tools companies.  Of course, the responsibility for any errors and mistakes is all mine, and all the good bits are from their help.