Building Better Cars Faster

Carmakers are accelerating their chip and electronic design schedules to remain competitive in an increasingly fast-changing market, but they are encountering gaps in the tooling, the supply chain, and in the methodologies they use to create those cars.

While it’s easy to envision how CAD software could be used to create the next new vehicle’s 3-D look, and how simulation software helps developers optimize the PPA of the next automotive chips, it’s much more difficult to integrate all of these pieces into a safe vehicle that will last for a decade or more.

The first step in this process is to synchronize the supply chain and to define the different steps, including what can be done concurrently and what needs to be done serially. That is pushing auto OEMs and their suppliers deeper into modeling and simulation, using virtual platforms to develop software. This is a familiar concept in the chip world, where dummy blocks are typically used to substitute for actual hardware when it isn’t available. Then, when the hardware becomes available, the developer will go back to the model and clean it up. But it’s never been done in a safety-critical market like automotive, where a consistent stream of updates and improvements need to be qualified according to rigid safety standards.

“This can be very messy, but it is changing,” observed David Fritz, vice president of hybrid and virtual systems at Siemens Digital Industries Software. “OEMs now demand their Tier 1 and Tier 2 suppliers, as well as contractors, deliver a software version of the hardware module, also known as hardware-in-the-loop (HIL). This enables the OEM to design using virtual platforms without the actual hardware. Not only will this speed up the design process, it will turn the ecosystem upside down. The supply chain is not used to this.”

New design trends
Automotive design takes much longer than consumer electronics design. It may take years before a new model is released, and while that is an improvement over the past, it’s not sufficient for carmakers to stay competitive in the quickly evolving automotive market. Consequently, OEMs want to further speed up the design process for EV, SDV, and other new vehicles, so project schedules now include both parallel and serial tasks.

“Engineering groups and their executive management teams have adopted the ‘shift left’ mantra of moving testing, quality, and performance evaluation to early in the design process as the sure path to greater profitability and competitiveness,” said David Vye, senior product marketing manager for RF/microwave products at Cadence. “The pressure to shift left requires technologists to shorten design cycles through concurrent design activities and reduction of design inefficiencies that delay delivery. Product delays occur when teams are waiting on other teams to start their design activity, when designers are waiting for analysis experts to provide data, and when disjointed tools require significant engineering time to transfer design data between point tools. This is a common problem that occurs between the chip and IC packaging teams.”

It’s significantly more difficult in automotive, though, where safety is the paramount concern. Increasingly, design teams must be concerned with the electrical and thermal impact of inserting a device into electronic packaging and the resulting performance deviation. This is where virtual prototyping and other system-level analysis and simulation tools fit in.

Traditionally, software developers finished the coding process and then tested the software on an electronic control unit (ECU) or an ADAS device. If this or similar hardware is not available, software developers are left idling. Hardware-in-the-loop (HIL) real-time simulation, in contrast, allows the development continue because the hardware specification can be tested and verified as if it was real hardware.

Taking this one step further, OEMs now will require Tier 1 and Tier 2 suppliers and contractors to provide software modules that incorporate the actual hardware design for ECU and ADAS devices. Using this approach, OEMs can create a complete virtual prototype, and at least in theory, they should be able to test and validate the complete automotive design.

“In the past, developers would add new ECUs to address a specific function,” said Marc Serughetti, senior director for Embedded Software Solutions & Systems at Synopsys. “Once validated, the ECU would then be integrated into the rest of the vehicle and other ECUs with communication networks, such as CAN or LIN.”

But speeding up that schedule by shifting left is difficult enough in consumer electronics, and it’s much more difficult in automotive where safety is the overriding concern. However, this overall design cycle is too slow to answer increasing customer requirements for more convenience and safety capabilities, and missing a market window is costly.

“As a result, automotive OEMs are moving toward software-defined vehicles,” Serughetti said. “This approach requires new E/E architectures, such as zone controllers with central compute, Ethernet-based communications, and new automotive software platforms capable of executing multiple functions in parallel safely and securely. In addition, the architecture needs to easily support software upgrades and updates, simplifying vehicle maintenance and enabling new revenue sources for OEMs. Simulation, using digital twins to validate these more complex systems, has become essential to decouple physical system development, including mechanical and hardware from software development. Using simulation, developers can validate well in advance of physical testbenches and mule vehicles availability. They also gain in efficiency, as simulation provides higher visibility and control, and can be deployed easily to execute large number of test scenarios in parallel. The result is earlier and simpler development, faster validation and deployment of new functions, and higher-quality software.”

Fig.1: The complexity of a vehicle makes automotive design challenging. Source: Cadence

From SoC to digital twin
Virtual prototyping is a complicated process, and while it has many benefits, the implementation can be challenging. How do you know, for example, that an ECU will function faultlessly in final production? More importantly, how do you ensure that every component (SoCs, ECUs, ADAS, and an internal private network such as the CAN bus) will work well together, taking into account timing, latency, data flow, error correction, etc.?

