vxedge Phase 3 · in progress
GitHub

Open source · agent-operable · software-defined vehicles

Experiment
with the vehicle
before it exists.

Software today. Hardware tomorrow. Same manifest.

vxedge is an open testbed where a software-defined vehicle is declared as code, run on one machine and measured. It is built for the engineers deciding what the next vehicle's architecture should be.

Pick an open problemHow it works →
A zonal vehicle, as vxedge provisions itPlan view of a car, front to the right. Four zone controllers, front-left, front-right, rear-left and rear-right, connect to one software gateway at the centre, which connects to central compute. Links from the front zones carry the ADAS safety slice; links from the rear zones carry the infotainment slice.front-leftfront-rightrear-leftrear-rightvxgatewaycentral-hpczone controllerscontainer · microVM · full VMone software gatewayOVS · tc · VXLAN · WireGuard · FRRcentral computeAutoware · ROS 2 · containersfront →ADAS · safety sliceinfotainment slice
A zonal vehicle as vxedge provisions it: four zone controllers and central compute joined through one software gateway, with safety and infotainment traffic on separate slices.

Why now

  1. 01

    Vehicles are becoming software. The architecture underneath — zones, networks, compute — is the decision that is hardest to undo.

  2. 02

    Those decisions are made on slides. They are proven years later on hardware rigs, when changing them costs the most.

  3. 03

    The reference results are closed. Industrial slicing trials publish numbers nobody outside can re-run. Engineering needs evidence it can check.

The approach

Three ideas.

  1. The vehicle is code.

    Zones, devices, links and slices live in one manifest. The same file runs as containers today, as full virtual machines with real guest operating systems, and on hardware when phase 4 lands.

    See the loop →

  2. Agents are teammates, not shortcuts.

    An agent gets the same API an engineer does, one tool per call, behind the same typed checks. It proposes experiments; models and manifests are validated before anything runs; changes to the bench will wait for a person.

    See how agents operate it →

  3. Evidence is the product.

    Every number ships with the manifest and digests that produced it, and a second campaign re-checks it. When an archive proved the first explanation wrong, that was published too.

    Read the evidence →

Proof

Four hypotheses measured. Four reproduced.

  • 0.91×

    ADAS tail latency under 1.2× infotainment overload, relative to idle. No packets lost.

  • −26.0 µs

    from one packaging decision. The obvious suspect did nothing; the archive found the real one.

  • 51.9 µs

    ADAS median during a sustained over-the-air update burst, against 52.2 µs without it.

See the evidence →

Where it's going

vxedge is not a digital twin yet. It is the model half of one.

  1. NowPhases 1–2 · done

    Slice isolation, ECU packaging and OTA co-location proven on real kernel networking and real 5G slices.

  2. NextPhase 3 · in progress

    A whole vehicle in software with one command. QNX and Android Automotive zones, Kuksa signals, agents that act.

  3. LaterPhase 4 · specified

    Hardware in the loop: Jetson, DRIVE, BlueField. The physical half joins the model half.

  4. HorizonNot started

    Today every manifest says class: road, subtype: car. Robotaxis, delivery robots and mobile robots come next.

  • Robotaxis
  • Delivery robots
  • Mobile robots

Open problems

Pick a hard one.

These are real, open and unclaimed. Each moves the testbed a rung closer to the real vehicle, and each is scoped so one strong engineer can own it.

  1. 1

    A whole vehicle with one command

    Make vxedge vehicle up boot every zone, the gateway and the services end to end. This is the phase-3 gate.

    vxedgeRust · Linux networking · libvirt
  2. 2

    Time-sensitive networking on the gateway

    Add an 802.1Qbv / Qav shaping mode with gPTP and measure it against today's queue-tree slices.

    vxedgeTSN · tc taprio · linuxptp
  3. 3

    Kernel-grade timestamps

    Replace userspace probing with SO_TIMESTAMPING, then re-run every hypothesis and report what moved.

    vxagentsRust · kernel networking
  4. 4

    QNX and Android Automotive zones

    Guest images that boot under the full-VM backend and honour the zone contract.

    vxpartsQNX SDP 8 · AAOS · KVM
  5. 5

    Closed-loop autonomy over a slice

    CARLA to ROS 2 to Autoware, with sensor streams carried as slice traffic, so control-loop latency becomes a metric.

    vxperimentsROS 2 · Autoware · GPU
  6. 6

    Agents that can act safely

    The confirmation flow that lets an MCP tool change the bench only after a person approves.

    vxmcpRust · MCP
  7. 7

    Signals like the real car

    A DBC-driven restbus feeding Eclipse Kuksa, so body ECUs speak COVESA VSS.

    vxpartsCAN · VSS · Kuksa
  8. 8

    Many vehicles at once

    The fleet layer: concurrent vehicles over one API, the groundwork for V2X.

    vxedgeRust · distributed systems
  9. 9

    A first hardware anchor

    Put one Jetson AGX in the loop and run the same experiment on both sides, so the parity ledger gets a measured calibration point instead of a label.

    vxedgeJetson · Linux networking · measurement

Start in three commands

Apache-2.0 code, CC BY 4.0 docs and results. DCO sign-off, no CLA. One workstation is enough for Tier 1.

Getting startedCollaborate →
$ git clone https://github.com/vxedge/vxedge
$ cd vxedge && cargo build --workspace
$ ./target/debug/vxedge doctor --tier 1