Road to ETX · Part 4 of 5
A vehicle that stops for thirty minutes can create far more than thirty minutes of work. Part 4 of 5 follows one interrupted delivery through dispatch, service and customer communication, and asks what it would take for an exception to carry its own context.
By Secu-Tech
Early one morning, a loaded vehicle arrives at a customer but cannot begin the delivery.
Within ten minutes, the driver calls dispatch. Within twenty minutes, the next delivery window is already at risk. Service joins the conversation. Customer support prepares an explanation. A second vehicle may need to be rerouted.
The original interruption still sits at one vehicle, but its cost has started to travel.
This is the organisational ripple of an unexplained stop. It moves from the driver to the people who replan, diagnose and communicate. Each function spends time on the same event from a different position, often with different information.
The vehicle may be stationary. The business is not.
A stop is a chain of decisions
Every interruption requires decisions:
- Can the delivery continue safely?
- Is the cause local, procedural or technical?
- Can service resolve it remotely?
- Does the customer need a new delivery window?
- Which later stops must be moved?
- Does the event indicate a recurring issue?
Those decisions become slower when the context is trapped in the vehicle or distributed across several systems.
A raw code alone is rarely enough. Dispatch needs operational impact. Service needs device and state information. The driver needs a clear next action. Customer support needs a reliable time expectation. Management may later need to know whether the event was isolated or part of a pattern.
The same exception therefore has several legitimate views. The answer is not to display every technical detail to everyone. It is to preserve a common event and provide the relevant context to each role.
Context should travel with the exception
An interruption is easier to handle when it answers basic questions immediately:
- What process was active?
- What changed?
- Which conditions were present?
- What safe state was reached?
- What action has already been taken?
- Who needs the information next?
This does not require the vehicle to depend on permanent cloud connectivity. The local system must remain able to operate and move to a defined safe state. Connectivity should carry the event and its context when available, support controlled diagnostics and prevent every person from beginning the investigation at zero.
Clear local operation and useful remote context are complementary, not competing, requirements.
Diagnose the ripple, not only the device
Service data is often evaluated through the device: fault frequency, component state and repair. Operations experience the same event through the route: delay, replanning, customer impact and follow-up work.
Bringing these views together changes the improvement question.
Instead of asking only why the device stopped, the organisation can ask:
- Why did the event require three phone calls?
- Which information was missing from the first call?
- Could dispatch distinguish a short interruption from a cancelled delivery?
- Could service see the relevant state without asking the driver to describe it?
- Was the completed event recorded well enough for later analysis?
The objective is not to promise that systems never stop. Industrial equipment, field devices and human processes all encounter exceptions. A more credible objective is to make the exception understandable, locally safe and operationally containable.
When context travels with the event, the cost is less likely to continue moving through the organisation long after the original interruption.
The same principle improves later learning. A consistently recorded event can be reviewed across operations and service without turning a single driver’s recollection into the only reliable source. Patterns can be discussed with evidence, while isolated incidents remain identifiable as isolated incidents. That is a more useful starting point for maintenance and process improvement than a list of unexplained stops.
Secu-Tech will show its answer at ETX in Kassel from 17 to 19 September 2026.
About Secu-Tech: Secu-Tech has developed electronic systems for the safe handling, monitoring and documentation of liquids and gases in Leobersdorf, Austria, for more than twenty years.