New Design Approaches For Automotive

The push toward increasing autonomy in automotive is driving new approaches in electronics development. Instead of designing individual components, the focus now is on modeling in context.

The ultimate goal is to create an executable specification based on industry-accepted standards, with enough flexibility to be able to customize that spec for different customers. This is a difficult engineering challenge, and by most accounts, automotive is now at the top of the list for complex electronic design.

By comparison, it’s much easier to build the electronics for an airplane than for an autonomous vehicle. The amount of logic and complex software that resides in a vehicle is 10 times greater than for an airplane. Automotive design brings together every form of technology and pushes all of them forward in unison.

One of the key approaches is model-based systems engineering (MBSE), and digital twins by extension. These are not new, and they have been used in the past for both aerospace and automotive. But they are evolving quickly to handle the growing complexity of increasingly autonomous vehicles.

“If you’re creating an anti-lock braking system or a windshield washer or something like that, it’s relatively simple and you don’t have to spend much time with these tools to be able to come up with that model,” said Kurt Shuler, vice president of marketing at Arteris IP. “But once you get to something really complex like a system on chip — just like with creating SystemC models or the like — you could spend more time than you would on the RTL, or on writing the specs for the RTL, the requirements and use cases for the specs for the RTL, or a SysML model.”

MBSE is far from simple. “In other spaces, there’s some automation, reuse, etc.,” Shuler said. “If you want to get a really detailed model for some of these semiconductor designs, it’s going to take so much work and time to do that. By the time you have it, it may not be worthwhile. These tools come out of the big mainframe software engineering type of tools. It’s UML with some system stuff put on it, and it’s a lot of the same vendors. Also, there’s no good open source tooling for this.”

But this kind of approach is considered increasingly necessary. “You cannot wait for RTL to be available and you cannot wait for the netlist to be available to look at power,” said Marc Serughetti, senior director product marketing, embedded software solutions at Synopsys. “You need to analyze those earlier, and you need to analyze in the context in which this is being used. This is why we talk in architecture design about workload, where those workload models are defined by how the SoC is going to be used, and what the load will be on that SoC, so you can explore that SoC and have an executable specification you can use across teams.”

What’s particularly attractive about MBSE is the ability to do pathfinding. “There’s a dynamic aspect of this early analysis, and the exploration of those systems, along with the ability to communicate between teams,” Serughetti said. “As automotive platforms become more complex, there’s more software. There are so many people involved in developing the system — it could be SoC vendors, OEMs, Tier 1 suppliers, or software companies. The old concept of writing a Word document and exchanging it does not scale anymore. That’s the clear reason you need an executable specification, and you have to be able to share that executable specification because that’s the best way for people to look at it. Systems are too complex nowadays for somebody to use a piece of paper to understand how it works and how it needs be executed.”

Others agree. “We have the ability and the need these days to model systems at a very high level, and to model them very early,” said Frank Schirrmeister, senior group director, solutions marketing at Cadence. “The interesting question becomes, when you go from phase to phase, how are the phases connected, and how much effort can you spend early on for that? It’s quite interesting to see how everything fits together. You would like to have one flow, but the step from one to the other is sometimes difficult and depends on the application domain, whether or not it’s actually something that makes sense.”

In the late 1990s, there were efforts in the industry to connect SysML to SystemC, but the question remained, how well does it connect into the implementation flows?

“Will we get ever to the point that you just put a specification in the black box and out comes the system and chip? This is the right question to ask,” Schirrmeister said. “Do we actually connect anything from upfront here, down into the implementation flow? Can we get a requirement spec in here into this black box and then out comes a chip and everything? The answer is, probably not. There’s refinement, and the models are quite a bit of a challenge.”

Keeping to the higher levels of abstraction can help, Shuler said. “That’s why with some of these physical systems, it’s a little bit easier. There are fewer moving parts, but once you get to semiconductors, it gets difficult. I’ve talked with people at ISO 26262 events to try to understand what people are doing, because I would love to have a more formal definition right up front of what this is. But one of the problems is that you can go down a rabbit hole to literally designing the product rather than just coming up with the requirements for the product. Ideally, you want to provide enough upfront requirements, and perhaps some use cases to describe what the end result should be, while giving the engineering team a lot of time for creativity. When you start defining things too detailed at the beginning, what you end up doing is a traditional waterfall process. And we don’t have that space to innovate.”

