embeddedverificationCI/CD

How Acquiring RocqStat Strengthens Software Verification: Lessons for Embedded DevOps

UUnknown

2026-02-24

9 min read

Vector's 2026 RocqStat acquisition shows timing analysis must be part of embedded CI/CD. Practical steps to embed WCET, VectorCAST, and static tests into pipelines.

Hook: Your embedded CI/CD pipeline is only as safe as its timing analysis

Embeded systems teams face a familiar, growing pain in 2026: functional tests pass in CI, but on physical targets the system misses deadlines, triggering costly rework, recalls or certification delays. The recent acquisition of RocqStat by Vector—announced in January 2026—makes a strategic point: timing analysis and worst-case execution time (WCET) estimation must live inside embedded CI/CD, not on the sidelines.

Why Vector acquiring RocqStat matters for embedded DevOps

Vector Informatik's acquisition of StatInf's RocqStat and expert team (reported by Automotive World in January 2026) signals a consolidation trend: vendors are unifying static verification, dynamic testing and timing analysis into a single toolchain. Vector plans to integrate RocqStat into VectorCAST, creating a unified environment for timing analysis, WCET estimation, and code testing. For engineering and DevOps teams building safety-critical systems, that integration reduces friction and improves traceability between unit tests, integration tests and timing proofs.

Vector's move underscores a 2026 reality: timing safety is now a first-class requirement for software verification across automotive and other software-defined industries.

Modern challenges: why timing analysis must be continuous

By late 2025 and into 2026, embedded software stacks are more complex: multi-core ECUs, mixed-criticality execution, AUTOSAR Classic/Adaptive, and hardware that includes accelerators and ML inference paths. These factors multiply timing variability. Traditional approaches—ad-hoc WCET runs on a lab bench, or separate offline analysis—fail to scale with frequent code changes and aggressive CI/CD cadences.

Key risks teams face:

Undetected regressions in real-time behavior after refactor or compiler flag changes
Discrepancies between measurement-based timing and static WCET proofs
Poor traceability for certification artifacts required by ISO 26262, DO-178C or IEC 61508
Expensive on-target test runs without automated gating

How to treat timing analysis as part of embedded CI/CD: an actionable blueprint

Integrating RocqStat capabilities (or another WCET engine) into your CI/CD means both tooling and process changes. Below is a practical, staged blueprint you can apply now.

1) Define your verification contract

Start with clear acceptance gates that include timing constraints. For each critical function, record:

Requirement ID and safety level (e.g., ASIL-D)
Maximum allowed execution time (WCET threshold)
Target hardware configuration (CPU, caches, scheduler, RTOS)
Measurement or analysis method (static WCET, measurement, hybrid)

2) Make timing analysis reproducible and automated

Put the WCET analysis into the pipeline as a reproducible build step. Key elements:

Containerize the toolchain (compiler, VectorCAST, RocqStat) to lock versions
Store analysis configs in source control (analysis.json, wcet.yaml)
Produce machine-readable results (SARIF extension or JSON) to merge into CI reports

3) Use hybrid strategy: static WCET + targeted on-target runs

Static WCET tools give safe upper bounds; measurements catch platform-specific deviations. Run static RocqStat analysis on every merge, and trigger on-target runs for:

High-risk changes touching scheduler or low-level drivers
Pull requests that change compiler flags, linker scripts, or optimization levels
Nightly integration builds for full-system timing validation

4) Gate merges with timing-aware policies

Extend your CI gating to include WCET checks. Example policies:

Fail merge if static WCET > requirement threshold
Warn but allow when WCET delta is small and approved by owner
Require full on-target verification for changes that touch mixed-criticality boundaries

5) Store evidence and provenance for certification

Collect artifacts automatically: source revision, build logs, compiler flags, mapping between tests and requirements, static analysis outputs and WCET reports. Keep these in an immutable artifact store with reproducible manifests.

Pipeline integration examples: GitHub Actions & Jenkins

Below are templates showing how to invoke static analysis, unit tests, and a RocqStat WCET step in a CI pipeline. Adapt paths and CLI options for your tool versions.

GitHub Actions (simplified)

name: Embedded CI

on: [pull_request]

jobs:
  build-and-verify:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - name: Setup toolchain container
        run: docker run --rm -v ${{ github.workspace }}:/work -w /work myregistry/vec-toolchain:2026-01 \
              bash -lc "./scripts/build.sh"

      - name: Run static analysis (cppcheck + clang-tidy)
        run: docker run --rm -v ${{ github.workspace }}:/work -w /work myregistry/vec-toolchain:2026-01 \
              bash -lc "./scripts/run-static.sh --output=reports/static.json"

      - name: Run VectorCAST unit tests
        run: docker run --rm -v ${{ github.workspace }}:/work -w /work myregistry/vec-toolchain:2026-01 \
              bash -lc "vectorcast-cli --project project.vct -run --junit=reports/junit.xml"

      - name: Run RocqStat WCET analysis
        run: docker run --rm -v ${{ github.workspace }}:/work -w /work myregistry/vec-toolchain:2026-01 \
              bash -lc "rocqstat-cli analyze --project project.cfg --output reports/wcet.json"

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

Jenkinsfile (declarative)

pipeline {
  agent any
  stages {
    stage('Checkout') { steps { checkout scm } }
    stage('Build') { steps { sh './scripts/build.sh' } }
    stage('Static Analysis') { steps { sh './scripts/run-static.sh --output=reports/static.json' } }
    stage('Unit Tests') { steps { sh 'vectorcast-cli --project project.vct -run --junit=reports/junit.xml' } }
    stage('WCET Analysis') { steps { sh 'rocqstat-cli analyze --project project.cfg --output reports/wcet.json' } }
  }
  post {
    always { archiveArtifacts artifacts: 'reports/**', fingerprint: true }
  }
}

