PARKING_TIME and duration restrictions

[sstephany]

I'm looking for guidance in interpreting duration restrictions as they relate to PARKING_TIME.

PARKING_TIME is defined as "time not charging".

If I set a min_duration restriction for PARKING_TIME of, let's say 300 seconds (5 minutes), is the interpretation: a) exclude the first 5 minutes of any parking time incurred relative to the start of the charge session? b) exclude the first 5 minutes of any parking time incurred in total? c) exclude the first 5 minutes of any parking time incurred after the end of the last charging period?

Thanks in advance for any perspectives on this!

[RobertDeLeeuw]

This is a question about Tariffs Your example is a TariffElement (part of a Tariff) This TariffElement has a restriction: min_duration of 300 seconds and has at least PriceComponent with dimension: PARKING_TIME.

the specification is not really clear on this. 'Minimum duration in seconds the Charging Session is ongoing.' Which I think means: The entire Charging Session. So, that would mean A. I would describe it as: When a Charging Session is longer then 300 seconds, this TariffElement is used.

[mbayings]

See also example on p99 and 100 from V2.2 RC2. It is meant to be that 'counting' the parking time starts after the min_duration period. But totally agree that that is not clear. The idea is that there are situations where parked-not charging starts after 2 hours and not immediately when the car is full.

[RobertDeLeeuw]

Problem is, there might be 2 different things companies want from a tariff:

• If you have charged for longer then: X seconds, parking is cheaper, free, or more expensive etc.
• First X seconds of parking (after charging) is cheaper, free, or more expensive etc.

If we want to make both possible, we might need to add: min_parking_duration / max_parking_duration.

[mbayings]

I don't see the first point. And the second point is already possible. And please don't support and implement and use the first point. EV drivers will not understand it and operators and service providers can probably not explain it in a clear understandable transparant way - not only after the charge action, but also before.. And then you act against laws and regulations and more important it will discourage people to use an EV.

[RobertDeLeeuw]

We can update the text of min_duration / max_duration duration to explain, that when used in combination with a PARKING_TIME dimension.

But a TariffElement can contain more then 1 PriceComponent, each PriceComponent has its own type/TariffDimensionType. What if a TariffElement contains both a PARKING_TIME and an ENERGY Dimension, what would the meaning of a min_duration tariff restriction mean? TariffElement valid aftermin_durationof the Charging Session? Or themin_duration` after charging has ended, and parking has started?

[sstephany]

I think @RobertdeLeeuw-IHomer hit the crux of the issue when he asks re: the meaning of min_duration tariff restriction, "TariffElement valid after min_duration of the Charging Session? Or the min_duration after charging has ended, and parking has started?"

I see two difficulties when using the spec to cover a variety of business cases is that it doesn't address

• We have no way of knowing in advance how long it will take to charge the vehicle, so we can't set anything relative to the event that represents the end of charging
• Tariff restrictions are not described as being relative to each other or their contained price_components, so the assumption is that min_duration is relative to the only thing we're certain of, the beginning of the start of the entire charge session (authentication + connect to disconnect)

Because of this a business is unable to describe a min_duration restriction relative to when the vehicle stops charging but is still connected. Granting someone 30 minutes to disconnect their vehicle after the charge is complete before incurring parking charges does not appear possible without recognizing this event, for example.

@RobertdeLeeuw-IHomer's idea of introducing min_parking_duration / max_parking_duration, defined as the min/max duration relative to the end of receiving a charge may be the best solution, as it preserves backwards compatibility by allowing the author of the tariff the ability to restrict PARKING_TIME like any other TariffDimension type using max/min_duration, but adds the ability to restrict PARKING_TIME relative to the end of a vehicle receiving a charge. Applying min/max_parking_duration to the end of receiving a charge only really seems applicable with PARKING_TIME, though, so there's no clear way to limit usage of these attributes to this TariffDimensionType only.

I agree with @mbayings when he states "If you have charged for longer then: X seconds, parking is cheaper, free, or more expensive etc." is going to be confusing to drivers, and even more difficult for businesses to explain it, but from what I can tell this is the only consistent way to interpret min/max_duration across all TariffDimensionTypes, since TariffDimensionTypes appear to all share the definitions of TariffRestrictions. Nowhere does the spec suggest TariffRestrictions should be defined differently based on the TariffDimensionType.

[sstephany]

I didn't mean to scare anyone off with my last post :-)

We're considering redefining the way we apply min/max duration altogether with one simple approach, to apply min/max duration to the aggregate of any TariffDimensionTypes defined as price components.

To illustrate this, let's say I define a TIME and PARKING_TIME component, each with a min_duration of 5 mins.

Now take someone who charges for 30 minutes, and spends 2 hours NOT charging. Total "charge session" time is 2.5 hours. The 5 minute min_duration would be applied to both totals in aggregate, meaning the driver would be charged for: 25 minutes (TIME) and 115 minutes PARKING_TIME.

We can apply this logic unilaterally for any series of PriceComponents in a TariffElement.

Would appreciate any thoughts on this approach @mbayings @RobertdeLeeuw-IHomer

[RobertDeLeeuw]

@sstephany I was waiting for others to provide their input. (and taking a vacation)

If we would update OCPI to work like this, we loose the other, but probably less used use case: "If you charge for longer the X seconds... then..." So we really need more OCPI implementers to give their feedback on this. We might break existing 2.1.1 implementations by changing this.

[paumartin]

Hi! Any update on this issue?

[RobertDeLeeuw]

We ended up not including the proposal of @sstephany in 2.2. Because would didn't know if we would break existing implementations. We did improve the description of min_duration and max_duration to better reflect the original idea. But yes, that means we do not support the other use cases yet.