vxedge Phase 3 · in progress

Deep dive

How it works

The machinery behind the story, for engineers who want to check it. Each section links to the code, the manifests or the archives behind it.

01Use cases

Eight jobs a vehicle platform team already has.

Each one is labelled for what it is today: measured with frozen results, live, partly built, or only specified. Nothing is shown as working that is not.

  • 01Measured

    Slice isolation

    Does safety traffic survive infotainment overload?

    Map ADAS, infotainment and OTA onto VLANs or real 5G slices (Open5GS, UERANSIM) with per-slice queue reservations, then sweep the load. ADAS p99 stayed at 0.91× idle on VLANs and 0.95× on 5G S-NSSAI slices, with no loss.

  • 02Measured

    Zonal topology studies

    How many zones, and what does the harness cost?

    Declare zones, links and harness properties (medium, length, rate, delay, jitter, loss) and compare a star against daisy-chained zones. The expected hop-count effect holds. Zone boot latency is characterised too: first-packet delay confirmed in 20 of 20 runs.

  • 03Measured

    ECU packaging and fidelity

    Container, microVM or full VM, and what does it cost?

    Run the same node under three isolation backends with identical network attachment. The virtio transport alone moves p50 by −26.0 µs; machine type moves it −0.3 µs, within noise. QNX and Android Automotive guests are the next rung.

  • 04Measured

    OTA beside safety workloads

    Can an update campaign run next to ADAS traffic?

    Signed, content-addressed delivery with Uptane-style metadata, in sustained 5 MB bursts next to the ADAS probe. Today this measures host-level contention; slice-enforced delivery over WireGuard is the next step.

  • 05Building

    Agent-operated experiments

    Can an agent run the loop without breaking the bench?

    vxmcp exposes the control plane to agent tooling, one tool per RPC. Models become manifests through two typed gates. Read tools work today; tools that change state wait on a confirmation flow that is not built yet.

  • 06Planned

    Autonomy closed loop

    What does the AD stack do when the network misbehaves?

    CARLA to ROS 2 to Autoware, with camera and lidar streams carried as slice traffic, so control-loop latency under contention becomes a first-class metric. Needs a GPU host.

  • 07Building

    Signals and diagnostics

    Does the signal plane behave like the real one?

    Eclipse Kuksa with COVESA VSS, a DBC-driven restbus for body ECUs, UDS/DoIP diagnostics. The Kuksa and signal-plane parts have landed in the registry; restbus and UDS are specified.

  • 08Live

    Reproduce anything

    Can someone else get my number?

    Every archive records the manifest hash, image digests, tool versions and run environment. A second campaign rechecks each verdict. When exp-003's rerun moved absolute latency outside the first run's spread, that was reported, not buried.

Next on the benchTSN gateway: HTB vs 802.1QbvKernel timestamps (SO_TIMESTAMPING)QNX SDP 8 and Android Automotive zonesFleet layer: many vehicles at onceHardware in the loop

02The loop

Declare. Run. Prove.

Everything is a manifest. The same files that define a vehicle define the experiment, and the run writes its own proof.

  1. 01 · DECLARE

    Describe the vehicle and the question

    Zones, nodes, links and slices in YAML, optionally generated from a SysML v2 model. The manifest is the only source of truth; there is no database.

    vxperiments/experiments/exp-001-ws/main.yaml
    kind: experiment
    id: exp-001
    network:
      slices:
        - id: adas
          mode: vlan       # s-nssai: real 5G
          vlan: 101
          qos: { min_rate_mbps: 100,
                 max_rate_mbps: 200, priority: 1 }
        - id: infotainment
          vlan: 103
          qos: { max_rate_mbps: 400, priority: 5 }
    method: { duration_s: 60, repetitions: 5 }
  2. 02 · RUN

    Provision a virtual vehicle, idempotently

    A Rust control plane converges the host to the manifest: gateway, zones as containers, microVMs or full VMs, a 5G core, services and probes. Running it twice is a no-op.

    terminal
    # validate everything first
    $ vxedge experiment validate
    $ vxedge doctor --tier 1
    
    # provision, then drive load
    $ vxedge experiment up
    $ vxedge traffic up --manifest exp-001
    
    # or the whole campaign, ~35 min
    $ sudo -E ./scripts/run.sh --repro
  3. 03 · PROVE

    Every run archives its own evidence

    Raw scrapes, structured samples, run environment, the manifest's SHA-256 and image digests. Analysis reads archives only, so anyone can regenerate the figure.

    excerpt of exp-001-summary.md
    | load | p99 µs (IQR) | loss % |
    |    0 |  89.6 (6.4)   |  0.0   |
    |  600 |  81.9 (5.0)   |  0.0   |
    
    adas p99 at max load: 81.9 µs
      = 0.91× baseline (threshold 2.0×)
    H1 HOLDS

Engineers and agents drive this loop through the same API. Neither gets a shortcut around the checks.

03Parity

Every part says how real it is.

