everest / libocpp Goto Github PK

It can (and already did) happen that a CSMS does not respond to a BootNotification.req with a BootNotification.conf before the timeout occurs. Then the BootNotification.req should be retried.

In charge_point.cpp method on_transaction_finished a hardcoded ISO14443 token type is used, where the token type that started the transaction is expected.

Not really a charging station use case. As soon as we start implementing a satelite style architecture, where the satelites also talk OCPP directly via the central node, we should implement this for optimizing updating the firmware in the satelites.

Functional Requirements

• K16.FR.01: Precondition CSMS sends a new SetChargingProfileRequest. Charging Station SHALL respond with a SetChargingProfileResponse with status = Accepted.

• K16.FR.02: Precondition K16.FR.01. Charging Station SHALL initiate schedule renegotiation with EV. Note: In ISO 15118 this is done by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message.

• K16.FR.03: Precondition K16.FR.02. Charging Station SHALL provide the ChargingSchedule data to the EV. Note: In ISO 15118 this is done in the ChargeParameterDiscoverRes message

• K16.FR.04: Precondition EV returns a charging profile. Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS. Note: In ISO 15118 EV may provide this as part of the PowerDeliveryReq message.

• K16.FR.05: Precondition K16.FR.04. Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.

• K16.FR.06: Precondition K16.FR.05 AND EV charging profile is within limits of CSMS ChargingSchedule. CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station. Note: Already checked by Charging Station, but CSMS does its own check.

• K16.FR.07: Precondition K16.FR.05 AND EV charging profile is NOT within limits of CSMS ChargingSchedule.
  CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.

• K16.FR.08: Precondition K16.FR.07. CSMS starts new renegotiation as per use case K16.

• K16.FR.09: Precondition When the Charging Station receives charging needs from the EV. The Charging Station SHOULD NOT send a NotifyEVChargingNeedsRequest to the CSMS. Note: CSMS initiated the renegotiation and has just sent a new charging profile, based on the initial charging needs from EV, energy already consumed by EV and whatever information has caused CSMS to update the charging profile. In ISO 15118 charging needs are sent via ChargeParameter-DiscoveryReq.

• K16.FR.10: Precondition K16.FR.04. The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.

• K16.FR.11: Precondition K16.FR.02 AND current or power in new charging schedule is lower than actual current or power. The Charging Station SHALL request EV to lower current or power to a value matching the new charging schedule at the first possible opportunity. Note: In ISO 15118 this can be communicated in CurrentDemandRes (for DC) or ChargingStatusRes (for AC).

• K16.FR.12: Precondition K16.FR.09 AND Charging Station sends a NotifyEVChargingNeedsRequest. The CSMS SHALL send a SetChargingProfileRequest. This situation is not desirable, because charging profile will likely be the same as in K16.FR.01, but this is added for robustness when Charging Station is not adhering to K16.FR.09.

• K16.FR.13: Precondition EV does not return a charging profile. Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the schedule that was selected by the EV (i.e. chargingSchedule.id = SAScheduleTupleId) In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupleId in PowerDeliveryReq.

I created two networkconnectionprofiles, but the setting 'networkconfigurationpriority' is set to 2 only. When networkconnectionprofile 2 can not connect, the application crashes:

(websocket_plain:252)  [info    ] [libocpp]  Closing plain websocket.
(websocket_plain:259)  [error   ] [libocpp]  Error initiating close of plain websocket: invalid state
(charge_point.cp:719)  [warning ] [libocpp]  Closed websocket of NetworkConfigurationPriority: 1 which is configurationSlot: 2
(charge_point.cp:822)  [info    ] [libocpp]  Switching to next network configuration priority
terminate called after throwing an instance of 'std::out_of_range'
what():  vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)
[email protected]: Main process exited, code=killed, status=6/ABRT
[email protected]: Failed with result 'signal'.

To give the CSMS the ability to request a report of all Components and Variables limited to those
that match ComponentCriteria and/or the list of ComponentVariables.

Use Cases to Adapt from OCPP 1.6J Implementation:

• #361 - Work in Progress
• #362
• #363
• #364
• #365
• #366
• #367
• #368 - Work in Progress
• #369

New Use Cases in OCPP 2.0.1:

• #309
• #310
• #311
• #312
• #313
• #314
• #315
• #316

From OCPP 2.0.1: Part 2, §3, Table 10 (condensed):

• FR.01: The sender of a <message>Request SHALL wait for a <message>Response or a timeout, before sending another request message.
• FR.02: When the Charging Station receives a valid OCPP request message according to the JSON schemas / RPC Framework AND the other system is not causing a security violation, the Charging Station SHALL respond with a RPC Framework: CALLRESULT.
  • If the Charging Station/CSMS needs to provide additional information, this can be done in the statusInfo element of the response message.
• FR.03: When the Charging Station/CSMS receives an invalid OCPP message according to the JSON schemas / RPC Framework OR the other system causes a security violation, the Charging Station/CSMS SHALL respond with a RPC Framework: CALLERROR.
• FR.04: When the CSMS did not accept the BootNotificationRequest from the Charging Station AND the Charging Station sends a message other than BootNotificationRequest, the CSMS SHALL respond with a RPC Framework: CALLERROR: SecurityError.
• FR.05: There are a few messages that do not provide their result in the response message, but send one or more messages that contain the result. When one of the following messages is received; GetReport, GetBaseReport, GetMonitoringReport, GetDisplayMessages, CustomerInformation, GetChargingProfiles, GetLog, UpdateFirmware, PublishFirmware, TriggerMessage(<message>), the Charging Station SHALL acknowledge the requests in the list below with a response message first, before sending the follow-up message shown after the arrow (→):
  • GetReport → NotifyReport
  • GetBaseReport → NotifyReport
  • GetMonitoringReport → NotifyMonitoringReport
  • GetDisplayMessages → NotifyDisplayMessage
  • CustomerInformation → NotifyCustomerInformation
  • GetChargingProfiles → ReportChargingProfiles
  • GetLog → LogStatusNotification
  • UpdateFirmware → FirmwareStatusNotification
  • PublishFirmware → PublishFirmwareStatusNotification
  • TriggerMessage(<message>) → <requested message>
  • Note: The CSMS needs to know that a request was accepted, so that it can expect result messages.

E.g. the close_connection() and open_connection() are quite similar between 1.6 and 2.0.1. And now in 2.0.1 there's a bug-fix in close_connection() not transferred to 1.6, yet:

• #288

• K17.FR.01: Precondition EV triggers a renegotiation and sends new charging needs The Charging Station SHALL send a NotifyEVChargingNeedsRequest to the CSMS.
• K17.FR.02: Precondition K17.FR.01. In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.
• K17.FR.03: Precondition K17.FR.02. If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Accepted'.
• K17.FR.04: Precondition K17.FR.02. If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Rejected'.
• K17.FR.05: Precondition K17.FR.02 If the CSMS is able to provide a charging schedule; but needs processing time, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Processing'.
• K17.FR.06: A NotifyEVChargingNeedsRequest SHALL contain either ACChargingParameters or DCChargingParameters.
• K17.FR.07: Precondition K17.FR.03 or K17.FR.05. The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and at most three chargingSchedule and optional salesTariff elements, that each contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable SmartChargingCtrlr.PeriodsPerSchedule.
• K17.FR.08: Precondition K17.FR.01. The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds. Note: This is to satisfy the ISO 15118 ChargeParameterDiscoveryReq timeout.
• K17.FR.09: Precondition K17.FR.07 AND EV returns a charging profile. Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS. Note: In ISO 15118 EV can sent its charging profile as part of PowerDeliveryReq.
• K17.FR.10: Precondition K17.FR.09. Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.
• K17.FR.11: Precondition K17.FR.10 AND EV charging profile is within limits of CSMS ChargingSchedule. CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station. Note: Already checked by Charging Station, but CSMS does its own check.
• K17.FR.12: Precondition K17.FR.10 AND EV charging profile is NOT within limits of CSMS ChargingSchedule. CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.
• K17.FR.13: Precondition K17.FR.12. CSMS starts new renegotiation as per use case K16.
• K17.FR.14: Precondition K17.FR.11. The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.
• K17.FR.15: Precondition K17.FR.01 AND Charging Station is offline. The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.
• K17.FR.16: Precondition K17.FR.07 EV does not return a charging profile. Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the schedule that was selected by the EV (i.e. chargingSchedule.id = SAScheduleTupleId). Note: In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupleId in PowerDeliveryReq.

