OTM 5.8: een voertuig mag eindelijk meer dan één brandstof hebben

Op 13 maart 2026 verscheen OTM 5.8. De datum staat expliciet in de changelog van de documentatie, en twaalf change requests gingen die dag dicht.

De rode draad is opvallend: dit is grotendeels een opruimrelease. Dubbele definities eruit, inconsistenties rechtgetrokken, en één inhoudelijke wijziging die een veld deprecieert dat vier jaar eerder juist met veel enthousiasme werd toegevoegd.

Voor de nieuwkomers: wat is OTM? Het Open Trip Model is de open standaard voor het uitwisselen van logistieke ritgegevens — ritten, zendingen, transportorders, voertuigen, locaties, goederen, acties en events — als lichtgewicht JSON over een REST-API.

Waarom het ertoe doet: in transport praat iedereen met iedereen, en zonder gedeelde taal is elke verbinding maatwerk. OTM wordt sinds 2018 beheerd door de Stichting Uniforme Transport Code samen met TLN, evofenedex en DALTI. Alle wijzigingen worden openbaar voorgesteld en besproken, wat betekent dat je bij elk veld kunt teruglezen waarom het bestaat — en, zoals deze release laat zien, waarom het soms weer verdwijnt.

In OTM 5.4, mei 2022, kreeg het voertuig de velden fuel en averageFuelConsumption. Enkelvoud, want een vrachtwagen reed op diesel en klaar.

Dat gaat niet meer op. Een hybride voertuig heeft meerdere brandstoffen, elk met een eigen gemiddeld verbruik, en in de conceptversie van de Kernset Primaire Data is dat ook functioneel zo vastgelegd.

5.8 vervangt daarom fuel, otherFuelType en averageFuelConsumption door één veld fuels: een lijst waarin elke brandstof zijn eigen gemiddelde verbruik meekrijgt. De oude velden zijn gedeprecieerd, niet verwijderd — de gebruikelijke werkwijze in OTM, en de reden dat je koppeling niet op de releasedatum omvalt.

Twee toevoegingen in dezelfde hoek:

• emissionStandard krijgt de waarde Z. De RDW hanteert emissieklassen 0 tot en met 6 én Z, die laatste met name voor elektrische voertuigen. Zonder die waarde kon je een elektrische truck niet correct classificeren — precies het voertuig waarvoor toegang tot een milieuzone het gunstigst is.
• Het carbon footprint-profiel actualiseert zijn brandstoflijst: diesel wordt fossile diesel (B0) en biodiesel (HVO) komt erbij. Als je CO₂ per liter uitrekent, is dat onderscheid geen semantiek maar een andere uitkomst.

De tweede inhoudelijke wijziging gaat over wat er misgaat op de losplek.

Sinds 5.7 kan een actie slagen, mislukken, deels slagen of geannuleerd zijn, met een reden erbij. Maar bij een zending met meerdere goederen — de klassieke casus: een pallet donuts en een pallet broodjes — was 'deels geslaagd' het enige dat je kon zeggen. Wélk deel bleef ongezegd.

5.8 maakt het mogelijk om vanuit een resultaat naar entiteiten te verwijzen en deelresultaten op te geven. Het totaalresultaat is dan 'deels geslaagd', en daaronder staat per goed of het gelost is of niet.

Dat is het verschil tussen een melding die een planner moet natrekken en een melding waar een systeem op kan handelen.

In 5.7 werd de actor grondig herzien met de types company en person. Zoals dat gaat met grondige herzieningen: er bleven scherpe randjes over, en 5.8 vijlt ze weg.

• roles ontbrak op de actor-entiteit zelf. Het veld verscheen wél als je actoren via een voertuig of locatie benaderde, maar niet in de definitie van de actor. Verwarrend, en een bekende bron van koppelingen die het bij de ene endpoint wel en bij de andere niet deden.
• Het verschil tussen actors[].entity.role en actors[].roles wordt nu expliciet uitgelegd in plaats van geraden.
• De actorbeschrijving verschilde per endpoint. Wie api/v5/actors/{uuid} las kreeg andere velden dan wie de actoren op een locatie bekeek.
• Het circulaire polymorfe patroon tussen actor, person en company is rechtgetrokken.

De rest van de release is het soort werk dat niemand claimt maar iedereen merkt:

