1 · The vCar
Instance…
Name…
State…
Containers…
Updated…
Refreshes every 2.5 s with GET /api/instance (this page shows only this vCar).
Starting and stopping the whole vCar is in the guide; the public page leaves it running.
2 · Its ECUs
| ECU | Container | Model | Diagnostics |
|---|---|---|---|
| loading… | |||
Tap an ECU to control it below. GET /api/instance/{id}/ecus
3 · One ECU: control, state and parameters
Stop leaves the ECU's container stopped (the vCar shows DEGRADED until you start it again). Restart puts every value back to the YAML value.
PATCH sends only the names you changed.
4 · Passenger Welcome
The driver's phone sends PW_Welcome (profile + seat position) → CentralHPC decides → it commands PW_SeatCmd (SeatECU) and PW_AmbientLightCmd (LightingControlECU). PW_DoorCmd asks DoorECU to open the door, which answers on PW_DoorStatus.
Passenger Welcome writes PW_Welcome.SeatPosTarget, then PW_Welcome.ProfileId (CentralHPC reacts to a new profile), then reads the answers. Back to rest writes profile 0, seat 0, door 0, proximity 0 and puts CentralHPC's profile back to 0.
Known on Alpha today: CentralHPC takes the welcome (its active_profile and commanded_light_level change), but its seat and light commands do not reach the bus yet, so PW_SeatCmd and PW_AmbientLightCmd stay 0. The door path works end to end.
5 · Signals on the bus
| Signal | Sender | Value | Write |
|---|
Read: GET /api/instance/{id}/signals/read?namespace=CentralHPC-BodyCAN&signal_name=…. Write (only signals no ECU sends): POST …/signals/restbus. Signals an ECU sends are changed through that ECU's state in section 3.
Request log
Every write this page made, newest first. The browser talks to this site; the site adds the API key and forwards to .