AUTOSAR has become an important standard in many automotive development projects over the past years. By providing a standardized way to describe software components and interfaces, AUTOSAR addresses many challenges such as the increasing complexity of software and the resulting need for collaboration between different teams, or even companies. With an architecture description that is already linked to a clearly defined semantic on the implementation level, AUTOSAR additionally helps to address several ISO 26262 objectives for the software architectural design. A software architecture concept that makes application software more independent from the hardware likewise facilitates the reuse of previously tested software components in a different context.

AUTOSAR has become particularly popular in connection to model-based development and automatic code generation. One reason being is that modern code generators like dSPACE TargetLink provide an automatic frame model generation from the architecture description, ensuring robust and consistent interfaces in the production code.

Testing AUTOSAR with dSPACE TargetLink and BTC EmbeddedPlatform

The combination of AUTOSAR and model-based development also brings particular challenges when it comes to model and code testing. This is in part due to the fact that the semantic of AUTOSAR communication mechanisms such as Client-Server communication or RTE Status doesn’t find a direct match in modeling languages like Simulink. Another challenge is the fact that on production code level, interfaces are implemented as so-called RTE-Macros and cannot be accessed directly when testing the code.

Together with dSPACE TargetLink, BTC EmbeddedPlatform automatically detects special AUTOSAR interface and is able to handle them on model and code level. In addition, the hierarchical approach within BTC EmbeddedPlatform particularly useful for AUTOSAR models, allowing individual testing of Runnables without the need to manually extract them from the software component.