Known issues OCTT

Known Issues: Release 2026-09

• OCPP 2.1 Known Issues

  • SUT CS:

    • B Provisioning

      • Known Issue Summary:
        The testcases are incorrectly failing when the TransactionEventRequests with trigger reason *ResetCommand* are sent after a ImmediateAndResume reset request. This transaction event is required as per B13.FR.04
        • Affected Testcases:
          TC_B_102_CS, TC_B_103_CS
        • Situation: ImmediateAndResume is supported
        • Work around: None
      • Known Issue Summary:
        The OCTT incorrectly does not include the Configured Unsupported componentCriteria as part of the GetReportRequest.
        • Affected Testcases:
          TC_B_19_CS
        • Situation: Always
        • Work around: n/a
    • C Authorization

      • Known Issue Summary:
        The OCTT does not proceed to the TxStopPoint and is not able to validate the TransactionEvent Ended after Masterpass Deauthorization.
        • Affected Testcases:
          TC_C_14_CS
        • Situation: When TxStopPoint is EVConnected.
        • Work around: Use another TxStopPoint or manually disconnect the cable after the Deauthorization.
    • E Transactions

      • Known Issue Summary:
        The transaction event containing the LimitReached trigger reason is not captured by OCTT resulting in test case timeout and failure
        • Affected Testcases:
          TC_E_106_CS, TC_E_107_CS
        • Situation: When transaction limits are supported
        • Work around: Logfiles can be manually reviewed
      • Known Issue Summary:
        Transaction event with trigger reason LimitSet is not handled correctly, resulting in a failure.
        • Affected Testcases:
          TC_E_105_CS
        • Situation: When transaction limits are supported
        • Work around: None
      • Known Issue Summary:
        The OCTT does not set the transaction limit during the energyTransfer reusable state as expected
        • Affected Testcases:
          TC_E_105_CS
        • Situation: Always
        • Work around: None
      • Known Issue Summary:
        The user does not receive any prompt for the manual action between step 5 and 6, causing the test case to incorrectly timeout.
        • Affected Testcases:
          TC_E_102_CS
        • Situation: Always
        • Work around: When the test case reaches step 5 and 6, the test case should provide enough time to set a limit on the charging station and continue.
      • Known Issue Summary:
        The test case is incorrectly attempting to set the readOnly component variable supportedLimits during preparation steps resulting in a INCONC result.
        • Affected Testcases:
          TC_E_10X_CS
        • Situation: When supportedLimits contains more members of the TransactionLimitType than what the one expected by the test case
        • Work around: None
      • Known Issue Summary:
        The OCTT reports a CostUpdated for the incorrect transactionId and therefore the transaction limit will never be reached resulting in unexpected failure.
        • Affected Testcases:
          TC_E_101_CS
        • Situation: Always
        • Work around: None
      • Known Issue Summary:
        OCTT does not respond with the {“idTokenInfo”:{“status”:”Accepted”}} when the transaction is started with TxStartPoints PowerPathClosed or EnergyTransfer and the first transaction event is chargingState=charging.
        • Affected Testcases:
          TC_E_41_CS, TC_E_42_CS, TC_E_50_CS, TC_E_51_CS
        • Situation: Only when the testcase fails.
        • Work around: Change TxStartPoint to Authorized.
    • I Tariff And Cost

      • Known Issue Summary:
        The OCTT is statically using 1001 elements instead of TariffMaxElements +1 in ChangeTransactionTariffRequest leading to an overflowing log. This might be expected for a PASS if the SUT supports an amount lower than 1001 elements or lead to a FAIL if more than 1001 elements are supported.
        • Affected Testcases:
          TC_I_113_CS
        • Situation: If your SUT supports TariffMaxElements higher than 1001.
        • Work around: n/a
      • Known Issue Summary:
        The OCTT is not sending the SetDefaultTariffRequest while specified by the Part 6 – Test case document.
        • Affected Testcases:
          TC_I_108_CS
        • Situation: Always
        • Work around: n/a
      • Known Issue Summary:
        The test case does not allow sufficient time to ensure that I08.FR.32 is tested.
        • Affected Testcases:
          TC_I_107_CS
        • Situation: Always
        • Work around: Ensure {{TariffCostCtrlr}} {{RunningCost}} is enabled. This can be done by executing the preparation steps of TC_I_101_CS. Once enabled the transaction event with Started will contain cost details that can be verified though manual inspection.
      • Known Issue Summary:
        Incorrect cost calculation values used.
        • Affected Testcases:
          TC_I_121_CS
        • Situation: Always
        • Work around: None
    • K Smart Charging

      • Known Issue Summary:
        In Step 3 “SetChargingProfileRequest” instead of the “Provided transactionId from before”, the OCTT sends a random generated transactionId.
        • Affected Testcases:
          TC_K_116_CS
        • Situation: Always
        • Work around: n/a
      • Known Issue Summary:
        The OCTT sends the incorrect charging profile kind, which results in test case failure.
        • Affected Testcases:
          TC_K_110_CS
        • Situation: When EMS control is supported
        • Work around: None
      • Known Issue Summary:
        During preparation steps, OCTT sends {{maxOfflineDuration}} as instance name instead of {{MaxOfflineDuration}}.
        • Affected Testcases:
          TC_K_100_CS
        • Situation: Always
        • Work around: None
      • Known Issue Summary:
        The OCTT attempts to set a non-existent instance of the {{V2XChargingCtrlr}} Component variable {{supportsFeature}}, resulting in failure.
        • Affected Testcases:
          TC_K_100_CS, TC_K_101_CS
        • Situation: When Smart Charging is supported
        • Work around: None
      • Known Issue Summary:
        By default {{chargingSchedulePeriod.numberPhases}} are being sent as part of the SetChargingProfileRequests to all charging station (AC and DC). For DC charging stations, the SetChargingProfileRequests MAY be rejected. OCTT is not taking this into account.
        • Affected Testcases:
          TC_K_XXX_CS, TC_K_XX_CS
        • Situation: DC charging stations that reject SetChargingProfileRequests containing{{chargingSchedulePeriod}}.{{numberPhases}} (For *2.1* this is applicable when {{DCInputPhaseControl}}is false/omitted).
        • Work around: If supported, set {{DCInputPhaseControl}} to {{True}}.
      • Known Issue Summary:
        Incorrect limit validation
        • Affected Testcases:
          TC_K_106_CS
        • Situation: When the charging rate unit is Watts
        • Work around: Set charging rate unit to Amps
      • Known Issue Summary:
        The OCTT iincorrectly fails when the expected *PullDynamicScheduleUpdateRequest* message is received shortly before the expected interval.
        • Affected Testcases:
          TC_K_121_CS
        • Situation: When the PullDynamicScheduleUpdateRequest interval is slightly fast
        • Work around: None
      • Known Issue Summary:
        NotifyEVChargingScheduleRequest limits are being validated without taking into account the different charging rate units. For example when the Watt equivalent limit is specified for Amps, the test case will fail.
        • Affected Testcases:
          TC_K_53_CS, TC_K_58_CS
        • Situation: When the configured charging rate unit is Amps and NotifyEVChargingScheduleRequest is sent with Watts.
        • Work around: Set configured charging rate unit to Watts
    • M Certificate Management

      • Known Issue Summary:
        Default EXIs currently have incorrect signatures.
        • Affected Testcases:
          TC_M_26_CS, TC_M_27_CS, TC_M_28_CS, TC_M_29_CS
        • Situation: Always
        • Work around: Use custom EXIs with correct signatures.
    • N Diagnostics

      • Known Issue Summary:
        OCTT does not allow the sending of multiple status notifications with status ‘uploading’ while the log is uploading.
        • Affected Testcases:
          TC_N_102_CS, TC_N_103_CS
        • Situation: When the charging station sends a stream of uploading status notifications
        • Work around: None
      • Known Issue Summary:
        Some N testcases do not run the EnergyTransferStarted Reusable State correctly when the monitored variable is Power or Current.
        • Affected Testcases:
          TC_N_45_CS, TC_N_51_CS, TC_N_52_CS
        • Situation: When configuring {{EVSE.Power}} instead of {{Power}}.
        • Work around: Configure the monitored variable as Power or Current without additional elements behind it.
    • O Display Message

      • • Known Issue Summary:
          The OCTT enforces language NL – we plan on making this configurable in the future.
          • Affected Testcases:
            TC_O_101_CS
          • Situation: If the SUT does not support language NL.
          • Work around: n/a
    • Q Bidirectional Power Transfer

      • Known Issue Summary:
        The OCTT incorrectly sends NotifyEVChargingNeedsResponse Status Accepted instead of Rejected and therefore Step 3 will not be executed by the Charging Station.
        • Affected Testcases:
          TC_Q_103_CS
        • Situation: This applies to ISO15118-20
        • Work around: none
      • Known Issue Summary:
        The OCTT does not capture the TransactionEvent correctly, which result in an incorrect fail.
        • Affected Testcases:
          TC_Q_125_CS, TC_Q_126_CS, TC_Q_127_CS
        • Situation: This applies to ISO15118-20
        • Work around: none
      • Known Issue Summary:
        Typo in {{SupportedEnergyTransferModes}}, resulting in failure.
        • Affected Testcases:
          TC_Q_102_CS
        • Situation: Always
        • Work around: None
      • Known Issue Summary:
        By default {{chargingSchedulePeriod.numberPhases}} are being sent as part of the SetChargingProfileRequests to all charging station (AC and DC). For DC charging stations, the SetChargingProfileRequests MAY be rejected. OCTT is not taking this into account.
        • Affected Testcases:
          TC_Q_XXX_CS
        • Situation: DC charging stations that reject SetChargingProfileRequests containing{{chargingSchedulePeriod}}.{{numberPhases}} (For *2.1* this is applicable when {{DCInputPhaseControl}}is false/omitted).
        • Work around: If supported, set {{DCInputPhaseControl}} to {{True}}.
    • R DER Control

      • Known Issue Summary:
        OCTT is expecting the clear DER request at step 28 to result in Not Found while there are active DER controls matching the results.
        • Affected Testcases:
          TC_R_102_CS
        • Situation: Always
        • Work around: None

  • SUT CSMS:

    • B Provisioning

      • Known Issue Summary:
        The test case times out after receiving all messages that were needed following the testcase description.
        • Affected Testcases:
          TC_B_105_CSMS
        • Situation: Always
        • Work around: The test case can be manually reviewed to prove conformance
      • Known Issue Summary:
        In 2.1 this testcase incorrectly fails due to the validation of the ocppVersion.
        • Affected Testcases:
          TC_B_42_CSMS
        • Situation: If the ocppVersion is not sent as part of the SetNetworkRequest.
        • Work around: None
    • C Authorization

      • Known Issue Summary:
        TC_C_103_CSMS and TC_C_104_CSMS are using the same idToken, but expect them to have a different amount prepaid (one positive, one without balance)
        • Affected Testcases:
          TC_C_103_CSMS, TC_C_104_CSMS
        • Situation: When Payment by prepaid card is supported
        • Work around: Between runs, update the configure IdToken or the balance
    • K Smart Charging

      • Known Issue Summary:
        The test cases expect a charging profile to be manually sent by the CSMS and does not wait for the negotiation to finish first. The OCTT then incorrectly validates the initially negotiated charging profile to be the manually sent charging profile.
        • Affected Testcases:
          TC_K_101_CSMS
        • Situation: Always
        • Work around: n/a
      • Known Issue Summary:
        The test case is incorrectly validating that {{idTokenInfo}} is present and accepted at step 4
        • Affected Testcases:
          TC_K_101_CSMS
        • Situation: When Bidirectional Power Transfer is supported
        • Work around: The test case can be manually reviewed to confirm correct behaviour.
    • M Certificate Management

      • Known Issue Summary:
        The testcases result in an ERROR verdict when EXI Requests are incorrect.
        • Affected Testcases:
          TC_M_26_CSMS, TC_M_28_CSMS
        • Situation: The configured EXI Request Install/Update are incorrect and {{ISO15118 Support}} is turned on.
        • Work around: Provide a functional EXI in the configuration.
      • Known Issue Summary:
        Default EXIs currently have incorrect signatures.
        • Affected Testcases:
          TC_M_26_CSMS, TC_M_28_CSMS
        • Situation: Always
        • Work around: Use custom EXIs with correct signatures.
    • Q Bidirectional Power Transfer

      • Known Issue Summary:
        The test cases expect a charging profile to be manually sent by the CSMS and does not wait for the negotiation to finish first. The OCTT then incorrectly validates the initially negotiated charging profile to be the manually sent charging profile.
        • Affected Testcases:
          TC_Q_125_CSMS
        • Situation: Always
        • Work around: n/a
      • Known Issue Summary:
        The OCTT is incorrectly validating the presence of Setpoint for a ExternalSetpoint charging profile (as well as sending it when run in API mode).
        • Affected Testcases:
          TC_Q_111_CSMS, TC_Q_112_CSMS
        • Situation: When EMS Control is supported
        • Work around: None
      • Known Issue Summary:
        OCTT is expecting the CSMS to send a set point of {{10000}}. Currently there is no way for the CSMS to know that this is the value that is expected to be sent. Additionally, the validation message is incorrect.
        • Affected Testcases:
          TC_Q_108_CSMS
        • Situation: Always
        • Work around: Before running the test case, ensure that the set point is configured to be 10000.

