XPULSEis coming.

The dot stops moving

A dispatcher watches a tanker cross a map. The route was planned, the vehicle is on time, the customer is expecting product. Order data, planning data and telematics have all done their job.

Then the dot arrives, and the screen goes quiet.

What happens next is the part of the journey that actually earns the money. The hose is connected. Access to the tank is checked. Product moves. A quantity is measured. A ticket is issued and an acknowledgement is collected. These are the minutes in which product, customer and proof finally meet, and in many operations they are also the minutes that leave the least usable trace.

The journey to the customer may be visible almost continuously. The delivery itself can still depend on a person reading one screen, entering a number into another device, explaining an exception by telephone, and carrying a paper record back into the billing process.

The problem is not a weak component

Each individual part of this usually works. The meter measures. The vehicle system controls. The driver knows the procedure and has done it several thousand times. The office software creates the order and the invoice.

The weakness is in the handover between capable components, and handovers are nobody’s product. No supplier sells them, no line item covers them, and no single system records what they cost.

That is why "more data" is not automatically an answer. A modern vehicle can produce a great deal of data and still leave the decisive delivery context fragmented. What matters is not volume. It is whether order, vehicle, product, metering event and proof remain recognisable as one operational sequence.

Small at one stop, structural across a network

At a single delivery, copying a value or making one clarification call is trivial. Nobody escalates it. Nobody logs it.

Repeated across every stop, every route and every working week, those small breaks stop being incidents and become the operating model. They consume driver time, but the cost does not stay with the driver. Dispatch waits for an answer. Customer service explains a delay. Administration reconciles a ticket. Service staff try to work out whether an interruption was caused by process, equipment or missing information.

The largest losses in a digital supply chain tend to live in exactly these ordinary transitions, and they are difficult to see precisely because no one system owns them.

Continuity has to reach the delivery point

A connected process does not mean every function depends on a permanent network connection. Local operation remains essential on a vehicle. Connectivity should preserve context, support synchronisation and put the right information in front of the right people, without making the physical delivery dependent on ideal reception.

It also does not mean replacing everything that works today. Most fleets run mixed vehicle generations and equipment from several suppliers, and most sites do too. Continuity has to begin with the installed environment, not with the assumption of a new fleet and a new forecourt.

The useful question is therefore not "how digital is our logistics chain?" It is more specific, and more uncomfortable:

Does the delivery remain one process from the order to the proof, or does it dissolve into disconnected moments in the last ten metres?

What this looks like from where you sit

• Fleet operators and distributors: the last ten metres are where your margin is decided and where your disputes originate, but they are usually the least instrumented part of the route.
• Site and network operators: you receive the consequences of decisions made in someone else’s vehicle and someone else’s software. Part 3 returns to this.
• Vehicle builders and integrators: the handover is designed, or it is inherited. It is rarely neutral.
• Service organisations: every gap in context becomes a diagnostic phone call later.

See the answer in Kassel

Over the coming weeks this series examines four of these operational gaps: the last ten metres, the paperwork that stays open after the delivery, the integration decisions a site inherits without ever making them, and the cost that keeps moving when a system stops.

Secu-Tech shows its answer at ETX in Kassel, 17 to 19 September 2026.

Two endings

At 14:40 the physical work is finished. The hose is disconnected, the ticket is produced, the vehicle moves to the next stop.

Three weeks later, the same delivery opens again. A quantity has been queried. The customer has a photographed ticket. The office has a record from the order system. The measured value sits in another source. Someone asks the driver what happened, but the route has since contained dozens of stops and the detail is gone.

Nothing here is dramatic. It is an email thread, a short call, a copied attachment, perhaps a credit note. But it exposes a structural divide: the physical event ends when product has moved safely, while the commercial event ends only when order, measured quantity, delivery record, customer acknowledgement and invoice all agree.

Most operations measure the first ending carefully and the second one hardly at all.

Four records are not the same as one event

