Verifying Timing and WCET in CI: Integrating RocqStat with Your Verification Pipeline
embeddedverificationCI/CD

Verifying Timing and WCET in CI: Integrating RocqStat with Your Verification Pipeline

aassign
2026-01-28
9 min read
Advertisement

Hands-on guide for embedding RocqStat+VectorCAST into CI/CD to automate WCET checks, gate deployments, and produce audit-ready timing artifacts.

Hook: Stop Surprises at Deployment — Automate WCET Checks in CI

If your team still discovers timing overruns only after integration testing or, worse, in the field, youre carrying technical debt that jeopardizes SLAs, safety certifications, and release schedules. Embedded teams building real-time, safety-critical systems need automated, repeatable timing verification in CI/CD so that a failed worst-case execution time (WCET) check blocks a merge before it becomes a problem in production.

In 2026 the momentum is clear: Vector Informatik's acquisition of StatInf's RocqStat (announced January 2026) signals a new era of integrated timing analysis inside the VectorCAST ecosystem. That makes it easier — and more essential — to bake WCET checks into your pipeline. This hands-on guide shows embedded software teams how to plug RocqStat (via VectorCAST) into CI/CD, automate WCET gates, and keep deployments safe and auditable.

Why timing verification in CI matters in 2026

Late-2025 and early-2026 trends underscore why you should act now:

  • Regulatory and industry attention on timing safety (automotive ISO 26262, avionics DO-178C considerations) is increasing; timing artifacts are now routinely requested in audits.
  • Toolchain consolidation — driven by Vector's acquisition of RocqStat — is encouraging unified workflows where testing and timing analysis share artifacts and traceability.
  • CI/CD adoption for embedded workflows has matured: cloud runners, deterministic containerized builds, and hardware-in-the-loop (HIL) farms make it practical to run automated timing checks earlier and more often.
"Vector will integrate RocqStat into its VectorCAST toolchain to unify timing analysis and software verification." " — Automotive World, Jan 16, 2026

What RocqStat + VectorCAST brings to your verification pipeline

At a high level, integrating RocqStat into CI gives you:

  • Automated WCET estimation that can be triggered after each commit or on pull requests.
  • Artifact-level traceability: link WCET results to VectorCAST test cases, code revisions, and tickets.
  • Gateable decisions: fail CI when timing budgets are violated, or open a remediation workflow. Use latency budgeting patterns to set sensible thresholds for fast checks vs. full runs.
  • Audit-ready reports and logs suitable for compliance reviews (ISO 26262, DO-178).

Integration patterns — where to run WCET checks

Not every WCET run needs to be a full, expensive analysis. Choose patterns that balance speed and coverage:

1) Pre-merge quick checks (PR gate)

Run a lightweight, incremental RocqStat check that focuses on modified modules or hot paths. If the quick check finds a potential regression, block the merge and surface the findings in the PR. For many teams this looks like a small, focused job or micro-app that runs only on changed modules.

2) Post-merge full analysis (release branch)

On release branches or nightly runs, run the full RocqStat analysis across the integrated codebase. Use this to update baseline WCETs, validate mitigations, and produce certification artifacts. These runs are good candidates for partitioning and distributed workers described below and for integrating with edge-sync or cache-reuse strategies.

3) Hardware-in-the-loop (HIL) / lab regression

Combine RocqStat's estimates with measured timing on representative hardware to validate worst-case assumptions. Use this pattern for final verification before deployment, and consider hybrid lab workflows or even Raspberry Pi cluster-based test harnesses for low-cost HIL farms where appropriate.

Prerequisites: what your CI environment must provide

  • Containerized environment or dedicated runners with the same toolchain versions you use locally.
  • VectorCAST and RocqStat licenses reachable from CI — manage floating licenses behind your firewall or use a secure license server and identity model like zero-trust identity.
  • Deterministic build configs (compiler flags, linker scripts) captured in the pipeline; include these in your audit checklist (tool-stack audit).
  • Artifacts from build and unit-test stages: binaries, map files, symbol tables, and VectorCAST test case outputs.
  • Storage for artifacts (S3, Nexus, CI artifacts) and a secure place to publish WCET reports.

Hands-on: GitHub Actions example

Below is a compact GitHub Actions workflow that runs a VectorCAST build, invokes RocqStat in headless/CLI mode, and fails the job if WCET exceeds a threshold. Adapt names and commands to your environment.

