Integrating Timing Analysis Tools into Embedded Release Pipelines: Scripts and Examples

Hook: Stop surprises at integration — catch timing regressions before they ship

Embedded teams spend months chasing intermittent latency problems that only appear on hardware. In 2026, with systems getting more software-defined and timing safety becoming a top-line requirement, you can no longer rely on late-stage manual checks. Integrating RocqStat and VectorCAST timing checks directly into your CI pipelines ensures PRs are gated by concrete worst-case execution time (WCET) and timing budgets, reducing production surprises and audit friction.

Why timing checks in CI matter in 2026

Late 2025 and early 2026 saw industry consolidation around combined verification + timing toolchains. Notably, Vector Informatik announced the acquisition of StatInf's RocqStat technology to integrate timing and WCET logic into the VectorCAST toolchain—an industry signal that timing analysis belongs in the verification pipeline, not as an afterthought (Automotive World, Jan 16, 2026).

For embedded firmware teams this means: tools are converging, auditors expect traceable evidence of timing compliance, and automated gating is now feasible. The ROI is faster releases, fewer reverts, and provable timing margins for safety-critical features.

High-level CI strategy for timing analysis: PR gating vs release validation

• PR gating: Fast, incremental checks on pull/merge requests that block changes introducing timing regressions beyond an acceptable delta.
• Release validation: Full-system timing runs (including longer analysis, HW-in-the-loop) that produce signed, auditable reports stored as release artifacts.
• Baseline-driven decisions: Use a committed baseline of WCET values and thresholds to decide fail/pass.
• Automation over manual interpretation: Parse tool outputs, annotate PRs, fail builds when thresholds are exceeded, and attach detailed artifacts for engineers and auditors.

Prerequisites and best practices

• Licensed access to RocqStat and/or VectorCAST, or use vendor-provided Docker images. Expect license server or node-locked license management.
• Self-hosted CI runners that can run cross-compilers and access hardware or simulation environments. Timing analysis often needs deterministic cross-compiled binaries.
• Deterministic builds: reproducible flags, fixed toolchain versions, and build caching to keep CI runtime manageable.
• Baseline file in repo (JSON/YAML) that lists expected WCETs and allowable deltas.
• Artifact storage (CI artifacts, S3, or a release server) for reports and signed proof.

GitHub Actions: Practical workflow example

Below is a concrete GitHub Actions workflow that demonstrates PR gating and release validation using vector tools and RocqStat. The workflow assumes a self-hosted runner with the necessary cross-compiler and tool licenses.

name: CI - Timing Checks

on:
  pull_request:
    branches: [ main ]
  release:
    types: [published]

jobs:
  build:
    name: Build firmware
    runs-on: [self-hosted, linux, arm-cross]
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup toolchain cache
        uses: actions/cache@v4
        with:
          path: ~/.cache/toolchain
          key: ${{ runner.os }}-toolchain-${{ hashFiles('toolchain_version.txt') }}

      - name: Build (cross-compile)
        run: |
          ./scripts/build.sh --target boardA --out build/boardA

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: firmware-build
          path: build/boardA

  timing-pr:
    name: Run quick timing checks (PR gating)
    runs-on: [self-hosted, linux, timing-enabled]
    needs: build
    if: github.event_name == 'pull_request'
    steps:
      - name: Download build
        uses: actions/download-artifact@v4
        with:
          name: firmware-build

      - name: Run VectorCAST unit tests
        run: |
          ./tools/vectorcast/run_vcast_cli.sh --project project.vcast --batch --out reports/vcast

      - name: Run RocqStat (headless quick run)
        env:
          ROCQ_LICENSE_SERVER: ${{ secrets.ROCQ_LICENSE }}
        run: |
          ./tools/rocqstat/run_rocq_cli.sh --binary build/boardA/fw.elf --config tests/timing_quick.cfg --out reports/rocq.json

      - name: Parse timing results and gate PR
        run: |
          python3 tools/ci/parse_timing.py --input reports/rocq.json --baseline timing_baseline.json --threshold 1.05

      - name: Upload timing report
        uses: actions/upload-artifact@v4
        with:
          name: timing-report
          path: reports

  release-validation:
    name: Full timing validation (release)
    runs-on: [self-hosted, linux, timing-enabled]
    needs: build
    if: github.event_name == 'release' && github.event.action == 'published'
    steps:
      - name: Download build
        uses: actions/download-artifact@v4
        with:
          name: firmware-build

      - name: Run VectorCAST full test matrix
        run: |
          ./tools/vectorcast/run_vcast_cli.sh --project project.vcast --matrix --out reports/vcast_full

      - name: Run RocqStat (full WCET analysis)
        env:
          ROCQ_LICENSE_SERVER: ${{ secrets.ROCQ_LICENSE }}
        run: |
          ./tools/rocqstat/run_rocq_cli.sh --binary build/boardA/fw.elf --config tests/timing_full.cfg --out reports/rocq_full.json

      - name: Generate signed report and upload
        run: |
          ./tools/ci/generate_signed_report.sh reports/rocq_full.json reports/vcast_full reports/final_report.pdf

      - name: Upload final artifacts
        uses: actions/upload-artifact@v4
        with:
          name: release-timing-artifacts
          path: reports/final_report.pdf