Big picture, new challenges
Increasingly, EDA vendors are involved in turnkey projects to deliver whole SoCs, and engage as consultants, which means they need to understand the whole system. And because companies like Volkswagen are building their own SoCs, those designs typically leverage IP from companies such as Arm, Synopsys, Cadence, Siemens, and others.

Since automated and autonomous driving will be implemented by one chip in the future, it means we have huge complexity with these “monster chips,” said Bernhard Bauer, member of the technical staff at Synopsys. He noted that OEMs tend to model different features in a standardized way.

Different OEMs are at different stages of implementing model-based vehicle development. “One aspect of model-based development to keep in mind is there are different paths into this that may have different virtual representations of a vehicle,” Serughetti said. “For example, in a whole virtual vehicle concept, there can be different levels of abstraction, such as when there is a virtual prototype model of an SoC on which software can be run. There are also technologies that provide a system-level abstraction. So there are a variety of ways to put together models of virtual vehicles. The challenge here is at the higher level. Engineering teams want to validate the functionality of a function. They don’t care too much about the underlying hardware in those activities. But other teams may want to bring multiple virtual prototypes together with the low-level software, because they’re interested in the specifications and how to validate the specifications when it comes to multiple ECUs talking to each other, and how to use those models for development.”

Given the highly competitive relationship among OEMs in the field of autonomous driving, it will be the overall concept of vehicle that will win the race, not the model behind it, Bauer noted. “This model will get unified over time, but at the moment some OEMs — especially in Europe — are still only half aware how important this modeling is. And it is this one model where the specific behavior of the vehicle can be configured. The most important aspect is the model-based system requirements, and apart from that, the model-based system architecture. Most people say the requirements indicate what has to be done, and the architecture says how it has to be done. There are also those who want a model on every functional and technical level to describe what has to be done, combined with a second level of how it should be done. On the whole, it is most important to catch the dynamics involved in all the autonomous behavior. A model-based approach is the one and only possibility to document and model the dynamics of all the features. Otherwise, you cannot fulfill the strong requirements on safety of the intended function (SOTIF), for example, or on the performance of the different SoCs that need to be built.”

This type of development is very application-specific, though, and automotive OEMs are likely adopters because of their focus on standards and standardized development approaches.

“There are certain industries that care about it much more than others because it becomes a question of predictability and repeatability,” said Schirrmeister. “You can automate with high-level synthesis, and with automation you can make the process repeatable from a higher-level description to get to a lower-level description. That’s actually something which is predominant in the aerospace domain. In aerospace and in automotive, people have been willing to build and automate this much more than in other domains. The reason there is not time-to-market or speed, but the repeatability of the flow. They want to automatically generate the software from a higher-level description, and then not have to fiddle with the software itself, but change the high-level description and get this flow.”

MBRE vs. MBSE
A new twist on MBSE is model-based requirements engineering (MBRE). which was developed based on feedback of automotive OEMs. They said that while MBSE made sense conceptually, was too complicated and didn’t reflect how their teams worked.

“Coming from the semiconductor industry, I thought, ‘What’s the big deal? We model everything so when you’re actually implementing a chip, you write it in RTL or Verilog or VHDL, and that is essentially a model,” said David Fritz, senior director for autonomous and ADAS at Siemens Digital Industries Software. “It just happens to be a model with enough detail that we can synthesize the netlist, and then go through the layout process. I realized it was all model-based engineering. Automotive OEMs are used to relying on the Tier 1 suppliers to say, ‘I’m going to give you the driving module, I’m giving you the steering module, and you don’t need to know what’s inside.’ Therefore, everything is a one-off. Everything is custom. Everything is the perfect fit for that one job.”

It led Fritz to wonder, “What if you write your requirements, do an abstract model, refine that model of the whole vehicle, so you’re doing hardware/software co-development/co-verification in a continuous integration? You’ll get there faster. This is agile development for a car.”

Still, questions remain. For example, what if there is a requirement to travel 100 miles per hour on the Autobahn and brake in time? How does that relate to the requirements breakdown?

“We’re modeling as best we can on the requirements that we have,” he said. “Then, when we run that dynamic model, new stuff will pop out. The model is refined to address that, and more new stuff will pop out again. This process refines the requirements as you get to higher and higher fidelity. That’s requirements engineering. Anybody who thinks they can map it in a digital twin is right, but they only get half the story. The rest is how you use digital twins to discover new requirements that go deeper and deeper.”

