embeddedCIverification

Automating Safety Verification: Orchestrating VectorCAST + RocqStat in CI Pipelines

aassign

2026-02-07

10 min read

A DevOps cookbook for embedded teams: integrate VectorCAST + RocqStat into CI to gate releases on verified WCET and timing constraints.

Gate Releases on Verified Timing: a DevOps cookbook for embedded teams

Missed deadlines, invisible regressions, and last-minute handoffs are the reality for many embedded teams trying to ship safety-critical software. If your CI runs unit tests but doesn't verify worst-case execution time (WCET) and timing constraints, you still have a release-risk gap. This cookbook shows how to orchestrate VectorCAST and RocqStat inside modern CI pipelines so every build is gated on verified timing, with reproducible reports, auditable artifacts, and automated alerts for regressions.

Why timing verification belongs in CI now (2026 context)

Late 2025 and early 2026 saw a wave of consolidation and feature integration in the safety tool market. In January 2026 Vector Informatik acquired StatInf’s RocqStat technology and team to integrate advanced timing analysis directly into its VectorCAST toolchain. That market move reflects two converging trends:

Regulatory and OEM pressure for demonstrable timing safety in automotive, aerospace, and industrial systems.
DevOps expectations: automated, auditable release gates that cover not just functional tests, but non‑functional safety properties like WCET and latency budgets.

For embedded teams, the implication is clear: timing verification is no longer an ad-hoc stage performed manually before release. It must be an automated CI gate that preserves traceability, supports reproducible analysis, and integrates with issue trackers and observability tools.

What this guide gives you

Concrete pipeline patterns for integrating VectorCAST + RocqStat with common CI systems (GitHub Actions, GitLab CI, Jenkins, Azure DevOps).
Practical scripts and parsing patterns to gate releases based on WCET and timing constraints.
Operational advice: licensing, containers, HIL/FAT vs static analysis, reproducible measurement, and audit trails.
Checklist and troubleshooting section for rollout at scale.

Core architecture: how VectorCAST + RocqStat fit into CI

At a high level, integrate timing verification into CI as a distinct stage that runs after build and functional tests but before release promotion. The stage can run in one of three modes, depending on project constraints:

Static timing analysis only — RocqStat analyzes the binary and cache and pipeline model to produce conservative WCET estimates. Fastest and most deterministic for gating.
Measurement-driven (HIL/FAT) — VectorCAST executes tests on hardware or hardware-in-the-loop (HIL), collects traces, then RocqStat refines estimates using measured execution paths.
Hybrid — Static analysis augmented by measured execution paths and cache/pipeline models for tighter WCET bounds.

Typical CI flow:

Checkout, compile, and create deterministic artifacts (compiler flags, map files, symbol tables).
Run VectorCAST unit/integration tests; collect coverage and execution traces if available.
Run RocqStat analysis (CLI) with a platform model; output JSON/XML WCET report.
Parse WCET results; compare against timing budgets and previous-good baselines.
If WCET > budget or regression detected: fail pipeline, open ticket, post trace to Slack/Teams with links to artifacts. Otherwise: tag artifact, store signed report, promote build.

Practical pipeline examples

Design principles for pipelines

Pin tool versions (VectorCAST and RocqStat) — timing results are sensitive to analyzer versions and platform models.
Use containers for reproducibility; provide a base image with licensed tools or a secure license proxy.
Store platform metadata (CPU model, compiler version, optimization flags, link-time map) as artifacts alongside WCET reports.
Produce machine-readable outputs (JSON/XML) from RocqStat and VectorCAST for automated gating and auditing.

GitHub Actions: example job

Below is a compact pattern; adapt to your organization’s secrets and license server approach.

# .github/workflows/wcet-check.yml
name: WCET Verification
on: [push, pull_request]

