The Complete AUTOSAR Verification Chain: AUTOSAR C++14 Static Analysis with Helix QAC, SWC and RTE Testing with TESSY 6

The Verification Gap in AUTOSAR Projects

Here is a situation every AUTOSAR team recognises. The software component compiles. The coding-standard report is clean. And the unit tests still cannot run, because the component only executes through an RTE that does not exist yet on the test bench. So someone hand-writes Rte_Read, Rte_Write and Rte_Call stubs, and from that day on the stubs drift quietly away from the ARXML model they were copied from.

The deeper problem is that AUTOSAR software component code carries two separate proof burdens:

1. Static proof: every line complies with the coding guidelines (AUTOSAR C++14, MISRA) across all execution paths, not just the tested ones.
2. Dynamic proof: each component behaves correctly through its ports and interfaces, exactly as the AUTOSAR model describes them, with structural coverage to show how thoroughly.

In one paragraph: the complete AUTOSAR verification chain is: enforce AUTOSAR C++14 and MISRA with static analysis first (Perforce Helix QAC or Klocwork), then test each software component dynamically against an RTE that Razorcat TESSY 6 provides automatically from the ARXML model description file, then collect statement, branch and MC/DC coverage as certification evidence (all three are coverage measurements TESSY supports, per Razorcat’s TESSY documentation). Per the TESSY V6 New Features document, this kind of dynamic testing with coverage is required for certifications according to standards such as DO-178, IEC 61508 and ISO 26262. GSAS Micro Systems is the India engineering partner for both Perforce and Razorcat, so the entire chain comes from a single relationship.

The general case for running both disciplines, including how ISO 26262 Part 6 asks for static and dynamic methods side by side, is set out in our TESSY plus Helix QAC guide to ISO 26262 Part 6 verification. This guide narrows that argument to AUTOSAR software components specifically, where the RTE makes the dynamic half genuinely harder, and walks the chain stage by stage with a decision table.

SWC, RTE and ARXML: What You Are Actually Verifying

Three terms carry the whole discussion, so briefly:

• AUTOSAR is, in Perforce’s words, a worldwide partnership of over 180 automotive manufacturers, suppliers, tool vendors and semiconductor vendors that has developed a standardized open software architecture for automotive ECUs since 2003.
• A software component (SWC) is the unit of AUTOSAR application software. It communicates with the rest of the system exclusively through ports and interfaces defined in the AUTOSAR model, not through direct function calls.
• The RTE (runtime environment) is the generated layer that connects SWCs to each other and to the basic software. The model that defines all of this is stored in ARXML files, the AUTOSAR XML model description.

That architecture is exactly what makes verification awkward: the code you must prove correct only runs inside a generated environment described in XML. The chain below deals with that head-on. For the coding-guideline side in depth, including how AUTOSAR C++14 relates to MISRA, see our MISRA and AUTOSAR compliance guide.

Stage 1: AUTOSAR C++14 and MISRA Static Analysis on SWC Code

Static analysis goes first because it reasons about every execution path on every commit, before a single test exists. Per Perforce, compliance with coding standards is needed to fulfill the requirements of ISO standards such as ISO 26262, and the AUTOSAR C++14 guidelines (formally, the Guidelines for the use of the C++14 language in critical and safety-related systems) permit constructs that other C++ coding standards do not: dynamic memory, exceptions, templates, inheritance and virtual functions. Perforce also notes the AUTOSAR guidelines share coding rules with MISRA C++, and that integration has since shipped: MISRA C++:2023, released in October 2023 per MISRA, integrates the AUTOSAR C++14 guidelines and targets C++17, per Perforce.

For this stage GSAS carries both of Perforce’s analysis engines in India:

• Helix QAC: per Perforce, its AUTOSAR compliance module finds and reports on violations of the standard, with in-depth analysis, comprehensive diagnostics and compliance reports demonstrating progress towards compliance.
• Klocwork: Perforce’s second static analysis engine, also carried by GSAS. Perforce’s Klocwork product page lists AUTOSAR C++14, MISRA C (2004, 2012 and 2023) and MISRA C++ 2008 among the coding standards it checks.

Choosing between them depends on how your team works; our MISRA and AUTOSAR compliance guide includes a QAC versus Klocwork chooser.

Watch: Applying the AUTOSAR Guidelines in Helix QAC

Perforce’s own walkthrough shows what enforcement looks like in practice: AUTOSAR Required and Advisory rule categories mapped to QAC diagnostics (a single guideline such as Rule A0-1-1 maps to five diagnostics, per the video), a pre-analyzed AUTOSAR project with violation markers, the Rule Groups tab for filtering violated AUTOSAR rules, severity-based prioritization, and the fix-and-reanalyze loop.

Stage 2: Dynamic SWC and RTE Testing with TESSY 6

