COTEVOS Test Cases around the Charging System Operator: A manufacturer s view Rok KRALJ ETREL Workshop Den Haag 14 th September 2015
ETREL background Partner in COTEVOS consortium OEM of different e-mobility solutions faced with interoperability issues Roaming solution OCHP E-Mobility Service Provider s back-end OCHP OCPP IEC 61851 ISO 15118 EVSE Operator s back-end Charging stations 2
What is interoperability? There are a lot of definitions of interoperability (less or more sophisticated). From manufacturer s point of view, the key stage is the final stage of installation and commissioning of equipment: Two components of an integrated system can: Be delivered by different manufacturers Both assure conformity to agreed standards or protocols When put into connected operation, the integrated system must properly operate (as expected by both of the manufacturers and by the client ) How to reach this? With correct pre-testing (and not by discovering ambiguities on the field) 3
Speaking to each other doesn t mean understanding each other Testing procedures are often focused on communication level: in common language: do we use the same language (words, syntax)? in electronic communication (for example SOAP): are all mandatory fields present in the messages, do all fields have the right name, do all field values have the right format,...? However: using the same language does not ensure that the two parties understand each other (as is commonly experienced in conversation) using the same communication standard or protocols does not ensure that the equipment operates exactly as expected by both OEMs Therefore the testing procedures should not be limited to communication level (language) they should be extended to functional level (understanding) 4
Extension of testing to functional level Mismatches on functional level may be caused by: OEMs interpret the provisions of the standard differently (e.g. what is the real meaning of an enumerator) the equipment wrongly interprets the information (e.g. error in programming) To discover errors, mismatches, and misunderstandings the functional level must be involved in testing: COMMUNICATION LEVEL Emulator Do this! OK, accepted Communication interface to DUT Do this! DUT FUNCTIONAL LEVEL DOES DUT REALLY BEHAVE AS ORDERED? With extension of testing to functional level, many unnecessary field interventions, additional costs, and dissatisfaction of clients can be avoided 5
Assessment of test results However, the functional level alone is not sufficient. Sometimes a proper (expected) behaviour of the target component (information receiving party) executing a function is incorrectly explained as correct operation of the DUT (information sending party). Such test result assessments may lead to wrong conclusions: WRONG PROCEDURE: DUT Do this! (correct sending of this message is tested) Emulator or real CORRECT PROCEDURE: Verification: DONE by the information receiving party? Do this! (correct sending of this message is tested) DUT Verification: CHECK SENT COMMAND PARAMETERS and ACCEPTED, not FAILURE? Emulator or real 6
Assessment of test results Example (not a COTEVOS case): Testing EVSE (DUT) for function of EV charging load control (specifically, correct sending of command to limit EV charging current): EVSE sends a signal to limit EV charging load to 16 A Verification: EV charging current is approx. 16 A YES So, EV is performing as was ordered by EVSE (DUT). EVSE works properly Wrong conclusion! EVSE signal (PWM) did not necessarilly conform to16 A, but actual charging current may be limited to 16 A due to EV (BMS) internal properties or other factors. Similarly, if EV charging load is not under 16 A, this doesn t necessarily mean that the EVSE itself does not conform to standards. 7
Assessment of test results To emphasise: Wrong procedure/verification: EV charging current = 16 A? YES DUT = OK NB: This step may be in place only after the correct procedure below was followed first DUT (EVSE) EV charging current to 16 A! Emulator or real (EV) Correct procedure/verification: check PWM parameters duty cycle (26,66 %), voltage, frequency, rise time, setting time...) Only in this manner (DUT conformance with standard), combined with extension of tests to functional level, can we aim for later interoperability also on the field. 8
Thank you for your attention! 9