²ÝÁñÉçÇø

We have all seen plenty of car advertisements showcasing a vehicle violently smashing into an obstacle and how its safety features save the life of a crash-test dummy inside. These demonstrations display just a fragment of the tests that automobiles undergo, particularly at the end of their development. Long before a brand-new car can be slammed into a barrier, every single component of the machine must be comprehensively tested. As automotive technology advances and vehicle architecture becomes increasingly complex, this only gets more challenging.

Automotive developers have made remarkable progress over the last 100 years. Everything from mechanical improvements to electronic advancements to, more recently, software innovation, has powered disruption from system to silicon. This has also increased the importance of software platforms that can validate, test, and mimic the behavior of a real cockpit. The success of the software-defined vehicle, whose functions and features are fundamentally enabled by software, is growing at an incredible pace, as we get closer to cars driving themselves.

This results in rising complexities for automotive OEMs and their suppliers as they try to keep pace with advancements in an already competitive market landscape. For chip designers and verification teams, components in nearly every part of modern automobiles need to be rigorously tested and validated for safety, security, reliability, and quality as well as making sure the software performs as intended with each of those components properly ¡ª compounding the challenge. The consequence is extended testing time for engineers and longer feedback time for developers across the development cycle.

Read on to learn about how ²ÝÁñÉçÇø is accelerating automotive software development, and the road ahead for the automotive industry.

There could be more than 100 such units controlling the car that you drive, with most commonly found in systems such as:

• Powertrain
• Stability control
• Body control
• Brakes
• Steering
• Advanced Driver-Assistance Systems (ADAS)

As automotive manufacturers continue to innovate vehicle designs and features, new ECUs must be developed. Testing these ECUs and their capabilities becomes increasingly difficult with every new development. The resource costs of expensive equipment and pressing engineer workloads are a major obstacle for manufacturers (not to mention the consequences of hardware damage from bugs found during the testing processes). Engineers are limited to what they can achieve running tests with prototypes and the results of hardware-in-loop simulations (HiLs) being nondeterministic, causing multiple tests to produce different outcomes. A lack of confirmed test results leads to more testing, time lost, and more costs. Factoring in the hundreds of ECUs that vehicles have, and legacy development methods, just aren¡¯t feasible.

Bringing Code to Life with Virtualization

The solution? Building software-based test environments called virtual ECUs that allow engineers to transition their development tasks from the road and test rigs to a PC environment.

Virtualizing this development significantly decreases testing time and cost. Without risking hardware exposure, developers can conduct tests and receive feedback in minutes. This adheres to the shift left methodology, a practice of accelerating development by prioritizing software development much sooner and excluding the wait time required for functional hardware models to develop and validate the software. This strategy pushes developers to discover problems earlier, before designs are complete ¡ª allowing for bugs to be fixed sooner (before they are installed into hardware) to speed up delivery.

The serial nature of the traditional automotive development process means that one needs to first develop the ECU before the software, putting pressure on aggressive time-to-market schedules. Using a Triple Shift Left approach, teams can implement simulation and shared models to develop software early on a virtual platform, facilitating increased collaboration across the automotive supply chain. Depending on the final use case and the availability of the source code, different parts of the ECU software can be ported to a PC and be tested simultaneously at many work seats (in parallel).

Today¡¯s advanced vehicles typically contain more than 100 million lines of code and require more than 100 ECUs to implement functions. By leveraging the Triple Shift Left approach, teams can accelerate the development and design cycle significantly through virtualized ECUs well before hardware availability, all without compromising on functional safety, security, reliability, and quality.

Let¡¯s take a look at an example of a C-code project virtual ECU. On the left side of the graphic above is a sample configuration file written by the user, specifying compilers (i.e., Visual Studio) and directories, tasks, and the input/output. The user plugs this into the SBS tool in Silver, along with any additional files, such as specifications for A2L and DBC, depending on the ECU. The Silver platform then creates a virtual ECU from the configuration file with a cloned application layer from the physical ECU that provides operating system emulation, virtual memory, A2L conversion, XCP connection, and flashing.

Once built, virtual ECUs provide a variety of capabilities for engineers throughout the development process, such as:

• Immediate feedback in system context with manual tests and debugging
• Automated testing from module level to virtual system level
• Large coverage testing and validation
• Optimization of design parameters
• Pre-calibration on PC (the same calibration interfaces as in the car)
• Real-time running of applications: rapid control prototyping, mixed virtual, and real components, etc.

To conquer the complexity of software-intensive vehicle systems, we believe it is essential for the development process to be virtualized by shifting software development steps from prototype vehicles, test rig, and HiL (hardware in the loop) to the PC of the function developer. Continuous integration is also a critical aspect of the virtual ECU. Integrating with several continuous integration tools (i.e., Jenkins) allows developers to test code changes on an ongoing basis with immediate feedback as to whether the updates work or fail. This becomes a huge time saver for engineering teams waiting for software updates to be completed before being installed in the vehicles ¡ª preventing risk to the hardware and accelerating the testing process.

For a deeper dive into Virtual ECU architecture, view this webinar on .