WCET and CI: Integrating Timing Analysis (RocqStat) into Your Embedded Preprod Pipeline
embeddedCI/CDtesting

WCET and CI: Integrating Timing Analysis (RocqStat) into Your Embedded Preprod Pipeline

ppreprod
2026-01-27
10 min read
Advertisement

Integrate WCET (RocqStat) into your CI pipeline for safety-critical embedded systems — automate timing checks, baselines, and gating in preprod.

Hook: When timing failures become safety failures

Embedded teams building safety-critical systems face a hard truth in 2026: functional correctness is no longer sufficient. Unknown or regressed worst-case execution time (WCET) can turn a perfectly passing test suite into a field failure. You don't want to find out a control loop missed its deadline after a release. Integrating timing analysis into your preprod CI/CD pipeline is no longer optional — it's a risk-control requirement.

In short: why integrate WCET (RocqStat) into CI now

Vector's January 2026 acquisition of StatInf's RocqStat confirms what many teams already know: timing safety and software verification are converging. Vector plans to integrate RocqStat into VectorCAST to offer a unified timing and verification toolchain. That consolidation creates a practical on-ramp for teams to push automated timing checks left, into their CI/CD and preprod automation.

"Vector will integrate RocqStat into its VectorCAST toolchain to unify timing analysis and software verification" — Automotive World, Jan 16, 2026

What you’ll get from this article

  • Concrete pipeline patterns to run WCET analysis (RocqStat) in CI and preprod
  • Examples: GitLab CI, GitHub Actions, Jenkins jobs and hook scripts
  • Automation strategies: gating, baselining, incremental analysis, and artifact management
  • Operational advice for safety, cost-control, and traceability in 2026 environments

High-level architecture: where timing analysis sits in your preprod flow

Integrating WCET analysis into CI means adding a deterministic timing-analysis stage in your build-test-verify pipeline. Here’s a pragmatic, production-ready layout:

  1. Source change pushed (feature branch / MR / PR)
  2. Compile artifacts (cross-compile in reproducible container)
  3. Unit tests + VectorCAST functional tests
  4. WCET analysis (RocqStat) — run static/measurement-based analysis using current binaries + maps
  5. Compare results to baseline & thresholds; generate report artifacts
  6. Annotate PR/MR with results; gate or warn according to policy
  7. Optional: deploy to ephemeral preprod hardware for measurement validation

Key design principles for integrating WCET into CI

  • Deterministic build environments: Use containerized toolchains (Docker, OCI) with pinned tool and compiler versions so timing artifacts are reproducible. See operational playbooks for reproducible edge/toolchain patterns like secure, latency-optimised workflows.
  • Incremental, staged analysis: Full WCET runs are expensive — run fast, targeted checks on MR, and schedule full analyses nightly or on a release branch.
  • Automation hooks: Expose RocqStat run control via CLI or API so CI systems can trigger analyses, fetch JSON reports and produce annotations.
  • Traceable baselines: Store WCET outputs as artifacts with provenance (commit hash, compiler flags, map files) to allow auditing and regression tracking.
  • Fail safe, but sensible gating: Use hard gates only for high-severity regressions; allow advisory fails for exploratory branches to reduce developer friction.

Practical CI examples

Below are example jobs for common CI platforms. They illustrate how to incorporate a RocqStat step, generate machine-readable output, and gate merges.

GitLab CI job (example)

# .gitlab-ci.yml
stages:
  - build
  - test
  - wcet

build:
  stage: build
  image: registry.example.com/embedded/toolchain:2026.01
  script:
    - make all
  artifacts:
    paths:
      - build/output/
    expire_in: 1 week

unit_tests:
  stage: test
  image: registry.example.com/embedded/toolchain:2026.01
  script:
    - make test
  dependencies:
    - build

wcet_analysis:
  stage: wcet
  image: registry.example.com/embedded/rocqstat:latest
  script:
    - rocqstat analyze --binary build/output/app.elf --map build/output/app.map --out results/wcet.json
    - ./ci-scripts/check-wcet-threshold.sh results/wcet.json || exit 1
  dependencies:
    - build
  artifacts:
    paths:
      - results/wcet.json
      - results/wcet-report.html
    when: always
    expire_in: 30d

GitHub Actions job (snippet)

