How To Model Cars

The most technologically advanced and comprehensive consumer product in the world today is not the smartphone. It’s the automobile. This is easier to see once the hood is up and you can take a peek around. Today’s cars contain sophisticated motion systems, crash safety systems, climate control systems, driver assistance, and infotainment, to name a few.

In semiconductor design, one of the most prevalent ways to address complexity is by raising the level of abstraction with modeling. But given the complexity of today’s vehicles, there are questions about whether system-level modeling is even possible.

To be sure, it is an incredible challenge to be able to do system simulation of the whole vehicle, so not surprisingly, the automotive industry today is in its very early stages of doing true system simulation, according to Sandeep Sovani, director for global automotive industry at Ansys. Instead, he said, system simulation is done at different stages, within very different domains. A simple way to define the domains is as follows: whole-system level, subsystem level, and component level.

“At the whole-system level, there is simulation that is routinely done looking at the drive performance of the vehicle—how the vehicle will perform, what fuel efficiency it will give, what type of torque it will take when it is running through different types of drive cycles, like going through the city or on a highway driving cycle,” Sovani said. “But those system simulation models make a lot of assumptions about the subsystems, because it is simply not possible to include the entire details of the subsystem at that level.”

Even the components themselves are complex systems. A braking system is much more than just the mechanical components. “For a system like this, at a component level, more detailed system simulation models are done until we go to the very bottom where full 3D models of components are required. A lot of what goes on is in the full 3D simulation of the models. Today, this is done with different tools, by different people, in different departments, in different companies in the automotive supply chain,” he pointed out.

Critical in all of this is having the ability to create modular models that can capture the behavior of a particular subsystem, and then to plug that modular model into a higher-level system model, Sovani said. “In addition, even if you have modular models of some components that get put into a system model, it will become a huge, monstrous system model, and it would be very difficult to run. Because of this, Model Order Reduction (MOR) or Reduce Order Models (ROM) is done such that once that model of a subcomponent or subsystem is made, then there is a ROM that would run fast. It will capture the behavior as accurately as possibly of the subsystem as needed. Of course, in reducing this order there is a loss of accuracy, just like image compression, for example, but that’s where the software researchers and algorithm researchers are working on figuring out the best way to preserve the fidelity of the model while still shrinking it down into a fast-running model.”

An automobile is basically a system of systems, which is confusing because there is no clear starting point. Thomas Heurung, manager of technical sales teams in Europe and India at Mentor Graphics, explained that a system modeling approach really depends where you are coming from. “Some guys are talking from a software system, some are talking from a hardware system, some of them are looking at this from an overall system, like an ABS or ADAS system. Then, when you take a couple of steps back, you could consider traffic as a system of systems. These are examples of the different perspectives found currently in the automotive design ecosystem today.”

And while the automotive design ecosystem is complex, he asserted it is the system itself that needs to be specified, which itself is very complex on a high level. “Coordinating the supply chain and providing the right type of specification, and then going about the requirements engineering in a way that the different suppliers can play a part in this big picture, is obviously a challenge. But it has nothing to do with system-level modeling in the automotive systems.”

As with all complex systems, a successful end product requires efficient communication of specifications among ecosystem players.

Frank Schirrmeister, senior group director, product management in the System and Verification Group at Cadence, said he knew of one attempt in the aerospace world where there was a full system simulation of a Boeing airplane. “From a capacity perspective the number of things you need to simulate is pretty huge so the question becomes, at what level of abstraction can each of those be simulated?”

Schirrmeister pointed to a recent conversation about how to bring together mechanical and electrical domains. “The picture is very complex from the system model perspective so my answer would be to not get that to the point where you co-simulate everything, but a model exchange at the system level between disciplines like mechanical, electrical and so forth. What you do is you do exchange between the different domains. You do it by way of modeling, but because it’s a system model you have done some level of abstraction in which you characterize the pieces relevance for the other tool to look at. Will there be a co-simulation at the level of which direction the electrons turn in on the silicon, like SPICE level together with the software and the mechanical effects? With everything simulated at full detail, the answer to that is probably no.”

He said engineering teams are taking into account tradeoffs being made in the context of system modeling, which means they are abstracting and removing some data. That has to be accounted for in the detailed representation. “For example, you can integrate an abstraction of the Ethernet model into your simulations to understand how it interacts with the software driving data through the Ethernet. The chip provider buys the IP, the chip provider adds their models of the IP, gives that to their customer, which is the Tier 1 — let’s say a Bosch or Continental or Delphi. They take the chip IP and put it into the ECU. So now they may add their environment around the ECU and provide a model to the OEM, and then the OEM integrates that with the rest of the system. It becomes very very cumbersome to understand all the abstractions necessary from the IP level all the way down to the OEM. However, it is getting better. If you look into the RFQ’s of Tier 1 providers, they will ask for a transaction level model of some kind to enable early software development on the chip.”

