Back-to-Back Test
Back-to-Back Testing closes the gap between model behavior and production code behavior.
Testing the model proves nothing about the code generated from it.
In model-based development, the production code is generated from the model. A discrepancy between model behavior and code behavior means the code cannot be trusted, regardless of how well the model itself has been tested. Back-to-Back Testing closes this gap systematically.
What Back-to-Back Testing verifies.
Back-to-Back Testing verifies that two different implementations of the same function — for example, a Simulink model and its generated production code — produce structurally identical behavior across all inputs.
Generate stimuli vectors
Stimuli vectors are generated automatically to achieve all desired structural coverage goals.
Run on the reference
The vectors are simulated against the reference implementation — for example, the model at MIL level.
Run on the comparison
The same vectors are then applied to the comparison implementation — for example, production code at SIL level.
Compare and flag deviations
Outputs are compared step by step; any deviation is flagged, with automated tools to localize the root cause.
One mechanism, five use cases.
The primary use case is MIL vs. SIL, but Back-to-Back Testing applies wherever two implementations must be proven equivalent.
Why this matters for tool qualification: when teams upgrade their code-generation toolchain, B2B testing provides formal evidence that the generated code has not changed behavior — replacing manual re-review with automated, traceable comparison.
Stimuli vectors — not test cases.
Stimuli vectors are automatically generated test inputs designed exclusively to achieve structural coverage — not to represent functional or requirements-based scenarios. They contain only input and calibration values and carry no expected output behavior. Their purpose is to exercise every reachable structural element of the model or code.
Because they target structure rather than function, stimuli vectors are complementary to requirements-based test cases — not a replacement. Both types are maintained in the same BTC TestStack profile and contribute to the overall coverage picture. Requirements-based test cases already in the profile count as stimuli vectors, too: any structural coverage they achieve is subtracted from the remaining workload, so requirements-based testing and Back-to-Back Testing reinforce each other rather than running as parallel tracks.
ATG for speed. CV for proof.
BTC TestStack provides two independent engines for stimuli vector generation. Using both in sequence is the recommended practice: run ATG first to reach high initial coverage rapidly, then run CV on the remaining uncovered goals.
ATG engine
CV engine
CV delivers unreachable proofs for goals that truly cannot be exercised — no vector is created for these, because no trace to them exists. For complex subsystems, child scopes can be analyzed independently, keeping generation tractable as complexity grows.
Every structural and robustness goal, in one pass.
Coverage goals don't have to be tested all at once — they can be selected per run based on project needs.
Domain Checks are defined per input signal and specify valid ranges — the expected operating range test generation must cover — and invalid ranges, values the signal should never take. The CV engine can prove invalid ranges unreachable if the implementation enforces the constraint. Range notation: [ / ] inclusive, ( / ) exclusive — for example [0.0, 0.45] for a full valid range, or !(0.45, 65.535] for a range violation that should be unreachable.
From stimuli vectors to a clean report.
Generate stimuli vectors
Select the structural and robustness coverage goals you need — including valid and invalid ranges — configure engine settings such as timeouts and parallel CV execution, and run generation. A healthy result shows every goal "Handled": covered by a vector, or proven unreachable. Both are complete outcomes.
Create and execute the test
Select stimuli vectors by folder or scope, set your reference (e.g. the model at MIL) and comparison (e.g. production code at SIL), and optionally configure tolerances. BTC TestStack simulates the vectors against the reference, replays them on the comparison, and compares outputs step by step.
Review the report
The Back-to-Back Test Report gives pass/fail counts and overall coverage at a glance, a per-vector comparison table for every signal and timestep, and — for any failure — Deviation Analysis that pinpoints exactly where reference and comparison first diverge.
Debug failures
Debug environment export generates a standalone model containing just the failed vector and the affected subsystem, reproducing the failure in an isolated context. Fix the root cause, refresh the profile, and re-run: a clean report confirms it. Note: a profile update invalidates existing unreachable proofs, since the analyzed code has changed — re-running the CV engine re-establishes them.
Evidence for every level.
All three reports are accessible from the Profile Navigator and can be exported for tool qualification packages or customer documentation.
Back-to-Back Test Report
Pass/fail per vector, deviation details, tolerance settings, and a comparison overview per scope — the primary evidence document for a B2B test run.
Code Analysis Report
Code coverage per subsystem for all structural and robustness goals, with a detailed goal-level breakdown.
Model Coverage Report
Coverage at model level per subsystem — model-level evidence, requiring a Simulink Verification and Validation toolbox license.
Proof that counts as evidence.
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.
Regression Test
Regression tests between different versions of a software play an important role in A-SPICE and ISO 26262.
Code Coverage Analysis
In BTC TestStack, code coverage is automatically calculated and updated in the background.
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.