mcms Technical Compliance Test Report

Size: px

Start display at page:

Download "mcms Technical Compliance Test Report"

Samson Parrish
5 years ago
Views:

1 Cityline Series Chargepoints mcms Technical Compliance Test Report 11th June 2018 CityEV Ltd. Technopole Kingston Crescent Portsmouth, UK PO2 8FA Tel:

2 Contents Introduction 3 4 Test 1 UTC Synchronisation 6 Test 2 Inventory & Equipment Control Information 7 Test 3 Event Log File Generation 7 Test 4 Load ON, Load OFF Test - Measurement Accuracy (Elexon test scenario 1) 8 Test 5 Two charge sessions with disconnect in between (Elexon test scenario 2) 9 Test 6 No connection, No consumption (Elexon test scenario 3) 11 Test 7 Consumption Over Midnight (Elexon test scenario 5) 12 Test 8 Communications Failure (Over Midnight) (Elexon test scenario 6) 13 Test 9 Power failure during communications failure 15 Appendix 1 - MID Approval 17 Appendix 2 - Energy Event Log File Format 18 Appendix 3 - Inventory File Format 20 Page 2 of 20

3 Introduction The Cityline series of electric vehicle chargepoints (EVSEs) from CityEV are designed to provide urban on-street residential electric vehicle charging infrastructure. A key feature of the system is the ability to use existing street lighting infrastructure and therefore significantly reducee deployment times and costs for urban EV charging infrastructure installation. The Cityline Chargepoint from CityEV Since the majority of existing street lighting electricity supply infrastructure use unmetered supplies it is necessary to provide a scheme for energy consumed by the chargepoints to be measured and appropriately billed. Currently the Supplier Volume Allocations Group (SVG) is responsible for overseeing the operation of the Supplier Volume Allocation processes (measurement systems and billing for unmetered supplies ) and are advised by the Unmetered Supplies User Group (UMSUG). The operation of UMS within Settlement is described by BSCP520 (Balancing and Settlement Code procedure) published by Elexon. This document describes the operation of the CityEV Cityline chargepoints within the measured Central Management System (mcms) and test reports to demonstrate compliance. Page 3 of 20

4 Based on the Elexon guidance document "measured Central Management System Test Specification" the following tests were performed at Compulogic Ltd., Burnt Thorns, Kilsby Lane, Rugby, CV21 4PN on behalf of CityEV on the Cityline chargepoint to verify compliance with the requirements specified in the relevant parts of BSCP520. The following tests were performed: 1. UTC Synchronisation 2. Inventory & Equipment Control Information 3. Event Log file Generation 4. On and Off test - measurement accuracy verification 5. Two charge sessions with disconnect in between 6. No connection, no consumption 7. Consumption over midnight 8. Communication failure (Over midnight) 9. Power failure during communications failure Test Set-up Cellular Data Link EV Simulator Cityline Chargepoint CityEV Server Chargepoint Database FTP Server 1.5KW AC Load Reference Energy Meter AC Power Generated Log Files Independent UTC Clock The test set-up comprises a Cityline charge point connected to an EV simulator with and AC load. All power supplied to the chargepoint passes via a reference energy meter. The chargepoint is connected to the Cityline central server where all events are recorded and the event log files and inventory files are produced. The reference energy meter used is a MID approved Landis & Gyr E110 S/N A Page 4 of 20

5 CityEV Chargepoint mcms test Setup The photo below shows the physical test setup as described above. UTC Time Reference 1.5KW Test Load EV Simulator Chargepoint Under Test Energy Reference Meter Note: For clarity, where event log files are shown in test results generally only partial log files are shown which include records which span the test duration. Page 5 of 20