When BasicAuthPassword is an empty string, libocpp will not continue and not log anything.

Scenario

1. External control system sends charging limit/schedule to Charging Station.

2. Optional: Charging Station calculates new charging schedule.

3. Charging Station adjusts the charging speed of the ongoing transaction(s).

4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.

5. The CSMS responds with NotifyChargingLimitResponse to the Charging Station.

6. If the charging rate changes by more than: LimitChangeSignificance, the Charging Station sends a TransactionEventRequest message to inform the CSMS.

7. The CSMS responds with TransactionEventResponse to the Charging Station.

Functional Requirements

• K11.FR.01: When an external charging limit/schedule is received during an ongoing transaction, the Charging Station SHALL NOT charge the ongoing transaction faster than this given limit/schedule.

• K11.FR.02: When K11.FR.01 AND Charging limit changed by more than: LimitChangeSignificance, The Charging Station SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.

• K11.FR.03: When K11.FR.02 AND EnableNotifyCharging LimitWithSchedules is true, The NotifyChargingLimitRequest SHALL contain the charging limits/schedules as set by the external system.

• K11.FR.04: When K11.FR.01 AND Charging rate changed by more than: LimitChangeSignificance, the Charging Station SHALL send a TransactionEventRequest message to the CSMS with trigger = ChargingRateChanged

• K11.FR.05: When K11.FR.02, the Charging Station SHALL NOT set the 'chargingLimitSource' to CSO in the 'NotifyChargingLimitRequest'.

• K11.FR.06: When an external charging limit/schedule is received, the Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (e.g. in a ReportChargingProfilesRequest).

  • It is RECOMMENDED to use negative values for the id of a ChargingStationExternalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile.

Currently we only support TxStopPoint EvConnected,Authorized and TxStartPoint PowerPathClosed. We would like to support more / all TxStopPoint and TxStartPoint s.

Functional Requirements

• K15.FR.01: When the Charging Station receives charging needs from the EV The Charging Station SHALL send a
  NotifyEVChargingNeedsRequest to the CSMS.

• K15.FR.02: Precondition - K15.FR.01 In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.

• K15.FR.03: Precondition - K15.FR.02 If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Accepted'.

• K15.FR.04: Precondition - K15.FR.02 If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Rejected'.

• K15.FR.05 K15.FR.02 If the CSMS is able to provide a charging schedule; but needs processing time, it SHAL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Processing'. Note: The Charging Station does not have to wait for the SetChargingProfileRequest. CSMS will send it later and trigger a renegotiation as per use case K16.

• K15.FR.06 A NotifyEVChargingNeedsRequest SHALL contain either ACChargingParameters or DCChargingParameters.

• K15.FR.07: Precondition - K15.FR.03 or K15.FR.05 The CSMS SHALL send a SetChargingProfileRequest with
  chargingProfilePurpose = TxProfile and a transactionId and at most three chargingSchedule and optional salesTariff elements, that each contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable Smart ChargingCtrlr.PeriodsPerSchedule. Note: The Charging Station will calculate the composite schedule(s) for the EVSE (taking into account a ChargingStationMaxProfile or ChargingStationExternalConstraints if present) and will convert that to the SAScheduleList format for ISO 15118

• K15.FR.08: Precondition- K15.FR.01 The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds. Note: This is to satisfy the ISO 15118 ChargeParameterDiscoveryReq timeout.

• K15.FR.09: Precondition - K15.FR.07 AND EV returns a charging profile. Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS. In ISO 15118 EV can sent its charging profile as part of PowerDeliveryReq.

