Skip to main content
TESSY + Perforce QAC: MISRA Static Analysis + MC/DC Dynamic Testing for Complete ISO 26262 Verification, featured image

TESSY + Perforce QAC: MISRA Static Analysis + MC/DC Dynamic Testing for Complete ISO 26262 Verification

GSAS Editorial · · 5 min read

TESSY + Perforce QAC: Complete ISO 26262 Part 6 Verification

ISO 26262 Part 6 does not ask for a choice between static analysis and dynamic testing. It points at both. Part 6 lists static code analysis and static analysis based on abstract interpretation among its software unit verification methods, alongside requirements-based test, interface test, fault injection test and resource usage evaluation. Static analysis is not a nice-to-have bolted on beside unit testing; it is one of the listed verification methods in its own right. Neither side is mandatory, because the standard’s strongest rating is highly recommended, but in practice assessors expect both.

Indian automotive teams achieve complete Part 6 verification by combining Perforce QAC for MISRA C/C++ static analysis with Razorcat TESSY for MC/DC dynamic unit testing. The two tools cover complementary verification objectives, and together they produce the evidence package that safety assessors need.

What Static Analysis Catches (and Dynamic Testing Cannot)

Perforce QAC enforces MISRA C:2012 and MISRA C++:2023 coding guidelines through deep semantic analysis. It detects:

  • Undefined behaviour: signed integer overflow, null pointer dereference, use of uninitialized variables
  • Implementation-defined behaviour: bit-field ordering, integer promotion, pointer arithmetic across objects
  • Coding standard violations: MISRA rules that prevent common embedded programming errors
  • Complexity metrics: cyclomatic complexity, nesting depth, and other metrics that correlate with defect density

These are properties of the source code itself, independent of any particular test input. Dynamic unit testing cannot detect them because they require analysis of all possible execution paths, not just the paths exercised by test cases.

What Dynamic Testing Catches (and Static Analysis Cannot)

TESSY executes the code with specific input values and verifies that outputs match expected results. It detects:

  • Logic errors: the function computes the wrong result for a given input
  • Off-by-one errors: loop boundaries, array indexing, threshold comparisons
  • Missing error handling: functions that do not handle edge cases correctly
  • Integration defects: when the function under test interacts incorrectly with its dependencies (tested through stub configuration)
  • Coverage gaps: unreachable code, untested branches, MC/DC conditions that are never independently exercised

These defects are only detectable by running the code with concrete inputs and comparing actual outputs against expected outputs. Static analysis cannot determine whether a function produces the correct result for a specific input, that requires execution.

The Combined Workflow

A practical ISO 26262 Part 6 workflow for Indian teams uses both tools in a CI/CD pipeline:

Phase 1, Static Analysis (Perforce QAC)

  1. Developer pushes code to the repository
  2. CI pipeline runs Perforce QAC with the project’s MISRA configuration
  3. New MISRA violations are flagged and reported
  4. Critical violations block the merge; advisory violations are tracked for resolution
  5. Compliance reports are generated for the safety case

Phase 2, Dynamic Unit Testing (TESSY)

  1. Same CI pipeline triggers TESSY batch execution
  2. TESSY compiles the units under test with the project’s cross-compiler
  3. Test suites execute (host-based for speed, or on-target via SEGGER J-Link for certification evidence)
  4. Coverage is measured, statement, branch, MC/DC
  5. Coverage thresholds are enforced as quality gates (e.g., 100% MC/DC for ASIL D functions)
  6. Coverage reports are generated for the safety case

Combined evidence: the safety case includes Perforce QAC MISRA compliance reports and TESSY MC/DC coverage reports, satisfying both the static and dynamic verification requirements of ISO 26262 Part 6.

If your units are AUTOSAR software components, Phase 2 has an extra dependency: an SWC only executes through the RTE. TESSY 6 provides that RTE automatically from the ARXML model description file, so the AUTOSAR-specific version of this workflow is walked stage by stage in our complete AUTOSAR verification chain guide, which also covers AUTOSAR C++14 enforcement in Perforce QAC and Klocwork.

Requirements Traceability Across Both Tools

TESSY imports requirements in ReqIF format (the OMG standard used by IBM DOORS, Polarion, and codebeamer) and links test cases to requirements for bidirectional traceability. Perforce QAC’s findings can be mapped to the same requirements, creating a unified traceability matrix that shows:

  • Requirement → MISRA compliance status (static analysis evidence)
  • Requirement → Unit test cases → Coverage achieved (dynamic testing evidence)

For teams in Pune and Bengaluru building AURIX-based ECUs for European OEMs, this combined traceability matrix is exactly what the assessor requests during a safety assessment.

Why Not Use One Tool for Both?

