What Are Virtual ECUs?

 With highly automated and autonomous driving as an ever-present topic, a new measure of validation has emerged: the number of kilometers, or miles, driven during test drives. It starts with Google's frequently quoted 8 million miles driven each day just in simulations (read Inside Waymo's Secret World for Training Self-Driving Cars), and it probably does not end with the numbers calculated by the RAND Corporation, for example. According to a 2016 study, just to lower the number of accident-related fatalities by 20 percent, we would have to cover 5 billion (!) miles in tests for each car (read Why It's Nearly Impossible to Prove Self-Driving Cars' Safety Without a New Approach).

Of course, no one can drive this distance on test mules, or even simulate the sheer number of test drives in anything near to real time. This becomes clear with a simple example. Say you want to perform a test drive in an urban area with a speed limit of 50 km/h, and the stretch of the road you want to observe is about half a kilometer long. That’s about half a minute (36 s) of “just driving”, so you would need more than a week of 24/7 simulations to cover one million kilometers (200 hours, or 8 days and 8 hours). And we are talking about pure simulation time without overhead like preparation or result analysis.

So, you could just buy a dozen fully equipped hardware-in-the-loop (HIL) systems and run the simulation on the weekend, right? Unfortunately, reality is not as simple as our math example. This is where software-in-the-loop (SIL) simulation enters the stage. It improves code quality as much as possible before you start to use the precious time of the HIL setup. In software-in-the-loop simulation, virtual ECUs (V-ECUs) have increasingly come up as devices under test in discussions of SIL experts during the last 18 months.

In my experience, V-ECUs solve a lot of problems if you start from scratch with a whiteboard as your engineering environment. The question is: What can they actually do?

To be more precise, I would like to split this one question into three, and answer them one by one:

1. What is a virtual ECU?
2. Why is it useful?
3. How do I get one?

What Is a Virtual ECU?

The short answer is: Any software functionality that can be executed without hardware.

Of course, this is not quite true, as everyone involved in model-in-the-loop (MIL) testing knows.

There is one key quality of V-ECUs that distinguishes them from regular MIL testing: They contain the unmodified production code, pretty much as the final ECU does. There are several ways to make your production code run in a SIL simulation environment. V-ECUs, though, are as close to the real thing as you can get without compromising the goals of easy process integration and fast and deterministic simulation. And by fast I mean faster than in real time.

Key ingredients for virtual ECUs are:

• A realistic scheduling behavior based on the timing/triggering information defined for the functionalities. This includes the simulation of an operating system that is able to trigger the code in different cycles and with different priorities, and that displays exactly the behavior you expect: preemption, interruption, you name it.
• The integration of more than just your software functionality into a software architecture. At this stage, you are already able to validate interface compatibility, find missing data at (or mismatches with) your colleague's software functionality, and ensure AUTOSAR compliance, if needed.
• At last, ECUs are connected at the bus level, and there is no reason why V- ECUs shouldn’t be connected to a simulated bus. And if you do not want to deal with a COM stack just for testing, it should really be possible to generate or substitute the real stack.

For developers using the AUTOSAR Classic Platform: A V-ECU contains at least the application layer and provides the AUTOSAR Runtime Environment (RTE) as well as an operating system (OS) itself. Everything else, such as basic software modules (BSWs), is optional, but it has to be possible to integrate, or even generate, the BSWs for simulation purposes.

Why Is a Virtual ECU Useful?

Whenever someone asks me this question, my counter question is "What are you working on?" Usefulness always depends on your tasks.

The good thing about V-ECUs is that there is more than one way to benefit from them.

If you compare virtual ECUs with hardware ECUs, virtual integration tests are a test setup which massively benefits from V-ECUs. The reason is simple: More often than not, integration testing is blocked by failing ECU communication, either due to plain interface problems or because the bus communication is not up to date in all participating ECUs.

With V-ECUs, these are exactly the kinds of problems which can be detected early on. By using a SIL-based integration setup as well as V-ECUs and a simulated bus instead of real hardware, the overall integration can be brought to a working development version without using HIL resources. This way, the HIL-based integration test can focus on bugs that are harder to find instead of spending time on the same type of problem over and over again.

