Softwares Replacing Hardware Prototype Development

Recently I published a blogpost announcing the new ETAS ISOLAR-EVE release and you’re maybe wondering what exactly I was talking about. So now I’d like to start a series of new posts about software testing in the automotive industry and what is nowadays possible to do on the PC. Before going into the details I'd like to focus first on what is actually needed in order to perform embedded software tests in a development process.

Test and validation are the most important activities to ensure the quality of automotive embedded software

Strong competitiveness on the market and high product renewal rates create short development cycles in the automotive industry. This obviously applies to the development of embedded systems. Unlike other industries such as avionics or railways, the automotive industry implements highly test-driven development processes in order to ensure the quality of the software.

Test and validation typically starts as early as possible using executable specification. It is of course then not really verification or validation in a software engineering sense but still already at this level system design and behavior of the embedded controls is often specified with models. The embedded functions are validated using specific rapid prototyping solutions – such as bypass in the engine management domain - and nowadays modeling at a higher level and system components integration at early stages are gaining more and more momentum (so called Model-in-the-Loop solutions). The reason behind this is of course the reduction of costly hardware prototype Development.

Software testing on the PC: what am I talking about?

Later in the development process this move toward virtualization also impacts the software development process. The idea is simple: to perform all software testing activities without evaluation boards, electrically complex set-up or even A-sample ECU connected to a Hardware-in-the-Loop system. At this level benefits are clear: lower costs – only software needed – time savings in setting-up the test platform and generally speaking better user experience through flexibility. Tests can be done significantly faster or slower for better investigation and there are no performance limits such as emulators or debug interface bandwidth. Furthermore it allows for dedicated software integration tests.

These promising perspectives need nevertheless to be implemented in an established test process. Because of the importance of those tests and in order to guarantee the quality of the final product it is definitely something to be considered carefully. The issue is basically twofold:

• to have a methodology and a corresponding process, ensuring that one knows what is tested and what is still to be tested all along the development cycle.
• to have the right virtualization technology fitting the defined process ensuring that the test intended to be performed is actually performed and provides relevant results

The topic of the methodology is my favorite. I have my taste for cerebral thinking - no I didn't write theoretical - defining how the world should be. After all I am an offspring of the culture which created René Descartes so that's understandable. But that's a very complex one too. Despite the homogenization and standardization of software architectures diversity is still the rule, between domains and sub-systems, depending on the cooperation models as well as business models between the market players. And culture plays quite a role too. Drawing a picture considering all the variants is not a topic for a blogpost rather for a discussion.

I have on the other side gathered experience for years discussing various use cases in different contexts and this is enough to extract some prerequisites that should be considered before deciding for a platform for software testing on the PC. At least I think. And that's what I will try to do now - without the ambition to be exhaustive in any way.

Make embedded software run on a standard PC

Obviously the first thing to consider is to make possible the execution of a target-specific code on the PC. There are different technical solutions:

• solutions based on HW simulation/emulation
• solutions recompiling the code for the PC target providing full access to the source code needing another level of abstraction

Both technical solutions have their strengths and weaknesses and they are highly depending on the use cases. So for now I will just allow myself a quite rough simplification: software testing is all about investigating software ensuring robust, bug-free and reliable behavior and for this access to the C-code during the execution is necessary. Thus solutions recompiling the code for the PC offer more flexibility and functionality whereas solutions based on HW simulation/emulation are more suitable for integration of the whole software into a virtual environment and its functional validation.

As I am blogging on software testing here I am focusing on the solutions integrating and recompiling the source code for the PC.

Having the HW abstraction at the software level is today made pretty easily possible with AUTOSAR. It might actually be more correct to write that it is made pretty easy as soon as a well-defined layered architecture is defined at an early stage. I have seen several "in-house" solutions in use that have been developed even before AUTOSAR. But nowadays the use of an industry-wide standard seems obvious. It is indeed the only way to cope with the significant increase of ECU functions exchanged in one format or another between more a more actors, due to:

• more and more distributed development worldwide
• more complex software sharing models between OEMs and ECU suppliers
• co-development of reusable components inside organizations that are getting bigger
• development partnerships
• the emergence of strong software engineering companies developing cross-industry expertise available at lower costs

According to AUTOSAR architecture the hardware abstraction is done at the lowest possible software level thanks to the MCAL. It provides standardized interfaces to the software components above. It means they are all hardware independent, including Basic Software services or hardware abstraction module (diagnostic, I/O, communication, memory management).