# .github/workflows/wcet-check.yml
name: WCET Check
on:
  pull_request:
  push:
    branches: [ 'main', 'release/*' ]

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

      - name: Setup toolchain container
        run: docker run --rm -v ${{ github.workspace }}:/work -w /work myorg/embedded-tools:2026-01 bash -lc "./ci/setup_env.sh"

      - name: Build project
        run: ./ci/build.sh

      - name: Run VectorCAST tests
        run: |
          ./ci/run_vectorcast.sh --project project.vcp

      - name: Run RocqStat WCET
        env:
          ROCQSTAT_LICENSE: ${{ secrets.ROCQ_LICENSE }}
        run: |
          ./tools/rocqstat/bin/rocqstat-cli --input artifacts/vectorcast/results.xml --output artifacts/rocq_report.json || true

      - name: Evaluate WCET threshold
        run: |
          python3 ./ci/parse_rocq_report.py artifacts/rocq_report.json --threshold 12000

Notes:

  • Keep RocqStat invocation idempotent and non-fatal in the workflow step; let the parsing step decide pass/fail after making the report available for debugging.
  • Store license secrets in your CI provider's secret store and ensure secure access controls (follow identity and access best practices).

GitLab CI and Jenkins snippets

GitLab CI job (simplified):

# .gitlab-ci.yml
wcet_check:
  image: registry.example.com/embedded-tools:2026-01
  stage: verify
  script:
    - ./ci/build.sh
    - ./ci/run_vectorcast.sh --project project.vcp
    - ./tools/rocqstat/bin/rocqstat-cli --input artifacts/vectorcast/results.xml --output artifacts/rocq_report.json || true
    - python3 ./ci/parse_rocq_report.py artifacts/rocq_report.json --threshold 12000
  only:
    - merge_requests

Jenkins pipeline (Declarative) example:

pipeline {
  agent { label 'embedded-runner' }
  stages {
    stage('Build') { steps { sh './ci/build.sh' } }
    stage('Unit Tests') { steps { sh './ci/run_vectorcast.sh --project project.vcp' } }
    stage('WCET') {
      steps {
        withCredentials([string(credentialsId: 'rocq-license', variable: 'ROCQ_LICENSE')]) {
          sh './tools/rocqstat/bin/rocqstat-cli --input artifacts/vectorcast/results.xml --output artifacts/rocq_report.json || true'
          sh 'python3 ./ci/parse_rocq_report.py artifacts/rocq_report.json --threshold 12000'
        }
      }
    }
  }
}

Practical scripting: parse RocqStat output and gate

RocqStat can produce machine-readable outputs (JSON/XML). Use a short script to:

  1. Extract the WCET value for the function or task under test.
  2. Compare against the configured threshold (absolute or percentage over baseline).
  3. Return non-zero exit code to fail the job and produce a diagnostic message.
#!/usr/bin/env python3
# ci/parse_rocq_report.py
import json
import sys
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('report')
parser.add_argument('--threshold', type=int, required=True)
args = parser.parse_args()

with open(args.report) as f:
    data = json.load(f)

# Replace keys with the actual RocqStat JSON structure
wcet_us = data['summary']['wcet_microseconds']
print(f"WCET estimated: {wcet_us} us (threshold: {args.threshold} us)")
if wcet_us > args.threshold:
    print('ERROR: WCET exceeds threshold')
    sys.exit(2)
else:
    print('OK: WCET within threshold')
    sys.exit(0)

