Over the past years, AUTOSAR has become an important standard in many automotive development projects. By providing a standardized way of describing software components and interfaces, AUTOSAR addresses many challenges like the increasing complexity of software and the related 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 also helps to address several ISO 26262 objectives for the software architectural design. A software architecture concept which makes application software more independent from the hardware also facilitates the reuse of already tested software component in a different context.
AUTOSAR has become in particular popular in connection with model-based development and automatic code generation. One reason is that modern code generators like dSPACE TargetLink provide an automatic frame model generation from the architecture description, which ensures 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 some particular challenges when it comes to testing models and code. One main reason is the fact that the semantic of AUTOSAR communication mechanisms like Client-Server communication or RTE Status information doesn’t find a direct match in modelling languages like Simulink. Another challenge is the fact, that on production code level interfaces are implemented as so-called RTE-Macros so that they cannot be access directly when testing the code.
Together with dSPACE TargetLink, BTC EmbeddedPlatform detects special AUTOSAR interfaces automatically and knows how to handle them on model and code level. In addition, the hierarchical approach within BTC EmbeddedPlatform is in particular useful for AUTOSAR models, allowing to test Runnables individually without the need to manually extract them from the software component.