feature article
Subscribe Now

Tool Documentation for Safe Automobiles

Cadence Announces Tool and Flow Safety Kits

Depending on which article or social media post you read, people are either excited about self-driving vehicles or they’re petrified. (Truck and taxi drivers are more of the latter, although for different reasons.)

And what makes people so nervous? To sum it up in one word, algorithms! And if our only experience with algorithms is social media, then we ought to be afraid. But, realistically, there’s no lack of awareness of the seriousness and safety requirements for automated vehicles. Cars have their own safety standard, ISO 26262, one of the specialty standards under the umbrella of IEC 61508.

In other words, the design practices well honed in the aerospace industry are being adapted for automobiles. Cars may not fall from the sky when things go wrong, but they can damage a lot of people and things. So vehicles will be designed much differently than Facebook feed algorithms. (Whether they’ll be successful is still an open question…)

Ultimately, auto manufacturers own the safety of the cars they market. But they assemble those cars from subassemblies made by suppliers. And anyone making those subassemblies will be building hardware and, in many cases, loading up software. And all of those bits need to work together, safely and predictably. So the final assembly is blessed as safe based on the processes and tests done by the automaker, supplemented by proof and tests and arguments from the makers of each subassembly. And on up the line.

Which means that, at some point, you come to components (hardware or software) that were made or verified by tools. How do you demonstrate that the tools and the flows in which they’re used are providing safe, predictable outputs?

This is something that aerospace folks have had to deal with for years. In theory, you have to prove that the tools you use are working correctly. Or, at the very least, that, if something goes awry, you’ll know – you don’t want any goofs quietly being absorbed into the overall design, only to cause some mayhem later. So it’s been common practice for tool vendors to do their own certification so that their users can rely on that rather than having to do it all themselves.

Well, the same situation is now in place for automotive design. And ISO 26262 has a specific category for tools and your level of confidence with them: the Tool Confidence Level, or TCL. No, not the scripting language. And no, that wasn’t the internal project code name for that very first giggly Elmo. Rather, it’s a three-level score you give to a tool or flow, with safety-related automotive stuff needing to achieve the highest level, TCL 1.

There’s a distinction between a tool and a flow, and it’s no mystery. As a tool user, you have little control over the tool itself – how it’s coded. The flow, however, is all about how you use the tool – so you could be on the hook for that. But Cadence has taken some steps to relieve you of much of the effort needed for either one in the form of “safety kits.” Each kit contains a safety manual – how to use the tools to ensure safety – as well as a series of Tool Confidence Assessment documents.

It would be nice if these docs contained page after page of outright proof of safety. While that’s possible for some use cases on some tools, much of this happens by argument, essentially giving an evidence-based rationale for why the tools should be safe.

You might think, “Hey, I can prove that my synthesis engine works correctly by running some verification or validation checks afterwards.” Well, yes, but then how do you prove that the verification tools don’t just happen to miss the error that the synthesis tool just happens to create? That might sound over-paranoid, but errors can spring from assumptions, and, if a basic assumption is made by a company making both design and verification tools, then that incorrect assumption might feed both tools. This is why, for example, it’s good to get IP from one vendor and verification IP from another – so that you have multiple points of view as cross-checks.

Cadence probably wouldn’t appreciate an interpretation that says you should get your design tools from one EDA guy and your verification tools from another. And, realistically, within a big EDA company, the different tools are created by different teams, so it’s unlikely that you would see this scenario. Unlikely enough that most people, for most designs, don’t worry about it at all. But when life and limb depend on it, you go the extra mile.

The process involves lots of head-scratching about what kinds of things could go wrong, what would happen if they did go wrong, and how you would know if they went wrong. And they’ve done this for tools and flows – it can help if your flow includes tools that provide cross-checks on each other.

With respect to individual tools, Cadence has a long list of tools for which they’ve created documents (green in the tables below), with another long planned list (blue in the tables). You’d think that, having gone through the pain of doing this, they’d be done. But no, with each tool update, you have to redo the docs – at least to some extent. Cadence’s approach is to update their docs with minor tool updates, while generating a new set of docs for major revisions.

Figure_1.png 

Figure 1. Individual tool TCAs. Green are done; blue is pending.

 

Once the specific tools are handled, then there are the flows. Cadence has, so far, documented two flows: digital design and verification (pre-implementation), and custom design and verification. On tap for delivery soon is the digital implementation flow.

The details of these flows matter, and they’re illustrated below. Each flow shows tools that could create incorrect data and tools that could fail to find an error. These are, of course, the tools that have individually been documented.

Figure_2.png 

Figure 2. Digital design and verification flow

 

Figure_3.png 

Figure 3. Custom design and verification flow.

 

 

Figure_4.png 

Figure 4. Digital implementation flow (pending).

(Flow images courtesy Cadence)

So what happens when you use a flow, but it doesn’t match these baseline flows exactly? Then you need to document the differences. So there’s still work, but a lot less work than if you had to document the entire flow. If a tool that you sub in for one of the Cadence tools is also documented, then you still save that time (but you still need to document the flow deviations). Anything you do that’s not pre-documented falls to you to handle.

Designing systems that are inherently safe is hard work, and the process surrounding it can feel like a burden. On the other hand, if you can sleep better knowing that that thing you designed is keeping the public in good hands, well, that’s worth something.

 

More info:

Cadence ISO 26262 TCL Compliance

 

One thought on “Tool Documentation for Safe Automobiles”

Leave a Reply

featured blogs
Feb 23, 2018
The IEEE-SA has a policy of keeping standards active by making sure they get a cycle of updates every 10 years. Including Verilog, SystemVerilog has been going on a cycle of updates every 5±1 years since 1995. I wrote here about the updates to 1800-2009 and 1800-2012, and no...
Feb 23, 2018
What is a software GPS, what does it have to do with Tensilica DSP IP, and why would anyone care? To answer that, let's start with a quiz from the transportation industry. How many shipping containers are currently in transit around the world? It turns out that no one kn...
Feb 22, 2018
We’ve spent a good chunk of the last year building a new on-site search experience for Samtec.com. This update continues that trend with our newly released competitor cross reference search addition. Using this feature, you can access competitor cross reference data for...
Jan 19, 2018
Artificial intelligence (AI) is reshaping the way the world works, opening up countless opportunities in commercial and industrial systems. Applications span diverse markets such as autonomous driving, medical diagnostics, home appliances, industrial automation, adaptive webs...