OTM 5.4: Fuel and CO₂ Become Part of the Standard

On 9 May 2022, eleven change requests closed in one go in the OTM tracker. That was OTM 5.4.

On paper the release looks like maintenance — one constraint added, a field here, some documentation straightened out. But it contains one change that turned out to be decisive in the years since: from 5.4 onwards you can record fuel consumption and emissions inside the standard itself, attached to the trip or consignment they belong to.

A quick reminder: what is OTM? The Open Trip Model is an open standard for exchanging logistics trip data over the web: trips, consignments, transport orders, vehicles, locations and the events that go with them. Lightweight JSON, over a REST API, under a Creative Commons licence.

The standard was originally built by Simacan with funding from the Dutch Beter Benutten programme, and in 2018 stewardship moved to the Stichting Uniforme Transport Code (SUTC), together with TLN, evofenedex and DALTI. That is exactly why OTM matters: it is not a vendor format but a standard jointly owned by shippers, carriers, software vendors and road authorities. Without one, every party builds its own translation layer to every other party — and that is the bill the sector has been paying for decades.

OTM already had events — a location update, a delay, an association created. But events lived apart from the entities they described. If you wanted to say that a trip burned 40 litres of diesel, there was nowhere to put it.

So 5.4 adds two things at once:

• Two new event types: fuelConsumedEvent and emissionEvent, both carrying a value and a unit, and both usable in the projected lifecycle (calculated up front) or realized (measured afterwards).
• An optional contextEvents field on every entity. This lets you send events inside the same message as the entity they belong to, instead of shipping them separately afterwards.

That second point is bigger than it sounds. contextEvents was not built for CO₂ alone — it is a generic mechanism. You can equally use it to hang traffic and location events off a trip to show how an ETA came about, or to carry the kilometres driven that will end up on an invoice.

One message containing both the trip and its evidence, instead of two messages the receiver has to stitch together.

Alongside the events, the vehicle entity gained an averageFuelConsumption field, in the format <litres> l/100km.

The reason is practical: average consumption is used to set tariffs, and it is the input you need to project consumption and emissions across a planned route. Without that field the value had to come from a side channel — which is exactly why it was so often wrong.

The remaining changes are smaller, but each closes a concrete gap:

• transportEquipmentConstraint — there was no way to express that a trip requires a refrigerated trailer. Now there is, with a type and a sub-type.
• sequenceNr on all action types — the field only existed on stop. Inconsistent, because the order of loading and unloading is information too.
• cancelled as a result status, receiverAbsent as a reason — an action could succeed, fail or partially succeed. Being cancelled before it even started was not expressible, even though it happens daily.
• Actors on events — parties processing OTM events for multiple customers could not indicate whom an event belonged to. Now an event can reference the actors involved.
• description on constraint values — constraints can be composite and deeply nested. Without a description, nobody remembers what a sub-constraint was for.

Plus three documentation changes: where actors and constraints belong (on the consignment or on the transport order), what actor roles on a consignment actually enforce, and which entity types an AssociationCreatedEvent may contain. Not specification changes — but the source of a great many badly built integrations.

In 2022, CO₂ reporting was still an annual-report exercise for most carriers. Today it is a requirement in tenders, in the CSRD chain, and in the conversation with municipalities about access to city centres.

That only works if the emission figures come from the same source as the trip data. Otherwise you get exactly what you see in practice: a planning system that tracks trips, a separate spreadsheet that calculates emissions, and nobody able to prove the two describe the same trips.

OTM 5.4 put that link into the data model. The emission hangs off the trip, not next to it.

That is precisely what we use it for in Keana. Keana bundles transport orders per hub into trips with time windows and stops, taking temperature classes, payload and range per vehicle into account. The CO₂ saving from that bundling is the whole point of the product — and that saving is only credible if it hangs off the same trips as the plan. See how it works in the Keana case.

OTM 5.4 shipped on 9 May 2022 and closed eleven change requests.

The core: fuelConsumedEvent and emissionEvent as new event types, and contextEvents as an optional field on every entity so events travel with the entity they describe. Alongside that, averageFuelConsumption on the vehicle, a constraint for equipment, sequenceNr on all actions, cancelled as a result status, and actors on events.

If you are building an OTM integration today and you need to do something with emissions: this is the release where that became possible.