Ask Flux
Help Center
How can we help?

Parking/Idle Price Component

Introduction

GreenFlux platform enables its customers to define parking price in the Billing Rule (price model) to bill a certain cost, per minute, when the car is in parking/idle mode.

The parking price will be calculated after the vehicle starts consuming near zero energy from the charger while the session is still ongoing. This price component (parking price) is also sometimes referred to as idle fee.

⚠️

Check later in this article the MUST requirements that need to be in place for you to use a tariff with parking price component.

Definition: Updated price model structure enabled by GreenFlux platform

To define a certain price model, in GreenFlux, it is now possible to choose several price components, which are defined in each billing rule. Each billing rule can have one or multiple price components, from the following ones:

  1. Start price component: Start Fee means the fee payable when an individual starts the session. This is also sometimes referred to as flat rate.
  1. Price per kWh component: kWh Fee is the fee for each kWh consumed in the entire session. It is possible to make it a bit more complex and also define a threshold, e.g. from 0 to 10 kWh, the price is x €/kWh, above 10 kWh, the price is y €/kWh, being the threshold 10 kWh in this case.
  1. Price per minute component: The minute Fee is the fee payable every minute while the session is in charging mode. It is possible to make it a bit more complex and also define a threshold, e.g. from 0 to 60 min, the price is z €/min, above 60 min, the price is w €/min, being the threshold 60 min in this case. Please note that when you use a tariff without parking price component, and without Time of Use, nor Dynamic Time Based tariff active, then the system will calculate the per minute price component for the entire session's duration.
  1. Parking price per minute component: The parking fee is payable every minute when the EV is connected to the charging station, and there is no energy consumption. It is possible to make it a bit more complex and also define a threshold, e.g. from 0 to 30 min (of parking time), the price is a €/min, above 30 min, the price is b €/min, being the threshold 30 min in this case.

Parking tariff: behavior and price computation

Note: Parking can be detected at any point when the EV is connected to the Charge station, as per the example hereunder:

Considering a session with the above behavior, we would have the following:

  1. The session has a total of 75 minutes in charging mode
  1. The session has a total of 60 minutes in parking mode (0 kWh)
  1. Total session duration of 135 minutes
  1. The session has a total of 8.5 kWh consumed
⚠️

The current billing engine design, determines that the parking computation of costs is only possible when the customer has explicitly opted for Time of Use (ToU) or Dynamic Time Based tariff (DTB) mechanism.  Please see below the last section for reasoning behind such restrictions.

Note: In case customer decides to use parking price per minute without setting ToU Or DTB, then parking price per min will be ignored. To alert User, GFX will add a logic to notify users when a tariff is selected on a charge station.

For the scenario illustrated above (75 min charging mode, 60 min parking,. ..), let us assess with 3 illustrative examples (different tariffs/price models), what the price computation will be:

Notion image

Technical details

Parking detection algorithm

The parking detection algorithm GreenFlux implements consists of assessing the average power between two meter values over a time frame of at least 15 minutes. When the average power is below or equal to 300 W, then the session is considered to be in parking mode. To be clear, the parking mode initiates in the initial time of the period being assessed.

Also important in the design of this algorithm is that GreenFlux assesses consecutive periods which are separated at least 15 minutes from each other.  As follows, we are providing an example for a concrete situation where charge station is communicating meter values every 8 minutes.

📜

This explanation around the parking detection considers a different scenario from the one in the example given at the beginning (where we could clearly see the meter values wer being sent with a 15 minute sample period). In the below example, the choice of the (perhaps unusual) 4 minutes sample period, is simply to illustrate that the assessment of the parking status is not done with a frequency less than 15 min. In this concrete case (sample period = 4 min), the lowest multiple of 4 that is bigger than 15 is 16, and that's what determines the frequency where parking status is detected.

Note: the above meter values represent in each period (4 min) the total energy delivered by the charge station during that time frame (4 min).

Notion image

SmartCharging exception:

GreenFlux SmartCharging Profiles are taken into account when deriving a parking state. I.e. if the Smart charging algorithm puts the charging profile to 0 Wh, the state will still be considered 'Charging'.

Configuration requirements - checklist

ℹ️

These configuration steps are only required until 30/June. From the 1st/July, tariffs with parking/idle fee component will work well, even without these configurations in place.

In order to work smoothly, this use case foresees that charge station has the following set of configurations:

  1. Requirement 1 - MUST: It is sending meter values: Energy Active Import Register.
  1. Requirement 2 - MUST: Charger MUST have either Time of Use (ToU) feature enabled or Dynamic Time Based (DTB) tariff feature enabled, as per below alternative scenarios.
    1. Check here how to enable Time of Use tariff feature: ToU - check 'Configuration steps - checklist' section
    2. Check here how to enable Dynamic Time Based tariff feature: DTB - check 'Configuration steps - checklist' section
Notion image
  • Requirement 3 - MUST: Customer picks a tariff which contains billing rule(s) with parking price per minute component, of course.
  • OPTIONAL: Additional details in CDR - only applicable to platform API, not visible through EvPortal for instance:
    • In order to guarantee that the CDRs (obtained through CA API) detailed data on the cost structure throughout the session as well as the associated tariff detailed structure throughout the session, a special configuration needs to be enabled for each platform API subscription. This needs to be requested through your CSM.

Happy Flow and Exceptions

The happy flow considers the charge station to have the proper configuration settings, as per above, plus it considers the charger to be connected to GreenFlux back-end, continuously communicating session related information, which is the basis for assessing parking mode.

What happens in extraordinary circumstances?

Situation 1: The charge station does not send meter values

This is a faulty behavior from the charge station and/or incorrect configurations from the charge point operator (CPO), because when there are no meter values being received, then GreenFlux platform does not know what is the energy being consumed and as such cannot calculate the session cost.

Situation 2: The charge station is offline throughout the whole session, including start and stop.

This is a bit dependent on how the charge station sends the information. But as a general rule of thumb, when all information is received in the correct order of events (chronologically) speaking, then GreenFlux platform should be able to process those and generate a CDR with the separation between charging and parking, when applicable.

CDR special configurations

When detailed cost breakdown, including applicable tariff elements, are required in the CDR (see properties total_wholesale, total_retail and total_reimbursement in this page: CDR API (greenflux.com)), then a configuration item needs to be enabled in the platform API subscription. Only from the moment this configuration is enabled in the subscription, these properties will start being available to be retrieved (without retroactive effects). This configuration is requested through your CSM.

Reasons to allow parking time/cost with ToU or DTB.

Because of following contraints, GFX decided to temporarily allow parking time/cost with ToU/DTB.

  • Constraint 1: If a customer has not opted for the ToU or DTB mechanisms (ToU meaning time of use(ToU) tariff, details here; DTB meaning Dynamic time based tariff, details here) then ‘Time’ in our charging period is related to time charging and parking, i.e. the time is between session start and session stop, regardless of charger/non-charging status. However, if a customer has chosen ToU/DTB, then ‘Time’ relates ONLY to time charging.
  • Constraint 2: In the existing billing model(without ToU/DTB), the price per minute concerns the entire session's duration (includes both period while charging and while in parking mode). Therefore, if a customer has a price component of 1 euro per minute and another parking cost component of 1 euro per minute, and considering a session with a total parking time of 20 minutes, the customer would be charged 40 euros.
  • Constraint 3: In the tariffs module, we communicate with the customer using the rate of 1 euro per parking minute, while we apply both the parking cost and the price per minute to the parking duration.
Did this answer your question?
😞
😐
🤩