Some tools attempt to provide both static analysis and dynamic testing. The challenge is that each discipline requires deep specialization:

  • MISRA compliance checking requires understanding of language standards, compiler-specific behaviour, and the nuanced intent behind each MISRA rule. Perforce QAC has decades of MISRA specialization; Perforce states that its safety experts actively participate in the MISRA C and C++ standards committees.
  • MC/DC coverage measurement requires sophisticated code instrumentation, test harness generation, stub creation, and test data management. TESSY has been refined for this specific workflow since its creation.

Using best-of-breed tools for each discipline produces better results than using a single tool that attempts both. The integration point is the CI/CD pipeline, both tools run in the same pipeline, share the same codebase, and produce complementary evidence for the same safety case.

GSAS Supplies Both

This is the practical advantage for Indian teams: GSAS Micro Systems is the authorized Indian partner for both Razorcat (TESSY) and Perforce (Perforce QAC). One purchase order, one vendor relationship, one support channel, covering the complete static + dynamic verification workflow.

Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR configure both tools on your project, set up the combined CI/CD pipeline, and help your team produce the verification evidence package that satisfies ISO 26262 Part 6 for your target ASIL level.

Why Buy from GSAS

GSAS Micro Systems provides TESSY + Perforce QAC as a combined verification stack with INR invoicing, joint training workshops, and integrated CI/CD consulting. Whether your team is starting a new ASIL D powertrain project or adding verification to an existing ASIL B body controller, GSAS provides the tools and the local expertise to build a certification-ready verification infrastructure.

Request a TESSY + Perforce QAC evaluation →

Interested in Razorcat tools?

Talk to our application engineers for personalized tool recommendations.

Frequently asked questions

How do QAC and TESSY work together for ISO 26262?
Perforce QAC runs first in the CI pipeline, enforcing MISRA static analysis and flagging violations before merge. TESSY then runs dynamic unit testing on the same clean codebase, measuring statement, branch and MC/DC coverage. The safety case combines both reports, satisfying ISO 26262 Part 6's static and dynamic verification requirements together.
What can static analysis catch that dynamic testing cannot?
Perforce QAC detects undefined behaviour, implementation-defined behaviour, MISRA coding-standard violations and complexity metrics by analysing all possible execution paths in the source code. These are properties of the code itself, independent of test inputs, so dynamic unit testing cannot detect them without executing every path.
What can dynamic testing catch that static analysis cannot?
TESSY executes code with specific inputs and compares actual outputs to expected results, revealing logic errors, off-by-one errors, missing error handling, integration defects and coverage gaps. Static analysis cannot determine whether a function produces the correct result for a given input, that requires running the code.
Can one tool provide both static analysis and dynamic testing for ISO 26262?
Some tools attempt both, but each discipline needs deep specialization: MISRA compliance checking requires nuanced understanding of language standards and compiler behaviour, while MC/DC coverage measurement requires sophisticated instrumentation and test harness generation. Best-of-breed tools integrated in the same CI/CD pipeline produce better results than one tool attempting both.
Can I buy Perforce QAC and TESSY from one partner in India?
Yes. GSAS Micro Systems is the authorized Indian partner for both Razorcat (TESSY) and Perforce (Perforce QAC), covering the complete static-plus-dynamic verification workflow through one purchase order and one support channel, with engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Functional safety is changing: AI standards, Rust guidelines and static analysis evidence converging on the safety case, GSAS India
Compliance & Safety Perforce

AI, Rust and the New Functional Safety Standards

AI has entered both the development flow and the shipped product, Rust is taking new safety-critical code that would once have been C, and the guidance layer is moving to cover both. A guide to five Perforce resources on that shift, from the GSAS engineering team in India.

2 Sept 2026 · 9 min read
SecOC freshness value desync on one timeline: a sender counter and a receiver counter running together until a reset event moves one of them, then a window of messages that carry a valid authenticator but are still rejected, ending at resynchronisation, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

SecOC vs MACsec vs TLS: Automotive Security Layers

SecOC, MACsec and TLS get compared as if a programme picks one. They are three different scopes, and most vehicles carry more than one. This article separates them in a single table by scope, unit protected, key source and what a capture still shows, then covers the two things almost nobody writes down: what each layer does to your ability to debug, and why an ECU can reject a message whose authenticator is perfectly valid after a reset. Protocol claims trace to the public AUTOSAR SecOC protocol specification, IEEE 802.1, the Wireshark dissector sources and Linux networking documentation. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 12 min read
Buyer-side evaluation framework for embedded unit testing tools, covering compiler and debugger fit, on-target execution, coverage levels and qualification evidence, from GSAS Micro Systems in India
Compliance & Safety Razorcat Automotive & Mobility

How to Evaluate a Unit Testing Tool for Embedded Software: A Buyer's Framework for Indian Teams

Unit test tool evaluations rarely fail on features. They fail because the tool cannot drive the compiler and debugger the project is already committed to, or because the evidence it produces sits outside the scope of the certificate the assessor asks for. This is a buyer-side framework: six questions, what a credible answer looks like in vendor documentation, and a four-week pilot that measures the answers instead of accepting them.

1 Aug 2026 · 10 min read