Adding WCET Checks to CI/CD: Automating Timing Verification for Safety-Critical Releases

Catch timing regressions before they hit the vehicle: adding WCET checks to CI/CD

Shipping software for safety-critical embedded systems in 2026 means two things: faster release cadences and harder regulatory scrutiny. The result? Teams face constant pressure to shift left on timing verification so a small code change doesn't introduce a worst-case execution time (WCET) regression that invalidates safety claims or triggers expensive re-tests. This guide shows how to integrate WCET checks — using RocqStat (now part of Vector's toolchain lineup) — into your CI/CD pipelines to detect regressions early and generate automated compliance evidence.

Why WCET in CI/CD matters now (2026 trends)

In late 2025 and early 2026 the industry accelerated two trends that change the game for embedded teams:

• Regulatory drift and consolidation: Standards like ISO 26262 and DO-178C emphasize traceable timing evidence as systems become software-defined. Auditors now expect more automated artefacts.
• Toolchain consolidation: Vector's acquisition of StatInf's RocqStat (January 2026) signals mainstream adoption of integrated timing analysis inside test toolchains such as VectorCAST — making WCET checks easier to operationalise.

The consequence is simple: timing verification cannot be a manual, late-stage activity. It must be embedded into CI/CD where regressions are inexpensive to fix and where the pipeline can produce reproducible artefacts auditors accept as evidence.

What you’ll get from this article

• Practical CI/CD patterns for running RocqStat WCET estimation in pipelines (GitHub Actions, GitLab CI, Jenkins)
• How to detect and gate on timing regressions per-PR and per-branch
• Strategies for keeping analysis fast (incremental checks, caching, module selection)
• How to automatically generate and sign compliance evidence for audits
• Advanced tips for VectorCAST + RocqStat integration and real-world operational advice

Core concepts: what you need to automate

Before you add checks, make sure you understand and can produce these artefacts automatically from CI/CD:

• WCET report (per binary/module/function): timestamped, tool-versioned output containing estimated maximums and analysis metadata.
• Baseline: trusted, audited WCET numbers (stored as JSON or equivalent) to compare new runs against.
• Comparator: an automated script that measures deltas and enforces thresholds (absolute ms or percentage).
• Traceability metadata: git SHA, build ID, tool-version, platform target and compiler flags.
• Artifact provenance: signed/compressed evidence packages for auditors (PDF + JSON + hashes + signatures).

High-level CI pattern

1. On PR/merge, build the target binary using your cross-toolchain and canonical compile flags.
2. Invoke RocqStat (or VectorCAST integrated analysis) in headless mode against the build artefact.
3. Export the WCET report and metadata to pipeline artifacts.
4. Run a comparator that compares output to baseline; decide pass/fail.
5. If pass, archive signed evidence; if fail, block merge and assign triage owners.

Design decisions to make up front

• Granularity: per-PR function-level checks vs full-system nightly analysis.
• Threshold policy: absolute ms, percentage increase, or statistical significance for probabilistic estimates.
• Runtime budget: whether you run a fast, conservative check in PR and a full analysis in nightly builds.
• Evidence format: choose JSON + PDF + signed hash vs custom report formats used by auditors.

Practical setup: prerequisites

• RocqStat CLI or the VectorCAST integration available in a headless, license-able form for CI.
• Reproducible build scripts that produce ELF/HEX images with deterministic flags.
• Containerised environment for the analysis step (Docker or OCI image) so CI runs are consistent.
• Storage for artefacts and baselines (artifact registry, S3, or your CI artifacts store).
• Small scripts to compare WCET outputs and control CI exit codes.

Example: GitHub Actions workflow (PR-level WCET check)

This pattern runs a fast RocqStat check on functions changed by the PR. The key is to limit analysis to only modules affected by the commit to keep runtime short.

