An order in VDA 5050 is not a single "go here" command. It's a structured route — a sequence of nodes and edges — that a vehicle executes incrementally, reporting progress back to the master at every step.
The base/horizon distinction is the single most important concept in the standard. It's what lets a fleet manager hand a vehicle a long route while only ever authorizing it to drive a short, safe prefix.
The anatomy of an order
An order carries three identity fields plus the route itself:
| Field | Meaning |
|---|---|
orderId |
The transport order's identity, assigned by the master |
orderUpdateId |
A counter that increments each time the order is extended |
nodes |
Waypoints, each with nodeId, sequenceId, released, actions |
edges |
Connections between nodes, each with edgeId, sequenceId, released |
The sequenceId runs continuously across both nodes and edges, so a vehicle always knows its exact position in the route. The released flag on each element is the heart of the design.
Base vs horizon: the released flag
Every node and edge carries a released boolean:
released = true → base → drive this now
released = false → horizon → plan only, do not drive
A fleet manager sends an order where only the first few nodes are released: true — the base — and the rest are released: false — the horizon. The vehicle drives the base and stops at its end. When the master wants the vehicle to continue, it sends an order update with orderUpdateId + 1 and releases more of the route.
This is how traffic control works at the protocol level. The master never lets a vehicle drive into floor it hasn't cleared. It extends the base only when the corridor ahead is free.
The order acceptance procedure
A vehicle doesn't blindly accept every order. It validates first:
- Check
orderIdandorderUpdateId— is this a new order or an update to the current one? - Validate the route — are the nodes and edges well-formed?
- Accept or reject, and report the decision in
state
A rejected order is a normal, recoverable event — the master logs it, fixes the order, and re-issues. The vehicle never half-executes a malformed order.
Reporting progress: nodeStates and edgeStates
As the vehicle drives, it reports progress through two arrays in state:
| Field | Meaning |
|---|---|
lastNodeId |
The most recently reached node |
nodeStates |
The remaining nodes, with their released flags |
edgeStates |
The remaining edges, with their released flags |
driving |
Whether the vehicle is currently moving |
newBaseRequest |
The vehicle is near the end of its base and wants more |
The newBaseRequest flag is the vehicle's way of saying "I'm about to run out of base — extend me or I'll stop." It's a pull signal that complements the master's push of order updates.
Why the state machine matters
The order lifecycle is a state machine, and like any good state machine, every transition is observable. The master can reconstruct exactly where a vehicle is and what it's doing from state alone — no timers, no dead reckoning, no guessing.
A vehicle that reports lastNodeId and an empty nodeStates is idle. A vehicle that reports lastNodeId and a non-empty nodeStates is still executing. Note that orderId never clears — an arrived vehicle reports its last order's id forever, so idle is orderId present AND nodeStates empty, never orderId alone. The distinction is what lets a fleet manager correctly decide which vehicles are free to take new work — a subtlety that trips up naive implementations.
Next: Instant Actions & Connection Watchdog — the immediate commands and the heartbeat that turns a network drop into a safe, defined state.