WP_Term Object
(
    [term_id] => 497
    [name] => Arteris IP
    [slug] => arteris-ip
    [term_group] => 0
    [term_taxonomy_id] => 497
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 111
    [filter] => raw
    [cat_ID] => 497
    [category_count] => 111
    [category_description] => 
    [cat_name] => Arteris IP
    [category_nicename] => arteris-ip
    [category_parent] => 178
)
            
Arteris IP logo color trans 4795x854 1
WP_Term Object
(
    [term_id] => 497
    [name] => Arteris IP
    [slug] => arteris-ip
    [term_group] => 0
    [term_taxonomy_id] => 497
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 111
    [filter] => raw
    [cat_ID] => 497
    [category_count] => 111
    [category_description] => 
    [cat_name] => Arteris IP
    [category_nicename] => arteris-ip
    [category_parent] => 178
)

The Zen of Auto Safety – a Path to Enlightenment

The Zen of Auto Safety – a Path to Enlightenment
by Bernard Murphy on 07-07-2021 at 6:00 am

Safety is a complex topic, but we’re busy. We take the course, get the certificate. Check, along with a million other things we need to do. But maybe it’s not quite that simple. I talked recently with Kurt Shuler (VP of marketing) and Stefano Lorenzini (functional safety manager) at Arteris IP and concluded that finding enlightenment in safety is more of a journey than a destination. I’m going to share with you a few stories they told me which highlight this journey. Because journeys / stories are my favorite way to share an idea.

The Zen of Auto Safety

We know safety; this is just a bigger design

If you’ve been building auto components for years, what’s new? A common problem, still, is in missing something in the Assumptions of Use (AoU). That part of the spec describing how the consumer of a chip expects to be able to use your system. Paradoxically, this can be more of a problem among established experts in automotive design. They already know safety; they’re just scaling up, integrating more IP and a bigger interconnect. The chip safety experts get involved late in the game; someone checks the fine print in an AoU and figures out, “Oops, we missed something.” They ask their IP supplier for help. The supplier pulls out all the stops and figures out a solution.

A few months later, the same integration team contacts them again, “Hey, we found another AoU problem.” Most of us are ready to bail out a favored customer once. Twice is asking too much. Kurt sent one customer a big quote; the second time around wouldn’t be free.

A somewhat related problem is this, “I need a solution, but what we’re doing is secret, so I can’t tell you exactly what I need. Why don’t you propose a solution, and I’ll tell you if it will work. If not, propose a different solution.” An open-ended discovery for no extra $$. It happens; it’s frustrating and expensive for a supplier who didn’t create the problem. And unhealthy for the integrator’s schedule.

I’ve just finished training; it must be done exactly this way

At the other end of the scale, in some ways, is the safety manager who insists on everything being presented precisely the way they were trained. FMEDA spreadsheets must have exactly the same columns, in the same order, with the same headers. No room for deviation. This confuses the standard with a regulation. Different users (semiconductor and Tier1 certainly) have their own preferred ways to organize data. Maybe it might be nice if they all did it in exactly the same way, but they don’t. Absent the force of a regulation, suppliers can’t bridge the gap by providing a different format for every customer preference.

The message here is – take a deep breath. What’s important is that the intent be satisfied, not that formats match exactly with the training course you took. Which introduces a subjective element, not always comfortable to our engineering brains, but that’s the way it is.

The RTL is frozen; we’ll fix it in software

You found a problem, but you already closed the door on RTL changes. Maybe you have a safety coverage problem in one function where you didn’t add safety mitigation logic. Now what do you do? You could potentially add a software fix. If the potential issue is a transient fault, you could run the step twice and compare. All software-driven. The tradeoff is that you add latency or throttle bandwidth a little when doing that. Especially if this is something you are doing through the NoC.

So now you need to have a talk with your customers’ safety manager. You missed a safety mechanism in design; as a result, your coverage is, say, 0.2% lower than it could have been. That’s one option. Or you could make a software fix which would raise the coverage back up. But performance would take a hit. You have run tests to characterize what impact that would have. What do they think?

You could argue that this was a particularly tricky case, and you’ve put a process in place to make sure it won’t slip past you in the future. Maybe you get lucky. Your customers also have tight schedules. And it is just 0.2%. They tell you OK, but this better not become a pattern. They expect continuous improvement.

Enlightenment

Kurt and Stefano agreed. It’s important to meet the intent – the spirit of the standard, not word by word precision. Worthy partners may be willing to bail you out, but don’t abuse that privilege. Finally, recognize that safety is a journey of collaboration and continuous improvement. The best of us will get better together. Those who aren’t willing to shoulder their share will have to find their own way.

You can learn more about Arteris IP investment in safety HERE.

Share this post via:

Comments

There are no comments yet.

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