Why a stop needs a cause

Every fleet management system on the market can tell you that robot 12 stopped at 14:03. Most can tell you it stopped in zone A3, and the better ones will tell you the code the vendor’s controller emitted while it happened.

None of that is a cause. It is a symptom with a timestamp.

The gap between an event and an explanation

A stop is the end of a chain, and the chain usually starts somewhere the robot cannot see. A pallet was placed 4cm proud of its footprint. A WMS order arrived for a location that a second system had already reserved. A sensor drifted far enough that two vehicles disagreed about where the aisle was.

Read the robot’s own log and every one of those looks identical:

14:03:11  AGV-12  state=BLOCKED  reason=OBSTACLE_DETECTED
14:03:11  AGV-12  zone=A3        recovery=MANUAL

OBSTACLE_DETECTED is true in all four cases and useful in none of them. It describes the moment the robot gave up, not the decision, ten minutes earlier and two systems away, that made giving up inevitable.

What it costs to guess

When the cause is missing, the floor fills the gap with the cheapest available explanation, and the cheapest explanation is almost always “the robot did something odd again”. That has three effects, and they compound:

1. The same stop recurs. Nothing was fixed, because nothing was identified.
2. Trust erodes. Operators route around the automation rather than through it, which is exactly the throughput the business bought.
3. Escalation goes to the wrong party. The integrator gets a ticket about a robot when the fix belongs in a WMS rule.

A stop you cannot explain is not one incident. It is a subscription to that incident.

Explanation is an integration problem

The reason the cause is missing is rarely that nobody logged it. It is that the pieces are logged in four places, by four vendors, in four shapes, and no one owns the join.

That is why the answer is a layer rather than a feature. To say why robot 12 stopped, something has to hold, at the same moment in time:

• the robot’s own state and telemetry,
• the order it was executing and where that order came from,
• the traffic decisions made around it,
• and whatever the sensors and the WMS believed about that spot.

Hold those together and the answer stops being a guess. Hold them for three months and the recurring causes rank themselves — which is when a stop stops being an incident and becomes a fix with an owner.

---

This is a placeholder post used while the blog is being built. The argument is real; the examples are illustrative.