Several records around one delivery is not automatically a problem. Different systems carry different legal, technical and commercial responsibilities, and collapsing them into a single database is neither realistic nor desirable.

The problem starts when those records have to be reconnected by hand, because they share no clear event identity and not enough common context.

A ticket shows a quantity. The planning system knows the order. The vehicle knows the compartment and the product. The customer holds an acknowledgement or a complaint. If these cannot be brought together quickly, a straightforward question turns into an investigation, and the investigation costs more than the disputed amount.

Late questions are especially expensive because context decays. The people who were present have moved on. A temporary exception may never have reached the final document. The longer a transaction stays open, the more work is needed to rebuild what was obvious at the delivery point.

This is a design problem, not a discipline problem

The instinctive response is to ask people to be more careful. Write the number down. Check the ticket. Confirm before leaving.

That response fails predictably, because it adds work at the exact moment when workload is highest and attention is lowest, and because it makes accuracy depend on the least supported person in the chain.

A better model starts from the event rather than the paperwork: one operational event that produces consistent information for the systems around it. Not one system for everything, but one recognisable delivery across metering, vehicle, customer proof and office processing.

The distinction matters more than it sounds. A large central platform can still receive incomplete or ambiguous data. A modest local system can create real continuity if the event is captured clearly, linked to the right context and passed on through defined interfaces.

Language discipline

Traceability invites overclaiming, so it is worth being precise about what any industrial record can and cannot be.

No event record should be described as legally immutable or court-proof without specific technical and legal validation for that jurisdiction and that use. The practical target is more modest and more useful: relevant process, status, operator and diagnostic information should be available to reconstruct what happened, and should be hard to lose by accident.

For the driver, that reduces the need to explain old stops from memory. For the office, it reduces document matching. For the customer, it shortens the path from question to answer, which is usually what they actually wanted.

The better performance question

The most useful measure is probably not how quickly the hose is disconnected. It is how quickly the delivery becomes a closed, consistent business event.

A delivery should not have two endings, one at the customer and another weeks later in administration.

Secu-Tech shows its answer at ETX in Kassel, 17 to 19 September 2026.

Four systems, none of them chosen together

A tanker arrives at a site. Product moves into the tank. A ticket is produced. A gauge reading changes. In a back-office system, a delivery is expected against an order.

Four systems have now described the same event, and none of them was selected with the others in mind.

The tank gauge was specified when the site was built or last refurbished. The wet stock and back-office systems arrived with a group IT programme. The metering equipment on the vehicle belongs to the supplier, not to the site. Each was a sensible decision on its own day, made by a different person answering a different question.

The site attended none of those meetings. It inherits the result, one delivery at a time.

The receiving end has no seat at the design table

Most integration discussion in this industry happens upstream. A vehicle builder decides what talks to what while a tanker is on the line. An equipment supplier decides which interfaces to document. A software vendor decides which formats to export.

The site is downstream of all of it, and its leverage looks small at the moment the hose is connected. But the site is where the consequences are counted, because it is the only place where the physical delivery and the commercial record have to agree.

When the systems around a delivery were never intended to be combined, the site absorbs the difference. Someone reads a value from one screen and types it into another. Someone photographs a ticket because there is no other way to attach it to the right record. Someone telephones the supplier because a number does not match and there is no shared view to look at together.

The site becomes the integration layer, in the same way the driver does on the road. It works, because people make it work, and that is exactly why the cost stays invisible.

Variance is where it surfaces

The clearest example is the difference between what was delivered and what the site believes it received.

A variance has several ordinary explanations: measurement conditions, temperature, the timing between a gauge reading and a delivery, an entry made against the wrong tank, or a genuine discrepancy that deserves attention. Separating them is routine work when the underlying records share context, and an investigation when they do not.

The problem is rarely that a number is unknown. It is that the number exists in several places with no reliable way to tie them to the same event. Weeks later, the question gets settled by whoever kept the better notes rather than by the evidence.

