Add calculated CO2 to consignment

[woutvandenheuvel]

Type of request

• [x ] I'd like to add something to the OTM 5 spec
• [ ] I'd like to change something in the OTM 5 spec

Is your feature request related to a problem? CO2 calculation on trips or/and consigments are more often made by external systems and platforms. Calculated value per consigment will be returned.

Describe the solution you'd like Add to consignment:

• Calculated CO2 planned
• Calculated CO2 realized

Describe alternatives you've considered Did you try to solve it with the current specification? If so, how? Please be as clear and concise as possible.

Additional context Add any other context or screenshots about the feature request here.

[thomaskolmans]

Full support for the addition, wouldn't it be possible to have this value in some sort of lifcycle instead of 2 separate fields?

[bmeesters]

I am currently working on a more detailed proposal. The direction will likely be to create new action types (which have lifecycles) for this. E.g. EmitPollutant that can be part of trips, moves, consignments, etc.)

[bmeesters]

Within Simacan we have thought about this use case a bit in the past week and come to the following proposal:

Add a new action EmitPollutant that contains a value-with-unit for the amount of CO2 (or any other pollutant) that has been emitted in the scope of that entity, together with optional references to trips, moves and consignments. We initially considered Emit but think that is not clear enough.

The advantages of this approach:

• By making it an action instead of a field you get lifecycles 'for free'.
• It gives freedom to be precise (track the CO2 emissions on each move) and to be general (track the C02 of an entire trip).
• It allows you to have multiple calculations for a single consignment, for example because it is part of multiple trips.
• It can be used on different entities without any modifications to those entities.

We feel that emissions, and consumption are pretty similar, so also propose another action ConsumeFuel that can be used to track how much fuel has been consumed in a trip or move.

Curious to know what you think about this proposal.

[thomaskolmans]

Action just doesn't feel right as far as definition of the word. Event would fit better already in my opinion but I believe there should maybe be a new value.

My argument for Event is that it's pretty much already possible through the Sensor and UpdateSensorEvent combination to have this data logged.

[bmeesters]

My argument for Event is that it's pretty much already possible through the Sensor and UpdateSensorEvent combination to have this data logged.

Yes that is true, but we cannot attach events to entities, so it is not possible to send a trip with emission data if they are events (currently). I agree with the sentiment that event events feel more appropriate, but they would make sending messages actually more awkward.

edit we could of course make it possible to attach events to entities, but I am not sure whether that will actually simplify things.

[bmeesters]

Discussed with @woutvandenheuvel and @mennolambooij and we agree that events make more sense than actions. Though it would also mean we would need to add an events field to every entity. Any thoughts @thomaskolmans?

[bmeesters]

Did you have a chance to think about this some more @thomaskolmans? I am wondering how you see the solution work with events if you want to provide it in one message.

[thomaskolmans]

Yes I have given this a bit of thought. However I don't like the events on every Entity. That will make things really odd. Maybe we have to introduce a new entity? Or a sub-entity that has some sort of lifecycle integrated?

A ValueWithUnit - and lifecycle?

It can be self-contained as it won't have a lot of lifeCycle changes or statusses (an assumption at this point in time)

[bmeesters]

So, if I understand your proposal correct, that would something like this in pseudo JSON:

consignment: {
  id: <uuid>,
  goods: [ .. ]
  emission: [
    {
       lifecycle: projected
       value: 10
       unit: co2e
    },
    {
       lifecycle: realized
       value: 12
       unit: co2e
    }
  ]
}

One the side I think it fits better than actions and is easier to integrate than events. On the other hand it would mean more changes (this fields needs to be on consignment, trip, move + we also would need a consumption field on consignment, trip and move) and it is also a little different with how we have been working with lifecycles up until now. I am not sure what's better.

Maybe we need something next to events and actions that can be added to entities. Maybe that is also what you meant with?

Action just doesn't feel right as far as definition of the word. Event would fit better already in my opinion but I believe there should maybe be a new value.

[thomaskolmans]

So I was playing with both scenario's in my head. I'm actually for either solution. A new Entity would take more time to implement and understand (it makes the model more "complex") but can be argued for as this will give the ability for a lot of future additions.

However, the above implementation is easy and would do it's job too. Would make an overview of what happened very clear and concise.

So in conclusion, both ideas came to my mind as "better then Events or Actions" but I'm not sure which one is the best. I'll think about it and I would like to hear some other opinions and arguments if there are any.

[bmeesters]

Thanks for thinking along Thomas. We are in contact with BigMile about this subject, so I am sure they have an opinion as well. I will also take your suggestions and discuss them internally and post back our views here.

but can be argued for as this will give the ability for a lot of future additions.

I think the actions/events or something new are better in this regard and I am personally leaning more towards this type of solution. It might be a bit more involved now, but I think adding fields with lifecycles are less future proof for similar additions (like the consumption already discussed in this topic).

[bmeesters]

I had a discussion with BigMile yesterday about this feature. They already have a non-OTM5 api and want to provide this same functionality in OTM5 soon. I showed the discussion we have had until now and will discuss it internally and provide feedback here as well. From what I understood they are leaning towards the emission and consumption value-with-unit-lifecycle fields. IMO it is a little less generic, but also simpler.