jobs:
  wcet:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up tools container
        run: |
          docker run --rm -v $PWD:/work -w /work yourcorp/vectorcast-rocqstat:2026 bash -lc "./ci/setup.sh"

      - name: Build firmware
        run: |
          ./ci/build.sh --config=release

      - name: Run VectorCAST tests
        run: |
          vectorcast-cli --project app.vcp --run-tests --output vcast_results.json

      - name: Run RocqStat WCET
        run: |
          rocqstat-cli analyze --binary build/app.elf --platform platform_model.yaml --vcast-results vcast_results.json --output wcet_report.json

      - name: Evaluate WCET
        run: |
          python3 ci/validate_wcet.py wcet_report.json --budget-ms 5.0

The key piece is validate_wcet.py — a simple script that parses Arch/Function-level WCET numbers and returns a non-zero exit code when constraints are violated. Use this exit code to gate merges and promotions.

Jenkins pipeline (Declarative): sample stages

pipeline {
  agent any
  stages {
    stage('Checkout & Build') { steps { sh './ci/build.sh' } }
    stage('VectorCAST Tests') { steps { sh 'vectorcast-cli --project app.vcp --run-tests --output vcast_results.json' } }
    stage('RocqStat Analysis') { steps { sh 'rocqstat-cli analyze --binary build/app.elf --platform p.yaml --vcast-results vcast_results.json --output wcet_report.json' } }
    stage('WCET Gate') {
      steps {
        script {
          def rc = sh(returnStatus: true, script: 'python3 ci/validate_wcet.py wcet_report.json --budget-ms 5.0')
          if (rc != 0) {
            currentBuild.result = 'FAILURE'
            error('WCET gate failed — blocking promotion')
          }
        }
      }
    }
  }
}

Parsing and gating strategies

Build your gate around three checks:

Absolute constraint — WCET must be <= system-level budget.
Regression threshold — WCET must not increase more than X% or Y ms vs baseline.
Per-path or per-function checks — Critical functions must remain within their local budgets.

Example validate_wcet.py (concept):

#!/usr/bin/env python3
import sys, json
report = json.load(open(sys.argv[1]))
budget_ms = float(sys.argv[3])
# Example: report['wcet_ms'] contains overall worst-case
if report['wcet_ms'] > budget_ms:
  print(f"WCET {report['wcet_ms']}ms exceeds budget {budget_ms}ms")
  sys.exit(2)
# Optionally compare to baseline stored in CI artifacts
print("WCET within budget")
sys.exit(0)

Use a small service or job that preserves baselines for the last known-good release. When a regression is detected, open a ticket (create GitHub issue or Jira) and attach the ROCQ/VCAST artifacts for triage.

Dealing with hardware and platform models

Timing results are only meaningful when the platform model is correct. RocqStat requires models for caches, pipelines, and interrupts. Manage platform models as versioned artifacts in the same repo or a controlled artifact store.

Keep CPU microarchitecture model, compiler flags, and linker map with the build artifact.
If you use HIL measurement, ensure trace collection is deterministic and timestamps are synchronized; collect traces as artifacts for replay/analysis.
For multi-core systems, choose a conservative cross-core interference model or use time-partitioning schedule traces to bound WCET.

Licensing, containers, and reproducibility

Timing verification requires licensed tools and often access to license servers. Recommended patterns:

Containerize VectorCAST + RocqStat with the exact versions and dependencies. Use CI runners with access to licensed tools or a license proxy in your network.
Adopt immutability: do not change compiler flags or optimization flags after a baseline is established — store compiler invocation in CI artifacts.
Use SBOMs and SLSA provenance where possible to increase trust in published artifacts and timing reports.

Security, audit, and compliance

Safety teams need traceability from requirement to test to timing claim. Make these a first-class part of the pipeline:

Sign WCET reports and artifacts (cosign or GPG) and store signatures with build metadata.
Link WCET reports to Jira requirements or safety-case artifacts automatically.
Keep immutable artifact storage (S3 with Object Lock, artifact registries) for final release evidence.
Maintain an audit log of tool versions, platform models, and operator who approved any manual re-evaluations.

How to reduce false positives and tighten WCET

Static WCET can be conservatively high. Combine strategies to get useful, actionable gates:

Use measured execution traces to rule out infeasible paths when safe to do so.
Increase model fidelity for caches and pipelines only when you can validate models with microbenchmarks.
Use path-sensitive analysis to focus on critical functions instead of monolithic over-approximations.

