Components taken out of context

Sometimes it seems hard to believe that the ISO26262 automotive functional safety standard was first published back in 2011 as we have an electronics industry that has only recently come to terms with what this really means for them. And this could all change as the second edition, currently in development and due out in 2018, will contain a new section looking at just the semiconductor industry.

Part of the problem has been that the standard is meant to ingrain functional safety into the whole supply chain from the smallest components right up to the completed vehicle. However, for component makers this caused problems because often they did not know exactly how these parts would be used in the final vehicle and with what other components and systems they would have to interact.

SEooC
The standard tried to address this by introducing the concept of a safety element out of context (SEooC). This at first had component makers scratching their heads and many in the early days were highly critical of the standard because of this. These days, most seem to have got to grips with what this means in practice and now have their whole production space geared up not only to meet the criteria but also to produce the documentation – and there is a lot – that is required to prove that the standard has been adhered to and to list the assumptions that have been made.

Assumptions? Well, yes, because that has become the key to unlocking what an SEooC really is. After conversations with the tier one and two suppliers and the car makers themselves, the component suppliers have to make a number of assumptions about how their devices are going to be used in the actual vehicle, and these assumptions have to be clearly documented. The bottom line is that the builders of the final system know that this device is only guaranteed to help make the final system ISO26262 compliant on condition that those assumptions are correct.

Above: Developing CPUs with fault detection and control features in the hardware. Image from ARM

“At the silicon level, we have to make sure we understand the safety goals and transform them into assumptions,” said David Lopez, Functional Safety Manager at NXP Semiconductors. “This is the first step of an SEooC.”

Michael Frese, Assistant Manager for Functional Safety at Renesas Electronics, added: “It is the responsibility of the OEM or tier one to define the safety goals and functional safety concept and talk to us. We can’t do this as a component company because we are not delivering the full system requirements.”

He said that Renesas created safety elements based on certain use cases and then confirmed these assumptions with the tier ones and OEMs at the start of development.

And Kyle Fabris, Automotive Functional Safety Engineering Manager at Linear Technology, said: “It lets us as a semiconductor company make assumptions at the vehicle level so as to be able to do the software and hardware development. We will talk to the OEMs about what their plans are and what they are trying to do. We look at these aspects and start to think about what are the assumed technical safety requirements.”

For example, Linear makes battery management devices and thus, after talking with the car maker, it has to make assumptions about the battery flow and cell voltage and look at the types of problem that could cause safety issues, such as overcharging.

“Once we know what the part has to do from a functional safety requirement, we have to look at what we do in the IC so we don’t violate that,” said Fabris. “We let the tier ones and twos and OEMs see what our assumptions are and make sure that our assumptions meet the exact requirements at the vehicle level. If they don’t, then we have to look again.”

He did add that this process was never going to be 100% right however, because every vehicle was different and that assumptions changed during the design cycle.

Above: ARM’s safety documentation information flow

“We have to go back and forwards with the customer and sometimes add in extra features,” he said. “Or they may have to use extra parts to cover the gaps.”

Frese added: “We say what safety mechanisms we have included and the customer can modify these to fit the use case. They can disable elements they are not interested in. It could also happen that the assumptions do not meet the reality, so you can introduce some measures external to the CPU. Otherwise, we would basically have to start again. However, the target is to avoid this by making sure the assumptions meet their requirements. This involves talking with them at an early stage.”

Another side to this is that it is not practical or economical for many components to be custom designed for each vehicle. The same components will often go into many different vehicles, as well as some non-automotive applications, and yet meet the requirements of them all.

“It is not efficient to build chips for each specific function,” said Neil Stroud, Director of Advanced Technology Marketing at ARM. “So you need scale, so you have a device that can provide functional safety for different customers. It is a difficult line to walk down.”

Frese added: “You don’t want the specification to be too strict. You want them to be at a certain level generic. You don’t want them valid just for one safety goal.”

Above: Safety lifecycle at Renesas

Documentation
One of the big headaches for the chip makers has been the amount of documentation that they now have to produce, the most important part of which is the safety manual because this is where all the assumptions have to be listed and explained.

“We have a safety package for each of our cores,” said Stroud, “and that includes a safety manual.”

The second package is the failure mode and effects analysis. This looks at possible failures and what effects these will have on other systems. The goal, of course, is for everything to fail safe.

“You have to look at how you fail and how the device and system behave after the failure,” said Lopez. “And you have to calculate the probability of your device failing. You have to implement some strategy to fail safe.”

The third package is a development interface report and this is where, when multiple companies are working on a design, there is a list of who is doing what and how they impact on each other.

“There is always some discussion about who should address what and there are some negotiations,” said Stroud. “Often, these were not discussed in the past and they often tripped up as a result. Total clarity is the order of the game here.”

All this of course adds cost. Frese estimates that die size has to grow by a fifth to meet some safety requirements and there is 20-30% more documentation.

Fabris added: “The documentation is a drain on our resources. There is 30-40% increase in overall effort, maybe a little bit more. There is a cost impact on that, but it is not as drastic as you would have thought.”

Above: Representation of development process and where assumptions must be made. Image from Linear Technology

Process
One change that has affected all component makers is that they now have to adhere to a development process that is designed to reduce the number of systematic problems that can cause failure.

“The result is better quality regardless of safety,” said Stroud. “This is something you need to audit and define.”

Frese added: “We had to create an ISO26262 development process that we integrated into our existing development process. We already had a strong process to avoid systematic failures and that is part of ISO26262.”

A full process goes through the whole supply chain and is why the documentation is important as that has to be passed up the supply chain and added to at each stage.

So, for example, an IP developer such as ARM will have certain processes that it needs to follow and document and then pass these up to its silicon partner, who will have more processes to add, and this then gets passed up to a system designer and so on right the way to the final vehicle.

“It is all about having the process in place so we can hand over the safety package with a clear list of what we have done,” said Stroud. “There will be our IP and other IP that go together into a chip design.”

Future
Hoping to help semiconductor companies come to terms with what they have to do with SEooCs is a new section – part 11 – that will appear next year in the second edition of ISO26262.

“This is aimed at semiconductor companies to give them guidelines,” said Fabris. “This is to try to make sure we are all together.”

Stroud said it would, “provide a framework and clarity across many aspects of semiconductor development for functional safety systems.”

These include topics such as base failure rate estimation, dependent failure analysis, fault injection and intellectual property.

“We see part 11 as a positive addition to the standard,” said Stroud.