CDNDrive: ISO 26262...Chapter 11

At CDNLive EMEA Robert Schweiger laid out his perspective on the automotive market. At April’s CDNLive Silicon Valley too, but as you might guess from his name, Germany is his home. Sanjay Lall, the head of Cadence EMEA, had told me the day before...

“ADAS is going crazy”.

Automotive manufacturers are under some conflicting constraints to deliver vehicles that are both efficient electric vehicles (driven by the requirement to reduce emissions) and, at the same time, safe autonomous vehicles. This is not going to be achieved with a supercomputer in the trunk of every car, it requires advanced-node, low-power SoCs. As it happens, Cadence is a company that can help you there!

It is also breaking down the traditional hierarchy of OEMs, who assemble the vehicle and build the engine, tier-1s, who supply the complete electronic control units (ECUs), and tier-2 and tier-3 who supply components, such as semiconductors, to the tier-1s. The OEMs are not just challenged technically, their business differentiation has historically been based on excellence in engine design (“the ultimate driving machine”) but that is going away with electric traction.

Robert went on to point out that connectivity of the vehicle cannot be relied on for autonomous driving. It is annoying to get “buffering…” when you are watching a movie, rather more serious when your car is trying to decide whether light is red or green. This means that the artificial intelligence (AI) that is at the heart of autonomous driving must be done at the edge. Since general purpose processors (CPU) and specialized graphics processors (GPU) are too power-hungry, that means specialized processors optimized for the problem, but still retaining programmability to keep current as technology advances.

One big area of dispute is whether to do local processing at all the sensors (video camers, radar, Lidar etc) or instead feed all the raw data to some super-powerful central processing unit. The problem with doing local processing is that something important might be filtered out, and the problem with the central approach is that the network bandwidth may be too high, and the computational power required may exceed what it is possible to deliver.

Cadence offers a range of Tensilica processors optimized for video and AI applications (and are quasi-standard for audio processing for sound systems, but that doesn’t have safety implications).

In the automotive world, ASIL safety certification is only done on complete systems. So semiconductor IP cannot be “ASIL certified” by definition. Instead, the buzzword is SEooC. A Tenslica processor (or any IP, from Cadence or elsewhere) is a “safety-element-out-of-context.”

The high-end Tensilica processors are ASIL-B ready, designed with a process that is ASIL-D compliant against systematic design faults. For ISO 26262 there are safety manuals and certified tool flows. The Tensilica organization also maintains ISO 9001 certification.

ISO 26262...Chapter 11

Next, Robert introduced Steve Williams of the Tensilica IP group, to do a deeper dive into what ASIL-ready processor IP really means, and what is in the new ISO 26262 part 11. For some introductory background and history of ISO 26262, see my post The Safest Train Is One That Never Leaves the Station.

ISO 26262 is a functional safety standard for passenger vehicles (it will soon cover motorcycles too, which have different standards—nobody will come out and say it explicitly, but motorcycles are so inherently dangerous that it doesn’t make sense to over-engineer all the electronics). Parts 1-10 address hardware, software, and tools. Part 11 (new! Improved!) addresses how IP suppliers and integrators work together.

ISO 26262 defines injury severity (from no injury, to survival uncertain), controllability (from easy to uncontrollable) and probabilities of happening (from probable to “incredible”), and then has a table showing what ASIL level is required for each combination. In turn, the ASIL levels map to requirements for things like single-point-failures. The tables above show the combinations, and the ASIL requirements.

One key aspect of ASIL is that judgment is applied at the item level. Of course, “item” is a technical term but means something such as a braking system (including sensors, analyzers, and actuators). In fact, there is a whole hierarchy of common words that are technical terms. Inside an item are components, like an SoC. Inside that are parts, like a processor. A sub-part might be an ALU, and an elementary sub-part might be a standard-cell. Phew. Don’t tell them about transistors!

ISO 26262 goes on to define FMEDA, Failure Modes, Effects, and Diagnostic Analysis. As an example, think of a light (like a brake light, or a dashboard warning light) controlled by an ECU. How might it fail? How might we address those failure reasons and mitigate them?

The table above shows an analysis, with reasons in the table on the left, and possible mitigations on the right. These range from adding error detection codes to network packets, to not being able to address the problem (the switch fails completely). Which mitigations should we use?

Of course, the requirements for this “light control IP” depend a lot on what light it is controlling. The cabin light doesn’t matter much, brake lights matter quite a bit, and the airbag problem light matters a lot (especially since you’d can’t even notice, unlike the brake lights). Some mitigations cost nothing, and others are costly or technically impossible. So which to apply varies with the light.

Even that simple, almost trivial, example goes to show that ASIL FMEDAs are complex. Tensilica IP already has a lot of basic safety mechanisms built-in to detect problems and either correct them or react to them.

These range from ECCs (error-correcting-codes) on memories, to watchdog timers (I’ve seen these called COPs for computer-operating-properly).

So what do you get with Tensilica IP to put it in your “item”?

• ASIL-B for random failures
• ASIL-D for design processes against systematic design faults
• ISO 26262 safety kits (safety manual, FMEDA and verification reports tailored to each configuration)
• Software development tools for ISO 26262
• ISO 9001 certified development process
• …and we have the certificates to prove it

 

Sign up for Sunday Brunch, the weekly Breakfast Bytes email