Until now, the biggest barrier to OEMs adopting MBRE was the availability of models of components from the tiered suppliers, but things are changing. “In order to have these models of the vehicle so they can determine what the requirements are, models have to be available,” Fritz said. “You start with the OEMs. Then they start telling their suppliers they need the models. Until about 18 months ago, the OEMs would get push back. Now, it’s completely turned around. There’s one OEM in North America that has so adopted this that they’ve gone out to all nine of their suppliers and said, ‘We need models of all of your solutions.’ They started pushing, and now we have six contracts in progress to develop the models.”

Specifically, the process begins by entering requirements, and a tool records those requirements, which then generates a functional model. Then, high-level abstract attributes are specified, modeling what the cameras, object detection, and classification are going to do. The hardware and software is synthesized for this system, and it is run in simulation. When this happens, data comes out, and it gets pulled back into the requirements so it can continue to be refined into a logical architecture.

Fig. 1: Using models to derive and validate complex requirements. Source: Siemens EDA

“We deduce the requirements from continually improved simulations that start very high level and abstract, and continue to increase over time. We end up with all these simulations that can do all these things — all these decisions that are made, including what the SoC looks like, for example, four Arm A76s and two Arm A53s. They can tell their supplier to go build it. They’re already running software. ‘Build it as quick as you can, but we don’t need it today. We don’t want what you have on the shelf. Tell us when you can have this. And if you can’t do it, we’ll go find someone else that does.”

In the past, OEMs relied on the tiered suppliers to tell them what they could have. “This has completely flipped. With this methodology, the OEMs can tell the suppliers what they need so they’re actually driving, instead of being driven by the supplier. And that’s what’s changing the ecosystem,” Fritz added.

Verifying automotive
Model-based approaches are very familiar in chip verification. Olivera Stojanovic, project manager at Vtool, noted that model-based approaches have been used by engineering teams to create the model of the whole chip in parallel. “The main reason for that is so the software team can start working on something while they’re in the development phase of this chip, because in other ways they will need to have the full chip developed and then start.”

In general, Stojanovic said the main challenge with automotive verification is how to be sure that all requirements are checked, and to plan all of the steps in advance, trace it for the code, and have very good documentation. This requires both extra effort from design point of view, and from the verification because it includes the traceability of requirements.

For the verification engineer, experience with automotive projects is valuable and teaches a systematic way of how things should be done. “There is a certain flow that you need to follow, and usually you need to create design verification requirements, and in advance, plan for each requirement, what kind of checkers you need, what kind of coverage, what kind of tests, etc.,” she said. “You want to follow a procedure — in advance. This means you need to understand everything before you start coding so that you will not have the situation where you started to develop something, and then figure out it is not correct, and it is not according to the specification. This may mean it is not defined well in the specification. All of these uncertainties should be eliminated at the beginning, and the verification is much better quality if you follow all of these steps in automotive.”

Conclusion
Approaches likes MBSE and MBRE are expected to become more widely adopted in automotive design.

“How much effort do I put in into this model development, and what do I get from it as a result? That’s the classic problem with the system design,” Schirrmeister said. “It comes down to how much effort to put into the models early on versus then later abstracting them from the implementation again?”

This is going to depends on the project. “In some projects, the risk of failure, if you have not done the early modeling appropriately, is quite significant,” he said. “Depending on the project, which comes down to the application domain, you may want to do models at higher levels early on to model the whole system. But again, it’s not the executable specification we thought we would get to 20 years ago. We haven’t gotten to that yet. More and more we look at connections, where people say they have a model in UML or SysML or any of the proprietary languages at that level and ask how to get from there down into the implementation? It will probably first become a reference for verification. And then, over time, it might feed into things like high-level synthesis. We’re still a ways off from where it will be a complete black box type of thing, where the tools crunch on it and make it work. But it’s becoming more important, given the system complexity and all the interactions between different elements like mechanical, electronics, and everything together.”

Related
Data Centers On Wheels: Special Report
Automakers shifting to HPC chips for improved performance and lower system cost.
The Case For FPGAs In Cars
Why the normal shift to hardened logic doesn’t necessarily apply.
Using 5nm Chips And Advanced Packages In Cars
Experts at the Table: Challenges and some potential solutions in ADAS and autonomous vehicle electronics.
The Good And Bad Of Auto IC Updates
Complex electronics and longer lifetimes will require much tighter supply chain management.