Notes:

• Use self-hosted runners labeled with capabilities (e.g., timing-enabled) so jobs land on machines with licenses and required HW access.
• The parse script should exit non-zero if WCET exceeds the baseline threshold—this blocks PRs automatically.
• Keep quick PR runs light: run a targeted subset of the code paths or simplified configs. Reserve deep analysis for release runs.

Example parsing script (tools/ci/parse_timing.py)

#!/usr/bin/env python3
  import json
  import sys
  import argparse

  parser = argparse.ArgumentParser()
  parser.add_argument('--input')
  parser.add_argument('--baseline')
  parser.add_argument('--threshold', type=float, default=1.0)
  args = parser.parse_args()

  with open(args.input) as f:
      roc = json.load(f)
  with open(args.baseline) as f:
      base = json.load(f)

  failures = []
  for func, data in roc['functions'].items():
      wcet = data['wcet_cycles'] / 1e6  # convert to ms if needed
      base_wcet = base.get(func, {}).get('wcet_ms')
      if base_wcet is None:
          continue
      if wcet > base_wcet * args.threshold:
          failures.append((func, wcet, base_wcet))

  if failures:
      print('Timing regressions:')
      for f in failures:
          print(f' - {f[0]}: {f[1]:.3f}ms > {f[2]:.3f}ms')
      sys.exit(2)
  print('Timing checks passed')
  sys.exit(0)
  

GitLab CI example: merge request gating and release stage

GitLab supports CI/CD and merge request pipelines. The example below runs quick RocqStat checks on MRs and a full timing job on tags/releases.

stages:
  - build
  - timing
  - publish

variables:
  ROCQ_LICENSE: $ROCQ_LICENSE

build:
  stage: build
  tags:
    - arm-cross
  script:
    - ./scripts/build.sh --target boardA --out build/boardA
  artifacts:
    paths:
      - build/boardA

rocq_pr:
  stage: timing
  tags:
    - timing-enabled
  needs: [build]
  only:
    - merge_requests
  script:
    - ./tools/rocqstat/run_rocq_cli.sh --binary build/boardA/fw.elf --config tests/timing_quick.cfg --out reports/rocq.json
    - python3 tools/ci/parse_timing.py --input reports/rocq.json --baseline timing_baseline.json --threshold 1.05
  artifacts:
    paths:
      - reports/

rocq_release:
  stage: timing
  tags:
    - timing-enabled
  needs: [build]
  only:
    - tags
  script:
    - ./tools/rocqstat/run_rocq_cli.sh --binary build/boardA/fw.elf --config tests/timing_full.cfg --out reports/rocq_full.json
    - ./tools/ci/generate_signed_report.sh reports/rocq_full.json reports/final_report.pdf
  artifacts:
    paths:
      - reports/final_report.pdf

GitLab gives flexibility to gate merges by requiring pipeline success for MRs. Use protected branches and MR approvals for extra control.

Parsing outputs & representing results in PRs/MRs

Timing tools produce rich output (XML/JSON), including path traces, per-function WCET, and call-graph info. Your CI should:

• Extract concise pass/fail metrics (max WCET, percent over baseline, top 5 regressions).
• Attach the full raw results as artifacts so reviewers and auditors can dig deeper.
• Create inline annotations or summary comments in PRs using the GitHub Checks API or GitLab MR comments.

Example: In GitHub Actions use actions/github-script or the GitHub Checks API to produce a check run with a summary and link to artifacts. For GitLab, use job log and MR comments via the API.

Thresholds, baselines and handling noise

Timing measurement has noise. Use strategies to avoid noisy false positives:

• Relative thresholds: Allow a small percentage delta (e.g., 5%) in PR gating and a stricter one for releases.
• Baseline per function: Maintain a baseline file mapping function -> expected WCET.
• Confidence levels: Require repeated failures across N runs before failing a PR, or require a reproducible delta above the threshold.
• Ignore noisy functions: Some functions have large variability—exclude or track them separately.

Release pipeline and auditability