Use a production OS – don’t test it

The Operating System is of course largely hardware dependent and also needs to be abstracted from its hardware dependencies. This is feasible using a scheduler, or a simulation of the target OS. But for most of the software validation tasks the correct scheduling according to the AUTOSAR models and the execution according to the final configuration is necessary to achieve the needed representativeness, especially for interrupts. The easiest thing to do here is to use the PC port of the AUTOSAR OS in addition to the PC MCAL modules. You then have all you need to abstract the execution of embedded software on the PC.

Nevertheless it has to be clear that the Operating System itself won't be part of the software-under-test on the PC. The OS configuration is tested and validated, the scheduling is ensured, but the overall timing behavior is obviously not, as it is highly dependent on the hardware resources management. You will do those tests later on the target anyway. So don't waste time doing them on the PC. What I mean is: it doesn't matter whether you're using the target OS on the PC or another one as long as you can read the very same configuration. There are much more important things to consider talking about the OS.

Control the time

In a purely virtual environment controlling the time is not only controlling the scheduling of the software-under-test. One still needs to make sure that its execution is synchronized with the test environment where test sequences and scenarios are defined. In other words: if a test sequence defines two events happening in a one second time frame, one must make sure that this second is the same for all other components of the test platform even if this is not a real second. If not, you will face significant timing inconsistencies and at the end of the day won’t get results that can really go through a quality assessment process. You will actually most likely have different results if the same test is run several times.

The implementation of a global time control mechanism is mandatory to make sure the tests performed on the PC are really verifying or validating anything at all. Having a time control for all inputs and outputs of the software-under-test enables a deeper investigation of the software and its interaction with the environment. It is then possible to apply detailed scenarios that are extremely complicated to reproduce in a real-time system, especially when it comes to testing safety critical software. Even before porting your software on the real target, software integration is possible up to the whole ECU software above the MCAL. The software quality is significantly improved especially in terms of robustness.

ETAS ISOLAR-EVE: complete infrastructure for software testing on the PC

All in all, a solution for software testing on the PC shall provide at least:

• the infrastructure for the integration of components to be tested through these 2 key components: the MCAL and the OS for the PC.
• a deterministic scheduling for the software-under-test according the OS specification, for real-time and virtual time execution
• a time control mechanism in order to ensure the consistency of the tests performed

Only with this one can consider to test software intended to be produced on the PC and to use the results of those tests in a quality assessment process.

We kept these foundations in mind while developing ISOLAR-EVE and they are now available out-of-the-box for all addressable use cases.

ISOLAR-EVE completely supports the AUTOSAR standard, both from an infrastructure and a configuration point of view. It is based on Eclipse and ARTOP, meaning it works on the real production software configuration without the use of a specific database or format. Because of this, a consistent AUTOSAR architecture can directly be read and tested with ISOLAR-EVE.

Configurable time and data flow control mechanism thanks to the RTA-OS for Windows PC

Most important, ISOLAR-EVE comes with the PC port of the AUTOSAR OS from ETAS. The PC ports – RTA-OS for RTPC and RTA-OS for Windows PC – allows for real-time and non real-time execution. It ensures in all cases the deterministic scheduling for the software-under-test according to the OS specification in AUTOSAR format.

In non real-time the RTA-OS for Windows PC provides a unique technology ensuring time control. A server exposes all variables of the software-under-test. The variables are created as a Virtual Device during the configuration of the software to be tested. Depending on the tests intended to be performed, this can be done automatically by ISOLAR-EVE. All the Virtual Devices are available with open and documented APIs and it is a matter of scripting to then simply connect to any 3rd party tool.

This technology is used by our development team to provide new product features such as the generation of Simulink® S-function for the integration into Simulink® models, the coupling with a rest-bus simulation tool, or connection with the ETAS Experiment Environment. It can also be used to develop customer-specific interfaces via engineering.

But this is a story for another post, I guess this one is long enough already and I thank you for making it all the way to here. Next time I will give examples and it should be more concrete dealing with use cases.

But whatever the use cases you may have and we may be able to tackle with EVE, the underlying technology will always be the same: a full AUTOSAR conform infrastructure and environment ensuring abstraction, and a time synchronization mechanism.

Technosoft Innovations is a medical device new product development & prototyping house. We provide leadership in designing high-performing healthcare systems.