• OCPP 2.0.1 Known Issues

  • SUT CS:

    • B Provisioning

      • Known Issue Summary:
        The OCTT incorrectly does not include the Configured Unsupported componentCriteria as part of the GetReportRequest.
        • Affected Testcases:
          TC_B_19_CS
        • Situation: Always
        • Work around: n/a
    • C Authorization

      • Known Issue Summary:
        The OCTT does not proceed to the TxStopPoint and is not able to validate the TransactionEvent Ended after Masterpass Deauthorization.
        • Affected Testcases:
          TC_C_14_CS
        • Situation: When TxStopPoint is EVConnected.
        • Work around: Use another TxStopPoint or manually disconnect the cable after the Deauthorization.
    • E Transactions

      • Known Issue Summary:
        OCTT does not respond with the {“idTokenInfo”:{“status”:”Accepted”}} when the transaction is started with TxStartPoints PowerPathClosed or EnergyTransfer and the first transaction event is chargingState=charging.
        • Affected Testcases:
          TC_E_41_CS, TC_E_42_CS, TC_E_50_CS, TC_E_51_CS
        • Situation: Only when the testcase fails.
        • Work around: Change TxStartPoint to Authorized.
    • K Smart Charging

      • Known Issue Summary:
        NotifyEVChargingScheduleRequest limits are being validated without taking into account the different charging rate units. For example when the Watt equivalent limit is specified for Amps, the test case will fail.
        • Affected Testcases:
          TC_K_53_CS, TC_K_58_CS
        • Situation: When the configured charging rate unit is Amps and NotifyEVChargingScheduleRequest is sent with Watts.
        • Work around: Set configured charging rate unit to Watts
      • Known Issue Summary:
        By default {{chargingSchedulePeriod.numberPhases}} are being sent as part of the SetChargingProfileRequests to all charging station (AC and DC). For DC charging stations, the SetChargingProfileRequests MAY be rejected. OCTT is not taking this into account.
        • Affected Testcases:
          TC_K_XX_CS
        • Situation: DC charging stations that reject SetChargingProfileRequests containing{{chargingSchedulePeriod}}.{{numberPhases}} (For *2.1* this is applicable when {{DCInputPhaseControl}}is false/omitted).
        • Work around: If supported, set {{DCInputPhaseControl}} to {{True}}.
    • M Certificate Management

      • Known Issue Summary:
        Default EXIs currently have incorrect signatures.
        • Affected Testcases:
          TC_M_26_CS, TC_M_27_CS, TC_M_28_CS, TC_M_29_CS
        • Situation: Always
        • Work around: Use custom EXIs with correct signatures.
    • N Diagnostics

      • Known Issue Summary:
        Some N testcases do not run the EnergyTransferStarted Reusable State correctly when the monitored variable is Power or Current.
        • Affected Testcases:
          TC_N_45_CS, TC_N_51_CS, TC_N_52_CS
        • Situation: When configuring {{EVSE.Power}} instead of {{Power}}.
        • Work around: Configure the monitored variable as Power or Current without additional elements behind it.

  • SUT CSMS:

    • B Provisioning

      • Known Issue Summary:
        In 2.1 this testcase incorrectly fails due to the validation of the ocppVersion.
        • Affected Testcases:
          TC_B_42_CSMS
        • Situation: If the ocppVersion is not sent as part of the SetNetworkRequest.
        • Work around: None
    • M Certificate Management

      • Known Issue Summary:
        The testcases result in an ERROR verdict when EXI Requests are incorrect.
        • Affected Testcases:
          TC_M_26_CSMS, TC_M_28_CSMS
        • Situation: The configured EXI Request Install/Update are incorrect and {{ISO15118 Support}} is turned on.
        • Work around: Provide a functional EXI in the configuration.
      • Known Issue Summary:
        Default EXIs currently have incorrect signatures.
        • Affected Testcases:
          TC_M_26_CSMS, TC_M_28_CSMS
        • Situation: Always
        • Work around: Use custom EXIs with correct signatures.

• OCPP 1.6 Known Issues

  • SUT CS:

    There are no known issues for SUT CS.

  • SUT CSMS:

    There are no known issues for SUT CSMS.