6 Test 1 UTC Synchronisation Time Synchronisation at each chargepoint is maintained to within +/- 2 seconds of UTC. The local chargepoint RTC is synchronised once per minute with the central server clock which is in turn synchronised using a high availability Internet time server once per hour. This test uses the chargepoint charge transaction log to verify synchronisation with UTC. Every charge transaction startt and end is logged in the chargepoint together with a UTC time stamp. These charge transaction records are then sent to the CityEV server database. The test was performed by starting and stopping a charge transaction with reference to the independent UTC time reference. The UTC timestamp from the charge transaction record shown on the server was then compared with the actual transaction start/ /stop time. Test 1 Results: With reference to independent UTC time reference, Charge transaction started at 19:39:00 referenced to local UTC time reference Charge transaction Stopped at 19:40:30 referenced to local UTC time reference Transaction log from server: Resulting UTC error at transaction start: 0 seconds Resulting UTC error at transaction end: 0 seconds Allowable error: UTC +/- 20 seconds RESULT: PASS Page 6 of 20

7 Test 2 Inventory & Equipment Control Information Each day the server system produces an inventory file for all chargepoints included in the mcms system. The file is produced in a CSV format and can be read by Excel. The format of the inventory file is shown in appendix 3. A copy of the inventory file produced accompanies this report. RESULT: PASS Test 3 Event Log File Generation Each day at 00:02 the chargepoint server system generates a daily event log file in the format shown in Appendix 2. This file contains the energy consumption data for each half hour, for each chargepoint in the system for the preceding day. Appendix 2 also shows an example log file output. Sample log files taken from the server system accompany this report. Updated Log File Version Generation Newer versions of previous days log files are generated where energy readings have arrived late, i.e. have arrived after the day to which the energy record pertains due a system or communications failure. The ability to generate newer versions of log files already generated for previous days is proven in test 9, "communications failure over midnight" In this test energy records for the previous day will arrive after midnight once the communications are restored and will result in a newer version of the "day of the failure" log being generated which contains the originally received records plus the records which arrived the following day. The ability to pick up and successfully process the generated log files has also been tested by a Meter Administrator, in this case Power Data Associates. RESULT: PASS Page 7 of 20

8 Test 4 Load ON, Load OFF Test - Measurement Accuracy (Elexon test scenario 1) For this test a charge transactionn is started with an AC load and is run for more than one hour such that the test duration spans 3 consecutive half hour measurement periods. Before the test the reference meter is read. When the test is completed: 1. The reference meter read and the total energy used calculated. 2. The energy used for the charge transaction as reported by the server charge transaction is compared with the actual energy used. 3. An event log file is generated 4. The total energy reported in the event log file for the three half hour periods spanning the test is compared with the actual energy used. Test 4 Results: Reference meter reading at test start: KWh Charge transaction started: Charge Transaction Ended: 10:35:11 11:49:43 Reference Meter Reading at testt End: Total Energy used during test: 1.72 KWh Charge transaction report from CityEV server: Total Energy used according to charge record: KWh Event log file output for test period: CITYEV CITYEV CITYEV CITYEV CITYEV Total Energy used according to event log file: KWh Recorded energy error compared to reference meter: 0.00 KWh RESULT: PASS Page 8 of 20

Test 5 Two charge sessions with disconnect in between (Elexon test scenario 2) This test performs two charge transactions each more than one half hour UTC periods duration.

9 Test 5 Two charge sessions with disconnect in between (Elexon test scenario 2) This test performs two charge transactions each more than one half hour UTC periods duration. There is at least a 1 hour gap between the two transactions. The result of this test should show the energy consumption over four or more event log records; the first record should show the energy consumed during the first charge transaction, the middle records should show zero consumption, save any standby power, and the last record of the test period should show the energy consumption of the second charge transaction. Test 5 Results: Reference meter reading at test start: 1st Charge transaction started: 1st Charge Transaction Ended: Reference Meter Reading at end of 1st charge transaction: Total Energy used during 1st Transaction: Reference meter reading at test start: 2nd Charge transaction started: 2nd Charge Transaction Ended: Reference Meter Reading at end of 2nd charge transaction: Total Energy used during 2nd Transaction: KWh 12:35:40 13:20: KWh 1.06 KWh KWh 15:33:22 16:20: KWh 1.08 KWh Charge transaction reports from CityEV server: Total Energy used for both Transactions: KWh & KWh = KWh Continued next page Page 9 of 20