The hundreds of millions of lines of code within the vehicle must perform without errors. When everything is operating in real-time, what happens if there is a software malfunction? How would this impact a vehicle moving at top speed on a freeway? Reliable testing and validation are critical. But even if ECUs from various suppliers have been tested successfully, integrating them together adds another level of complexity.

“Testing ECUs separately is only the beginning,” Fritz said. “The subtle issues, which take the most time to discover and correct, only become apparent once all the ECUs are connected together and operating simultaneously. This simultaneous operation stresses the network connecting the ECUs. Latency is injected due to network bandwidth limitations. Arbitration and transmission times over distance will add latency. Using stimuli requires synchronizing the entire system and evaluating each ECU’s outputs based on context. This is where scenarios come in. They provide realistic stimuli into the system, and the aggregate outputs of the ECUs in the system can be evaluated at the system level. For example, does the vehicle hit a light pole? The final scenario will be evaluated based on the operation of all of the individual components, such as ECUs, operating together.”

Initially, the modeling and simulation start with the SoC and system-on-module (SoM), then go on to include ECUs and ADAS. Even though Tier 1 or Tier 2 suppliers design and test many of these components, OEMs have the ultimate responsibility for ensuring a virtual prototyping will deliver a vehicle in which every component functions faultlessly. The big challenge is to how to do this with maximum efficiency and still meet safety and reliability requirements.

Most OEMs are familiar with automotive SoC design and selection. The next step is to optimize ECUs and ADAS, which is an ongoing process.

“Automotive electronic control units (ECUs) can benefit from size and weight reduction when PCBs are designed with modeling tool,” Cadence’s Vye said. “This will miniaturize the PCB with fine-line multi-layer substrates, blind and buried vias, microvias, substrate embedded passive and active components, and rigid-flex substrates that can be folded and fitted into automotive housings that target specific voids and spaces within the car. Integration with mechanical CAD (MCAD) tools ensures productive ECU co-design of housings and PCBs.”

Automotive ECUs created with PCB, SiP, and SoC fabrics also must accommodate harsh thermal and electromagnetic operating conditions within a car. “With inter- and intra-ECU data rates also rising dramatically, this demands careful signal, power, and thermal integrity analysis,” he said. “Gigahertz communications between memory and CPU in SiP and PCB designs within an ECU, or network communication between ECUs, all benefit from signal integrity (SI) analysis, where signal, power, and ground can be coupled and simulated together.”

Looking at the big picture, the automotive industry is moving from a very linear model to a more collaborative model, where the interaction and engagement of OEMs with suppliers are changing. Synopsys’ Serughetti noted that OEMs are interacting deeper into semiconductors and software, thereby forming new ecosystems.

“Virtual vehicle vision enables this integration and interaction to happen. Technologies to establish a virtual vehicle need to be scalable on multiple aspects. An important one is scalability for progressive build, where virtual ECUs from different suppliers need to be integrated together,” Serughetti said. “A virtual vehicle infrastructure can be used to facilitate this vertical integration, from SoCs to ECUs to the virtual vehicle. It actually provides a lot of value for the OEMs. They can use this infrastructure to make sure an ECU meets their requirements. In this way, their suppliers can integrate and validate the ECU very early on, both standalone and in the context of the overall system. The process works a little bit like a plug-and-play system where you can add another ECU to an existing system, but also evaluate different ECUs or software modules.”

Today, there is no comprehensive tool OEMs can buy off-the-shelf to do virtual prototyping on an entire vehicle, according to multiple experts. That requires modeling of individual components or modules and the integration of these individual components into a virtual vehicle. The most likely scenario is that different modeling/simulation tools may be used to model individual components. This will depend on the type of model (completeness and accuracy of the representation), which is itself driven by the validation use case under consideration.

For example, the simulation of vehicle dynamics has different requirements than those for simulating ECU software. Similarly, if a very accurate model is needed (to the physical level), this may require a different technology than a very high-level model, which just provides a simple functional behavior.

“Models are going to come from various parts of the supply chain, with different parts employing different tools,” Serughetti said. “The key is, then, at the vehicle level. Technologies must enable users to bring together each individual component model and their associated simulation technologies to build the virtual vehicle. Standards like Functional Mock-up Interface (FMI) will play a key role here.”

[FMI is a standard to exchange dynamic simulation models. This free standard defines a container and an interface to exchange dynamic models using a combination of XML files, binaries, and C code, distributed as a ZIP file. Version 3.0 was released in May 2022.]

Digital twins
Ultimately, OEMs will use something like a digital twin (DT), which relatively new in the automotive space and still evolving. The automotive industry has different opinions about DTs.

“It’s a reverse ‘Lord of the Rings’ situation,” said Frank Schirrmeister, vice president of solutions and business development at Arteris IP. “There probably will never be one simulation that rules them all. Development teams use different tools for simulating various scopes during projects. The ‘divide and conquer’ approach is not dead, because the scope and complexity of what users can pragmatically simulate depends heavily on aspects like the simulation’s fidelity; the affected domain — electronics, mechanics, etc.; the type of use model — architectural analysis, optimization for power, cost, and other characteristics, functional verification, software development, and so on; and many others.”

Some consider any development platforms that allow simulation of the design throughout various phases of a project as a ‘digital twin.’

