Verification of AUTOSAR Software Using a SystemC Virtual Platform

[Please welcome ISX R&D team member Markus Winterholer back to the Team ESL blog. This is the second post from Markus, last week he posted "Software Verification or Validation with ISX?"]

My bedtime reading of the last couple of days was a new book Hardware-dependent Software: Principles and Practice.  It motivated me to work even harder on the upcoming releases of ISX. According to the authors, software verification is gaining more and more importance since the complexity of software in embedded systems is increasing exponentially.  Until a decade ago, only about 10% of the development costs of electronic systems were spent on software, whereas 90% of expenses went into the hardware. Today, this ratio has shifted significantly toward software.

It was one chapter (the last one in fact) that most caught my attention. Chapter 10 "Verification of AUTOSAR Software by SystemC-based Virtual Prototyping" by M. Krause, O.Bringmann and W. Rosenstiel outlines how car makers and tier 1 suppliers in the automotive industry can benefit from SystemC Virtual Platforms.

The automotive standard AUTOSAR (AUTomotive Open System ARchitecture) decouples hardware dependent software or Basic SoftWare (BSW) and application software using a standardized middleware layer called RTE (RunTime Environment). The goal is to make the application software completely independent from the underlying hardware architecture to allow an arbitrary distribution onto different ECUs. Applications can exist and communicate independently of a particular infrastructure and mapping onto ECUs in an environment called Virtual Functional Bus (VFB). Besides the separation of application and infrastructure, the use of abstraction levels is also part of the concept. Three levels of abstraction are defined: specification level with no timing behavior, a timed modeling level where time has been considered by sequenced behavior, and cycle accurate timing by implementation of prototype platforms.

The authors show how AUTOSAR software components can generally be represented by SystemC modules. The presented mapping of the AUTOSAR VFB view to SystemC Communication Processes (CP) level offers a potential use model for ISX. In the automotive industry (similar to other industries) parts of the functionality are developed by suppliers. If functional behavior of an application does not exist yet, or is provided by another supplier or by the OEM later during the development process, communication traffic can be generated by cyclic or constrained random data transmission of the corresponding data type. ISX seems to be the perfect fit here. Since the group of Prof. Rosenstiel is already experienced using ISX it should be feasible to build a testbench for the case study described in the book.

Another idea that came to mind is to build a general AUTOSAR software verification component. We can use ISX either at the RTE interface to verify that the hardware dependent software has no bugs when running on the specific hardware or prototype by driving the embedded software through the RTE interface and checking that the responses are as expected. We can also validate the architecture of the system by driving testcases and building checks to validate the timing of the unit. Since we are able to use ISX for different levels of abstraction we can validate the system at all three levels of abstraction. In the case of application software (above the RTE interface), we can use ISX to drive regression tests.

 

Markus Winterholer