Rethinking Car Design

The automotive industry is undergoing sweeping changes in both technology and business, and functional safety increasingly cuts across both of them.

Every safety-critical industry has one or more functional safety standards, whether that is manufacturing, avionics or automotive. In automotive, it’s a combination of ISO 26262 and various ASIL levels, which are aimed at preventing environmental failures by having systems respond to different faults.

Source: Mercedes-Benz F015

The standards couch things in a language that is particular to the industry, but they are all talking about the same kinds of things.

“They address reliability of design, i.e., understanding what you actually need to protect from, and actually protecting against it,” said Robert Bates, chief safety officer for the embedded systems division at Mentor, a Siemens Business. “Automotive puts it in a particular way that the automotive OEMs weren’t used to dealing with before ISO 26262, but it’s all kind of similar to that; what do we learn here and what kinds of increments do we learn as we go from place to place? Security is the same way. And then, what can we then take that is specific to the industry and extend it that way?”

Each of these standards has multiple facets, as well. So while the ISO 26262 standard has a very specific definition, there are a number of sides that need to be considered.

“There’s the systematic side of rigorous verification, and matching requirements, along with the random side,” said Dave Kelf, vice president of marketing at OneSpin Solutions. “The reliability overall is going to feed off from the safety side, and ISO is driving it. ISO 26262 is starting to address this much more competitive automotive market because the traditional safety markets, like the aeronautical space, don’t care if the pilot’s got an extra radio function. He doesn’t need it. So the competitive nature isn’t there. You can take a long time to change things. The new car manufacturers have to address the safety concerns, obviously, but they’re in a much more competitive environment than any of the ones before. The new standard has allowed them to build new capability more quickly, keep it to the safety standard, which is really critical, but allow them to compete in this environment today. This notion of safety, although it is well defined, is starting to encroach into all areas of semiconductors, and it’s all about how to drive the business but handle the reliability issues that these guys have to worry about as well — and not kill people.”

This is a big change for automotive, a conservative industry built on mechanical and hydraulic engineering. But as more electronic driver-assisted features are added to cars, competition is heating up. That, in turn, is forcing the industry to become more of a consumer-focused, driven industry.

“ISO 26262 is helping automotive OEMs balance the safety versus that, and it’s a case of coming together the kinds of things that we can do to help them, and the kinds of things that they need to think of themselves to make that balance because you’re never going to have anything that’s perfectly safe,” said Bates. “You can take the car, you can encase it in concrete, put it at the bottom of a pool, and then it’s probably safe, but it’s not very competitive. That’s the balance that they’re going to have to face over the next 5, 10, 15 years.”

The business of risk
Conceptually, at least, this type of risk platform has existed in the server area for some time under the acronym RAS, for reliability, availability and serviceability.

“Functional safety is another dimension of it,” said Anush Mohandass, vice president of business development at NetSpeed Systems. “The fact is that the world is full of random faults, and it’s going to be a probabilistic assumption that maybe the chip failed, maybe the chip didn’t. You may recall the braking incident with Toyota. It’s the same thing. Any death? Maybe it’s the chip, maybe it’s the software, maybe it’s the driver, or lack thereof.”

One of the big advantages of safety standards is they provide a reference guide for manufacturers, which is basically a best-practices roadmap that can be used to minimize liability in personal injury or class-action lawsuits. The better defined those best practices are, the better a manufacturer is likely to fare in court.

“There is a functional design issue, but there is also the legal documentation issue that you were prudent in delivering as safe a system as you possibly can,” said Charlie Janac, chairman and CEO of ArterisIP. “There are approximately 35,000 to 40,000 deaths a year on U.S. highways — about 1.25 million worldwide — so if we can save about 80% to 90% of those people, we can save 36,000 lives [in the U.S.] through ASIL Level 3 to Level 5 driving. The benefit to the U.S. economy is somewhere around $750 billion if you avoid the accidents, the economic damage, the lives, etc. The problem is that of those 4,000 people that are going to die, some of them are going to die because of technology, and they are different people than would have died the other way.”

Dealing with complexity
The big challenge is that these are complex systems, and they are built on new technology. The complexity of systems such as ADAS and autonomous driving have greatly expanded the complexity of automotive electronics.

“It’s a few orders of magnitude bigger than what used to be considered automotive electronics,” said Sanjay Pillay, CEO of Austemper. “That’s changed the landscape because the existing flows don’t scale. It’s for people like us to go address that part of the problem, which is make it scalable and meet the requirement of ADAS, for example, which is a true SoC chip. It’s no longer a microcontroller. How do you build systems with this level of complexity while still maintaining the standards that are required?”

The answer to that question isn’t straightforward. It involves everything from rethinking the system to rearchitecting tools to fit automotive, and it includes both methodology and engineering learning.