• K15.FR.10: Precondition K15.FR.09 Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.

• K15.FR.11: Precondition K15.FR.10 AND EV charging profile is within limits of CSMS. ChargingSchedule CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station. Note: Already checked by Charging Station, but CSMS does its own check.

• K15.FR.12: Precondition K15.FR.10 AND EV charging profile is NOT within limits of CSMS ChargingSchedule CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.

• K15.FR.13: Precondition K15.FR.12 CSMS starts new renegotiation as per use case K16.

• K15.FR.14: Precondition K15.FR.11 The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.

• K15.FR.15: Precondition K15.FR.03 AND Charging Station is offline. The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.

• K15.FR.16: Precondition K15.FR.07 It is RECOMMENDED to configure the Charging Station, such that a TransactionEvent with idToken has been sent prior to the NotifyEVChargingNeedsRequest Message, so that CSMS can take the user into account when creating a charging schedule.

• K15.FR.17: Precondition When Charging Station receives a SetChargingProfileRequest immediately after the transaction has tarted and before it has sent the NotifyEVChargingNeedsRequest to CSMS. The Charging Station SHOULD respond with SetChargingProfileResponse with status = Rejected and a statusInfo with reasonCode= InvalidMessageSequence. CSMS sent profile too early. It does not harm if CS accepts the charging profile instead of rejecting it, as long as it sends a charging profile again when it receives the NotifyEVChargingNeedsRequest.

• K15.FR.18: Precondition K15.FR.03 OR K15.FR.05. CSMS IS RECOMMENDED to use only one chargingSchedule in a SetChargingProfileRequest. This ensures that there is no doubt about which schedule the EV will follow, even when no NotifyEVChargingScheduleRequest is received.

• K15.FR.19: Precondition K15.FR.07 AND EV does not return a charging profile Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the schedule that was selected by the EV (i.e. chargingSchedule.id = SAScheduleTupleId) In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupleId in PowerDeliveryReq.

Scenario

1. The CSMS asks the Charging Station for the installed charging profiles by sending a
   GetChargingProfilesRequest message.
2. The Charging Station responds, indicating if it can report Charging Schedules by sending a
   GetChargingProfilesResponse message.
3. Charging Station sends a number of ReportChargingProfilesRequest messages to CSMS.
4. The CSMS acknowledges reception of the reports by sending a
   ReportChargingProfilesResponse to the Charging Station for every
   ReportChargingProfilesRequest.

Functional Requirements

• K09.FR.01: When requestId is set in the GetChargingProfilesRequest, the Charging Station SHALL set the requestId in every ReportChargingProfilesRequest that is sent as a result of this GetChargingProfilesRequest.
• K09.FR.02: When the charging profiles are reported in more than one ReportChargingProfilesRequest, the Charging Station SHALL set the tbc flag to true for all ReportChargingProfilesRequest messages except the last.
• K09.FR.04: If evseId is set to a value greater than 0 in the GetChargingProfilesRequest, the Charging Station SHALL report the installed charging profiles for the specified EVSE that match all fields in chargingProfile.
• K09.FR.05: If evseId is set to 0 in GetChargingProfilesRequest, the Charging Station SHALL only report charging profiles installed on the Charging Station itself (the grid connection) that match all fields in chargingProfile.
  • EVSE #0 can have a ChargingStation MaxProfile, ChargingStation ExternalConstraints or a TxDefaultProfile. Note, that a TxDefaultProfile is not applied to EVSE #0 but to all individual EVSEs (see K01.FR.14).
• K09.FR.06: If evseId is NOT set in the GetChargingProfilesRequest, the Charging Station SHALL report all installed charging profiles that match all fields in chargingProfile.
• Table 175, No. 7: When the Charging Station has no charging profiles that match the parameters in the GetChargingProfilesRequest the Charging Station SHALL respond with: NoProfiles.

Not really a charging station use case. As soon as we start implementing a satelite style architecture, where the satelites also talk OCPP directly via the central node, we should implement this for optimizing updating the firmware in the satelites.