WCET in CI: integrate RocqStat timing analysis into your embedded CI pipeline
embeddedci-cdsafety

WCET in CI: integrate RocqStat timing analysis into your embedded CI pipeline

ccodenscripts
2026-02-04 12:00:00
10 min read
Advertisement

Make WCET checks part of PR validation. Use RocqStat (now part of Vector's roadmap) to automate timing analysis in CI for reliable, auditable timing evidence.

Stop WCET regressions from slipping into PRs — run timing analysis in CI

If your team spends hours chasing intermittent latency spikes or arguing about whether a commit increased the worst-case execution time, you need automated WCET checks in your pull-request pipeline. In 2026, with automotive and safety-critical software growing more complex, the acquisition of StatInf’s RocqStat by Vector (announced Jan 16, 2026) is a turning point: it paves the way for a unified timing-analysis and verification flow inside VectorCAST. That means teams can soon treat timing analysis as a first-class CI artifact — the same way unit tests and static analysis are today.

Why unified timing analysis matters in 2026

Software-defined vehicles, multicore ECUs, and tighter safety standards are forcing embedded teams to prove timing safety earlier and more frequently. In late 2025 and into 2026, several trends made this urgent:

  • Increasing adoption of multicore and mixed-criticality designs that complicate worst-case timing reasoning.
  • Stricter expectations from ISO 26262 and industry guidance: timing evidence must be traceable and reproducible.
  • A push toward continuous verification: test, static analysis, and now timing checks must run automatically on feature branches.

Vector's acquisition of RocqStat consolidates timing expertise into the VectorCAST toolchain, promising continuity of the RocqStat team and a unified path for combining WCET estimation with testing and coverage. This makes it realistic to automate timing checks in CI without creating a parallel, disconnected tooling silo.

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

High-level CI strategy for WCET checks

Integrating RocqStat (or any WCET estimator) into your CI pipeline follows three core steps:

  1. Produce a reproducible build with the same compiler, flags, and map symbols that the WCET tool expects.
  2. Run the timing analysis (static, measurement-based, or hybrid) to produce machine-readable reports.
  3. Evaluate the results against gated thresholds and upload artifacts / annotations to the PR.

Decide the analysis mode

  • Static WCET analysis: Uses control-flow and microarchitectural models. Fast and deterministic — good for early PR checks.
  • Measurement-based: Uses instrumented runs or hardware traces — more accurate for complex platforms but requires hardware-in-the-loop (HIL).
  • Hybrid: Combine static estimates with measured traces for core loops or drivers. Useful for mixed-criticality subsystems.

Requirements for reproducible CI timing checks

  • Deterministic toolchain: Pin compiler and libc versions inside a Docker image or build container.
  • Map files & symbols: Generate full link maps and keep symbol information for per-function WCET mapping.
  • Licensing: Commercial timing tools need license handling (license server, files in secrets). CI must secure license tokens.
  • Source-to-binary traceability: Tag artifacts with commit IDs and build metadata so reviewers can re-run analysis locally.

Practical CI examples and scripts

The examples below are conservative, vendor-agnostic recipes that assume a RocqStat-like CLI is available in CI (the Vector integration will expand native support inside VectorCAST in the medium term). You can adapt these to GitHub Actions, GitLab CI, or Azure Pipelines.

Containerize the build and the timing tool

Start by creating a Docker image that contains your cross-compiler, build tools and the timing analysis CLI. Example Dockerfile (minimal):

FROM ubuntu:22.04

# Install utilities
RUN apt-get update && apt-get install -y build-essential cmake git python3 jq curl --no-install-recommends \
    && rm -rf /var/lib/apt/lists/*

# Install cross-toolchain (example placeholder)
# RUN apt-get install -y gcc-arm-none-eabi

# Install RocqStat CLI (hypothetical binary distribution)
COPY tools/rocqstat /opt/rocqstat/rocqstat
RUN chmod +x /opt/rocqstat/rocqstat && ln -s /opt/rocqstat/rocqstat /usr/local/bin/rocqstat

ENV PATH="/usr/local/bin:$PATH"

WORKDIR /workspace

Notes: replace the placeholder with your platform-specific cross compiler and place the rocqstat binary according to your licensed distribution. Ensure license tokens are injected at runtime via CI secrets.

Utility script: run analysis and enforce thresholds

Create a wrapper script that runs the timing tool, converts results to JSON, and fails the job if limits are exceeded. This example uses a conservative JSON schema that many tools provide; adjust keys for the actual tool output.

#!/usr/bin/env bash
set -euo pipefail

# check_wcet.sh: run rocqstat, save artifacts, and fail if thresholds exceeded
# Usage: ./check_wcet.sh  

BUILD_DIR=${1:-build}
THRESHOLD_US=${2:-500}  # example overall WCET threshold in microseconds

REPORT_JSON="$BUILD_DIR/rocqstat-report.json"
HTML_REPORT="$BUILD_DIR/rocqstat-report.html"

# Run the (hypothetical) RocqStat CLI to analyze the ELF or map
# Inputs: binary or map path must be produced by your build system
rocqstat analyze --binary $BUILD_DIR/firmware.elf --map $BUILD_DIR/link.map -o $REPORT_JSON --html $HTML_REPORT

# Basic validation: check overall WCET value in microseconds
if ! jq -e '.overall_wcet_us' "$REPORT_JSON" >/dev/null; then
  echo "ERROR: report missing overall_wcet_us"
  exit 2
fi

OVERALL_WCET_US=$(jq '.overall_wcet_us' $REPORT_JSON)

echo "Overall WCET (us): $OVERALL_WCET_US (threshold: $THRESHOLD_US)"

if (( $(echo "$OVERALL_WCET_US > $THRESHOLD_US" | bc -l) )); then
  echo "FAIL: WCET exceeds threshold"
  # Save artifacts for PR review
  ls -lh "$REPORT_JSON" "$HTML_REPORT" || true
  exit 1
else
  echo "PASS: WCET within threshold"
fi

GitHub Actions workflow example

Below is a compact GitHub Actions workflow that runs on PRs. It builds, runs RocqStat in the container, uploads artifacts and annotates the PR.

name: WCET Check
on:
  pull_request:
    paths:
      - 'src/**'
      - 'CMakeLists.txt'

jobs:
  wcet:
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/yourorg/embedded-wcet:2026-01
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build Firmware
        run: |
          mkdir -p build && cd build
          cmake .. -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake
          make -j$(nproc)

      - name: Run RocqStat Analysis
        env:
          ROCQSTAT_LICENSE: ${{ secrets.ROCQSTAT_LICENSE }}
        run: |
          ./check_wcet.sh build 500

      - name: Upload WCET artifacts
        uses: actions/upload-artifact@v4
        with:
          name: rocqstat-artifacts
          path: build/rocqstat-report.*

Tips:

  • Use GitHub Checks or PR Annotations to surface function-level regression comments.
  • Expose per-function deltas: post a small table in the PR showing functions with WCET deltas.

GitLab CI example

stages:
  - build
  - wcet

build:
  stage: build
  image: registry.gitlab.com/yourorg/embedded-wcet:2026-01
  script:
    - mkdir -p build
    - cd build
    - cmake ..
    - make -j$(nproc)
  artifacts:
    paths:
      - build/firmware.elf
      - build/link.map

wcet_check:
  stage: wcet
  image: registry.gitlab.com/yourorg/embedded-wcet:2026-01
  dependencies:
    - build
  script:
    - ./check_wcet.sh build 500
  artifacts:
    paths:
      - build/rocqstat-report.*
  only:
    - merge_requests

Artifacts, reporting, and triage workflow

To make timing checks actionable in PR review, produce these artifacts:

  • Machine-readable report (JSON): required for automated gating and delta calculation.
  • HTML report: human-friendly summary with per-function WCET, call-graphs and hot paths.
  • Delta report: list of functions that changed WCET vs baseline; useful for reviewers.
  • SARIF or JUnit-style annotation: integrate with code-scanning dashboards or test reports.

Good CI practice: store a baseline report on the default branch and compute a delta in PR pipelines. Only flag regressions that exceed a tolerance to avoid noisy failures.

Dealing with multicore, OS and interrupts

Embedded systems today frequently run on complex platforms with OS scheduling, interrupts and shared resources. A few recommended strategies:

  • Scope timing checks: start by checking safety-critical tasks and drivers rather than whole-system WCET.
  • Use compositional analysis: analyze tasks individually and combine results with system-level arbitration models.
  • Model shared resources: include contention and locking overhead where possible, or conservatively budget for it in CI checks.
  • Hybrid HIL runs for verification only: run measurement-based full-system timing checks nightly or on the main branch while keeping PR checks fast and static.

Operational best practices

  • Pin everything: Container images, compilers, and RocqStat binary versions must be pinned to ensure reproducible estimates. This helps with trust and automation in your releases.
  • Protect licenses: Use ephemeral license tokens and store them in secret managers. Consider a central license-server with per-job tokens.
  • Noise budgeting: Allow small tolerances to account for non-determinism in measurement-based data; static analysis should be deterministic.
  • Review policy: Define an owner for timing regressions; triage should test if the regression is real, a toolchain change, or a false positive.
  • Automate triage: Use baselines and diff reports so reviewers only see changed functions with meaningful deltas.

Example PR gating workflow

  1. Developer opens PR. CI runs build + static RocqStat analysis within 10–20 minutes.
  2. CI uploads JSON and HTML reports. If overall WCET or per-function WCET exceeds PR thresholds, the job fails and comments on the PR with a delta table.
  3. If PR is blocked, the author can either optimize code or open a timing-bump ticket (with evidence) if the change is necessary.
  4. Nightly full-system HIL timing runs verify PRs merged into main and update the baseline if verified.

Hypothetical case study: small team, big impact

Acme Auto (hypothetical) integrated a RocqStat-like static WCET checker into its PR workflow in early 2026. They followed the incremental approach:

  • First month: enabled function-level static checks on communication drivers and safety tasks. This cut debug cycles by 30% because regressions were caught before integration tests.
  • Second month: added nightly HIL runs for full-system verification and advanced multi-core contention modeling.
  • Result: timing evidence became part of the release artifacts and made ISO 26262 audits smoother because timing reports were reproducible and traceable to commits.

Key takeaway: start small, protect critical paths, and expand coverage once the automation proves stable.

Future predictions and strategy (2026+)

Vector's acquisition of RocqStat is more than a product story: it signals a trend toward integrated verification suites where testing, coverage, and timing analysis share metadata and artifacts. Expect these developments:

  • Stronger integration between WCET tools and unit / integration testing frameworks (VectorCAST + RocqStat will be an early example).
  • WCET-as-code patterns: timing budgets checked by CI and stored as code-managed artifacts.
  • Better support for SARIF or unified signatures for timing issues so developer tooling (IDEs, pull-request bots) can present timing regressions inline.
  • AI-assisted prioritization: machine learning models highlight the most likely real regressions from noisy timing data.

Security, licensing and trust considerations

Timing tools increasingly require close handling of proprietary build artifacts and licenses. Follow these rules:

  • Never expose license files in public or in logs; use secrets managers and mount them at runtime.
  • Validate tool outputs: cross-check static estimates with occasional measurement-based runs to detect modeling drift.
  • Keep an audit trail: record ROCQSTAT and VectorCAST versions used to generate WCET evidence for audits.

Actionable takeaways

  • Pin toolchain and tool versions in CI images so WCET reports are reproducible.
  • Run fast static WCET checks in PRs and reserve measurement-based HIL checks for nightly/merge pipelines.
  • Upload JSON and HTML artifacts and compute deltas against a baseline to avoid noisy PR comments.
  • Secure commercial licenses with secrets managers and ephemeral tokens in CI.
  • Start small: scope checks to safety-critical functions first, then iterate toward system-level verification.

Next steps — get started today

If you maintain an embedded codebase, create a small experiment branch and add the Dockerfile + check_wcet.sh example above. On GitHub/GitLab, enable the workflow for merge requests and monitor the noise level for a week. Tighten thresholds and expand scope once false positives are understood.

Vector's move to integrate RocqStat into VectorCAST (Automotive World, Jan 16, 2026) makes it practical to expect deeper, supported integrations in 2026 — but you don't have to wait: the patterns shown here work with current CLI-based timing tools and will translate directly when Vector releases integrated workflows.

Call to action

Ready to treat timing like tests? Clone our sample repo (contains Dockerfile, check_wcet.sh and CI workflows) and run a WCET check against one of your microcontroller subsystems. Set up a baseline, protect your license secrets, and let timing regressions surface as transparent PR feedback. If you want a hands-on walkthrough for VectorCAST + RocqStat integration when Vector releases support, reach out and we'll publish a step-by-step migration recipe.

Advertisement

Related Topics

#embedded#ci-cd#safety
c

codenscripts

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-01-24T04:48:40.096Z