AUTOSAR
Perfect support for testing models and production code.
Your AUTOSAR interfaces live in the code. Your model doesn't know about them.
Testing Classic and Adaptive components means reconciling that mismatch by hand — and stubbing every RTE or ARA dependency — before a single test case can run.
One standard, built for reuse.
AUTOSAR, short for Automotive Open System Architecture, is a standardized software architecture framework that improves the efficiency, scalability and reusability of software in the automotive industry, with guidelines and specifications for developing automotive software components that integrate and collaborate across different ECUs.
By promoting a modular, layered approach, AUTOSAR manages complexity and separates software functions from hardware, enabling flexibility and interoperability. Standardized interfaces and communication protocols promote compatibility among automotive systems, facilitating software reuse across vehicle models and generations.
- Modular & layered
- Hardware-independent
- Standardized interfaces
- Reusable across ECUs
Two platforms, one standard.
AUTOSAR Classic and AUTOSAR Adaptive share the same overarching aim — standardizing automotive software — but cater to different requirements.
AUTOSAR Classic
Designed primarily for hard real-time control systems, such as engine control and brake systems, which require deterministic behavior and low-latency responses.
AUTOSAR Adaptive
Targets high-performance computing systems typically found in infotainment, telematics and advanced driver-assistance systems, leveraging dynamic software updates, service-oriented communication and support for the POSIX operating system.
Two gaps open up when you test at both levels.
AUTOSAR offers numerous benefits, but also presents unique challenges when testing software at both the Simulink model level and the production code level.
Mapping of model and code elements
Tests are necessary at both model and code levels, but while AUTOSAR interfaces are defined at the code level, they don't exist at the model level. The code generator bridges this gap, and depending on the tool used — dSPACE TargetLink or MathWorks Embedded Coder — the model architecture for the same AUTOSAR component can vary significantly. The testing tool needs to understand this mapping automatically, so tests can run at both levels without a manual harness.
Stubbing for SIL testing
Testing AUTOSAR software components or adaptive applications at the production code level (SIL) requires compiling the code — and these components are even less self-contained than typical non-AUTOSAR applications. Dependencies toward the RTE (Classic) or ARA (Adaptive) need to be stubbed to compile and test individual units.
Testing AUTOSAR with BTC TestStack.
BTC Embedded Systems is a member of the AUTOSAR consortium, bringing years of experience in supporting the platform.
Full support, Classic and Adaptive
AUTOSAR Classic and AUTOSAR Adaptive are fully supported for dSPACE TargetLink and MathWorks Embedded Coder.
Architecture understood automatically
BTC TestStack automatically analyzes and comprehends the AUTOSAR architecture, extracting a corresponding test interface — for instance, a client/server call with a "Get" semantic is interpreted as an input signal for the test architecture.
Test execution on both levels, no manual harness
It understands the mapping of model elements and code elements, so tests run at both model and code level without manual test harness preparation.
Stubbing handled automatically
All external references are properly stubbed, either using stub implementations from the code generator or by adding missing elements itself.
BTC TestStack
is ISO 26262 certified
The certificate addresses functional-safety standards across multiple industries:
For ISO 26262, BTC TestStack is certified with the highest Tool Confidence Level (TCL), valid for all ASIL levels including ASIL D. We provide the certificate and report to customers free of charge on request — removing most tool-qualification effort on the customer side.
Explore the rest of the stack.
Requirements-based Testing
Requirements-based testing for Simulink, TargetLink, Embedded Coder and handwritten code.
Back-to-Back Test
Back-to-back tests between model and code are highly recommended by the ISO 26262 standard.
ISO 26262
The completeness of testing activities cannot be evaluated without measuring structural coverage of the software unit.
Talk to our engineering team.
Tell us where your engineering problem actually is. We'll tell you whether an evaluation license, a workshop, or a conversation is the right next step.