// 001 — Certification & validation
SimCloud is built to the credibility requirements of UN R171 Annex 5, EU 2022/1426 Annex III Part 4, and the Euro NCAP virtual-testing protocols.
This page states exactly what the platform does today, what is being built, and what is sequenced but not started — using three status verbs and nothing stronger. Where we have numbers, the numbers are here. Where a limitation is known, it is named.
// 002 — The landscape
Four regimes decide whether simulated evidence is worth anything. None of them asks for a badge; all of them ask for traceable, correlated, reproducible work.
Binding vehicle regulation
Virtual testing counts only against a validated toolchain: R157 defines that validation as correlation of the simulated outcome with physical tests, and R171 makes an Annex 5 credibility assessment mandatory the moment simulation is used at all.
The credibility assessment, written in shall
Every toolchain version used to release data must be stored, every generated datum must be traceable to the version that produced it, and stochastic models must be characterised in terms of their variance with deterministic re-execution possible.
Acceptance is a number
Correlation is scored, not asserted: ISO/TS 18571 methodology on longitudinal acceleration against a stated threshold, with a minimum share of each verification cluster required to pass.
The vocabulary an assessor expects
OpenSCENARIO XML and OpenDRIVE for scenario and road interchange, ISO 34503 for the operational design domain, ISO/TS 18571 for correlation scoring, ISO 26262-8 §11 for confidence in the tools themselves.
// 003 — Seeing it
Short captures from the product, self-hosted and uncut. Slots without a capture yet say so rather than showing something else.
Placing actors on the twin, driving them through timed points with ambient traffic around them, and watching the result in the 3D viewport — before anything is sent to a render worker.
The same scenario executed in CARLA, with the trajectory overlay and the lateness and arrival diagnostics visible side by side against the browser preview.
Feasibility warnings firing on an edit the vehicle could not physically execute — the editor refuses to pretend a schedule is achievable when the calibrated model says it is not.
A run manifest opened next to the conformance report for the scenario that produced it: image digest, map hash, constants version, seed, and the checker output.
// 004 — Standards & alignment
Three verbs, used strictly. “Available today” means shipped and demonstrable on request. “In progress” means the work exists on a branch or is scheduled this quarter. “On our roadmap” means researched and sequenced, not started.
| Standard / regulation | What it requires | Our status | How we know |
|---|---|---|---|
| ASAM OpenSCENARIO XML | Scenarios exchangeable in the format assessors, test houses, and protocol suites read. | Available today | Native export: scenarios authored in SimCloud leave the platform as OpenSCENARIO XML. Sample export on request. |
| ASAM OpenDRIVE | Road networks described in a standard exchange format rather than a private one. | Available today | Native map ingestion: our digital twins carry an OpenDRIVE road network, and scenarios are authored against its lanes and junctions. |
| ASAM Quality Checker conformance | Machine-checked conformance of exported scenarios and ingested road networks, not a claim of correctness. | In progress | The ASAM qc-framework is being wired into CI so every export and every ingested network produces a conformance report artifact. |
| Sim-to-real correlation, ISO/TS 18571 methodology | Quantified correlation between simulated and physically measured behaviour, scored by a published method. | In progress | Calibration against purpose-recorded runs is in the platform today; ISO/TS 18571 scoring is being implemented against the openvt.eu reference implementation and packaged as a versioned dossier. |
| Run provenance and release traceability | Every released datum traceable to the toolchain version that generated it (EU 2022/1426 Annex III Part 4, §3.2.3.1). | In progress | Digest-pinned worker images, conformance manifests, and a release ledger already exist operationally; per-run manifests are formalising them into a one-click export. |
| UN R171 Annex 5 / EU 2022/1426 Part 4 credibility principles | A versioned simulation handbook per toolchain release: toolchain description, assumptions, fidelity evidence, known limitations, stochastic-model policy. | On our roadmap | The platform is designed to these principles today — deterministic execution, versioned constants tables, limitations recorded with the work. The generated handbook that packages them per release is sequenced, not started. |
| ISO 34503 operational design domain and coverage | The ODD described in a standard structure, with covered and uncovered parameter space accounted against it. | On our roadmap | Researched and sequenced: ODD descriptions attached to datasets and campaigns, coverage as parameter-space accounting over that ODD. |
| ISO 26262-8 §11 confidence in the use of software tools | Evidence that a tool used in a safety lifecycle cannot introduce an undetected error into the work product — a tool confidence level determination. | On our roadmap | Sequenced behind customer pull. We hold no tool confidence assessment today and do not imply one. |
We name no certification we do not hold. The status column is updated with each platform release.
// 005 — Measured, not asserted
Three pieces of evidence from the engineering practice behind the platform. Each one is a measurement we can show you, and each one travels with what it does not yet cover.
Calibrated against recorded runs
Fitting a gear ladder from purpose-recorded launch traces — rather than assuming one — moved the modelled peak launch acceleration of the Lincoln from 3.17 m/s² to 7.84 m/s², against 7.89 m/s² on the recorded trace. Every speed band improved or held, and above 14 m/s nothing moved by more than 0.03 m/s².
Named residual: the ambulance peak is still under-predicted. It is a shape error, not a scale error, and it needs more emergency-class traces rather than more parameters.
How we know thisCross-language parity gates
The browser preview engine and the CARLA worker are two implementations of the same decision layer in two languages. They are pinned to each other by shared golden vector tables generated from the worker and checked on both sides in continuous integration — decision by decision, tick by tick. A divergence fails the build rather than surfacing as a mysterious difference in someone's results.
Preview and full simulation are still different fidelities, and we treat the preview as an authoring aid, not as evidence.
How we know thisLimitations published, not buried
Calibration work in this platform lands with its known-limitations table attached: vehicle coverage, launch-regime residuals, and the measured differences between the browser preview and a full simulation run. The honesty is not a disclaimer at the bottom of a page — it is the same artifact the engineering work is graded against.
If a claim on this page does not survive your reading of it, tell us and we will change the page.
How we know this// 006 — Deterministic & reproducible
EU 2022/1426 Annex III Part 4 §3.2.6.4 requires that stochastic models be characterised in terms of their variance and that deterministic re-execution be possible. Meeting a shall by construction is worth saying plainly.
// 007 — Talk to us
The correlation dossier collects the calibration work, the parity gates, and the known-limitations table in one versioned document. Ask for it and we will send the current revision, including what it does not cover.
We answer diligence questions in writing.
SimForge · Building #159, 1301 South 46th St, Richmond, CA 94804 USA