The Carbulator

Technical Pitch - what it does
Difference between previous / enhanced BookingOption JSON
Carbulator in action - calculating 2nd BookingOption out of 5

Inspiration

The problem today is that CO₂ emissions are not visible for export agents who have to decide which flights to choose on planning the shipment.

Existing booking systems provide flight options, but they often do not contain CO₂ details, especially for cargo. Reason is, the existing CargoXML/CargpIMP message structures are too limited to include such information.

To reduce CO₂ emissions, we must start at the planning and booking for air cargo - and have CO₂ emissions visible to decision makers when they plan the shipment - which is currently not the case.

Challenges addressed:

Sustainability
Developer experience
Open

Solution and what it does

Our solution addresses exactly this problem: It makes CO₂ emissions and compensation costs visible by enriching the 1R flight options seamlessly with CO₂ details.

Because ONE Record data model allows to include CO₂ emmission data, we want to use 1R data structures to always include the CO₂ data especially for the flight bookings.

Once the new ONE Record process is adopted by the industry, and it makes sense to include CO₂ emmission data into those ONE Record 'BookingOption' data.

How we built it

The 'Carbulator' uses the API of CarbonCare to calculate CO₂ emissions and CO₂ compensation costs as per new standard ISO-14083:2023. BookingOptions JSON used as input data gets enhanced with CO₂ details and provided as JSON again.

Programmed in JAVA programming language, hosted on GitHub.

APIs used:

ONE Record Ontology via Java API Library https://github.com/riege/one-record-ontologydatamodel
ONE Record JSON marshalling/unmarshalling Java API Library https://github.com/riege/one-record-jsonutils
CarbonCare CO₂ calculation API https://my.carboncare.ch/ISO-API_3.0.zip
More open source Java utility APIs to be used (e.g. Easy REST API, Apache Commandline Scanner API etc). The project is built with open source CI tools (maven or gradle) and all required API library dependencies are listed in the project configuration files which is published on GitHub.

Challenges we ran into

We missed vehicleType in Ontology 3.0.0 for BookingOptions, therefore unable to calculate vehicle specific CO₂ emmissions
CO₂ method names are free text in Ontology. We recommend to add a ISO-14083:2023 compliant codes to the Ontology.

Accomplishments that we're proud of

We had been able to use ONE Record Ontology, the public domain Riege ONE Record Utility libraries on a real project.
Converting / using ONE Record BookingOption data with a existing production level 3rd party (CarbonCare) API for calculation

What we learned

We learned how to use the NE:ONE 1.0.0 server (but refrained from last minuted code changes to keep the achieved solution stable)
Adding CO₂ compensation costs to regular freight costs make a difference, but it's not massive on a 'per Kg' level.

What's next for The Carbulator

Apply the learnings from the the NE:ONE 1.0.0 server to The Carbulator and update some of our public source ONE-Record libraries with the outcome.
Integration of The Carbulator into Riege TMS Software when the MCD project is implemented
Integration of The Carbulator into CarbonCare services and products