COOLJAPAN OÜ / OxiCAR
OxiCAR — autonomous driving simulation

A driving simulator that is not a game engine.

CARLA is Unreal Engine 4 with a Python API attached. OxiCAR is 628,269 lines of Rust in which the physics, the renderer, the middleware and the road format were written from the specifications. It runs headless, and it runs on a CPU.

27 crates 628,269 lines 15,204 / 15,205 tests 0 clippy warnings No Unreal, no Unity
Workspace gateoxicar · cargo nextest
ItemCountStatus
Unreal Engine0Absent
Unity0Absent
C++ physics engine0Absent
C++ DDS middleware0Absent
Clippy warnings, -D warnings0Clean
Tests passing0of 15,205
cargo nextest run --workspace on the evaluation source: 15,205 run, 15,204 passed, 6 skipped. The single non-pass is a work-stealing stress test that hits the 60-second slow-timeout under full parallel load, and passes in 0.07s in isolation. Clippy is run with --workspace --all-features --all-targets -- -D warnings. You do not have to take our word for any of it. Reproduce it yourself
Clause 01Landscape

Every open simulator is a game engine wearing a research hat.

That is not a criticism of the engines. It is an accounting of what you inherit when you build on one: a GPU requirement, a release cadence you do not control, an asset pipeline, and a licence written for shipping games.

SimulatorBuilt onCompositionHeadless on CPUV2X and middleware
CARLAUnreal Engine 4C++ and Python over the engineGPU expectedExternal ROS bridge
AirSimUnreal Engine 4 / UnityC++ and Python over the engineGPU expectedCustom RPC
OxiCARNothing. Written here.628,269 lines of Rust, 27 cratesYes — the default pathDDSI-RTPS, C-V2X and IEEE 1609.2 in-workspace

The interesting consequence is not speed, and we make no speed claim — no benchmark against CARLA or SUMO exists. It is that a scenario run is a Rust function call rather than a frame the engine decided to render, and that a research group without a GPU budget can run one.

Clause 02Fidelity

The sensor models are the product.

A simulator that renders a nice picture and returns a perfect point cloud is a rendering demo. These are the models a perception team actually argues with.

LiDAR and event camera
  • Multi-echo waveform returns
  • Mie forward-scatter weather attenuation
  • Polarimetric Stokes and Mueller propagation
  • 905nm versus 1550nm eye-safety budgets
  • DVS event camera with a bandwidth-saturation model
Radar and navigation
  • FMCW range-Doppler processing
  • The CFAR family, with ROC reports
  • Leeson phase-noise model
  • ITU-R P.838 rain attenuation
  • IMU and GPS with LAMBDA integer-ambiguity resolution
Standards, written from the documents
  • OpenDRIVE · OpenSCENARIO 1.x XML and the 2.0 DSL
  • Lanelet2, with a bidirectional converter · MCAP
  • OMG DDSI-RTPS · ROS 2 REP-2003 lifecycle nodes
  • OSI · ETSI ITS-G5 · IEEE 802.11p · C-V2X Mode 4 · IEEE 1609.2-2022
  • SAE J3016 ODD · SHRP2 / euroFOT metrics
Clause 03Status

What is wired, what is in the tree but not wired, and what does not exist.

A simulator is easy to demo and hard to trust. The distinction below is between code that runs in the default pipeline, code that exists and compiles but nothing calls, and work that has not been done.

LiDAR default scan path — CPU box-level ray/AABBImplemented
LiDAR wgpu compute path and CPU BVH pathIn tree, not wired
Renderer — CPU PBR with tonemap, SSAO and GTAOPrimary path
Renderer — real wgpu offscreen GPU pipeline with texture readbackFlat and unlit only
V2X message signing — ECDSA-P256-SHA256, RFC 6979 noncesReal cryptography
V2X SCMS credential and PKI simulationBoolean flag. Not production-grade.
oxicar-air — eVTOL vertiport and corridor APIStub-grade
oxicar-il — imitation learningData layer only. No neural-net training.
Hardware-in-the-loop, SIL cluster, distributed multi-host, digital twinNot built
Benchmark against CARLA or SUMODoes not exist

