Monitor fleet charging sessions: Read the data correctly

Monitoring charging sessions centrally means considering the state of a charging session, the latest data and its operational significance together. For each relevant session in your electric fleet, you therefore need a clear assignment, reliable timestamps and a next action. An entry in the charging overview alone does not tell you whether a vehicle is currently receiving energy or whether the billing data is already complete.

This distinction is especially useful when several people work with the same data. Dispatch, fleet management and finance ask different questions about a charging session. A shared definition of statuses prevents them from drawing different conclusions from the same display.

Which states should you consider separately?

Start by defining three levels. The technical state describes what the charging infrastructure last reported. The transaction state shows which information about an individual charging session has arrived. The processing state describes whether your team still needs to complete an assignment or a check.

A useful operational sequence might be: session detected, session in progress, ended, data complete, assignment verified. These terms are a suggestion for your process. The information actually available depends on the software you use and its data sources.

Transactions and monitoring are also treated separately at protocol level. For OCPP 2.0.1, the Open Charge Alliance describes configurable transaction start and end conditions as well as a device model for configuration and monitoring. This does not establish a general real-time capability for a fleet portal. Source: OCA on transaction handling.

Timestamps make a charging overview reliable

When assessing software, ask for an explanation of every timestamp. Relevant times include the start and end of a session, the time of the latest message and the time that message reached the system. A later correction may have its own timestamp too.

A session that ended two hours ago but was only transmitted five minutes ago belongs to the period when charging took place. At the same time, the transmission delay matters when assessing data quality. Do not combine these two purposes into a single date.

Also define when data becomes too old for your work. An outdated status can matter for a departure in half an hour. For a monthly report, a record completed later may be sufficient. The threshold follows your operational needs; it is not a universal technical constant.

Turn notifications into cases someone can resolve

A monitor is useful when an issue reaches someone responsible for handling it. For every case you monitor, define four things: the trigger, the owner, the response deadline and the completion criterion. This helps you avoid a list of notifications that nobody takes responsibility for.

For a charging session without an assigned vehicle, the completion criterion could be the confirmed assignment. If status messages stop arriving, the first criterion is: data source checked and actual vehicle condition clarified. A missing message alone does not prove a technical fault.

Also define when notifications should be grouped. Ten updates about the same problem should not create ten independent tasks. A case reference connects the initial notification, questions, processing and resolution. Use a concrete test case to check whether the software directly supports these tasks.

Practical example: An old status before the early shift

Fictional practical example: At 6:30 am, dispatch checks twelve vehicles scheduled to depart at 7:00 am. For one vehicle, the overview shows a charging session in progress, but the latest message is from 4:10 am. The display is therefore insufficient to confirm that the vehicle is ready for use.

The person responsible arranges an on-site check of whether the vehicle is connected and what state of charge it displays. Data transmission is checked at the same time. The vehicle is ready for use; only the incoming data feed had been interrupted. The observation, feedback and completion time are documented in the case.

The operational lesson is that an “outdated data” warning triggers clarification. It is not automatically counted as a failed charging session. For later analysis, communication problems and charging sessions that actually stopped prematurely remain separate categories.

Practical checklist: Fields your review sheet needs

Use a table with the following columns for your next software discussion:

• Session ID and charging location, so the case can be found unambiguously.

• Vehicle, driver or cost centre, where necessary for the purpose.

• Reported state and a clear definition of that state.

• Event time, latest data arrival and identifiable gaps in the data.

• Person responsible, next action and agreed deadline.

• Reason for closure and any information still outstanding.

Test the sheet with a normal charging session, a session reported late and a session with a missing assignment. Record which data is actually available. Where information is missing, add a practical way to clarify it. An empty column should not create a false sense of certainty.

For regular analysis, you can carry the findings into your monthly fleet reporting. Recurring causes deserve an action of their own with a named owner. Also define which issues should trigger a notification for the fleet team that requires a prompt response.

Use your specific questions about status information to discuss which data and assignments you need in day-to-day work: discuss your fleet requirements with StromNow.