Orders are for planned movement. But a fleet also needs to react now — pause a vehicle, cancel an order, start charging. That's the instantActions topic. And because all of this runs over a network, the standard also needs a way to answer the hardest question in distributed systems: is the other side still there?
The instantActions topic
Instant actions are immediate commands that bypass the order queue. The standard defines eight:
| Action | Purpose | blockingType |
|---|---|---|
startPause |
Hold the vehicle | HARD |
stopPause |
Resume after a hold | HARD |
cancelOrder |
Abort the current order | HARD |
startCharging |
Begin charging at a station | HARD |
stopCharging |
Release from the charger | HARD |
initPosition |
Set the initial pose | HARD |
stateRequest |
Force an immediate state message | NONE |
factsheetRequest |
Request a factsheet publication | NONE |
The blockingType field tells the vehicle how the action interacts with the current order:
| blockingType | Meaning |
|---|---|
NONE |
May run while the vehicle drives; doesn't affect the order |
SOFT |
Driving pauses while the action runs, then resumes |
HARD |
The vehicle must stand still and other actions pause; driving resumes when the action finishes |
cancelOrder stops the vehicle, deletes the order, and cancels pending actions — but note that the deletion is cancelOrder's own semantics, not a property of HARD. A HARD action merely holds the vehicle still while it runs; the order survives it. After a cancel there is no "resume"; the master re-plans from scratch.
The actionStates lifecycle
Every action the vehicle receives is tracked in state.actionStates, keyed by actionId:
WAITING → INITIALIZING → RUNNING → FINISHED
└──→ FAILED
The master correlates each action it sent with its reported status. An action that reaches FAILED is a signal to the master that something went wrong vehicle-side — not a silent no-op.
The connection topic and the last-will pattern
The connection topic carries a single enum: ONLINE, OFFLINE, or CONNECTIONBROKEN. The clever part is how CONNECTIONBROKEN gets published.
When a vehicle connects to the MQTT broker, it registers a last-will message — a message the broker will publish automatically if the vehicle disconnects unexpectedly. The sequence is:
- Vehicle connects, registers last-will =
CONNECTIONBROKEN - Vehicle publishes
ONLINE(retained) - On graceful shutdown, vehicle publishes
OFFLINE, then disconnects - On unexpected disconnect, the broker publishes
CONNECTIONBROKEN
The broker is the trusted third party. A vehicle that loses power or crashes can't publish anything — but the broker notices the dropped connection and publishes the last-will on its behalf. The fleet manager learns about a dead vehicle even when that vehicle can't say a word.
Controlled stop on supervision loss
A sound implementation gives the connection watchdog a specific consequence on the vehicle side (the standard leaves loss behavior to the vehicle's safety concept — this is the behavior our fleet implements). When a vehicle loses broker connectivity, it doesn't just keep driving blindly. It performs a controlled stop — normal deceleration, order data preserved — and resumes only when supervision returns.
This is the crucial safety framing: connection loss is degraded mode, not a safety event. The actual safety functions (e-stop, protective stop, STO) live on the vehicle's onboard safety controller and the safety PLC — never on MQTT. The connection watchdog is about process integrity, not safety integrity. The two are deliberately kept separate.
Why this matters
A fleet that can't distinguish "vehicle is idle" from "vehicle is gone" is a fleet that will eventually send an order into a void. The connection watchdog closes that gap. And a fleet that can't react instantly — pause, cancel, stop charging — is a fleet that can't respond to a changing floor.
Next: Fleet Integration, Traffic & Deadlock — how it all comes together in a working fleet, and how VDA 5050 compares to MassRobotics.