# .github/workflows/wcet-check.yml
name: wcet-check
on: [pull_request]
jobs:
  build-and-wcet:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup build toolchain
        run: ./ci/setup-toolchain.sh
      - name: Build changed modules
        run: ./ci/build-changed-modules.sh
      - name: Run RocqStat
        env:
          ROCQSTAT_LICENSE: ${{ secrets.ROCQSTAT_LICENSE }}
        run: |
          docker run --rm -v $(pwd):/work -w /work rocqstat/cli:2026 \
            rocqstat analyze --input build/moduleA.elf --config rocqstat.yaml --output artifacts/wcet-moduleA.json
      - name: Compare WCET
        run: python3 ci/compare_wcet.py artifacts/wcet-moduleA.json baselines/wcet-moduleA.json --threshold 5
      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: wcet-report
          path: artifacts/*.json

The example assumes a Docker image exposing a rocqstat CLI. Replace the CLI invocation to match your licensed package or VectorCAST headless API. The comparator script should return a non-zero exit code when the delta exceeds policy limits so CI fails the PR.

Comparator script: sample logic

A robust comparator performs a few checks beyond raw numeric comparison:

• Ignore unordered metadata fields.
• Compare the function-level WCET table and detect which functions increased.
• Apply threshold rules per-function or per-module.
• Produce a human-readable summary and machine-readable JSON for evidence storage.

# ci/compare_wcet.py (simplified)
import json, sys
new = json.load(open(sys.argv[1]))
baseline = json.load(open(sys.argv[2]))
threshold = float(sys.argv[3])
report = {"regressions": []}
for func, new_val in new['functions'].items():
    base_val = baseline['functions'].get(func)
    if base_val is None:
        continue
    delta_pct = (new_val - base_val) / base_val * 100
    if delta_pct > threshold:
        report['regressions'].append({'function': func, 'baseline': base_val, 'current': new_val, 'delta_pct': delta_pct})
print(json.dumps(report, indent=2))
if report['regressions']:
    sys.exit(2)

Scaling up: full-system nightly analysis

Per-PR checks are great for catching immediate regressions but sometimes a change interacts across modules and only shows up in full-system WCET. Run a comprehensive nightly or gated pre-release pipeline that:

• Build the full image with instrumented compile flags if needed.
• Run RocqStat’s full analysis (may be longer-running).
• Store the full-system WCET report in an immutable artifact store with metadata and signatures.
• Trigger traceability workflows for any deltas beyond acceptance criteria.

Performance tactics: keep CI fast and deterministic

• Incremental analysis: only analyze changed functions or affected call graphs in PR checks.
• Cache intermediate artefacts: control-flow graphs, IL dumps and preprocessed binaries can be cached between builds to avoid recomputation.
• Parallelise: split per-module analyses across multiple runners or containers.
• Two-tier policy: fast conservative checks in PRs; full formal analysis in nightly pipelines.

Dealing with measurement variability and probabilistic estimates

RocqStat and similar tools may provide different analysis modes (pure static, statistical/probabilistic, measured traces). Your CI comparator must understand the mode used and apply appropriate thresholds.

• For probabilistic WCET: use statistical tests (confidence intervals) rather than simple percentage thresholds.
• For measurement-based estimates: ensure repeatable harness runs and remove outliers via established filtering (e.g., remove warm-up runs).
• Record the analysis configuration (seed, sample count) in metadata so runs are reproducible for auditors.

Generating audit-ready evidence automatically

Auditors want traceability, immutability, and reproducibility. Automate the following outputs from your pipeline and sign them:

• WCET JSON report with function-level values, analysis mode, and tool-version.
• Human-readable PDF summarising results and hit-lists of regressions.
• Provenance packet that includes git SHA, build artifacts (ELF), compile flags, and checksums.
• Digital signature of the evidence (use your org’s code-signing key or HSM-integrated signing to ensure non-repudiation).
• Retention policy that keeps artefacts for the period required by your standard (e.g., 7–10 years for automotive projects).

Putting it together: artifact packaging example

# make-evidence.sh (conceptual)
set -e
mkdir -p artifacts/evidence
cp artifacts/wcet-*.json artifacts/evidence/
cp build/*.elf artifacts/evidence/
cat > artifacts/evidence/metadata.json <