Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
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 Synopsys is accelerating automotive software development, and the road ahead for the automotive industry.
Electronic Control Units: A Core Component with Limitations
Electronic control units (ECUs) are embedded systems on semiconductor chips that run software to achieve a variety of functions. They provide numerous capabilities ranging from necessities such as engine control and brake lights, to safety and security functions for deploying airbags and locking doors, to comfort features letting you customize your car’s seat angle and temperature.
Traditionally, automotive software development up until today has dealt with several bottlenecks. Apart from dealing with ongoing software advancements, using a hardware-based development approach means that before you have an updated .hex file available for testing, conveying data saved in a hexadecimal format and typically used by microcontroller units, the software cycles between several teams and takes even more days or weeks if you have additional suppliers in the loop. Once the updated file gets uploaded to the electronic control unit, further tools are needed to run, measure, and calibrate the software.
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.
Getting Feedback in Minutes with Virtual ECUs
With the Synopsys Silver virtual ECU platform, developers can build ECUs by launching virtualized environments to test every aspect of an ECU’s software stack. Just from a PC, you can use a physical ECU’s application code to construct a virtual ECU to short-circuit several aspects of the development process. Silver also acts as a powerful platform for testing and validating the interaction of networked ECUs, transmission, car components, and engines through simulation.
Developers have a variety of options when it comes to building virtual ECUs. Most often, they generate virtual ECUs from C-code libraries, but they can be derived from other sources, including simulating models. Developers tasked with an assignment — say, a chip simulation project — commonly don’t have full access to the application code, but virtual ECUs can still be created with Silver from compiled binary code and flashed onto the target. The build process can even be automated.
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 Using a Virtual ECU to Accelerate Automotive Application Software Development.
Looking Ahead
In the age of software-defined vehicles, the automotive industry is expected to roll out more advancements in ADAS technology with almost limitless possibilities on the horizon. With every year, the promise of seeing fully autonomous vehicles driving on the road alongside us seems attainable.
For society to trust autonomous vehicles, they have to be as close to perfect as possible. A significant portion of the responsibility for preventing bugs and system failures falls on the developers who design the underlying software powering these technologies. Virtual ECUs help them do that — quicker and cheaper. By virtualizing test environments, engineers can reduce their development time (and cost) with continuous integration and maximal deployment efficiency.
As the future of automotive drives toward autonomous vehicles, virtual ECUs will be a key enabler for teams to validate and test without additional hardware and hit the accelerator on automotive software development.