OTM 5.6: The Release Where Government Joined In

OTM 5.6 shipped on 17 November 2023. Seven change requests closed that day, and lined up next to each other they tell one story: the standard was no longer being used by carriers alone.

The Dutch government wanted to publish restrictions on public road usage through OTM. School zones, weekly markets, roadworks. That asks something different of a data model than a trip from A to B.

For anyone new to it: what is OTM? The Open Trip Model is an open standard for logistics trip data — trips, consignments, transport orders, vehicles, locations, goods, actions and events — as lightweight JSON over a REST API.

Why that matters: in transport, more or less everyone talks to everyone. A shipper with three carriers, a carrier with ten shippers, both with a road authority and a customs system. Without a shared standard that integration count is quadratic, and every integration is bespoke work someone has to maintain. Since 2018 OTM has been stewarded by the Stichting Uniforme Transport Code, with TLN, evofenedex and DALTI, and every change is debated in public. That is what makes it a standard rather than a format.

This is the furthest-reaching change in 5.6, and it comes straight from what road authorities needed.

A road closed every weekday between 07:00 and 09:00 for construction. A school zone that only applies during school hours. A market on every second and fourth Saturday. In OTM you could only express that by listing every single occurrence by hand — unworkable, and guaranteed to go stale.

So 5.6 adds support for recurring dates and time intervals per ISO 8601. That is the notation with a leading R: R/2022-01-01/P1M for 'every month starting 1 January 2022'.

One warning that was raised in the discussion itself, and still holds: the standard libraries in .NET and Java do not parse this out of the box. System.DateTime and java.time have no concept of recurring intervals. Anyone supporting this writes their own (de)serialisation for it.

That is no reason to skip it, but it is exactly the kind of detail that wrecks an integration schedule if you only discover it during testing.

Constraints in OTM said what was restricted, but not how firmly. Not even after the clean-up in 5.5.

Must a vehicle stay under 25,000 kg because the bridge will not hold otherwise, or because the customer prefers it? For a human that difference is obvious; for a planning system it is not. And a routing engine that cannot tell them apart is either too strict (no solution found) or too lax (a solution that is not allowed).

So 5.6 adds enforceability to constraints, with two values: enforced for an absolute requirement and preference for a preference. A small field, a large difference in what an optimiser can do with it.

Two changes concern where something happens:

• Sub-locations — a distribution centre is not one point. There are docks, gates and loading bays, and 'somewhere on site' is too coarse once you plan against time windows. A location can now contain sub-locations.
• routeEntityConstraint replaces routeConstraint — so a constraint on a route references the route entity itself, in line with how the rest of the model handles associations. The old name leaves the specification, which makes this the change your existing integration trips over first.

Finally: transportEquipment on the load and unload actions.

You could state that a consignment's goods were loaded into a vehicle, but not into which trailer. For a long combination vehicle or a multi-trailer set-up, that is exactly the information you need to know what is where.

Alongside that, owner was added as an actor role — the party that owns the goods is not automatically the shipper, and that distinction carries legal consequences.

5.6 is the release that takes the most work to implement and shows up least in a changelog. Recurring times need custom parsing, sub-locations need you to open up your location model, and enforceability is only useful once your planner acts on it.

But it is also the release that made OTM usable beyond the carrier. Once a road authority publishes in the same language a planner reads, you can connect policy and planning without an intermediate layer.

That is the heart of what we do with Keana: bundling transport orders into trips that respect what is actually permitted in a city centre, per time window and per vehicle. See the Keana case.

OTM 5.6 shipped on 17 November 2023 with seven change requests closed.

The core: recurring dates and time intervals per ISO 8601 (mind your own deserialisation), enforceability on constraints with the values enforced and preference, sub-locations on a location, routeEntityConstraint replacing routeConstraint, transportEquipment on load and unload actions, and owner as an actor role.

The common thread: OTM stepped out of the carrier domain and became the language government uses to talk about the road as well.