Scaling timing verification for multiple teams and repos

When multiple teams share a platform, introduce a timing-service model:

Centralize platform models and timing budgets in a repository owned by platform engineering.
Provide a shared CI job/library (a pipeline template or reusable action) that teams reuse to run VectorCAST + RocqStat with consistent inputs.
Publish a dashboard of WCET trends and regressions; use automated anomaly detection for long-term drift.

Sample integration pattern: VectorCAST + RocqStat with GitLab CI and artifact retention

stages:
  - build
  - test
  - timing

build:
  stage: build
  script:
    - ./ci/build.sh --target=hw
  artifacts:
    paths:
      - build/app.elf
      - build/app.map

unit_test:
  stage: test
  script:
    - vectorcast-cli --project app.vcp --run-tests --output vcast_results.json
  artifacts:
    paths:
      - vcast_results.json

wcet:
  stage: timing
  script:
    - rocqstat-cli analyze --binary build/app.elf --platform platform.yaml --vcast-results vcast_results.json --output wcet_report.json
    - python3 ci/validate_wcet.py wcet_report.json --budget-ms 5.0
  artifacts:
    when: always
    paths:
      - wcet_report.json
      - rocqstat_logs/**

Troubleshooting common issues

Inconsistent results between CI runs: Check compiler flags, link map, and microarchitecture model; ensure deterministic builds.
WCET spikes after refactor: Inspect per-function WCET deltas; often caused by changed inlining or loop bounds.
Timeouts in analysis: Increase analysis resources or change analysis precision; schedule heavy runs nightly and baseline checks on PRs.
Hardware access bottleneck: Use hybrid flow — run static analysis per-PR, schedule HIL nightly for final validation.

Case study (pattern): Automotive ECU team

An ECU software team adopted the pipeline above in mid-2025 during early RocqStat commercial deployments. Results within six months:

100% of releases required passing WCET gate — catching three regressions that would have missed an ECU timing budget.
Faster triage: automated diffs of function-level WCETs reduced time-to-diagnose from days to hours.
Improved collaboration: safety and platform teams agreed on a single platform model repo, enabling reproducible verification across feature branches.

Integrating timing analysis into CI transformed the team’s release confidence: "We no longer ship unknown timing debt," said the lead firmware engineer.

Future trends and what to plan for (2026+)

Tighter tool integration: Expect deeper VectorCAST + RocqStat integration that reduces manual glue code and standardizes outputs for gating.
AI-assisted model generation: ML techniques will help generate/validate CPU models and detect infeasible paths to tighten WCET without manual effort.
Cloud HIL & remote ledgers: More teams will use cloud-hosted HIL testbeds and verifiable ledgers for timing claim attestation.
Regulatory convergence: OEMs and certifying bodies will increasingly expect machine-readable timing evidence as part of the safety case.

Checklist: production-ready timing gate

Pin VectorCAST and RocqStat versions and store them in CI metadata.
Version and store platform models with each build artifact.
Produce machine-readable WCET reports and sign them.
Implement both absolute and regression gating rules.
Use hybrid analysis (static + measured) for critical releases.
Preserve artifacts and traceability to requirements in your issue tracker.

Final recommendations

Start small but enforce discipline. Add a WCET gate on feature branches using conservative static analysis to stop obvious regressions early. Run deeper, hybrid HIL verification for release candidates nightly. Automate trace collection, artifact signing, and ticket creation so developers get instant, actionable feedback. Most importantly, treat platform models, compiler flags, and binary maps as first-class artifacts — losing version parity is the number one cause of spurious timing regressions.

Call to action

If you’re planning a rollout, begin by creating a minimal CI job that runs VectorCAST unit tests and a RocqStat static analysis on each PR. Use the validate_wcet pattern above to fail the build on violations and store the reports. If you want a ready-made CI template or hands-on help integrating VectorCAST + RocqStat into GitHub Actions, Jenkins, or GitLab CI, contact our engineering team at assign.cloud for a tailored migration plan and a reproducible pipeline starter kit.

assign

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.