WP_Term Object
(
    [term_id] => 497
    [name] => Arteris
    [slug] => arteris
    [term_group] => 0
    [term_taxonomy_id] => 497
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 136
    [filter] => raw
    [cat_ID] => 497
    [category_count] => 136
    [category_description] => 
    [cat_name] => Arteris
    [category_nicename] => arteris
    [category_parent] => 178
)
            
Arteris logo bk org rgb
WP_Term Object
(
    [term_id] => 497
    [name] => Arteris
    [slug] => arteris
    [term_group] => 0
    [term_taxonomy_id] => 497
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 136
    [filter] => raw
    [cat_ID] => 497
    [category_count] => 136
    [category_description] => 
    [cat_name] => Arteris
    [category_nicename] => arteris
    [category_parent] => 178
)

Automotive System Reliability – ISO 26262 impacts IP and Tools

Automotive System Reliability – ISO 26262 impacts IP and Tools
by Tom Simon on 08-03-2017 at 7:00 am

If you have been following the topic of ISO 26262, you now realize that IP, or even EDA design tools, developed with the highest quality standards still can’t be ISO 26262 certified. Recently I had a conversation with Kurt Shuler from Arteris about this topic. He is VP of Marketing at Arteris, and he is also on several ISO 26262 technical committees. He pointed out that there is plenty that IP and tool providers can do to make it easier for the automotive systems developed with their products to achieve ISO26262 qualification.

Let’s dig a little deeper into how this works. Kurt first brought up how the context for IP and tools is important. Before highly programmable devices, it was easier to assess how a component would operate in a larger system. Now IP and tools are by definition 99.9% safety elements out of context. Because they can be used for just about anything, there is no way to determine how well they will perform without understanding the context in which they will be used.

Even the way that Automotive Safety Integrity Levels (ASIL’s) are defined drives the concept that it is how things are used that matters most. The controller chip for your seat position has markedly different qualification requirements than the same component used in an autopilot system.

So we know that ASIL levels are set for each identifiable hazardous event in a subsystem. By the way, a handy way to remember the severity of ASIL levels, is to think that C and D stand for “causes death.” ASIL A, for instance, is applied for the seat position system events. The ASIL level is the ‘product’ of the injury severity of the event, the exposure (or likelihood), and the controllability. Kurt cited the example of a cruise control going offline. In that instance the driver could take over. Or even an autopilot failure today can be recovered by the driver grabbing the wheel. Time frames are important. Each event has a recovery interval – the amount of time available for a driver or the system itself to recover.

Kurt talked about features that can be added to IP and software to make it easier for a hardware component to help achieve a higher qualification levels. In Arteris’ case, they offer products for on chip communication. They have built-in checkers that validate the integrity of the data communications. These regularly and periodically check the system, even when it is operating to make sure there are no faults. Kurt pointed out that the checkers themselves need to be checked. So, of course, there are features that check the checkers by intentionally inserting faults and ensuring they are handled.

For IP the crux of the issue is coverage. Kurt points out that the IP providers must make it as easy as possible for their customers to assess diagnostic coverage. What is known as Failure Mods, Effects and Diagnostic Analysis (FMEDA) becomes essential. It has to cover a myriad of issues, such as stuck bit, power transient, and almost anything else that you can imagine. For each of these the effect of the failure must be determined. It’s important that issues that occur at the lower level can be caught and then handled at the system level.

Because ISO 26262 anticipates sustaining engineering and traceability for up to 10 years, there will be many new requirements for design data preparation and preservation. In fact, entire tool chains must be available in order to recreate, analyze or modify designs over this period. ISO 26262 at the IP level is really about documentation, so that the system designers have the information necessary to qualify the system. Kurt mentioned that Arteris is offering a service to hold all configuration files for a customer design in a secure repository for the required 10 year period.

My conversation with Kurt was very informative. One of the benefits of having an IP provider that is so involved in the development of relevant standards is that the IP they develop is much more likely to facilitate implementation of the qualification process. Certainly, it is evident that the requirements of ISO 26262 are making their way through the entire semiconductor supply chain. When cars become fully autonomous, without any driver controls, it will be essential that complying with the reliability standards is considered at every level of system development. For more information about ISO 26262 and how Arteris is engaged in this effort, take a look at the Arteris website.

Share this post via:

Comments

8 Replies to “Automotive System Reliability – ISO 26262 impacts IP and Tools”

You must register or log in to view/post comments.