A twin is only as good as its least faithful part. vxedge keeps a ledger: for each part, what runs today, how close it is to production, and what closes the gap. Nothing is shown as hardware that is not.

  • RealThe production software or Linux kernel path itself.
  • EmulatedReal operating system or software on modelled hardware.
  • PlannedSpecified in the architecture, not built yet.
  • CaveatWorks, with a stated limit on what it can tell you.
PartTodayStateCloses with
Network pathLinux kernel: OVS or bridge, tc HTB per slice, VXLAN, WireGuardRealBlueField offload · p4
5G coreOpen5GS with real S-NSSAI PDU sessionsReal—
5G radioUERANSIM gNB and UE in softwareEmulatedAerial RAN · p4
Zone ECUsReal guest OS under container, microVM or KVMEmulatedQNX SDP 8 · p3
HarnessPer-link rate, delay, jitter, loss; 100BASE-T1 length and weightEmulatedTSN 802.1Qbv · p3
MCU firmwareUnmodified firmware on register-level modelsPlannedRenode · p3
SensorsWorld streams carried as slice trafficPlannedCARLA · p3
Central computeAutoware and ROS 2 in containersPlannedDRIVE AGX · p4
TimingUserspace timestamps on a shared hostCaveatKernel timestamps · open

p3, p4: the phase that closes the gap. Every row is registered in FACTS.md, the public form of the per-part fidelity ledger the spec plans for track M.

04Retarget

Same question, another vehicle.

A vehicle is a manifest, and an experiment names its vehicle by id. Point the same loop at a different architecture, and validation checks that every slice and device it needs exists before anything runs.

Vehicle Xvx-h1-vehicle
Vehicle X, vx-h1-vehicle: two zones, front-left running the ADAS probe and rear-left running the infotainment load, each on its own slice to the gateway.front-rightrear-rightfront-leftadas-proberear-leftinfot-loadvxgateway2 zones · 2 devices · 2 slices
exp-001 · slice isolation under overload
main.yaml
# the experiment manifest
vehicles: [vx-h1-vehicle]
vehicles: [vx-h-harness-vehicle]

$ vxedge experiment validate
Vehicle Yvx-h-harness-vehicle
Vehicle Y, vx-h-harness-vehicle: three zones wired twice, as a star with a direct segment from each zone to the gateway, and as a daisy chain front-left to front-right to rear-left, over 100BASE-T1.rear-rightfront-leftstar · chainfront-rightstar · chainrear-leftstar · chainvxgateway3 zones · 6 devices · star vs daisy chain · 100BASE-T1
exp-014 · star vs daisy-chain harness
Live retarget and validatePlanned two vehicles at once (fleet layer)

Both vehicles are real manifests in vxperiments: exp-001 runs on X, exp-014 on Y. The diff is the one line that binds an experiment to its vehicle.

05Agentic by design

Agents propose. Typed gates decide.

Every frontend is a thin client over one API. An LLM agent gets the guarantees an engineer gets, and no extra reach. The risk is in sequencing, so that stays with the caller and behind gates.

How a generated experiment reaches the bench

  1. ProposeAn engineer or an agent writes a SysML v2 model of the vehicle and the question.
    Live
  2. Type-check the modelGate 1: the model must be well-typed against the requirement and structure library.
    Live
  3. Validate the manifestGate 2: vxedge manifest validate --json, the same checks up runs.
    Live
  4. ConfirmA multi-round-trip confirmation before any tool that changes state. A person approves.
    Planned
  5. RunIdempotent up, progress streamed as a job, every action audited.
    Live
  6. ArchiveEvidence written with digests, readable by any frontend.
    Live

vxmcp tool surface (MCP spec 2026-07-28)

ToolWrapsState
experiment_statusExperimentServiceLive
zone / compute listZoneService · ComputeServicePlanned
job watch · eventsJobService · EventServicePlanned
results summaryresults archivePlanned
up · down · traffic upbehind confirmationPlanned

Guardrails

  • One tool, one RPCSequencing and judgment calls belong to the agent, never to the server.
  • Typed before it runsModel typing, then manifest validation. The safety argument is structural.
  • Audit, not trustJobs stream progress and an audit log records what happened, in order.

06Under the hood

Real kernel networking and real guests, not a model of them.

vxAPI · gRPC / Protobuf (vxedge.v1) · vxedged · jobs · events · auditCLI · vxmcp · GUI (planned)

Control plane

  • Rust · tonic
  • idempotent reconciler
  • no database
  • Unix socket · mTLS + OIDC remote

Network

  • OVS or Linux bridge
  • tc HTB per slice
  • VXLAN · WireGuard · FRR
  • Open5GS + UERANSIM

Nodes

  • container · microVM · libvirt
  • QNX · Zephyr · FreeRTOS · AAOS
  • Autoware · ROS 2
  • Kuksa · COVESA VSS

Evidence

  • vxprobe · vxtraffic agents
  • Prometheus · PCAP
  • SHA-256 manifests · digests
  • results archives