Unless we agree on a good way to include 'event' like data to entities themselves I think this is the current best proposal.

Note, within Simacan we have included a context field on all entities that can contain events that are relevant to why an entity is the way it is. This is used for example in the ETA calculations that we provide (the events show LocationEvents to indicate on what data we based the eta calculations. I am not sure whether context (that are events) is the best possible solution, but I find that it works rather well. Any thoughts @thomaskolmans? Would you be open for an addition like this (with modifications if needed)?

[MGemmink]

Thanks @bmeesters and @thomaskolmans for the elaborate discussion on this topic, reading it made me change my opinion multiple times. It would be great if it is possible to track emissions in OTM for various entities. The proposed solution with the emission field could be a good fit for the BigMile Emission API for mapping the planned CO2 emissions. However, I see some challenges:

The emission field lacks the possibility to store detailed information about the emissions. E.g. it can be important to know with which framework the emissions were calculated. We can extend the field with other attributes, but this can get very big. At which point is it no longer desirable to store this directly in the entity instead of an event? Providing context to an Event can be helpful to provide information about which framework was used or how the planned emissions were calculated. This is also relevant for allocating emissions for different consignments or goods.

From an ease-of-use perspective, the emission field is great to easily exchange emission information, but I wonder if we still need a way to do it with events, which feels more in line with the spec.

Let me know your thoughts on this.

Martijn

[bmeesters]

Thanks @MGemmink for chiming in. The more I think about it the more I would something more generic than a new field (with potential extra attributes). So I would be in favor of making it an Event with the proper information (which could include the used framework). Then the problem of how to add events to entities still remain. Adding events to entities initially feels a bit weird. However I think this is mostly due to framing.

For example, we could add a field history to each entity that could contain all the relevant events that lead to the current state of the entity in question. Something like this would already be beneficial for Simacan, since we calculate ETAs and if we could add the location updates that have influenced that ETA that would be a welcome addition. Now, I think history might not be great, because that would imply that everything has finished, which would not be the case for projected CO2 emissions. Which is why I thinnk adding a field context that could contain the events would be better and clearer than naming the field events. Any thoughts?

[MGemmink]

Thanks @bmeesters for your reply. I think a context field could indeed be helpful to know how a certain value came to be, just as for ETAs, you want to know how emissions are calculated and what was taken into consideration. I have a question though, how do we know which events to show in the context field? Maybe context needs to be bigger than merely a list of events in which we can capture the additional information. An example:

{
  ... # the entity details
  emissions: [{
    value: 100.23,
    unit: "co2e",
    lifecycle: "planned"
  }, {
    value: 106.80,
    unit: "co2e",
    lifecycle: "realized"
  }],
  context : {
    emissions: { # the context for the `emissions` field in the entity (or in the external attributes)
      framework: "GLEC", # attributes for the context.
      ...
      events: [{
        ... # the events that were used to calculate the emissions
      }]
    }
  }
}

What do you think?

[bmeesters]

In my opinion, we should either go with the fields or with the context, not both. So my proposal is one of:

1. Using fields:

{
  entityType: consignment
  goods: [..] // omitted for brevity
  emissions: [{
    value: 100.23,
    unit: "co2e",
    lifecycle: "planned"
  }, {
    value: 106.80,
    unit: "co2e",
    lifecycle: "realized"
  }],
}

advantage: simple to use/understand downside: non-extensible solution, we would to add a sea of parameters for similar use cases

2. Using events (in context)

{
  entityType: consignment
  goods: [..] // omitted for brevity
  contextEvents: {
    {
       eventType: emissionEvent 
       framework: GLEC,
       lifecycle: projected
       emission: {
         value: 106.80,
         unit: "co2e"
      }
    },
    {
       eventType: emissionEvent 
       framework: GLEC,
       lifecycle: realized
       emission: {
         value: 106.80,
         unit: "co2e"
      }
    },
   // potentially other events, such as consumed fuel, etas calculated, etc.
  }
}

advantage: extensible, in line with OTM downside: harder to use/understand

My current preference goes to the second. Since it is more extensible for other type of 'context' without any changes to the base format. I think it is also more in line with the philosophy of OTM. That said, it might be a bit harder to use, since you would need to extract the emission events out of the list of events before you can use them.

@thomaskolmans, @MGemmink, @ptv-jcl any preferences for either?

[ptv-jcl]

Events seem more logical flow for adding realization data then fields to me.

[bmeesters]

How else would you share events in combination with the target entities they are about? We can add fields to entities, but I doubt that will make the standard simpler in the long run. But I suppose given your answer you would be in favor of option 1? Including one for emissions and one for fuel consumption?

IMO if we can somehow link events and entities that would make a lot of use cases possible without any further changes, which is why I am pushing for it.

[ptv-jcl]

No, I'm in favor of option 2.

[bmeesters]

Ah I guess I misunderstood

[thomaskolmans]

In favor for option 2

[MGemmink]

I'm also in favor of option 2.

[bmeesters]

Alright, thanks everyone for all the input. We'll go with option 2 then.

[bmeesters]

This is now part of OTM5.4