“We have teams coming from two broad extremes,” said Adam Sherer, verification product management director at Cadence. “There are consumer companies that are entering automotive [Apple and Google], having built big SoCs with more than acceptable failure rates. And then you have automotive companies that have not done rigorous verification up front in design. They just tested it. There’s still a testing cycle that will occur, but the speed with which these systems are maturing is pushing the automotive companies to do more up-front verification, more design-in. The consumer companies are feeling the harsh reality that maintaining an automotive manufacturing line means 100% products working, and turnaround times for errata are measured in hours. Trying to get these teams to find the right working points is a re-tooling across the industry.”

Kelf agrees: “This is now the next big discontinuity. It’s evolved from something that we all said, ‘Okay, we’ll get our verification systems working better,’ to a point where it’s, ‘Oh no, this needs a rethink of a lot of the things we need.’ And it’s not just the simulator, the formal verification, bring in some fault simulation. It’s right across the whole tool suite. It’s a whole methodology change. It’s a whole new understanding, and it’s a new cooperation between the vendors and the customers to really figure out how we can address this, how we can leverage the knowledge of the hardcore automotive guys who have lived this before. How can we use that knowledge in these tools? And what can we build on these tools to actually make that work out in the competitive environment we’re in?”

Even verification, a stalwart of electronic design, is undergoing change. “Traditionally, verification was more back-end,” said Bates. “And even from the pure quality, safety world viewpoint, you talk about verification every step of the way. The whole industry to be successful needs to do the same. As far as what that does to the tooling, it doesn’t make the traditional tooling entirely obsolete but it does force more and more sophisticated verification every single step of the way. Maybe you can expand upon the tools that we have today. Maybe you need new tools. You certainly need new workflows in using those tools, and it’s a huge change in thought process both for us and for our customers to be able to be successful.”

So while the system needs to be verified, so do the individual pieces of silicon that go into that system.

“Functional safety is an imperative because yesterday’s car had about $300 worth of semiconductors in it,” said ArterisIP’s Janac. “But if you look at something like the Tesla, that has $2,000 worth of semiconductors, it’s heading toward $3,000 to $4,000 per car. When you have more components, in order to keep the safety even at the old historic levels, the safety level of each individual component — because there are more of them — has to be significantly improved. That’s a semiconductor design, software design issue, but it’s also a tool issue. There’s a whole stack of these that have to work.”

Who’s responsible?
One of the big questions, which so far has not been fully answered, involves liability. When accidents do happen with autonomous cars, will errors be traced back to the chip design team?

“The chip design team has to do the robust design, and it has to have met the standard, and it has to provide the documentation that it met the standard, and then they should be okay,” Janac said.

But there are still a number of variables that are not fully defined. With the tremendous amount of development happening now, it appears there should be a a more standardized tool flow that accompanies ISO 26262. This is still under development by a number of companies.

Mentor’s Bates observed that the bulk of those efforts appear to be focused on the safety analysis aspects — identifying potential faults with a formalized process to determine what the mitigation should be. “There is limited good tooling for that today, and that’s a big hole.”

At the same time, it is well understood what is needed, even if the tools aren’t available yet.

“If you look at ISO 26262, there are two components to it,” said Austemper’s Pillay. “There is the measurable portion of it, and then there is the expert-driven, review-based portion of it. Both have to be done. There are tools for the measurable portion. Those will be standardized because you do want to be able to go through a tool flow and be able to produce all the collateral that’s required to get certification. The second half of it is the expert-driven part, where you still have to have the experts do it. The trick’s going to be in the balance between where you draw the line between the experts and where the tool flow is, or go completely expert-driven and it becomes a non-scalable problem. There are not that many experts in this world who can address that and get everybody going. You cut that down too much and it becomes too tool-specific. Then the questions start coming up about how to quantify or qualify these tools. We are still in a transitional phase. It will settle itself down at some point.”

At the end of the day, three things must happen to make this all work.

“First is resilient design, i.e., no tool is going to help if the architecture doesn’t include things like lock-step, or unit duplication or ECC,” said Janac. “Second, for functional safety, a third-party consultant is required who will say all of the rules were followed. It cannot be yourself. It cannot be the tool provider. It has to be a third-party safety consultant who says, ‘I’ve blessed this, I’ve looked at this, and it is conforming to that level.’ Third is the tool flow, which includes things like packet injection, fault simulation, etc. Those three things have to operate in union.”

Related Stories
Tech Talk: ISO 26262
What’s new in the automotive standard and how to design cars that can fail safely.
Rethinking Verification For Cars
Second of two parts: Why economies of scale don’t work in safety-critical markets.
Autonomous Cars Drive New Software
Security, reliability and complex integration are required, but can it happen quickly enough?
Self-Driving Cars Rattle Supply Chain
Shift from hundreds of MCUs to more centralized computing is creating chaos in the auto industry.