Remote start attempt¶
Remote starts are a way to start a charging session via the CSMS. The flow here is fully asynchronous and brings some challenges to the CSMS, especially as we want to provide APIs around it to enable third parties to integrate. In addition to the OCPP case the remote start attempt is also built in mind with different protocols in the backend, where remote starts are not only triggered on stations directly within the system, but stations potentially reached via different interfaces (e.g. roaming).
Due to the asynchronicity and the fact that a remote start request not automatically results in a charging session, an extra data structure is introduces, which we call here remote start attempt. The remote start attempt is created at the point the remote start is enqueued. This is a reference which will then later on to a charging session within the backend.
OCPP flow¶
In order to understand the challenges, one can face with a remote start, we first will have a look into the details of remote start via OCPP which nevertheless if its roaming or direct communication with the station, will be somehow executed.
As you can see here there is no direct link between the actual remote start attempt and the resulting charging session which is created during the processing of the start transaction. Rather the backend can only guess which attempt belongs to the start transaction, based on the station, connector (EVSE) and identifier information used (Starting with OCPP 2.0.0 onwards we can reference the charging session directly).
Remote start attempt flow¶
The flow for the “happy case” can be seen as following.
A remote start attempt first comes into the status pending. The remote start attempt will then be triggered. As soon as we set up the first transmission to the station, we change the attempt to sending.
In case of of an successful response with the status Accepted, the status of the remote start attempt changes to waiting_for_start_transaction. This status will be then finally end in charge_log_attached as soon as we receive a start transaction. Note that between all those state changes there might be various reason why a remote start attempt could be seen as failed (e.g. receive a Rejected from the station or the station is currently offline etc.)
There is additional information in the failedReason property which gives more insights to the failed status.
Possible failure reasons:
| Code | Description |
|---|---|
| unknown_station_communication_type | The system could not determine the communication type of the station. This can only happen if the station might be manually set up and not configured correctly. |
| cp_configuration_is_invalid | Similar to unknown_station_communication_type this might only happen a station is configured incorrectly or combinations of parameters are used which are not matching (e.g. a connector was chosen which does not belong to the station (or was deleted). |
| unknown_error | An unexpected error happened during the execution |
| rejected_by_station | the station answered with rejected (comes in combination with the rejected status) |
| station_communication_error | the communication with the station failed (e.g. no response or station was not reachable if soap was used) |
| unknown_status_from_station | the station responded with a different status than Accepted or Rejected |
| timeout_reached | marked attempt as failed as valid until was reached and no transaction started. |
State transitions¶
The different state changes can be appear in the following order:
The remote start attempt will be potentially put back to pending if some form of retry is happening (e.g. trying to send the same parameters again might cause a refresh of the remote start attempt instead of creating a new one).
- A remote start attempt counts as finished if:
- the charging session was started
- a failure happened (e.g. station did not respond)
- the station rejected the remote start attempt.
State descriptions¶
- pending: This status indicates that the remote start attempt has been successfully accepted by the backend system, and the validation of input parameters succeeded. The remote start request has been enqueued for transmission to the respective station.
- sending: The remote start is being sent to the station. For stations that are connected, this means the remote start message has been sent to the station and the backend system is awaiting the response of the station. If the response is negative and the remote start request is rejected, the remote start attempt will be transitioned to the failed state. If the station accepted the request, the remote start attempt is transitioned to the waiting_for_start_transaction state.
- waiting_for_start_transaction: In this state, the backend system awaits a StartTransaction message from the station which will then be associated with the previous remote start request. Should a timeout occur, the remote start attempt will enter the “failed” state. However, when the backend system receives a session, the remote start attempt transitions to the “charge_log_attached” state.
- charge_log_attached: In this state, the system has received a session and the session was linked to the Remote Start Request.
- failed: In this state, the remote start attempt failed and is enriched with a failure reason.