When building a release, your pipeline should produce an auditable evidence bundle:

• Signed PDF/HTML report with results, timestamps, tool versions, and license info.
• Raw RocqStat/VectorCAST output files (XML/JSON), with checksums and signatures.
• Link to the exact Git commit and CI pipeline ID to reproduce the run.

Automate signing (GPG or vendor-supplied signing) and upload artifacts to the release or an internal artifact repository. Keep retention policies aligned with auditor expectations—safety-critical projects often require multi-year retention.

Advanced strategies and optimizations

• Containerize the toolchain: Vendor images or internal Docker images reduce environment drift. For RocqStat/VectorCAST, check vendor guidance on containerization and license forwarding.
• Incremental analysis: Cache intermediate analysis results and only re-analyze changed modules when possible.
• Parallelize runs: Split analysis by module or test harness and run concurrently on multiple runners.
• Hardware-in-the-loop (HIL): For realistic timing validation, integrate HIL tests as a separate CI stage with reserved lab runners.
• Embrace the VectorCAST-RocqStat integration: As vendors integrate timing into verification toolchains (Vector’s 2026 acquisition of RocqStat tech), plan to migrate to unified workflows where tests and WCET data are produced together.

Licensing, security and vendor lock-in considerations

Timing tools are vendor products and require careful handling:

• Manage license servers securely and put credentials in secrets stores (GitHub Secrets, GitLab CI variables). Rotate and audit access.
• Network egress: Ensure hosts with license access are tightly controlled and monitored.
• Plan for vendor lock-in: Keep analysis artifacts in open formats (XML/JSON) and maintain scripts to parse them in-house so you can migrate tools if needed.

Quick case scenario (typical outcome)

Consider a firmware project for a vehicle ECU. Before CI gating, the team saw timing regressions during system integration roughly 2–3 times per release. After integrating RocqStat quick checks into PR pipelines and running full analysis at release time, the team reduced late-stage regressions by 70% and cut integration cycles by two weeks per release. The result: predictable timing margins and smoother certification evidence.

Checklist and reusable templates

• Add timing_baseline.json to the repo with per-function WCET expectations.
• Create quick and full RocqStat configs (e.g., tests/timing_quick.cfg, tests/timing_full.cfg).
• Provision self-hosted runners with labels arm-cross and timing-enabled.
• Implement tools/ci/parse_timing.py to standardize gating logic.
• Produce signed reports in release pipelines and store them with release artifacts.

Actionable takeaways

• Start small: Add a lightweight RocqStat quick check in PRs to catch clear regressions without slowing developers.
• Baseline first: Commit WCET baselines and treat them as code—review them in PRs.
• Automate annotation: Have CI produce human-readable summaries and attach artifacts for reviewers.
• Reserve deep runs for releases: Full WCET analysis is expensive—run it in release stage and archive signed reports.
• Plan for vendor integration: With Vector integrating RocqStat into VectorCAST in 2026, re-evaluate tooling strategy to exploit unified verification pipelines.

"Timing safety is becoming a critical requirement for software-defined systems." — industry reporting on Vector’s RocqStat acquisition (Automotive World, Jan 2026)

Next steps (how your team can get started this week)

1. Identify one critical module and create a quick RocqStat config for PR gates.
2. Provision a self-hosted runner with necessary licenses and toolchain.
3. Add a CI job that runs the quick timing check and uses the parse script to gate PRs.
4. Schedule a release job that runs full WCET and archives signed reports.

Closing: build confidence into every merge

In 2026, timing analysis belongs in CI. Combining RocqStat and VectorCAST checks into PR gating and release pipelines turns timing from a risky, late-stage guess into a repeatable, auditable property of your firmware. Start with quick PR checks, keep a strict baseline for releases, and automate artifacting and signing. The tools are ready—now it’s about integrating them into your DevOps routine so teams ship faster with confidence.

Call to action

Ready to add timing gates to your pipeline? Try our starter templates and scripts (GitHub/GitLab) or contact the simpler.cloud engineering team for a hands-on workshop to integrate RocqStat/VectorCAST into your CI and release flow.

Related Reading

• Microscopic Hunters: A Lesson Plan on Genlisea and Underground Trapping Mechanisms
• Onboard Health & Micro‑Commerce 2026: Air Quality, Creator Streaming and Tokenized Souvenirs
• Peter Moore and the Trombone: Meet the Musician Rewriting Brass Expectations
• DIY Name Plaques: Using 3D Printing and Printable Art to Make Personalized Letter Signs
• Protecting Teens from Social App Harms: How New Features (Cashtags, LIVE Badges) Change the Risk Landscape