OTM 5.4: brandstof en CO₂ worden onderdeel van de standaard

Op 9 mei 2022 gingen elf change requests in één klap dicht in de OTM-tracker. Dat was OTM 5.4.

De release oogt op papier als onderhoud — een constraint erbij, een veldje daar, wat documentatie rechtgetrokken. Maar er zit één verandering in die de jaren daarna bepalend is gebleken: vanaf 5.4 kun je brandstofverbruik en uitstoot in de standaard zelf kwijt, vastgeplakt aan de rit of zending waar ze bij horen.

Wat is OTM ook alweer? Het Open Trip Model is een open standaard voor het uitwisselen van logistieke ritgegevens over het internet: ritten, zendingen, transportorders, voertuigen, locaties en de events die daarbij horen. Lichtgewicht JSON, via een REST-API, onder een Creative Commons-licentie.

De standaard is ooit gebouwd door Simacan met financiering uit het programma Beter Benutten, en werd in 2018 ondergebracht bij de Stichting Uniforme Transport Code (SUTC), samen met TLN, evofenedex en DALTI. Dat is precies waarom OTM ertoe doet: het is geen leveranciersformaat, maar een standaard waar verladers, vervoerders, softwareleveranciers en wegbeheerders gezamenlijk eigenaar van zijn. Zonder zo'n standaard bouwt iedere partij een eigen vertaallaag naar iedere andere partij — en dat is precies de rekening die de sector al decennia betaalt.

OTM kende al events — een locatie-update, een vertraging, een aangemaakte associatie. Maar events leefden los van de entiteiten waar ze over gingen. Wilde je vertellen dat een rit 40 liter diesel verbruikte, dan had je daar geen plek voor.

5.4 voegt daarom twee dingen tegelijk toe:

• Twee nieuwe eventtypes: fuelConsumedEvent en emissionEvent, allebei met een waarde en een eenheid, en allebei bruikbaar in de levenscyclus projected (vooraf berekend) of realized (achteraf gemeten).
• Een optioneel veld contextEvents op álle entiteiten. Daarmee kun je events meesturen in hetzelfde bericht als de entiteit waar ze bij horen, in plaats van ze er los achteraan te sturen.

Dat tweede punt is groter dan het klinkt. contextEvents is niet gebouwd voor CO₂ alleen — het is een generiek mechanisme. Je kunt er ook de verkeers- en locatie-events onder een rit mee hangen om te laten zien hoe een ETA tot stand kwam, of het gereden aantal kilometers meesturen dat straks op de factuur belandt.

Eén bericht dat de rit én de onderbouwing bevat, in plaats van twee berichten die de ontvanger zelf aan elkaar moet knopen.

Naast de events kreeg de vehicle-entiteit een veld averageFuelConsumption, in het formaat <liter> l/100km.

De reden is praktisch: gemiddeld verbruik wordt gebruikt om tarieven te bepalen, en het is de invoer waarmee je verbruik en uitstoot over een geplande route vooruit berekent. Zonder dat veld moest die waarde uit een zijkanaal komen — en dan klopt hij dus vaak niet.

De overige wijzigingen zijn kleiner, maar lossen elk een concreet gat op:

• transportEquipmentConstraint — je kon niet uitdrukken dat een rit een geconditioneerde trailer vereist. Nu wel, met een type en subtype.
• sequenceNr op alle actietypes — dat veld zat alleen op stop. Inconsistent, want de volgorde van laden en lossen is net zo goed informatie.
• cancelled als resultaatstatus, receiverAbsent als reden — een actie kon slagen, mislukken of deels slagen. Maar geannuleerd worden vóór hij begint kon niet, terwijl dat in de praktijk dagelijks gebeurt.
• Actors op events — partijen die OTM-events voor meerdere klanten verwerken konden niet aangeven bij wie een event hoorde. Nu kan een event verwijzen naar de betrokken actoren.
• description op constraint-waarden — constraints kunnen samengesteld en diep genest zijn. Zonder omschrijving weet niemand meer waar een deelconstraint voor bedoeld was.

En drie documentatiewijzigingen: waar je actoren en constraints hoort te zetten (op de zending of op de transportorder), wat de rollen van actoren op een zending precies afdwingen, en welke entiteittypes een AssociationCreatedEvent mag bevatten. Geen specificatiewijzigingen, wel de bron van een hoop verkeerd gebouwde koppelingen.

In 2022 was CO₂-rapportage voor de meeste vervoerders nog iets van een jaarverslag. Inmiddels is het een eis in aanbestedingen, in de CSRD-keten en in het gesprek met gemeenten over toegang tot binnensteden.

Dat werkt alleen als de uitstootcijfers uit dezelfde bron komen als de ritgegevens. Anders krijg je precies wat je in de praktijk ziet: een planningsysteem dat ritten bijhoudt, een losse spreadsheet die uitstoot berekent, en niemand die kan aantonen dat de twee over dezelfde ritten gaan.

OTM 5.4 heeft die koppeling in het datamodel gelegd. De emissie hangt aan de rit, niet ernaast.

Dat is ook precies waar wij het in Keana voor gebruiken. Keana bundelt transportorders per hub tot ritten met tijdvensters en stops, rekening houdend met temperatuurklassen, laadvermogen en actieradius per voertuig. De CO₂-winst van dat bundelen is het hele punt van het product — en die winst is alleen geloofwaardig als hij aan dezelfde ritten hangt als de planning. Lees hoe dat werkt in de Keana-case.

OTM 5.4 verscheen op 9 mei 2022 en sloot elf change requests.

De kern: fuelConsumedEvent en emissionEvent als nieuwe eventtypes, en contextEvents als optioneel veld op elke entiteit zodat events meereizen met de entiteit waar ze bij horen. Daarnaast averageFuelConsumption op het voertuig, een constraint voor materieel, sequenceNr op alle acties, cancelled als resultaatstatus en actoren op events.

Als je vandaag een OTM-koppeling bouwt en je moet iets met uitstoot: dit is de release waarin die mogelijkheid ontstond.