10 Event log file output for test period: CITYEV CITYEV } CITYEV } Total 1st Period = KWh CITYEV } CITYEV CITYEV CITYEV CITYEV } Total 2nd Period = KWh CITYEV } CITYEV Total Energy used according to event log file: KWh Recorded energy error compared to reference meter: 0.00 KWh RESULT: PASS Page 10 of 20

11 Test 6 No connection, No consumption (Elexon test scenario 3) This test demonstrates that if no charge transaction occurs for a 24 hour period the generated event log file will contain no energy consumption data apart from the chargepoint standby by energy consumed. Below is the log file generated for a 1 day period with no charge transactions: Hmeterid CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV T Test 6 Results: Total energy logged for 24h = 1.4% =7Wh (Standby energy, about 0.3W) RESULT: PASS Page 11 of 20

12 Test 7 Consumption Over Midnight (Elexon test scenario 5) This test demonstrates the ability to record energy consumption spanning midnight correctly in two consecutive event log files, one for each of the two days or part days where consumption starts in one day and ends in the next day. For this test a charge transactionn is started before midnight and terminated sometime after midnight. The resulting energy consumption from the two resulting log files are compared to the actual energy consumed during the test. Test 7 Results: Reference meter reading at test start: Charge transaction started: Charge Transaction Ended: Reference Meter Reading at end of charge transaction: Total Energy used during 2nd Transaction: KWh 01/05/1823:31: :32 02/05/1800:18: : KWh 1.07 KWh Charge transaction report from CityEV server: Event log file output for test period before midnight: 01/05/18 Hmeterid CITYEV CITYEV Event log file output for test period after midnight: 02/05/18 Hmeterid CITYEV CITYEV Charge transaction recorded across two different daily log files Total Energy used according to both event log files: KWh ( )*5) Recorded energy error compared to reference meter: 0.00 KWh RESULT: PASS Page 12 of 20

13 Test 8 Communications Failure (Over Midnight) (Elexon test scenario 6) This test demonstrates the ability to maintain energy consumption data in the event of a communications failure to the remote chargepoint or a systems failure in the central server system which results in half hourly energy use not being recorded by the server. Two charge transactions are performed with a communications failure occurring after the first transaction and before the second transaction. This results in the first transaction events being reported to the server but the second transaction events will be stored locally and reported once communications is restored. Additionally, the communications failure will extend over midnight. This should result in the first transaction being reported in the daily log file for day 1 but not the second. When the log file for day 2 is produced a new version of the log files for day 1 should also be produced which shows the energy records from the second transaction. Test Procedure: 1. Record reference energy meter reading 2. Start charge transaction 3. Continue charge transactionn for more than 1/2 hour 4. Terminate charge transaction 5. Disconnect communications link to chargepoint. 6. Wait 1 hour 7. Start charge transaction 8. Continue charge transactionn for more than 1/2 hour 9. Terminate charge transaction 10. Record reference energy meter reading and calculate total energy for both transactions. 11. Wait until after midnight 12. Restore communications link 13. Confirm that the locally stored charge transactions and half hourly energy records for the period when the communications was down are received by the server 14. Confirm all consumption is recorded in the event log file Page 13 of 20

14 Test 8 Results: Reference meter reading at test start: Charge transaction started: Charge Transaction Ended: Communications disconnected Charge transaction started: Charge Transaction Ended: Reference Meter Reading at end Communications Restored d of charge transactions: KWh 02/05/18 21:31:40 02/05/18 22:13:58 22:20:00 02/05/18 23:18:25 02/05/18 23:54: KWh 03/05/18 00:15:00 Total Energy used during Transaction: 1.84 KWh Charge transaction report from CityEV server: Event log records for communications down period received by server Event log file output for test period Created before communications restored: Hmeterid CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV Energy for first part of 1st transactionn reported before communications failure New Version event log file outpu for test period Created after communications restored: Hmeterid CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV New records reported after communications restored Total Energy used according to event log file: KWh (( )*5) Recorded energy error compared to reference meter: 0.00 KWh RESULT: PASS Page 14 of 20

