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 →
Engineers and agents reaching one vehicle through four frontends on one vxAPIThree OEM engineers and an agent reach one vehicle through four frontends: the vxedge CLI, the vxmcp MCP server, an API and SDK path, and a web dashboard. A network architect uses the CLI, a safety engineer works through an agent that speaks MCP to vxmcp, and an ECU software engineer uses the web dashboard. All four call the same vxAPI of vxedged, which provisions the zonal vehicle: one software gateway, four zone controllers and central compute.vxAPIgRPC · Protobuffront-leftplannedfront-rightplannedrear-leftemulatedrear-rightemulatedvxgatewayrealcentral-hpcplannedvxedge CLIrealvxmcpbuildingAPI · SDKbuildingweb dashboardplannedsame vxAPIvxedgedcontrol planenetworkarchitectECU softwareengineersafetyengineeragentbuildingMCPADAS safety sliceinfotainment sliceMCPvxAPI callplanned or buildingEngineers and agents reaching one vehicle through four frontends on one vxAPIThree OEM engineers and an agent reach one vehicle through four frontends: the vxedge CLI, the vxmcp MCP server, an API and SDK path, and a web dashboard. A network architect uses the CLI, a safety engineer works through an agent that speaks MCP to vxmcp, and an ECU software engineer uses the web dashboard. All four call the same vxAPI of vxedged, which provisions the zonal vehicle: one software gateway, four zone controllers and central compute.vxedge CLIrealvxmcpbuildingAPI · SDKbuildingweb dashboardplannedsame vxAPInetworkarchitectsafetyengineerECU softwareengineeragentbuildingMCPscripts · CIgRPC · Protobufvxedgedcontrol planefront-leftplannedfront-rightplannedrear-leftemulatedrear-rightemulatedvxgatewayrealcentral-hpcplannedADAS safety sliceinfotainment sliceMCPvxAPI callplanned or building
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. Where it is going: engineers and their agents reach one vxAPI through the command line, an MCP server, an API and SDK path, and a web dashboard, so all of them share one manifest and one archive of results. Dashed parts are planned or building.

Why now

  1. 01

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

  2. 02

    Early decisions rest on paper models. They are often confirmed years later on hardware rigs, when changing them costs the most.

  3. 03

    Published results are hard to re-run. Slicing results rarely ship the manifests and digests needed to repeat them. Engineering needs evidence it can check.

The approach

Three principles.

  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 use the same API as engineers.

    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. Every result carries its evidence.

    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 on the same host.

  • 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 measured on real kernel networking and 5G core slices with a simulated radio.

  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

Open problems

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. The code repository opens after the docs; Getting started walks the same steps today.

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