Design patterns for thresholding and flaky results

  • Baseline + delta: store a baseline WCET per release and allow a small delta (e.g., 5") for PR checks; require full justification for larger increases.
  • Tiered gates: block merges for critical functions but only warn for low-risk modules.
  • Re-run policy: for non-deterministic analyses, implement a retry policy with provenance logging to distinguish noise from regression. Design your retry and cache policies similar to patterns in edge-sync and low-latency work.
  • Annotate changes: require developers to add timing impact analysis in PR descriptions when touching real-time code.

Traceability, audit trails, and safety artifacts

To satisfy auditors and safety engineers, your pipeline should produce:

  • Signed artifacts: store signed copies of the RocqStat reports alongside VectorCAST logs and source commit IDs.
  • Traceability matrix: link test cases, requirements, and WCET estimates so reviewers can trace a timing number back to code and tests. Make this part of your standard tool-stack audit.
  • Change log: each failed gate should create a Jira ticket with attached reports for review and mitigation planning; integrate teams via collaboration suites for smoother triage.

Performance, scaling, and licensing considerations

WCET analysis can be resource-heavy. Use these strategies to scale:

  • Incremental analysis: run full analysis nightly but quick incremental checks per-PR. This pattern aligns with serverless/monorepo scaling ideas.
  • Partitioning: analyze independently compiled modules in parallel workers and merge results.
  • Cache and artifact reuse: reuse compiled binaries and intermediate analysis caches between runs.
  • License pooling: manage RocqStat/VectorCAST floating licenses via a license server and autoscale runner pools around license capacity. Tie license access to a secure identity model like zero-trust identity.

Common pitfalls and how to avoid them

Non-deterministic builds

Ensure reproducible builds by pinning compiler versions and using deterministic linker flags. Differences in optimization or inlined functions can alter WCET estimates; guidelines from monorepo and build optimization discussions are a helpful reference.

Hardware-dependent timing

Static analysis must be validated against representative hardware. Where peripheral IRQs or DMA affect timing, complement RocqStat's estimates with measured traces from HIL or instrumented runs — including low-cost testbeds described in Raspberry Pi cluster guides.

Optimizations that hide bugs

Aggressive compiler optimizations may alter control flow in ways that change WCET. Lock down compiler flags used in CI and document any differences between development and production toolchains.

Case study (short): from ad-hoc to gated deployment

Example: an automotive ECUs team moved from monthly timing reviews to a CI-enforced policy in 6 weeks. They:

  1. Containerized their build and VectorCAST environment.
  2. Added a PR-level RocqStat quick check that focused on modified code paths.
  3. Implemented a baseline + 8% delta gate; anything larger opened a mandatory review ticket.
  4. Used nightly full analysis to update baselines and generate certification artifacts.

Result: a 60% reduction in late timing regressions and faster triage when regressions occurred.

Security and compliance

Protect your timing analysis assets and secrets:

  • Keep license servers within your network and restrict access via VPNs or private runners.
  • Encrypt artifacts at rest and in transit.
  • Use role-based access controls to limit who can modify thresholds or suppress gates.
  • Maintain immutable logs of run outputs for auditability.

Future predictions (2026 and beyond)

What to watch for as RocqStat becomes part of VectorCAST's ecosystem:

  • Tighter IDE and trace integration: expect more seamless linking of GCOV, VectorCAST test coverage, and RocqStat timing results inside unified reports.
  • Cloud HIL and virtualized hardware: cloud providers will expand deterministic HIL offerings, enabling large-scale timing regression farms; keep an eye on edge visual and observability tooling that helps onboard virtual HIL.
  • AI-assisted prioritization: ML will help prioritize which functions to analyze in-depth by predicting timing sensitivity from code and change history — early experiments appear in continual-learning tooling write-ups.
  • Greater regulatory focus: auditors will increasingly expect automated timing verification evidence as part of certification packages.

Step-by-step checklist to get started (actionable)

  1. Containerize your build and test environment (include VectorCAST & RocqStat versions).
  2. Wire up license access for your CI runners in a secure way (use identity and access best practices).
  3. Create a PR-level RocqStat quick-check job that runs against modified modules.
  4. Implement a baseline repository for WCET results and add a parsing script to gate on thresholds.
  5. Set up nightly full WCET runs and publish signed reports to your artifact store.
  6. Integrate results with your ticketing (Jira) and notification systems (Slack, MS Teams) and standardize on collaboration tooling.
  7. Document the flow and prepare certification artifacts for compliance teams.

Final recommendations

Start small: add a per-PR quick-check that fails fast and produces usable diagnostic output. Use nightly full runs to keep baselines fresh. Treat timing verification like any other test: version your toolchain, lock configurations, and make results discoverable and auditable. With VectorCAST and RocqStat integration becoming a standard, embedding WCET checks into CI is the pragmatic next step for teams building safe, reliable embedded software in 2026.

Call to action

Ready to eliminate timing surprises? Start by cloning our sample CI repo that demonstrates VectorCAST + RocqStat in GitHub Actions, complete with parsing scripts, baseline store, and gating examples. If you need help designing a rollout plan, contact your Vector representative or an embedded CI specialist to run a 2-week pilot that integrates WCET gates into your pipeline. For scaling and partitioning patterns see edge-sync and low-latency workflows.

Advertisement

Related Topics

#embedded#verification#CI/CD
a

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.

Advertisement
2026-02-05T00:18:09.917Z