# .github/workflows/wcet.yml
name: WCET Analysis
on:
  pull_request:
    branches: [ main, release/* ]

jobs:
  wcet:
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/example/rocqstat:2026
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: make all
      - name: Run RocqStat
        run: rocqstat analyze --binary build/output/app.elf --map build/output/app.map --out results/wcet.json
      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: wcet-results
          path: results/
      - name: Annotate PR
        run: |
          python3 ci-scripts/annotate_pr.py results/wcet.json

Jenkins pipeline (declarative) example

pipeline {
  agent {
    docker { image 'registry.example.com/embedded/rocqstat:2026.01' }
  }
  stages {
    stage('Checkout & Build') {
      steps { sh 'make all' }
    }
    stage('Run WCET') {
      steps {
        sh 'rocqstat analyze --binary build/output/app.elf --map build/output/app.map --out results/wcet.json'
        archiveArtifacts artifacts: 'results/**', fingerprint: true
        sh './ci-scripts/check-wcet-threshold.sh results/wcet.json || exit 1'
      }
    }
  }
}

Sample threshold checker (bash)

Your CI should enforce simple, automated checks before human review. A small script can parse a RocqStat JSON output and decide whether to fail the pipeline or leave a warning.

#!/usr/bin/env bash
# ci-scripts/check-wcet-threshold.sh
set -euo pipefail
REPORT="$1"
MAX_ALLOWED_US=5000  # example: 5ms
# Extract worst-case value (assumes JSON key worst_case_us)
WCET_US=$(jq '.worst_case_us' "$REPORT")
if [ "$WCET_US" -gt "$MAX_ALLOWED_US" ]; then
  echo "WCET violation: ${WCET_US}us > ${MAX_ALLOWED_US}us"
  exit 1
else
  echo "WCET OK: ${WCET_US}us <= ${MAX_ALLOWED_US}us"
fi

Automation hooks and integration patterns

Successful automation depends on the ability to trigger, parameterize and consume timing-analysis runs. Here are practical hooks to implement.

  • CLI entrypoint: Make RocqStat invocations reproducible and script-friendly. Example flags: --binary, --map, --config, --profile, --out-format json/html.
  • API/Webhook: If RocqStat is hosted or wrapped by VectorCAST, use its API to start analyses, retrieve statuses and stream reports for MR annotations. See examples of API-driven automation in low-latency edge stacks like live streaming edge workflows.
  • Baseline store: Save each analysis result with metadata (git SHA, compiler flags, maps). Use object storage (S3/GCS) or your CI's artifact store; tie this into your observability and archival pipeline similar to cloud-native observability patterns (observability for trading firms).
  • Incremental mode: Expose a "change-set" mode where RocqStat focuses on modified functions and call paths referenced by tests to accelerate MR checks — a concept related to provenance-aware differential checks (operationalising provenance).
  • Measurement hooks: Allow ingestion of runtime measurements from preprod device farms (hardware-in-loop) to refine measurement-based WCET and reduce pessimism. Measurement collection ties into your observability pipeline (cloud observability).

Practical policies: gating vs advisory

Not every WCET increase should block a merge. Here are pragmatic policies used by production teams:

  • Hard gate: If WCET for a safety-critical path increases above ASIL-mapped threshold, block merge and require remediation.
  • Soft gate: If WCET increases but remains within margins, open an advisory issue or assign to owner for triage.
  • Nightly full-run: Run exhaustive WCET analyses nightly (or on main branch) and create regression tickets automatically if results diverge from baseline. Use cost-aware scheduling patterns described in discussions of serverless vs dedicated compute to manage spend.
  • Escalation automation: Integrate with issue trackers (Jira) to auto-create tickets for failures and attach artifacts and links to the MR.

Reducing compute and cost in preprod environments

Full WCET analysis can be expensive, especially for large codebases and multicore targets. Strategies to reduce cost while preserving safety:

  • Incremental analyses on MRs for functions changed; run full analyses only on main/release branches.
  • Cache and reuse intermediate analysis artifacts keyed by compiler flags + commit SHA.
  • Tiered scheduling: fast static approximations in PRs; measurement-enhanced nightly runs.
  • Ephemeral preprod hardware pools — spin up only on demand to collect measurements and then release to save on hosting costs. Pattern mirrors ephemeral edge pools in low-latency stacks (edge streaming).

Recent years (late 2024–2026) accelerated the adoption of multicore ECUs in automotive and aerospace. Timing analysis tools are evolving to cover multicore interference, cache effects and mixed-criticality scheduling. RocqStat and VectorCAST's integration roadmap aims to provide combined functional and timing verification that understands modern concurrency patterns. Expect tooling that fuses static timing analysis, worst-case contention modeling and measured traces from hardware-in-the-loop to deliver tighter, certifiable WCET bounds.

Evidence-first: combining static analysis with measurements

Pure static WCET often produces conservative estimates. To reduce over-pessimism while staying safe, teams combine:

  • Static path analysis (RocqStat) to enumerate candidate worst paths
  • Directed tests & tracing to collect execution times for likely worst-case paths
  • Statistical/MBT fusion to reconcile measurement-based execution times with static upper bounds

In CI, you can automate this by running targeted path tests in preprod hardware after a successful static run and feeding measured traces back into RocqStat to refine the bound.

Traceability & compliance for safety certification

For ISO 26262/DO-178C and other safety standards, traceability and reproducible evidence are essential. Integrate the following into your pipeline:

  • Sign and store WCET reports with provenance (git SHA, compiler, build date).
  • Keep mappings between requirements and analyzed code paths via VectorCAST or your traceability tool.
  • Ensure archived artifacts are immutable and accessible to auditors for the required retention period. See field playbooks on safety and certification for operational controls (safety playbook).

Operational checklist to get started (practical roadmap)

  1. Containerize your compiler and RocqStat toolchain so CI runs are reproducible.
  2. Add a lightweight RocqStat MR job that analyzes changed functions only and returns a simple pass/warn/fail.
  3. Store analysis outputs as artifacts and register them in a baseline store keyed by commit SHA.
  4. Create a nightly full-run job that performs exhaustive WCET analysis and opens tickets for regressions.
  5. Connect measurement collection from your preprod device farm to feed back into analysis for tighter bounds.
  6. Implement gating policy and train teams: explain why some merges may be blocked and how to triage timing failures.

Real-world example: a small timeline

Week 1: Containerize toolchain and run manual RocqStat runs on main. Week 2: Add an MR job for incremental analysis and a simple threshold script. Week 3: Add PR annotation and nightly full-run with automated ticketing. Week 6: Connect preprod device farm and measurement feedback. By month 3 your team has reproducible, auditable WCET checks as part of preprod.

Common pitfalls and how to avoid them

  • Pitfall: Too many false positives from conservative analysis. Fix: Add measurement-based validation and refine static constraints from tests.
  • Pitfall: Over-gating developer productivity. Fix: Use soft gates for minor regressions and require human review only for safety-critical violations.
  • Pitfall: Missing provenance in reports. Fix: Save build metadata, tool versions and map files with each WCET report — see approaches to operationalizing provenance for inspiration.
  • Pitfall: Unbounded cost from full-analysis runs. Fix: Incremental checks in PRs and scheduled full runs with spot-checks; lean on cost-aware compute strategies described in serverless vs dedicated compute essays.

Future predictions (2026–2028)

Expect three converging trends:

  • Toolchain consolidation. Vector's RocqStat acquisition demonstrates industry consolidation to provide end-to-end verification + timing. This will simplify CI integrations as vendors add APIs and CI plugins.
  • Smarter hybrid analysis. WCET tooling will increasingly blend static, measurement and machine-learning-derived heuristics to reduce pessimism without sacrificing safety.
  • Shift-left timing checks. Organizations will treat timing checks like unit tests — fast, automated and part of day-to-day development — reserving heavy-weight runs for release verification.

Actionable takeaways

  • Start small: Add an incremental RocqStat MR job that targets changed functions.
  • Make it visible: Annotate PRs with WCET results and attach artifacts.
  • Automate escalation: Nightly full runs + auto-ticketing for regressions.
  • Preserve provenance: Store reports with git SHA, compiler flags and maps for audits — see operational provenance patterns.
  • Balance cost & safety: Use tiered runs — fast checks for PRs, exhaustive runs for release branches.

Closing: why this matters to your preprod pipeline

Integrating WCET into CI turns timing risk into a manageable, automated process. The Vector–RocqStat move in early 2026 makes it easier for teams to get started: expect tighter integrations between functional verification and timing analysis within the familiar VectorCAST environment over the next 12–18 months. By adopting the CI patterns above, you reduce surprises, lower time-to-merge, and create an auditable record to support certification.

Call-to-action

Ready to add WCET checks to your embedded preprod pipeline? Start by containerizing your toolchain and adding a lightweight RocqStat MR job this week. If you want a checklist, CI job templates, and a starter script bundle we use in production, request the prebuilt repo and pipeline templates from our team — or trial VectorCAST with RocqStat to see unified timing + verification in action.

Advertisement

Related Topics

#embedded#CI/CD#testing
p

preprod

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.

Advertisement
2026-02-04T12:31:50.492Z