OTM 5.6: de release waarin de overheid meeschreef

OTM 5.6 verscheen op 17 november 2023. Zeven change requests gingen die dag dicht, en als je ze naast elkaar legt vertellen ze één verhaal: de standaard werd niet langer alleen door vervoerders gebruikt.

De Nederlandse overheid wilde beperkingen op het gebruik van de openbare weg via OTM gaan publiceren. Schoolzones, weekmarkten, wegwerkzaamheden. Dat vraagt iets anders van een datamodel dan een rit van A naar B.

Voor wie er nieuw in stapt: wat is OTM? Het Open Trip Model is een open standaard voor logistieke ritgegevens — ritten, zendingen, transportorders, voertuigen, locaties, goederen, acties en events — als lichtgewicht JSON over een REST-API.

Waarom dat belangrijk is: in transport praat vrijwel iedereen met iedereen. Een verlader met drie vervoerders, een vervoerder met tien verladers, allebei met een wegbeheerder en een douanesysteem. Zonder gedeelde standaard is dat aantal koppelingen kwadratisch, en elke koppeling is maatwerk dat iemand moet onderhouden. OTM wordt sinds 2018 beheerd door de Stichting Uniforme Transport Code, met TLN, evofenedex en DALTI, en alle wijzigingen worden openbaar besproken. Dat is wat het een standaard maakt in plaats van een formaat.

Dit is de meest verstrekkende wijziging in 5.6, en hij komt rechtstreeks uit de behoefte van wegbeheerders.

Een weg die elke werkdag tussen 07:00 en 09:00 dicht is voor werkzaamheden. Een schoolzone die alleen tijdens schooltijden geldt. Een markt op elke tweede en vierde zaterdag. Dat kón je in OTM alleen uitdrukken door elke afzonderlijke gebeurtenis handmatig op te sommen — onwerkbaar, en gegarandeerd verouderd.

5.6 voegt daarom ondersteuning toe voor terugkerende datums en tijdsintervallen volgens ISO 8601. Dat is de notatie met een R ervoor: R/2022-01-01/P1M voor 'elke maand vanaf 1 januari 2022'.

Eén waarschuwing die in de discussie zelf al werd gemaakt, en die nog steeds geldt: de standaardbibliotheken van .NET en Java parseren dit niet uit zichzelf. System.DateTime en java.time kennen terugkerende intervallen niet. Wie dit ondersteunt, schrijft er eigen (de)serialisatie voor.

Dat is geen reden om het niet te doen, maar het is wel het soort detail dat een integratieplanning omgooit als je het pas bij het testen ontdekt.

Constraints in OTM zeiden wát er beperkt was, maar niet hoe hard. Ook niet na de opschoning in 5.5.

Moet een voertuig onder de 25.000 kg blijven omdat de brug het anders niet houdt, of omdat de klant dat prettiger vindt? Voor een mens is dat verschil vanzelfsprekend, voor een planningsysteem niet. En een routeoptimalisatie die geen onderscheid maakt, is óf te streng (geen oplossing gevonden) óf te soepel (een oplossing die niet mag).

5.6 voegt daarom enforceability toe aan constraints, met twee waarden: enforced voor een absolute eis en preference voor een voorkeur. Klein veld, groot verschil in wat een optimalisator ermee kan.

Twee wijzigingen gaan over de plek waar iets gebeurt:

• Sublocaties — een distributiecentrum is niet één punt. Er zijn dokken, poorten en laadplekken, en 'ergens op het terrein' is te grof zodra je op tijdvensters plant. Een locatie kan nu sublocaties bevatten.
• routeEntityConstraint vervangt routeConstraint — zodat een constraint op een route naar de route-entiteit zelf verwijst, in lijn met hoe de rest van het model associaties legt. De oude naam verdwijnt daarmee uit de specificatie, dus dit is de wijziging waar je bestaande koppeling het snelst over struikelt.

Tot slot: transportEquipment op de acties load en unload.

Je kon aangeven dat de goederen van een zending in een voertuig geladen werden, maar niet in wélke trailer. Bij een LZV of een combinatie met meerdere oplegger is dat precies het stuk informatie dat je nodig hebt om te weten wat waar staat.

Daarnaast werd owner toegevoegd als actorrol — de partij die eigenaar is van de goederen is niet automatisch de verlader, en dat onderscheid heeft juridische gevolgen.

5.6 is de release die het meeste werk kost om te implementeren en het minst opvalt in een changelog. Terugkerende tijden vragen eigen parsing, sublocaties vragen dat je je locatiemodel opendoet, en enforceability is pas nuttig als je planner er iets mee doet.

Maar het is ook de release die OTM bruikbaar maakte buiten de vervoerder om. Zodra een wegbeheerder in dezelfde taal publiceert waarin een planner leest, kun je beleid en planning aan elkaar knopen zonder tussenlaag.

Dat is de kern van wat we met Keana doen: transportorders bundelen tot ritten die rekening houden met wat er in een binnenstad daadwerkelijk mag, per tijdvenster en per voertuig. Bekijk de Keana-case.

OTM 5.6 verscheen op 17 november 2023 met zeven gesloten change requests.

De kern: terugkerende datums en tijdsintervallen volgens ISO 8601 (let op je eigen deserialisatie), enforceability op constraints met de waarden enforced en preference, sublocaties op een locatie, routeEntityConstraint als vervanger van routeConstraint, transportEquipment op laad- en losacties, en owner als actorrol.

De rode draad: OTM stapte uit het vervoerdersdomein en werd ook de taal waarin de overheid over de weg praat.