OTM 5.5: Fewer Constraints, More Modelling Power

Crowds of fun-seekers exploring a city on foot, "

Arjan Franzen

7 February 2023

Diagram: the separate speedConstraint, weightConstraint, sizeConstraint and temperatureConstraint are replaced in OTM 5.5 by a single valueBoundConstraint

On 7 February 2023, nine change requests closed and OTM 5.5 was out. It is an unusual release in the 5.x series, because its most striking change makes the standard smaller rather than bigger.

The reason was stated plainly in the discussion: every release brought new constraint types, and the list was becoming unworkable for newcomers.

Back to basics: what is OTM? The Open Trip Model is the open standard transport and logistics parties use to exchange trip data — trips, consignments, transport orders, vehicles, locations, goods and events, as lightweight JSON over a REST API.

What makes it matter is who owns it. Since 2018 OTM has been stewarded by the Stichting Uniforme Transport Code, together with TLN, evofenedex and DALTI, and changes are debated in the open on GitHub. No single vendor decides on their own what goes into the standard. That is why a shipper, a carrier and a road authority can describe the same trip the same way — and why no per-integration translation layer is needed.

The problem: constraints outgrew themselves

Constraints are how OTM expresses what must or must not happen: at most 25,000 kg, no higher than 3.80 metres, unload between 07:00 and 10:00, refrigerated transport, driver with ADR certification.

Every new need produced a new constraint type — 5.4 added one more for transport equipment in May 2022. Speed, weight, dimensions, temperature — each defined separately, each with its own documentation. Precise, but the list grew long, and anyone building their first OTM integration could no longer see the wood for the trees.

The working group made an explicit choice: merge what resembles each other.

valueBoundConstraint replaces four of them

The answer is a single constraint with a value, a unit and an upper or lower bound. That covers speed, weight, dimensions and temperature with one pattern.

Important for anyone already integrated: the old constraints are deprecated, not removed. They remain supported. That is a deliberate stance in OTM, and it is the difference between a standard you can follow and a standard that breaks your integration.

In fairness, the working group wrote down the downside themselves: this hides complexity. There are fewer types to implement, but no fewer situations to think about. What you gain is that getting started stays comprehensible.

Low-emission zones and road closures

Two additions concern access to the road itself — precisely where planning and policy meet.

  • emissionStandardConstraint — the emission class was already on the vehicle, but you could not express that a route, trip or location requires a minimum class. For driving into a low-emission zone, that is exactly the piece of information the planner needs.
  • accessConstraint — a new constraint type with values closed, partialClosed and open, to describe (temporary) road closures. The reason it was not allowed to be a generic constraint: a generic one cannot tell a routing engine that this road is shut, and so cannot make it compute an alternative.

Fuel, charging and the rest

The remaining changes:

  • fuel becomes an enum instead of free text. As long as everyone could pick their own spelling, the field was not machine-usable — a problem the moment you want to calculate emissions from it.
  • New refuel action — covering both refuelling and charging; the fuel type makes the distinction. Previously you had to abuse a generic action for it.
  • transportOrder on the consignment — the association only worked one way. In OTM entities usually point both ways, so this was an inconsistency.
  • EORI number as a contact detail — the EU registration number needed for customs handling.
  • Documentation on constraints — when a constraint belongs on the consignment and when on the goods themselves. Not a specification change, but the most frequently asked question.

What you notice in practice

5.5 is the release you only appreciate once you build planning that meets the real world. A city centre with a low-emission zone, a bridge under maintenance, a chilled consignment that only fits certain vehicles: these are not edge cases, this is Tuesday.

For Keana — our planning software for green city logistics — this is the kind of information the entire bundling problem turns on. Which vehicle may enter that zone, which street is shut this week, and which stops can therefore be combined into one trip. See the Keana case.

In short

OTM 5.5 shipped on 7 February 2023 with nine change requests closed.

The core: valueBoundConstraint replaces the separate constraints for speed, weight, dimensions and temperature — the old ones stay supported but are deprecated. Alongside that, emissionStandardConstraint for low-emission zones, accessConstraint for road closures, fuel as an enum, a refuel action, a transportOrder reference on the consignment, and EORI as a contact detail.

The lesson worth taking from this release: a standard that only ever grows becomes a standard nobody fully implements.

no image placeholder

Optimize with ZEN's Expertise