OTM 5.5: minder constraints, meer modelleerkracht

Op 7 februari 2023 werden negen change requests gesloten en stond OTM 5.5 er. Het is een ongewone release in de 5.x-reeks, want de opvallendste wijziging is er een die de standaard kleiner maakt in plaats van groter.

De aanleiding stond met zoveel woorden in de discussie: bij elke release kwamen er nieuwe constraint-types bij, en de lijst begon voor nieuwkomers onwerkbaar te worden.

Even terug naar de basis: wat is OTM? Het Open Trip Model is de open standaard waarmee partijen in transport en logistiek ritgegevens uitwisselen — ritten, zendingen, transportorders, voertuigen, locaties, goederen en events, als lichtgewicht JSON over een REST-API.

Het belang zit hem in wie er eigenaar van is. OTM wordt sinds 2018 beheerd door de Stichting Uniforme Transport Code, samen met TLN, evofenedex en DALTI, en de wijzigingen worden in het openbaar besproken op GitHub. Geen enkele leverancier bepaalt in zijn eentje wat er in de standaard komt. Dat is de reden dat een verlader, een vervoerder en een wegbeheerder dezelfde rit op dezelfde manier kunnen beschrijven — en dat er dus geen vertaallaag per koppeling nodig is.

Constraints zijn in OTM de manier om te zeggen wat er moet of niet mag: maximaal 25.000 kg, hooguit 3,80 meter hoog, lossen tussen 07:00 en 10:00, gekoeld vervoer, chauffeur met ADR-papieren.

Elke nieuwe behoefte leverde een nieuw constraint-type op — 5.4 voegde er in mei 2022 nog eentje toe voor transportmaterieel. Snelheid, gewicht, afmeting, temperatuur — allemaal apart gedefinieerd, allemaal met hun eigen documentatie. Precies, maar de lijst werd lang, en wie voor het eerst een OTM-koppeling bouwt ziet door de bomen het bos niet meer.

De werkgroep koos expliciet: samenvoegen wat op elkaar lijkt.

Het antwoord is één constraint met een waarde, een eenheid en een boven- of ondergrens. Daarmee dek je snelheid, gewicht, afmetingen en temperatuur af met hetzelfde patroon.

Belangrijk voor iedereen die al koppelde: de oude constraints zijn gedeprecieerd, niet verwijderd. Ze blijven ondersteund. Dat is een bewuste keuze in OTM en het maakt het verschil tussen een standaard die je kunt volgen en een standaard die je koppeling breekt.

De eerlijkheid gebiedt te zeggen wat de werkgroep zelf ook opschreef: je verstopt hiermee complexiteit. Er zijn minder types om te implementeren, maar niet minder situaties om over na te denken. Wat je wint is dat de instap begrijpelijk blijft.

Twee toevoegingen gaan over toegang tot de weg zelf — en dat is precies waar planning en beleid elkaar raken.

• emissionStandardConstraint — de emissieklasse stond al op het voertuig, maar je kon niet uitdrukken dát een route, rit of locatie een minimale klasse vereist. Voor het rijden in een milieuzone is dat nu net het stuk informatie dat de planner nodig heeft.
• accessConstraint — een nieuw constraint-type met de waarden closed, partialClosed en open, om (tijdelijke) wegafsluitingen te beschrijven. De reden dat dit géén generieke constraint mocht worden: een generieke constraint kan een routeoptimalisatie niet vertellen dat déze weg dicht is, en dus geen alternatief laten berekenen.

De overige wijzigingen:

• fuel wordt een enum in plaats van vrije tekst. Zolang iedereen zijn eigen spelling mocht kiezen, was het veld niet machinaal te gebruiken — en dat is een probleem zodra je er uitstoot mee wilt uitrekenen.
• Nieuwe actie refuel — tanken én laden vallen hieronder; het brandstoftype maakt het onderscheid. Voorheen moest je daar een generieke actie voor misbruiken.
• transportOrder op de zending — de associatie werkte maar één kant op. In OTM verwijzen entiteiten juist meestal beide kanten op, dus dit was een inconsistentie.
• EORI-nummer als contactgegeven — het EU-registratienummer dat je bij douaneafhandeling nodig hebt.
• Documentatie over constraints — wanneer hoort een constraint op de zending en wanneer op de goederen zelf. Geen specificatiewijziging, wel de meest gestelde vraag.

5.5 is de release die je pas waardeert als je een planning bouwt die met de echte wereld te maken heeft. Een binnenstad met een milieuzone, een brug in onderhoud, een gekoelde zending die maar in bepaalde voertuigen mag: dat zijn geen randgevallen, dat is dinsdag.

Voor Keana — onze planningssoftware voor groene stadslogistiek — is dit het soort informatie waar het hele bundelingsvraagstuk op draait. Welk voertuig mag er die zone in, welke straat is deze week dicht, en welke stops kun je daardoor wel of niet in één rit combineren. Bekijk de Keana-case.

OTM 5.5 verscheen op 7 februari 2023 met negen gesloten change requests.

De kern: valueBoundConstraint vervangt de aparte constraints voor snelheid, gewicht, afmeting en temperatuur — de oude blijven ondersteund maar zijn gedeprecieerd. Daarnaast emissionStandardConstraint voor milieuzones, accessConstraint voor wegafsluitingen, fuel als enum, een refuel-actie, een transportOrder-verwijzing op de zending en EORI als contactgegeven.

De les die je uit deze release kunt meenemen: een standaard die alleen maar groeit, wordt vanzelf een standaard die niemand meer helemaal implementeert.