That is not a metering problem or a software problem. It is an integration problem, and it was created before anyone at the site was involved.

Retrofit is where it surfaces again

Sites change. A new tank goes in. A monitoring requirement appears. A group standardises on a different back-office platform. An operator wants delivery confirmation to reach the system automatically instead of by email.

At that point the question is no longer what the equipment does. It is what the equipment will share, and whether anybody documented it.

Where interfaces are documented and were intended to be combined, this is a project with a cost and a date. Where they were not, it becomes a negotiation with the installed base, and the cheapest option on the original day turns out to have been the most expensive one.

This is also why claims of universal compatibility are unhelpful to a site operator. Nobody needs a supplier who says everything works with everything. What helps is a supplier who can say precisely which interfaces exist, what they carry, and what it would take to connect them here.

The site cannot rewrite decisions taken upstream. It can ask different questions before the next ones are taken, whether it is specifying equipment, agreeing a supply contract or approving a refurbishment.

None of these questions is about a device. All of them decide how much routine friction a site lives with for the next decade.

The most useful integration question at the receiving end is therefore not whether the systems are modern. It is whether the delivery arrives as information the site can actually use, or only as product plus paper.

Secu-Tech shows its answer at ETX in Kassel, 17 to 19 September 2026.

The ripple

At 07:10 a loaded vehicle arrives at a customer and cannot begin the delivery.

At 07:20 the driver calls dispatch. At 07:30 the next delivery window is at risk. Service joins the conversation. Customer support prepares an explanation. A second vehicle may need rerouting.

The original interruption is still sitting at one vehicle. Its cost has already left.

This is the organisational ripple of an unexplained stop. It travels from the driver to the people who replan, diagnose and communicate, and each of them spends time on the same event from a different position, usually with different information.

The vehicle is stationary. The business is not.

A stop is a chain of decisions

Every interruption forces decisions: whether the delivery can continue safely, whether the cause is local, procedural or technical, whether service can resolve it remotely, whether the customer needs a new window, which later stops move, and whether this event indicates a pattern.

Those decisions get slower when context is trapped in the vehicle or scattered across systems.

A raw code 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 this was isolated or recurring.

The same exception therefore has several legitimate views. The answer is not to show every technical detail to everyone. It is to preserve one common event and give each role the part of it they can act on.

Context should travel with the exception

An interruption is far easier to absorb when it answers the basic questions immediately: what process was active, what changed, which conditions were present, what safe state was reached, what has already been done, and who needs to know next.

None of that requires permanent cloud connectivity. The local system must remain able to operate and to reach a defined safe state on its own. Connectivity should carry the event and its context when it is available, support controlled diagnostics, and stop every person in the chain from starting their investigation at zero.

Reliable local operation and useful remote context are complementary requirements, not competing ones. Treating them as a trade-off is how organisations end up with systems that are impressive in the office and unhelpful at the roadside.

Diagnose the ripple, not only the device

Service data is usually evaluated through the device: fault frequency, component state, repair. Operations experience the same event through the route: delay, replanning, customer impact, follow-up work.

Bringing those two views together changes the improvement question. Instead of asking only why the device stopped, an organisation can ask why the event required three telephone calls, which information was missing from the first one, whether dispatch could tell a short interruption from a cancelled delivery, whether service could see the relevant state without asking the driver to describe it, and whether the completed event was recorded well enough to analyse later.

The objective is not to promise that systems never stop. Industrial equipment, field devices and human processes all meet exceptions. A more credible objective is to make the exception understandable, locally safe and operationally containable.

Consistently recorded events also improve what comes afterwards. Patterns can be discussed with evidence rather than recollection, and isolated incidents stay identifiable as isolated incidents. That is a far better starting point for maintenance planning than a list of unexplained stops.

Secu-Tech shows its answer at ETX in Kassel, 17 to 19 September 2026.