15 Test 9 Power failure during communications failure This test proves that energy event records locally stored in the chargepoint remain intact if there is a power failure at the chargepoint while the communications link is still down and still contains stored records not yet transferred to the server. Upon power being restored and communications restored all records stored during the communications failure should be transferred to the server. Test procedure: 1. Disconnect communications link to chargepoint. 2. Record reference energy meter reading 3. Start charge transaction 4. Continue charge transactionn for more than 1/2 hour During this time at least 2 half hour energy consumption records should be stored locally in the chargepoint. 5. Terminate charge transaction 6. Record reference energy meter reading 7. Disconnect power from the chargepoint 8. Wait 1 hour then restore power to the chargepoint 9. Restore communications link 10. Confirm that the locally stored charge transactions and half hourly energy records for the period when the communications was down are received by the server 11. Confirm all consumption is recorded in the event log file Results next page. Page 15 of 20

16 Test 9 Results: Reference meter reading at test start: Communications disconnected Charge transaction started: Charge Transaction Ended: Reference Meter Reading at end of charge transaction: Power Disconnected Power Restored Communications Restored Total Energy used during Transaction: KWh 07:30:00 07:31:51 08:16: KWh 08:20:00 09:25:00 09:28: KWh Charge transaction report from CityEV server: Event log records for communications down & power down period received by server Event log file output for test period: CITYEV CITYEV CITYEV CITYEV Total Energy used according to event log file: KWh Recorded energy error compared to reference meter: 0.00 KWh RESULT: PASS Page 16 of 20

17 Appendix 1 - MID Approval Page 17 of 20

18 Appendix 2 - Energy Event Log File Format Filename: mmmmmmmyyyymmddvvv.log where: mmmmmmm = Sub-Meter ID (alphanumeric) yyyymmdd = date to which the events pertain vvv = version number log = file extension with all characters in lower case File header: HMMMMMMMYYYYMMDDVVV where: H = header identifier, H MMMMMMM = Sub-Meter ID (alphanumeric) YYYYMMDD = date to which the events pertain VVV = version number File body: UUUUUUUUUUUHHMMSSPPP.PPI where: UUUUUUUUUUUU = CMS Unit Reference (alphanumeric) HHMMSS = time in hours, minutes and seconds, in UTC throughout the year PPP.PP = percentage of base power relative to 1KWh/Hour I = information flag (alphanumeric) File trailer: TNNNNNNN where: T = trailer identifier, T NNNNNNN = total number of lines including header and trailer All lines are terminated with a carriage return. Page 18 of 20

19 Appendix 2 - Energy Event Log File Format Event Log File Output Example: Hmeterid CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV CITYEV T The above example is of a part-day log file. Normally, one log file is produced each day and will contain 48 entries per chargepoint. Page 19 of 20

20 Appendix 3 - Inventory File Format Filename: cityevinventory.csv File is provided in CSV format with column headings as follows: cmsunitreference unittype MPAN submeterid description lattitude longitude postcode street_address unit_energy_type unit_number no_of_controls lamp_energy_code control_energy_code regime_energy_code Column Descriptions: cmsunitreference Unit reference number in the form CITYEVnnnnnn unittype Chargepoint type MPAN Meter Point Administration Number submeterid Sub Meter ID if relevent description Chargepoint location description lattitude Chargpoint location latitude longitude Chargepoint location longitude postcode Chargepoint location postcode street_address Chargepoint location street address unit_energy_type Unit energy type unit_number Always 1 no_of_controls Always 1 lamp_energy_code Allocated by MA control_energy_code Allocated by MA regime_energy_code Always 999 Inventory File Output Example: Page 20 of 20

ELD DRIVER GUIDE June 21, 2018

ELD DRIVER GUIDE June 21, 2018 Contents Getting Started with PrePass ELD...4 Enroll in the PrePass ELD Program... 4 For a Carrier Enroll in the ELD Service... 4 For a Driver Get Driver Login Information...