Infrastructure-as-Code and reproducible toolchains

Make your analysis environment IaC-managed. Example pieces:

Dockerfile for reproducible toolchain image (compiler, VectorCAST, RocqStat)
Terraform to provision on-target test runners (bare-metal or cloud-based device farm)
Configuration stored in Git alongside code to meet traceability

Sample Dockerfile (skeleton)

FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y build-essential python3 curl
# Install cross-compiler, VectorCAST, RocqStat (licensed installers or package)
COPY installers/ /opt/installers/
RUN /opt/installers/install-vectorcast.sh && /opt/installers/install-rocqstat.sh
WORKDIR /work
ENTRYPOINT ["/bin/bash"]

Sample Terraform snippet to register a runner

resource "aws_instance" "on_target_runner" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "c5.large"
  tags = { Name = "on-target-runner" }
  provisioner "remote-exec" {
    inline = ["sudo /opt/installers/setup-runner.sh"]
  }
}

Dealing with multicore, caches and modern hardware

By 2026 the hardest part of WCET is handling shared resources: caches, buses, and accelerators. Best practices:

Lock down hardware configuration for analysis: fixed core assignment, cache partitioning where possible
Use path-sensitive and composition-aware static analysis (RocqStat-style approaches) that model caches and pipelines
Cross-check static WCET against worst-case measurement harnesses designed to maximize interference
When absolute proofs are infeasible, use compositional verification and increase monitoring at runtime

Bridging static analysis and runtime observability

Verification is stronger when static results and runtime telemetry converge. Recommended integration points:

Export WCET results to a time-series DB (Prometheus/Grafana) for trend analysis
Correlate test failures or timing regressions with commit metadata to identify root cause quickly
Automate creation of new measurement scenarios when static analysis highlights a risky path

Prometheus exporter example (pseudo)

# after running rocqstat-cli, produce metrics
rocqstat-cli analyze --project p.cfg --output wcet.json
python3 scripts/wcet_to_prometheus.py --input wcet.json --prom-url http://prom:9091/metrics

Test selection, incremental WCET, and cost control

Full WCET runs are expensive. Use incremental strategies:

Run full WCET analysis nightly; run incremental WCET per-PR using changed-function set
Prioritize tests by risk: scheduler and I/O first, UI or logging later
Leverage differential analysis to only recompute affected call paths

These practices reduce cloud and hardware farm costs and accelerate feedback—key FinOps goals.

Traceability and compliance: generating certifiable evidence

For ISO 26262, DO-178C and other standards you must produce:

Requirement-to-test traceability
Tool qualification evidence for analysis tools
WCET reports and assumptions used
Immutable build artifacts and manifests

Automation helps here. Example of a traceability JSON record:

{
  "requirement_id": "REQ-1234",
  "commit": "abcde12345",
  "tests": ["test_init","test_scheduler_irq"],
  "wcet_report": "reports/wcet.json",
  "wcet_value_ms": 3.7,
  "tool_versions": {"vectorcast": "v11.2","rocqstat": "v2.0"}
}

Example: Real-world outcome—how a timing issue was caught early

Consider a Tier-1 supplier that embedded RocqStat into VectorCAST in a nightly pipeline. A compiler upgrade changed inlining heuristics and a background task suddenly increased its worst-case runtime by 40%. The static WCET analysis flagged the path immediately at merge time and prevented a regression from propagating to system integration where debugging and rework could have cost weeks of schedule slip. The result: a 35% reduction in verification cycle time and avoided rework cost estimated at >$200k (conservative, based on measured lab run rates).

Advanced strategies and 2026 trends

As we move through 2026 you'll see the following trends accelerate:

Toolchain consolidation: More vendors will embed timing engines into test suites (Vector+RocqStat is an early example).
Cloud-native on-target farms: Device-as-a-Service grows, enabling large-scale worst-case exploration without heavy local labs.
ML-assisted WCET: Machine learning helps prioritize path exploration and predict which code paths are likely to increase WCET.
Standardized timing artifacts: Expect SARIF-like extensions or new schemas for WCET and timing proofs to ease pipeline integration.

Checklist: Immediate steps your team can take (actionable)

Inventory critical tasks and record WCET thresholds per requirement.
Containerize your toolchain (compiler, VectorCAST, RocqStat) and commit configs to Git.
Integrate static WCET runs on every PR; gate or warn based on thresholds.
Establish nightly on-target measurement jobs for full-system timing validation.
Automate artifact collection: WCET reports, compiler flags, build manifest and test-to-requirement mapping.
Monitor timing trends in Grafana; alert on deviations beyond statistical baselines.
Plan tool qualification evidence generation for certification audits.

Final thoughts: what the RocqStat acquisition signals to engineering leaders

Vector's acquisition of RocqStat reflects how verification priorities are shifting in 2026: timing analysis and WCET are no longer an afterthought but a continuous verification requirement that must be integrated into the CI/CD toolchain. For teams building safety-critical embedded software, the practical takeaway is clear—invest in reproducible, automated timing analysis and tie those results directly into PR workflows and certification artifacts. The result is faster feedback, fewer production surprises, and stronger evidence for regulators and customers.

Call to action

Start by running a short pilot: containerize your toolchain, add a static WCET step to a single critical PR workflow, and collect results for one sprint. If you want a starter repo with templates (GitHub Actions, Jenkinsfile, Dockerfile and Terraform snippets) and a sample mapping between requirements and WCET artifacts, request the ControlCenter embedded verification starter pack. Our team can help you design an incremental rollout that reduces risk and supports certification needs.

References:

Automotive World, "Vector buys RocqStat to boost software verification", January 16, 2026: Automotive World

Unknown

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.