There are other challenges for system-level modeling. “As we move to add untimed TLM or higher-level abstractions on the hardware side, algorithmic abstractions for software and analog, we don’t have consistently complete synthesis paths for all of those elements, especially not on the analog side,” said Adam Sherer, product management group director for automotive safety in the Systems Verification Group (SVG) at Cadence. “It comes back to how the verification tasks are divided so you are not really repeating anything, but answering how do you make sure you’ve done enough at each level? For the standards side, the ISO 26262 asks for both modeling and requirements tracing because it recognizes that the modeling is going to be incomplete and imperfect. It’s good, you need to do both it because really you need to get two things out of that—you get the connection across modeling abstractions with some means of actually doing that, and you get a traceable record of what you have verified. Those things are really critical when you are looking through the traceability from the OEM all the way through to the IP components that make up the work products in your end system. We need to make those connections. Both are needed, but I would argue that the requirements are more persistent across all of those abstractions.”

There is plenty of agreement about growing complexity of these systems. There is less agreement about what to do about it.

“You have 70+ controllers sitting on a CAN and approximately 100 million lines of code, so the problem is very large,” said EDA consultant Bernard Murphy. “Many of those systems must deliver a real-time quality of service, which is challenging to validate for conventional modeling/simulation methods. You have to worry about all of this operating effectively in a very noisy environment, through internal and external EM interference coupling to 5 kilometers of cabling. And you have to prove safe operation under all possible circumstances for the 10-plus years of life of the vehicle, so you have to worry about hardware and software reliability, soft error rates and more.”

He believes the only way to manage this is through abstraction and separation of concerns and related standardization.

Playing catch up
While not the full answer, the advanced approaches described above could be poised for adoption. But they’re not. Far from it, in fact, said Sovani. During a recent meeting, one of Ansys’ customers disclosed its approach using what is called “document-based systems engineering,” which means one group does the modeling, creates the output of the model, and creates a document (report) based on that, which is then passed onto the next group of people. They take the inputs from that report and put it into their models. “This is the very, very early stage where people want to ultimately go to model-based system engineering with models that can be transferred, models that can plug and play with each other nicely.”

It might seem like a no-brainer to borrow methodologies from the semiconductor space, but looking at vehicles today, Sovani said, the technologies embedded in it are so diverse that the design and engineering have to be done in equally diverse ways. “For example, a car has a gasoline engine, and the gasoline is burned inside of the engine, so the combustion process needs to be developed and modeled. The engineering of that combustion process is itself a very complex, difficult task. There are books upon books upon journals of papers, decades of research, thousands of researchers working on that. That’s very different from, let’s say, a vehicle that now has a battery in it, and the electrochemistry of the battery has to be developed. Those are very different things, and further from them would be crash safety of a car. How is the car going to collapse in the event of a crash? How is the metal is going to bend in the right way to protect the occupants? These sciences are so different. In those scenarios you might have a thermal engineer working on the combustion engine. You might have a chemist working on the battery, but have a mechanical engineer working on the structure side. It’s very different, and that makes it challenging to have one unified design process.”

Unchartered waters
For a company just entering the model-based development market, the observations are plentiful.

Tucker Taft, director of language research at AdaCore, explained that for the past two decades AdaCore has been selling compilers mostly to the aerospace and defense market, and focusing on the Ada and C programming languages. About four years ago, the company realized that modeling was coming of age—particularly with one of its customers, which went from buying hundreds of copies of its compiler to just five. When questioned, it turned out the company had completely moved to model-based development, so it didn’t need hundreds of copies of compilers for programmers because they’d gotten rid of their programmers.”

To address model-based development, AdaCore knew it would need to be focus on the safety side of things, and to this end the company is building a so-called auto-coder/co-generator that will take Simulink models and generate Ada or C from them. Taft said the goal is a tool that can be trusted to “generate precisely what the model said—it doesn’t add anything, it doesn’t remove anything.”

It turns out the auto industry has been getting by without these trusted co-generators for a while, but as the industry changes and becomes even more safety-conscious—think self-driving cars—if the car does something crazy, it’s hard to blame the driver. “Clearly, the stakes are getting higher in the automotive industry,” Taft added.

Satisfying those stakes means there is work yet to be done.

Alexander Tan, product line manager, Automotive Solutions Group at Marvell Technology Group, stressed that system modeling is an important step in building a fault-tolerant, automotive network for next generation E/E (electric/electronic) architectures. “Some level of component modeling is built into specific automotive standards such as the AUTOSAR operating system. With the advancement of Ethernet systems into vehicle architectures and the use of new protocols like Audio Video Bridging and Time Sensitive Networking to support different classes of data traffic, there is a need for more advanced network modeling tools and there are several companies working to provide solutions.”

This often requires a stage-testing a prototype network, as well, to ensure correct system design.

Finally, a third important type of modeling is at the channel level to investigate performance expectations in the electrical harness and related systems. “By modeling at the component, channel, and network protocol level and combining that with testing of prototype systems, it is possible to develop and refine system level automotive designs,” he said.

But as with all complex systems, integrating new technology into the design process takes time. And no matter how great the need, or how dramatic the changes in automobiles, modeling will have to prove its usefulness and reliability over a period of years, across groups with very different needs, and incrementally through multiple generations of vehicles.