Static analysis cannot tell you whether a component produces the right output on a port for a given input. That requires execution, and executing an SWC in isolation is precisely the problem TESSY Version 6 was built to remove. TESSY is developed by Razorcat Development GmbH in Berlin, and every capability below is stated in the TESSY V6 New Features document, whose feature compilation Razorcat Development GmbH provided.

AUTOSAR Software Components Map to TESSY Test Modules Automatically

TESSY 6 supports testing and integration of software components by combining C code level analysis with information from the AUTOSAR model description. The AUTOSAR components are mapped to TESSY modules automatically, based on the model files and the respective source file name templates. No manual test-project assembly per component.

The RTE Is Provided Automatically from the ARXML Model File

The AUTOSAR runtime environment is provided for an SWC automatically based on the ARXML model description file. TESSY then analyzes the implementation source files and retrieves a mapping from the source code to the ports and interfaces of the AUTOSAR model. This is the step that retires handwritten RTE stubs, and with them the drift between stubs and model that makes stub-based test rigs so expensive to maintain.

Ports, Interfaces and AUTOSAR Constants in the Test Data Editor

Ports and interfaces of the SWC are available at TESSY’s testing interface and inside the test data editor, so test data is supplied to ports and their data elements directly in the graphical user interface. For all AUTOSAR data elements and operation arguments, the applicable AUTOSAR constants are offered in the auto-completion menu as potential input data or expected results. Engineers specify tests in the vocabulary of the AUTOSAR model, not in the vocabulary of a stub file.

AUTOSAR Model Consistency Checks During Test Execution

TESSY 6 applies various consistency checks of the AUTOSAR model for an SWC to the implementation code, or measures them dynamically during test execution, and shows the C code interface side by side with the AUTOSAR port interfaces. Divergence between what the ARXML promises and what the C code does is caught inside the test run itself, instead of surfacing later during ECU integration.

What Else Is New in TESSY 6

Also per the TESSY V6 New Features document: a built-in link stubber that automatically stubs external C++ classes and methods so the test driver links cleanly, an optimized Test Cockpit view with faster updates, and a YAML/ASCII based database backup format that stores per-module TESSY script files, YML metadata and interface settings, which makes test assets diffable and mergeable under version control. For the broader TESSY workflow (Classification Tree Editor, requirements traceability, host and on-target execution), see the TESSY product page and our ISO 26262 unit testing checklist.

Stage 3: Coverage Evidence for ISO 26262

Verification only counts when it produces evidence. Per the TESSY V6 New Features document, dynamic module, unit and integration testing with code coverage is required for certifications according to standards such as DO-178, IEC 61508 and ISO 26262, and TESSY determines the coverage along the way. For MC/DC in depth, see our MC/DC coverage guide.

TESSY 6 extends where that coverage can come from. The Hyper Coverage feature integrates the Accemic Technologies hardware trace port analysis tool: per Razorcat, FPGA-based online trace data processing acquires branch and MC/DC coverage data directly during system and integration testing. Imported into TESSY, coverage appears at source file level in the Test Cockpit, and the Coverage Viewer shows the reached branches for each system test case, which supports requirements-based testing and reveals untested code. Gaps left by system-level tests, typically corner cases and error handling that normal operation never triggers, are then closed with targeted unit test cases.

The result is one coverage picture assembled from both ends of the V-model, instead of a unit-test number and a system-test number that never reconcile.

Which Tool at Which Stage: A Decision Table

Read the table top to bottom and it is also the recommended order. Static first, so dynamic testing runs on clean code (the rationale is covered in our shift-left toolchain guide); dynamic SWC testing second; coverage consolidation last. If you are evaluating dynamic tools side by side, our TESSY versus VectorCAST comparison covers that decision separately.

AUTOSAR Verification Support for Indian Tier-1 and OEM Teams

Indian automotive programs increasingly own AUTOSAR-based software end to end: Tier-1 suppliers in Pune and Chennai delivering SWCs into global platforms, OEM software teams in Bengaluru and Delhi NCR integrating them, and engineering service organisations in Hyderabad and Mumbai carrying the verification workload in between. What these teams rarely get from any single vendor relationship is the whole chain: the static half and the dynamic half usually arrive through different channels, with different support paths and no one accountable for the seam between them.

GSAS Micro Systems closes that seam. GSAS is the India engineering partner for both Perforce and Razorcat, which means AUTOSAR C++14 and MISRA enforcement (Helix QAC, Klocwork) and ARXML-driven SWC and RTE testing (TESSY 6) come with local evaluation support, deployment engineering, INR invoicing and a single support channel, from GSAS offices serving Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR. For the vertical picture, see our automotive solutions page.

If your team is building or verifying AUTOSAR software components, request a quote or a guided evaluation and we will scope the chain against your ISO 26262 evidence requirements.