Look at V-ECUs from a function developer's point of view, too. V-ECUs are able to grow: Take the code you just programmed, automatically generate a simple run-time environment and operating system, and integrate this V-ECU into a small SIL environment. Connect it to plant models used in the HIL environment, create an integration with other light-weight V-ECUs, or even generate a COM stack to directly connect the V-ECU to a simulated bus.

I can still hear you ask “Why should I use an additional test artifact? I have used unit tests or back-to-back testing for ages.”

True. But are you able to easily integrate the device under test with other V-ECUs? Probably not.

A simulator for V-ECUs, like dSPACE VEOS, integrates not only V-ECUs, but also plant and environment models, e.g., motor models, vehicle dynamics models, or full-fledged driving scenarios. By the way, these are the same models you would run on a SCALEXIO system. Additionally, the PC-based simulator lets you use the same tools – and, by consequence, the same tests – you would use on a HIL test bench.

But being a computer scientist myself, there are two qualities I value above all:

• In the end, I test source code: I am able to stop and debug the V-ECUs and the whole simulation setup at any time. I just attach my debugger of choice, insert a breakpoint, and go for it. I use automated testing and code coverage analysis, but let’s be honest: In the end, a debugger is the most valuable tool when you want to get to the bottom of a problem.
• V-ECUs and SIL simulations are just software. First of all, time is simulated (and therefore an illusion, at least to a V-ECU), and the simulated time typically progresses way faster than in real time, and you can even influence it. Just use regular high-performance hardware instead of the five-year-old laptop that has been retired to the bottom drawer of your desk. The pure software approach is great for automated tests, and if the test throughput required by quality assurance increases, you can just use copies of the overall simulation setup or move it to cloud systems entirely. As I said, it’s just software, right?

How Do I Get a Virtual ECU?

This leaves us with the last question: How do I create a V-ECU? As I am writing this blog post, V-ECUs are not standardized (yet), so their creation depends on the SIL tool chain you are using.

At dSPACE, we always recommend a modular tool chain, so when talking about V-ECUs, we focus on standards whenever possible. Let's have a look at the content of a V-ECU. There is already a solution that makes automotive software modular and exchangeable: The AUTOSAR standard.

If I develop software according to AUTOSAR (and use an ARXML file to specify it), I can directly import it into an AUTOSAR authoring tool. In our case, this is dSPACE SystemDesk. But even if I do not work with AUTOSAR, I specify interfaces for the software, be it in Excel sheets or in XML files provided by other tools.  I then use SystemDesk to create an AUTOSAR wrapper by using the Excel sheet as specification for the appropriate AUTOSAR description. And when I say “I use SystemDesk”, I mean “My Python script processes the Excel sheet and automates SystemDesk”.

This means that whether or not I use AUTOSAR to develop software, in the end I have an automatically generated AUTOSAR software architecture in SystemDesk that I got either by importing an ARXML file or by scripting my very own Excel sheet.

And if my colleagues hand me a brand-new V-ECU based on the AUTOSAR Adaptive Platform that contains the latest functions for autonomous driving, I just use SystemDesk to neatly wrap it into a VEOS-compliant file format.

I used the term "scripting", because whatever I do to generate reusable artifacts, I want to automate it. This is the only way to generate the artifacts over and over again each time I update the source code. Hello, continuous integration and delivery.

Regardless of the initial form of the source code and description, the result is a V-ECU implementation. It can be directly imported to dSPACE VEOS for simulation or be connected with other V-ECUs as well as environment models.

Summary

V-ECUs are not as mysterious as one may think: In the end, it boils down to enriching the code, AUTOSAR or not, with an automatically generated run-time environment and operating system to use it in a software-in-the-loop environment. There, it runs fast – unless it reaches a breakpoint for debugging. The simulation itself does not depend on hardware, so after you set it set up once, you can scale it by either copying it, or by moving it to cloud systems.

And virtual ECUs are flexible. I like to follow Gall’s law and always start with a minimalistic one, containing just a small portion of the code I am writing. From there, I set up my test environment. After that, I let the V-ECU grow, adding more functionality and handing it over to my colleagues. They are quite happy to replace the restbus systems or functional models in their SIL integration setups with real production code provided by my V-ECU.

In the end, it is production code that is tested with virtual ECUs. To improve quality and to tackle the millions of miles of test drives just by means of simulation.