• Dubbele definities verwijderd — dezelfde entiteit of hetzelfde veld stond op meerdere plekken in de specificatie gedefinieerd, zoals de eenheid van maat.
• actions op het voertuig — je kunt nu acties aan een voertuig koppelen zonder de omweg via een rit. Bijvoorbeeld om vast te leggen dat er een trailer aan hangt.
• actions op de zending binnen een transportorder — een losse zending kon een lijst acties hebben, dezelfde zending binnen een transportorder niet. Een gat in de specificatie, geen ontwerpkeuze.
• entityType ontbrak in de subtypes van goods — items en transportEquipment misten de discriminator waarmee je ze uit elkaar houdt. Voor iedereen die genereert vanuit de OpenAPI-specificatie was dat direct kapot.
• Volume op transportmaterieel en goederen — niet iedere klant heeft lengte, breedte en hoogte paraat, maar volume vaak wel.
• CBS-profiel: Trip.vehicle stond in het JSON-schema als array terwijl de kernspecificatie één voertuig verwacht. Dat brak validatie voor iedereen die het officiële schema gebruikte.

Bij deze release werd ook de opzet van de documentatiesite veranderd. De aparte versies 5.6 en 5.7 zijn verwijderd en vervangen door één 5.x, met als motivering dat het geen zin heeft om minor releases apart te versioneren.

En er kwam een changelog. Dat is een kleine gebeurtenis met grote praktische waarde: tot dan toe was 'wanneer is versie X uitgekomen' een vraag die je alleen kon beantwoorden door change requests en commits na te lopen.

Eén ding is het vermelden waard, en het is precies het risico dat bij de versiesprong van de libraries al te voorzien was.

Op het moment dat 5.8 verscheen, stond de nieuwste OTM .NET-package op 5.7.1.1 — uitgebracht in augustus 2025. De Java-toolkit stond op 1.0.2.0 uit oktober 2025, en spreekt dus ook 5.7.

Dat is geen ramp: de gedeprecieerde velden blijven werken, dus een koppeling op 5.7 blijft functioneren tegen een tegenpartij op 5.8. Maar het betekent wel dat de nieuwe mogelijkheden — fuels, deelresultaten per goed, emissionStandard: Z — vanaf dag één niet uit de standaardbibliotheek komen. Wie ze nodig heeft, schrijft dat stuk voorlopig zelf.

De les blijft dezelfde als bij elke standaard: het versienummer van je library vertelt je wat hij spreekt, niet wat de standaard inmiddels kan.

Als je vandaag op OTM koppelt, staan er drie dingen op je lijst.

Kijk of je iets met brandstof doet. fuel en averageFuelConsumption werken nog, maar fuels is de vorm waarin nieuwe tegenpartijen het zullen aanleveren, en de enige vorm die een hybride correct beschrijft.

Controleer of je genereert vanuit de OpenAPI-specificatie. De ontbrekende entityType in de goods-subtypes en het Trip.vehicle-schema in het CBS-profiel zijn precies het soort fouten die in gegenereerde code stilletjes verkeerde types opleveren.

Herbekijk je uitzonderingsafhandeling. Deelresultaten per goed zijn de eerste keer dat je machinaal kunt zien welk deel van een zending níet is aangekomen.

Bij Keana, onze planningssoftware voor groene stadslogistiek, raakt dat laatste direct de herplanning: een half geloste zending vraagt om een andere vervolgactie dan een geweigerde. En fuels raakt de kern van waar het product op afgerekend wordt — aantoonbare CO₂-reductie, per voertuig, per rit. Bekijk de Keana-case.

OTM 5.8 verscheen op 13 maart 2026 met twaalf gesloten change requests.

De kern: fuel, otherFuelType en averageFuelConsumption op het voertuig worden gedeprecieerd ten gunste van fuels, een lijst met per brandstof een eigen gemiddeld verbruik. emissionStandard krijgt de waarde Z. Actieresultaten kunnen naar entiteiten verwijzen en deelresultaten per goed bevatten. De actor wordt rechtgetrokken na de herziening van 5.7. En een reeks specificatiefouten is opgelost, waaronder de ontbrekende entityType in de subtypes van goods en het Trip.vehicle-schema in het CBS-profiel.

Daarnaast kreeg de documentatiesite één gezamenlijke 5.x-versie in plaats van een pagina per minor — en, eindelijk, een changelog.