TC_036_CS — Connection Loss During Transaction
TC_036_CS — Connection Loss During Transaction
Source: OCPP 1.6 — Compliancy Testing Tool — Test Case Document (Trial 2025-06, Draft). System Under Test: Charge Point, page 47.
Identification
| Field | Value |
|---|---|
| Test case name | Connection Loss During Transaction |
| Test case Id | TC_036_CS |
| System under test | Charge Point |
Description
This scenario is used to cache meter values, when a connection loss occurred during a transaction.
Purpose
To test if the Charge Point is able to handle a connection loss during a transaction, without (for example) losing meter values.
Prerequisite(s)
- N/a
Before (Preparations)
Configuration State(s):
- MeterValueSampleInterval is <Configured MeterValueSampleInterval>
Memory State(s):
- N/a
Reusable State(s):
- Charging
Scenario Detail(s)
| Charge Point (SUT) | Central System (Tool) |
|---|---|
| [Remove the connectivity between the Charge Point and the Central System.]; [Wait till charge point sends few meter values (at least 3)]; [Restore the connectivity between the Charge Point and the Central System.]; [Charge Point sends all queued meter values.]; 1. The Charge Point sends a MeterValues.req | 2. The Central System sends a MeterValues.conf |
Tool validation(s)
Charge Point side:
Step 1:
(Message: MeterValues.req)
- All queued meter values need to be sent in chronological order (Also before sending any new meter values).
- Between the reported timestamps need to be a number of seconds equal to the <configured MeterValueSampleInterval>
- The OCTT checks that all MeterValues.req messages that should have been queued are received. This is determined based on the timestamp fields.
- The sampledValue.format should be Raw or omitted.
- The sampledValue.context should be Sample.Periodic or omitted.
Central System side:
- N/a
Expected result(s) / behaviour
Charge Point side:
- N/a
Central System side:
- N/a