“The definition often includes simulation, emulation, and FPGA-based prototyping,” Schirrmeister said. “However, its purpose extends into the product lifecycle for aspects like predictive maintenance, for which different types of stimulation may be better suited. I have seen cases in which pre-production digital twins reproduced defects identified during a product’s life cycle.”

A vehicle may look like a system to the OEMs, but it is more accurately a system of sub-systems. “Many of these sub-systems come in the form of heterogeneous electronic modules, which are continually evolving thanks to the underlying advances in semiconductor and integration technologies that support greater sensing, computation, and communications performance in a smaller footprint. These highly complex modules still depend on specialized design, analysis, and implementation tools, which are computationally more powerful and integrated than previous generations of EDA. Through the adoption of in-design analysis and design platform interoperability within the context of the digital twin, OEMs will be able to simulate the function of the whole vehicle on a practical level,” added Cadence’s Vye.

Designing with safety, security in mind
As digital twins and the software simulation of the many functions and interactions of every single component within the vehicle continue to evolve to be the ultimate virtual prototyping solution for automotive, a critical piece that cannot be overlooked in the automotive design process is the requirement for functional safety and cybersecurity.

Thierry Kouthon, technical product manager, Security IP at Rambus pointed to the importance of using comprehensive security approach. “Rambus’ CryptoManager Root of Trust (RT-640) is a security processor that is ASIL-B certified. The ASIL-B certification level means that the RT-640 functions as designed, even when failures occur in the IC, as long as they appear below a certain probability. The Integrity Level selected, ASIL-B, dictates the probability. We mainly used two tools to ensure that the CryptoManager Root of Trust (CMRT) will behave as predicted. The first tool provided Diagnostic Coverage results, which measures the effectiveness of the system in detecting all failures. Diagnostic Coverage considers all the components of the CMRT and measures whether the safety mechanisms in place can detect failures in them. A second tool provides fault campaigns, and can completely emulate the functioning of the CMRT by using the exact representation of its circuit. It simulates faults artificially in the CMRT and detects whether they are handled appropriately. Using both of these tools, we can demonstrate our design’s viability to our auditors.”

On functional safety and the ISO 26262 standard, Kouthon noted that, depending on the geography, automotive design requires manufacturers to build systems that achieve functional safety, which aims to reduce failure risk when using complex electronic systems in motor vehicles.

“Semiconductors used for automotive applications face environmental challenges like temperature, moisture, and vibrations,” Kouthon said. “In addition, manufacturers are designing more complex ICs with shrinking geometries. All those factors increase the risk of fault. Functional safety is a property of these systems, which can be assessed using the methods described in the ISO 26262 standard. Functional safety is essential to reduce the risk of endangering motor vehicle passengers and others in the vicinity of the vehicle, and the risk of damage to other vehicles, roadside property, and nearby infrastructure resulting from an accident. Functional safety has substantial legal ramifications in Europe and other geographies because it relates to product liability. In many judicial systems, manufacturers can avoid product liability only if they can demonstrate that the system could not prevent a fault based on the state of science and technology existing at the time of manufacturing. The ISO 26262 standard introduces Safety Integrity levels to mitigate four categories of risk levels (ranging from A to D, with D being the highest and A the lowest) for vehicle equipment failure, based on the potential damage to property and endangerment of occupants.”

The adherence to ISO 26262 strongly impacts how OEMs build modern vehicles. “They need to introduce in their designs error correction schemes, test sequences, redundancies, and many other mechanisms to ensure that the probability of failure of electronic equipment in the vehicle is below the thresholds established by the ISO 26262 standard. Failure to do so may result in vehicle recalls and legal action,” he said.

Arteris IP’s Schirrmeister agrees. “Developers will simulate and test various aspects, including safety, security, and functionality, across a defined case of scenarios, power consumption, thermal effects, and many more. Again, no one tool covers all of it, and even for specific use models like verification, teams will use different tools depending on the required fidelity — software-based simulation, emulation, prototyping, and others. That’s why users ask IP vendors to provide models of different fidelity, some abstracting access to memory as a single transparent transaction, others modeling the specific performance aspects of an NoC.”

Other challenges and the future
As virtual prototyping matures, OEMs have to deal with the challenges that come from software reuse and updates, as well. As new features and functions are added to the vehicle, it is beneficial to re-use existing, proven, software code. That code may be spread around the vehicle, in ECUs and ADAS, for instance. If there is an update of the original code, it will be important to apply the changes throughout. In the next few years, the millions of lines of code today will be increased manyfold. Imagine the burden of keeping track of all the changes. Additionally, updates will be sent over the air to vehicles on the road. Unless bookkeeping is done correctly, the consequences will be unthinkable.

Automotive is a slow-moving industry for good reasons. Unlike consumer products, vehicles are on the road for a long time. Many considerations must go into the design process, such as functional safety, which sits at the top of the list. The addition of software and electronics will surely add to the complexity of the design. On one hand, OEMs want to accelerate the design process, but on the other, the availability of the all-in-one, off-the-shelf virtual prototyping design tool may take time.