Read the SCMS row twice if V2X security is why you are here. The P-256 signing and batch verification are genuine elliptic-curve cryptography against the IEEE 1609.2-2022 envelope. The credential-management layer above them models certificate validity as a boolean with no chain and no signature check. Do not use it for anything resembling real vehicle-to-everything security. The repository says the same thing in the same words.

Clause 04Fit

Who this is actually for.

Research without a GPU budget
  • AV and ADAS groups running perception, planning and fusion workloads
  • Headless CPU execution as the default, not a fallback
  • One cargo build, no engine install, no asset pipeline
  • Runs on a laptop and in a cluster job
Autoware and V2X integrators
  • From-scratch OMG DDSI-RTPS: StatefulWriter, StatefulReader, ACKNACK bitmaps, SEDP discovery
  • REP-2003 lifecycle nodes with ordered bring-up and rollback
  • Autoware-shaped topics
  • Full C-V2X and DSRC stack: CAM, DENM, SPAT, sidelink
Homologation and safety argument
  • oxicar-vnv: LTL and MTL runtime monitors
  • Shalev-Shwartz RSS safety envelopes
  • ASIL-weighted coverage scoring
  • SAE J3016 ODD, Wood, geometric and Riedmaier coverage models
Clause 05Provenance

Nine years removing C. Then we had to write the simulator itself.

The other products in this ecosystem close this page with a stack tree — a numerics floor we rebuilt before we built on it. A simulator does not work that way. CARLA's C++ is not a dependency you can swap out: CARLA is Unreal Engine, with a research API attached. There is no layer underneath to replace. The engine is the product.

So the work was different, and larger. The rigid-body physics is ours. The renderer is ours. The DDSI-RTPS implementation that ROS 2 talks to is ours, written from the OMG specification rather than linked against Fast DDS or Cyclone. The OpenDRIVE parser, the OpenSCENARIO 1.x reader and the 2.0 DSL, the Lanelet2 converter, the MCAP writer, the IEEE 1609.2 security envelope — all of it written here, from the documents, in Rust.

OxiCAR 27 crates · 628,269 lines of Rust ├─ physics · renderer written here — no engine wrapped ├─ DDSI-RTPS · REP-2003 written here — from the OMG and ROS 2 specs ├─ OpenDRIVE · OpenSCENARIO · Lanelet2 written here — from the ASAM documents ├─ LiDAR · radar · DVS · IMU/GPS written here — from the sensor physics └─ reused from the ecosystem ├─ OxiFFT radar range-Doppler, camera, IMU, V2X ├─ OxiZ SMT — scenario and envelope checking └─ OxiArc · OxiSQL · oxicode recording and replay └─ Rust standard library. Nothing further down.

Writing it instead of wrapping it is the entire case. A simulator built on a game engine inherits that engine's release cadence, its licence, its GPU assumption and its idea of what a frame is — and inherits them permanently, because you cannot refactor them out. This one inherits none of it. That is why it runs headless on a laptop, why the scan path is deterministic enough to argue about, and why every number it produces comes out of code you have a licence to read.

Most of the ecosystem is public on GitHub under Apache-2.0. The simulator is the part we licence.

Clause 06Next

Three ways in.

Evaluation

Source access for research and academic use. Tell us the sensor suite and the scenario set; you get the workspace and the limitations section above, in more detail.

Commercial licence

Source or integration licence for a product line. Priced per year, no royalty on your vehicles, no per-seat runtime fee, no audit clause.

Programme partnership

Homologation toolchains, ODD and RSS evidence work, or a national AV programme, including exclusive rights within a territory. This is the one that needs a conversation.