SMART METER TEST PROTOCOL

OCTOBER 03, 2019 SUSTAINABLE ENERGY FOR PAKISTAN (SEP) PROJECT

Submission Date: October 03, 2019

Contract No.: AID-OAA-I-13-00028 Task Order: AID-391-TO-16-00005 Activity Start Date and End Date: August 3, 2017 to April 26, 2021

Submitted by: Tetra Tech ES, Inc. 1320 North Courthouse Road, Suite 600 Arlington, VA 22201 Tel. +1-703-387-2100 | Fax +1-703-243-0953

www.tetratech.com

This report was produced for review by the Agency for International Development. It was prepared by Tetra Tech ES, Inc. for the Sustainable Energy for Pakistan (SEP) Project.

SMART METER TEST PROTOCOL OCTOBER 03, 2019

SUSTAINABLE ENERGY FOR PAKISTAN (SEP) PROJECT

DISCLAIMER

This study/report is made possible by the support of the American people through the United States Agency for International Development (USAID). The contents are the sole responsibility of the Tetra Tech ES, Inc. and do not necessarily reflect the views of USAID or the United States Government. CONTENTS

1. INTRODUCTION ...... 7

2. OBJECTIVES AND TASKS ...... 8 2.1 OBJECTIVES ...... 8 2.2 CERTIFICATION PROCESS ...... 8 2.2.1 PHASE – I PREPARATION ...... 9 2.2.2 PHASE – II TESTING AND VALIDATION ...... 9 2.2.3 PHASE – III CERTIFICATION ...... 10

3. TEST SCOPE ...... 11 3.1 SCOPE ...... 11 3.1.1 TABLE READ ...... 11 3.1.2 WEB SERVICE ...... 11 3.2 PARTICIPANTS ...... 11 3.2.1 TEST INSPECTOR ROLE ...... 12 3.2.2 VENDOR TECHNICAL TEAM ROLE ...... 12 3.2.3 PITC SUPPORT TEAM ...... 12

4. SETUP PROCEDURE ...... 13 4.1 GENERAL ...... 13 4.2 TEST PHASES ...... 14 4.2.1 EYEBALL DATA VERIFICATION ...... 14 4.2.2 INTEROPERABILITY TESTING ...... 15 4.2.3 INTEGRATION TESTING ...... 16 4.2.4 LOAD TESTING...... 17 4.2.5 STRESS TESTING ...... 19

5. REPORTS 21 5.1 GENERAL INFORMATION FORM ...... 21 5.2 TEST RESULT SUMMARY ...... 22 5.3 FORMS FOR ETL ...... 23 5.3.1 INSTANTANEOUS DATA...... 23 5.3.2 BILLING DATA ...... 24 5.3.3 MONTHLY BILLING DATA ...... 27 5.3.4 DATA ...... 30 5.3.5 EVENTS ...... 33 5.3.6 METER VISUALS ...... 34 5.4 FORMS FOR COMMANDS ...... 37 5.4.1 AUX RELAY OPERATIONS ...... 37 5.4.2 TIME SYNCHRONIZATION ...... 39 5.4.3 SANCTIONED LOAD CONTROL ...... 40 5.4.4 LOAD SHEDDING SCHEDULING / MANAGEMENT ...... 41

SMART METER TEST PROTOCOL STRATEGY iii 5.4.5 TIME OF USE CHANGE ...... 42 5.4.6 DEVICE CREATION ...... 43 5.4.7 UPDATE IP PORT...... 45 5.4.8 METER DATA SAMPLING ...... 46 5.4.9 ACTIVATE METER OPTICAL PORT ...... 47 5.4.10 WAKE UP SIM NUMBER UPDATE ...... 47 5.4.11 METER STATUS ...... 49

iv SMART METER TEST PROTOCOL STRATEGY ABBREVIATIONS & ACRONYMS

AEB Area Electricity Board (former name for a DISCO) AEDB Alternative Energy Development Board AMI Advanced Metering Infrastructure AMR Automated Meter Reading API Application Programming Interface AT&C Aggregate Technical and Commercial B2B Business-to-Business BI Business Intelligence CE (Ops) Chief Engineer Operations CE (P&E) Chief Engineer Planning and Engineering CIS Customer Information System CIM Common Interface Model COP Chief of Party CP Commercial Procedures CSD Customer Service Director CT Current Transformer DBMS Data Base Management System DISCO State-owned Electricity Distribution Company D&S Design & Standards ETL Extract, Transform and Load FESCO Faisalabad Electric Supply Company Limited FY Financial year GEPCO Gujranwala Electric Power Company Limited GIS Geographic Information System GoP Government of Pakistan HE Head End System HESCO Hyderabad Electric Supply Company Limited HT High Tension, or High Voltage Level IESCO Islamabad Electric Supply Company Limited kWh Kilo Watt Hour KPIs Key Performance Indicators LDI USAID’s Load Data Improvement Project LESCO Lahore Electric Supply Company Limited LT Low Tension, or Low Voltage Level MDC Meter Data Collector MDM Meter Data Management MEPCO Multan Electric Power Company Limited M&E Monitoring and Evaluation MoE Ministry of Energy MW Megawatt NEPRA National Electric Power Regulatory Authority

SMART METER TEST PROTOCOL STRATEGY v NPCC National Power Control Center NTDC National Transmission and Dispatch Company PEPCO Pakistan Electric Power Company Limited PESCO Peshawar Electric Supply Company Limited PDC Power Distribution Control Center PITC Pakistan Information Technology Company QESCO Quetta Electric Supply Company Limited RO Revenue Officer SDO Sub Divisional Officer SE Superintending Engineer SEP USAID’s Sustainable Energy for Pakistan Project SEPCO Sukkur Electric Power Company Limited S&S Standards & Specification Department under PEPCO (formerly D&S department) SGITL Integration and Testing Lab SQL Structured Query Language TESCO Trible Area Electric Supply Company Limited TC SEP Technical Component UDIL Universal Data Integration Layer USAID United States Agency for International Development WAPDA and Power Development Authority XEN Executive Engineer

vi SMART METER TEST PROTOCOL STRATEGY 1. INTRODUCTION

Automating the meter reading process is a proven and a cost-effective way to streamline meter-to-cash function. However, with its rising demand, utilities all around the world are looking for more than just data for monthly bill creation, but to also use this information to improve distribution processes, provide efficient customer service and conduct effective energy planning. Advanced metering infrastructure (AMI) is an integrated system of smart meters, communications networks, and data management systems that enables two-way communication between utilities and customers. The system provides number of important functions that were either not previously possible or had to be performed manually, such as the ability to automatically and remotely measure electricity use, connect and disconnect service, detect tampering, identify and isolate outages, and monitor voltage. As part of the earlier USAID Power Distribution Program (PDP), smart meters were installed on feeders at the grid stations across all the DISCOs for recording load profiles and real-time monitoring of power dispatch. The project was further extended to provide support to three DISCOs (MEPCO, PESCO and HESCO) with smart meters installation at the customer level. Initially, the solution was designed to support integration of all types and makes of smart meters, but unfortunately, the AMI project remained confined to a single vendor resulting into a vendor lock situation for the DISCOs. USAID’s Sustainable Energy for Pakistan Project (SEP) took up the challenge and designed an open-architecture multi- vendor compliant AMI platform to introduce multiple head-end systems on AMI platform. SEP in collaboration with DISCOs, PITC, NTDC’s S&S and smart meter manufacturers, initiated and developed Universal Data Integration Layer (UDIL) for establishing an integrated AMI platform offering equal opportunity to all vendors including international manufacturers. The UDIL layer comprises of a suite of standardized table structures which are added over Meter Data Connector (MDC)’s database for exposing meter profiles received from smart meters. This ensures the sanctity of proprietary database with exposing data in a standardized format over the UDIL layer. The newly designed standards also define the structure of Application Programming Interface (API) services required for establishing two-way communication between MDM and MDC systems. With USAID's assistance, SEP has setup a Smart Grid Integration Testing Lab (SGITL) at WAPDA House Lahore, empowering the Power Information Technology Company (PITC) to test and certify the application layer and integration compliance of smart grid devices including smart meters and other network switching devices. With the technical assistance extended by PITC, this lab offers a sandbox environment to smart device manufacturers to prototype test their devices and associated software ensuring conformity to the UDIL standards prior to applying for official testing over the multivendor compliant AMI enterprise landscape and subsequent certification. This document contains a set of test protocol and defines processes that need to be followed to certify smart meter head-ends for compliance to the standards defined in UDIL.

SMART METER TEST PROTOCOL STRATEGY 7 2. OBJECTIVES AND TASKS

2.1 OBJECTIVES The primary objective of the test protocol strategy is to lay down set of procedures that smart device manufacturers are required to follow to get the application layer of their products certified on universal standards. The four-stage process will ensure that the smart meters adheres to the technology standards set by PITC defined in UDIL and so making the technology to qualify for the enhanced AMI enterprise landscape currently installed. The enhanced AMI enterprise landscape diagram is described below for reference.

2.2 CERTIFICATION PROCESS Emphasis has been placed on laying down a credible yet simple process for potential vendors to demonstrate compliance of their smart devices to the defined standards. The processes are defined in three phases as following: Preparation The preparation phase is aimed to help vendors understand the technology standards set by PITC. Testing and Evaluation In this phase, vendor is required to deploy and configure its products in the Smart Grid Integration Testing Lab (SGTIL). The lab is equipped with test instances of multiple utility applications to establish integration with the proposed device in the sandbox environment. Certification After successful testing and compliance, PITC will issue a smart grid conformance certificate containing necessary details of the product version.

Phase - 1 Phase - 2 Phase - 3 Preparation Testing & Evaluation Certification

8 SMART METER TEST PROTOCOL STRATEGY 2.2.1 PHASE – I PREPARATION The following activities are to be covered under the preparation phase. These are elaborated in sequence of their occurrence.

2.2.1.1 MEETING WITH PITC • Vendor must initiate a request for an introductory meeting with PITC, through email/courier. • In response, PITC will set up a meeting with the vendor and brief them regarding the certification process. • Meeting request to be sent at: o Email : [email protected] o Postal : CEO-PITC, Room 405, WAPDA House, Shahrah-e-Quaid-e-Azam, Lahore.

2.2.1.2 CRITERIA REVIEW • The specific certification criteria will be presented by PITC to the vendor. In case of smart meter application layer, this corresponds to Universal Data Integration Layer (UDIL). • Several application level specifications are common to smart products, while some are device-specific. PITC has developed a wide range of criteria tailored for such smart devices. Vendors are required to make themselves familiar with the criteria and verification methods specific to their device at the certification stage. • For more details regarding criteria defined for the smart meters, visit the link: http://www.PITC.com.pk/index.php/features/open-architecture-based-AMI

2.2.1.3 OBTAIN CREDENTIALS • PITC will make available necessary infrastructure required for the testing of the smart device application. o This includes virtual space over its enterprise landscape dedicated for the vendor to install the test application; o A kiosk will also be provided to support installation of hardware and establish its communication with test application, which is subject to certification. • The credentials will be shared confidentially with the vendor.

2.2.2 PHASE – II TESTING AND VALIDATION The following activities will be covered under the testing and validation stage. These are elaborated in sequence of their occurrence. Device Installation • A sample device will be installed at the kiosk to demonstrate communication between hardware and software. This refers to establishing wireless communication between smart meter and its head-end system via Telephone Company (TELCO). The Subscriber Identification Module (SIM) installed in the smart meter will be assigned an Protocol (IP) Address from authorized pool to communicate via VPN network. • The kiosk will also include space for installation of electrical appliances for the case where there is a requirement to put some load on the device. Application Installation • Application instance is required to be installed over the virtual space provided by the PITC. PITC shall render all possible support in setting up of hardware and software. • Kiosk is also equipped with a Liquid Crystal Display (LCD) screen to enable the vendor to display the statistics and carry out necessary configurations to make the development environment up and running for commencing the conformance test. Conduct Test Run • PITC will perform following tests to certify the application layer of MDC system:

SMART METER TEST PROTOCOL STRATEGY 9 o Eyeball Data Check Test o Inter-Operability Test o Integration test. • The test run is an opportunity provided to vendors to setup the complete architecture ready for PITC to commence the conformance test. Vendor is required to carry-out unit testing of application until the system is made ready for the PITC to conduct the abovementioned tests formally. • They can deploy upgraded instance of application, subject to any development surfacing from unit testing. PITC will validate all the iterative results and will maintain a copy of outcomes. Establish Integration • Application will be tested for integration with other systems on enterprise landscape. • On need basis, integration with other applications will be established in the sandbox environment such as billing system, Customer Relationship Management (CRM) and Meter Data Management (MDM). During the test, successful creation of Validation Editing Exception (VEE) file for input into the billing system will be evaluated.

2.2.3 PHASE – III CERTIFICATION Certification related activities are stated as following. These are elaborated in sequence of their occurrence. Results Preparation • Final report will be prepared / generated by system that will entail details of certification outcomes. • The report will be comprehensive enough to cover all aspects of conformance of a vendor’s smart device application to the smart grid enterprise landscape. • The report will include all details but not limited to hardware and software used during the testing and validation and final test results. • PITC will evaluate the inter-operability and integration test results. • PITC will archive the test results and maintain the application instance at virtual environment as an evidence of certification. This will be subject to agreement with the Vendor. Certificate Award (Yes/No) • Based on the results and outcome of the tests, PITC, at its sole discretion, will decide whether to grant or not the certificate. • In case of rejection, vendor will be required to go through the certification process by re-applying to PITC for the certification and will go through the entire process again. • A certificate, duly numbered and signed by CEO PITC will be issued to the successful vendor. The certificate will also include name and version of application certified and, in some cases, it will mention the expiry date.

10 SMART METER TEST PROTOCOL STRATEGY 3. TEST SCOPE

The comprehensive testing of smart meter will involve several phases to ensure all functions of the subject application are thoroughly tested with results duly documented. The testing will commence once the agreement has been signed between PITC and the vendor.

3.1 SCOPE

The scope will include verification of following Extract Transform and Load (ETL) functions and services.

3.1.1 TABLE READ Following tables/views will be read from the head-end system. • Grid Profiles o Instantaneous Data o Load Profile Data • Meter Profiles o Billing Data o Monthly Billing Data o Events o Meter Visuals

3.1.2 WEB SERVICE Apart from tables/views following web services will be tested to verify two-way communication between MDM system and various head-ends available on AMI enterprise landscape. These services are comprehensively explained in the UDIL document with examples. • Auxiliary Relay operation • Time synchronization • Sanctioned Load update • Load-shedding schedule update • Time-of-use register update • Device creation • Update of IP / port • Meter data sampling • Activate optical port • Wake-up numbers update • Meter status check

If the meter vendor proposes table read (as defined in previous section) via services, then all the grid and meter profiles will fall under web services and therefore will be tested accordingly.

3.2 PARTICIPANTS The testing of the smart meter application at the SGITL will be managed by PITC. The Test Inspector will lead the overall certification process in collaboration with the technical representatives from vendors. Following are the responsibilities set for each of the role:

SMART METER TEST PROTOCOL STRATEGY 11 3.2.1 TEST INSPECTOR ROLE • Planning the execution of testing activities. • Check if all the necessary resources to execute the testing activities are available. • Check if test is being conducted together with the software development during all the phases. • Develop test cases and prioritize testing activities. • Execute all test cases and report defects, define severity and prioritize each of defects. • Prepare status report of the testing activities. • Carry out necessary interactions with vendors. • Keep CTO PITC update about progress of the testing activities.

3.2.2 VENDOR TECHNICAL TEAM ROLE • Read all the documents and understand the compliance requirements. • Based on the information obtained in the above step, plan the deployment of application that is to be tested. • Inform the Test Inspector about resources that will be required for application testing. • In close coordination with the Test Inspector, execute all the test cases, define severity and priority for each defect.

3.2.3 PITC SUPPORT TEAM • Provide technical assistance in setting up all kind of communication protocols e.g., Wireless Area Network (WAN), Personal Area Network (PAN), Frequency (RF), Power Line Carrier (PLC) and environment.

12 SMART METER TEST PROTOCOL STRATEGY 4. SETUP PROCEDURE

4.1 GENERAL The general procedure will include following activities in setting up the infrastructure.

Activity No Activity Description Participant(s)

1.1 Vendor’s technical team will share Technical team – Vendor specifications of hardware required for the Test Inspector installation of head-end application with the Test Inspector. This may include requirement for data concentrator units if required.

1.2 Vendor’s technical team will share Technical team – Vendor specifications pertaining to environment Test Inspector required for the installation of supporting devices such as smart meters with the Test Inspector.

1.3 Provision of physical / virtual environment PITC support team required for the installation of upgraded head- Test Inspector end system as per requirement received from the Test Inspector.

1.4 PITC support team will share credentials with PITC support team the Test Inspector in a sealed envelope. Test Inspector

1.5 Test Inspector will share credentials with Test Inspector vendor’s technical team. Technical team – Vendor

1.6 PITC support team in coordination with Test PITC support team Inspector will make available necessary Test Inspector environment for carrying out the application test.

1.7 Test Inspector will make the available kiosk Test Inspector – PITC equipped with meter hanging accessories to the technical team for installation of supporting devices.

1.8 Test Inspector will create a profile in testing Test Inspector – PITC application for the vendor. The other relevant data such as connection string will also be maintained in the application for execution of the test.

1.9 Test Inspector will select features Test Inspector – PITC (tables/services) that are required to be tested.

1.10 Test Inspector will generate a test plan from the Test Inspector – PITC application that will: • Include test milestones • Events of test phases • Estimate the time for each testing task

SMART METER TEST PROTOCOL STRATEGY 13 1.11 Test Inspector is required to generate a Test Inspector – PITC REPORT (See General Information Form) as customer profile for record purpose.

4.2 TEST PHASES

The following illustration outlines series of testing phases that needs to be performed to ensure satisfactory operation of application in the production environment. The phases are built on one another to ensure that individual system functionality meets the requirements as laid down in the relevant specification. With testing phases in progress, testing becomes more integrated and rigorous.

Level-1, 2 and 3 target the scope related to the testing of MDC communication whereas Level-4 and 5 are designed specifically to test the MDC system for its performance by bombarding message protocols using virtual threads.

Level 5 - Level 4 - MDC Stress Test Level 3 - MDC Load Integration Test Level 2 - Test Level 1 - Inter- operability Eyeball Data Test Verification Test

4.2.1 EYEBALL DATA VERIFICATION The individual/unit testing will comprise head-end system connected to a single meter for validation of performance of individual functions of the head-end system. This will be completed in the presence of the vendor’s staff that are part of the team and are responsible for development of the system.

4.2.1.1 EVENTS Activities and corresponding responsible roles for the individual testing phase are explained below:

Activity No Activity Description Participant(s)

1.1 Install MDC system with upgraded data layer Technical team – Vendor and services as specified in the UDIL document. Networks – PITC Test Inspector – PITC

14 SMART METER TEST PROTOCOL STRATEGY 1.2 Install pre-configure smart meters for the test Technical team – Vendor phase on kiosk provided by PITC.

1.3 Powering appliances to put some load on smart Technical team – Vendor meter for measurement. Test Inspector – PITC

1.4 Carry out eyeball data verification by Test Inspector – PITC comparing data visible both on MDC and smart meter screen.

1.5 Test Inspector will click the ‘Retrieve’ button Test Inspector – PITC on the Unit Testing tab to see the profiles on SGITL application after selecting the MDC under test.

1.6 Update REPORT (See Test Result Summary) Test Inspector – PITC from test application for successful verification.

4.2.2 INTEROPERABILITY TESTING The scope of system integration test will include establishing communication of the head-end system with the MDM system. This will include executing ETL activities for fetching information from exposed tables/views maintained in the head-end system as per UDIL. Additionally, web services will be tested to ensure end-to-end communication between smart meter and meter data management (MDM) system via the head-end system.

4.2.2.1 EVENTS The activities and participants for the system and integration testing phase are explained below:

Activity No Activity Description Participant(s)

1.1 Test Inspector will select a sample meter Test Inspector – PITC number (Device Number) to perform integration test.

1.2 Using the testing application, under the Technical team – Vendor Integration Testing tab, the Test Inspector will Test Inspector – PITC click the ‘Start ETL’ button to commence data fetching activity and to load data from the MDC system into the MDM database. The service will continue running by continuous loading of incremental data to the MDM database at pre- defined intervals set by the SGITL.

1.3 Progress of loading will be visible on the MDM Test Inspector – PITC dashboard in an iterative manner starting from grid profiles to meter profiles. The sequence of loading will be as follows: • Instantaneous Data • Load Profile Data • Billing Data • Monthly Billing Data • Events • Meter Visual

SMART METER TEST PROTOCOL STRATEGY 15 The successful load of profiles will be indicated through green marks against each line item presented in the relevant box.

1.4 At the end of the activity, a REPORT (See Test Inspector – PITC Reports under section ‘Forms for ETL’) will be generated by the Test Inspector for record purposes.

1.5 After the ETL activity is completed, the Test Test Inspector – PITC Inspector will continue with the testing process for web services. The web services will be tested one-by-one passing each of the sample device number assigned to each smart meter. The sequence of tests for web-service is as follows: • Auxiliary Relay Operation • Time Synchronization • Sanctioned Load Update • Load-shedding Update • Time-of-Use Register Update • Device Creation • Ip/Port Update • Meter Data Sampling • Activate Meter Optical Port • Wake-up Number Update • Meter Status Check

The successful load of profiles will be indicated with green mark against each line item presented in the relevant box .

1.6 At the end of the activity, a REPORT (See Test Inspector – PITC Reports under section ‘Forms for Commands’) will be generated by test inspector for record purposes.

4.2.3 INTEGRATION TESTING The integration test phase will comprise verifying MDC’s behavior in complete AMI cycle starting from data retrieval from meter, profile processing and sharing with target system down to the consumer billing/invoicing.

4.2.3.1 EVENTS Activities and corresponding roles responsible for regression testing phase are stated below:

Activity No Activity Description Participant(s)

16 SMART METER TEST PROTOCOL STRATEGY 1.1 Installation of upgraded MDC system with Technical team – Vendor upgraded data layer and services as specified in Networks – PITC the UDIL document. Test Inspector – PITC

1.2 Installation of smart meter on the kiosk made Technical team – Vendor available by the PITC.

1.3 Using the ‘Device Creation’ service as defined Test Inspector – PITC in UDIL document, addition of smart meter record will be carried out in the MDC system via MDM.

1.4 Powering appliances to put some load on smart Technical team – Vendor meter for measurement. Test Inspector – PITC

1.5 Extract monthly billing data from MDC via ETL / Test Inspector – PITC API

1.6 Execute VEE process and export billing file Test Inspector – PITC

1.7 Import file in billing system Test Inspector – PITC

1.8 At the end of the activity, update summary Test Inspector – PITC report for integration compliance.

4.2.4 LOAD TESTING The load testing phase will include bombarding MDC system with the operational requests comprising maximum meter numbers which the system is capable to handle. The maximum number of meters (concurrent sessions) that MDC can handle is declared by each of the meter vendor in their product specifications. The outcome of the load test is a measure of system performance based on volume of requests to see how close the latency is as to rated value as claimed by the vendor. The unit of measure is ‘throughput’ which the number of I/O processed with respect to time. Throughput = number of completed requests / time to complete the requests The load testing phase will require creation of virtual meters based on protocol which is followed by meter vendor such as DLMS/COSEM, ANSI etc.

4.2.4.1 EVENTS Activities and corresponding roles responsible for the performance and stress testing phase are explained below:

Activity No Activity Description Participant(s)

1.1 Using the testing application, in the SGITL, the Technical team – Vendor Test Inspector will click the ‘Start ETL’ button Test Inspector – PITC to commence data fetching activity and load data from the MDC system into the MDM database. The service will continue running by loading incremental data to the MDM database at pre-defined intervals set by the Test Inspector.

1.2 The loading progress will be visible on MDM Test Inspector – PITC dashboard in an iterative manner starting from grid profiles to meter profiles. The sequence of data loading will be as follows:

SMART METER TEST PROTOCOL STRATEGY 17 • Instantaneous data • Load profile data • Billing data • Monthly billing data • Events • Meter visuals The successful loading of profiles will be indicated with a green mark against each line item presented in the box.

1.3 At the end of the activity, a (See Reports Test Inspector – PITC under section ‘Forms for ETL’) will be generated by Test Inspector for record purposes. This includes the throughput information.

1.4 After the ETL activity is completed, Test Test Inspector – PITC Inspector will continue with the testing process for web services. Test Inspector will click on ‘Execute Services’ button to start the activity. There will be a random sequence generated by the application to execute web-services listed below: • Auxiliary relay operation • Time Synchronization • Sanctioned Load Update • Load-shedding Update • Time-of-Use Register Update • Device Creation • Ip/Port Update • Meter Data Sampling • Activate Meter Optical Port • Wake-up Number Update • Meter Status Check The successful execution of service will be indicated with a green mark against each line item presented in the box.

1.5 At the end of the activity, a REPORT (See Test Inspector – PITC Reports under section ‘Forms for Commands’) will be generated by Test Inspector for record purposes. This includes the throughput information.

18 SMART METER TEST PROTOCOL STRATEGY 4.2.5 STRESS TESTING The stress testing phase will include bombarding MDC system with the operational requests comprising maximum meter numbers which the system is capable to handle. The continuous queuing of jobs will continue until the system crashes. Hence, the outcome of the stress test is a measure of system performance based on volume of requests to record the max latency of the system. The unit of measure is ‘throughput’ which the number of I/O processed with respect to time. Throughput = number of completed requests (max before crash) / time to complete the requests The load testing phase will require creation of virtual meters based on protocol which is followed by meter vendor such as DLMS/COSEM, ANSI etc.

4.2.5.1 EVENTS Activities and participants for performance and stress testing phase are explained below:

Activity No Activity Description Participant(s)

1.1 Using the testing application, in the Stress Technical team – Vendor Testing tab, Test Inspector will click the ‘Start Test Inspector – PITC ETL’ button to commence data fetch activity and to load data from the MDC system into the MDM database. The service will continue running with loading incremental data to MDM database at pre-defined interval set by SGITL.

1.2 The loading progress will be visible over the Test Inspector – PITC MDM dashboard in an iterative manner, starting from grid profiles to meter profiles. The sequence of load will be as follow: • Instantaneous Data • Load Profile Data • Billing Data • Monthly Billing Data • Events • Meter Visual The successful load of profiles will be indicated with a green mark against each line item presented in the box.

1.3 At the end of the activity, a REPORT will be Test Inspector – PITC generated by the Test Inspector for record purposes. This includes recording of maximum throughput number before the system crashes.

1.4 After the ETL activity is completed, Test Test Inspector – PITC Inspector will continue with the testing process for web services. Test Inspector will click the ‘Execute Services’ button to start the activity. There will be a random sequence generated followed by an application to execute web- services listed below: • Auxiliary Relay Operation

SMART METER TEST PROTOCOL STRATEGY 19 • Time Synchronization • Sanctioned Load Update • Load Shedding Update • Time-of-Use Register Update • Device Creation • Ip/Port Update • Meter Data Sampling • Activate Meter Optical Port • Wake-up Number Update • Meter Status Check

The successful execution of service will be indicated with green mark against each line item presented in the box against it.

1.5 At the end of the activity, a REPORT will be Test Inspector – PITC generated by the Test Inspector for record purposes. This includes recording of maximum throughput number before the system crashed.

20 SMART METER TEST PROTOCOL STRATEGY 5. REPORTS

5.1 GENERAL INFORMATION FORM

SMART METER TEST PROTOCOL STRATEGY 21 5.2 TEST RESULT SUMMARY Following summary of all required integration conformity tests will be prepared by the test conducting inspector on Form SGIT – 02 for the management’s review and final approval:

22 SMART METER TEST PROTOCOL STRATEGY 5.3 FORMS FOR ETL

5.3.1 INSTANTANEOUS DATA Smart meter collects and stores energy data at pre-defined time interval which is further forwarded to relevant head-end system periodically. However, possibility exists to retrieve meter profiles on real-time basis for decision-making. To meet this requirement, the end-user can request to retrieve basic parameters from meters via the head- end system. Test Inspector is required to review the information obtained from ‘instantaneous view/API and compare it with the data retrieved from head-end system (via reports). Additionally, the data is to be verified with the information displayed by the MDC and comparing it by physically scrolling through meter registers. Inspector can put a comment against each field where necessary. Instantaneous data will be recorded in the Form SGITL – 03 below:

SMART METER TEST PROTOCOL STRATEGY 23

5.3.2 BILLING DATA The ‘Billing Data’ contains information obtained from the smart meter registers that are exclusively recording customer’s energy consumption for various TOD usage. Registers are based on tariff allocated to customer and have the provision to record peak/off values. Another key information maintained in the data set is the bi-directional flow of energy for in case the smart meter is configured for net metering. Test Inspector is required to review the information obtained from ‘billing data’ view/API and compare it with data retrieved from the head-end system (via reports). Additionally, the data is to be confirmed with information displayed on the led screen of the meter, by physically scrolling through the meter registers. Inspector may put a comment against each field, where necessary. All the values will be recoreded using the Form SGIT- 04 below:

24 SMART METER TEST PROTOCOL STRATEGY

SMART METER TEST PROTOCOL STRATEGY 25 active_mdi_abs_t1 Decimal T1 Absolute Active MDI kW active_mdi_abs_t2 Decimal T2 Absolute Active MDI kW active_mdi_abs_t3 Decimal T3 Absolute Active MDI kW active_mdi_abs_t4 Decimal T4 Absolute Active MDI kW active_mdi_abs_tl Decimal Total Absolute Active MDI kW cumulative_mdi_pos_t1 Decimal T1 Cumulative Active MDI kW (Import) cumulative_mdi_pos_t2 Decimal T2 Cumulative Active MDI kW (Import) cumulative_mdi_pos_t3 Decimal T3 Cumulative Active MDI kW (Import) cumulative_mdi_pos_t4 Decimal T4 Cumulative Active MDI kW (Import) cumulative_mdi_pos_tl Decimal Total Cumulative Active MDI kW (Import) cumulative_mdi_neg_t1 Decimal T1 Cumulative Active MDI kW (Export) cumulative_mdi_neg_t2 Decimal T2 Cumulative Active MDI kW (Export) cumulative_mdi_neg_t3 Decimal T3 Cumulative Active MDI kW (Export) cumulative_mdi_neg_t4 Decimal T4 Cumulative Active MDI kW (Export) cumulative_mdi_neg_tl Decimal Total Cumulative Active MDI kW (Export) cumulative_mdi_abs_t1 Decimal T1 Absolute Cumulative Active MDI kW cumulative_mdi_abs_t2 Decimal T2 Absolute Cumulative Active MDI kW cumulative_mdi_abs_t3 Decimal T3 Absolute Cumulative Active MDI kW cumulative_mdi_abs_t4 Decimal T4 Absolute Cumulative Active MDI kW cumulative_mdi_abs_tl Decimal Total Absolute Cumulative Active MDI kW mdc_read_datetime Datetime Reading Date & Time of MDC db_datetime Datetime Record Entry Date & Time in Database Test Inspector: Name Designation

Signature

26 SMART METER TEST PROTOCOL STRATEGY 5.3.3 MONTHLY BILLING DATA The ‘Monthly Billing Data’ comprises information obtained from the smart meter registers that are exclusively recording monthly billing determinants. This information is provided to the billing engine for consumer billing and invoicing. Registers are based on tariff allocated to customer and have the provision to record peak/off values. The dataset contains bi-directional flow of energy for net metering in case the smart meter is configured for net metering. Test Inspector will record the information obtained from ‘Monthly Billing Data’ view/API and compare it with data retrieved from the head-end system (via reports). Additionally, data is to be verified with information displayed on the led screen of the meter, by physically scrolling through the meter registers. All the values will be recoreded using the Form SGIT- 05 below:

SMART METER TEST PROTOCOL STRATEGY 27

28 SMART METER TEST PROTOCOL STRATEGY active_mdi_abs_t1 Decimal T1 Absolute Active MDI kW active_mdi_abs_t2 Decimal T2 Absolute Active MDI kW active_mdi_abs_t3 Decimal T3 Absolute Active MDI kW active_mdi_abs_t4 Decimal T4 Absolute Active MDI kW active_mdi_abs_tl Decimal Total Absolute Active MDI kW cumulative_mdi_pos_t1 Decimal T1 Cumulative Active MDI kW (Import) cumulative_mdi_pos_t2 Decimal T2 Cumulative Active MDI kW (Import) cumulative_mdi_pos_t3 Decimal T3 Cumulative Active MDI kW (Import) cumulative_mdi_pos_t4 Decimal T4 Cumulative Active MDI kW (Import) cumulative_mdi_pos_tl Decimal Total Cumulative Active MDI kW (Import) cumulative_mdi_neg_t1 Decimal T1 Cumulative Active MDI kW (Export) cumulative_mdi_neg_t2 Decimal T2 Cumulative Active MDI kW (Export) cumulative_mdi_neg_t3 Decimal T3 Cumulative Active MDI kW (Export) cumulative_mdi_neg_t4 Decimal T4 Cumulative Active MDI kW (Export) cumulative_mdi_neg_tl Decimal Total Cumulative Active MDI kW (Export) cumulative_mdi_abs_t1 Decimal T1 Absolute Cumulative Active MDI kW cumulative_mdi_abs_t2 Decimal T2 Absolute Cumulative Active MDI kW cumulative_mdi_abs_t3 Decimal T3 Absolute Cumulative Active MDI kW cumulative_mdi_abs_t4 Decimal T4 Absolute Cumulative Active MDI kW cumulative_mdi_abs_tl Decimal Total Absolute Cumulative Active MDI kW mdi_reset_datetime Datetime MDI Reset Date & Time reset_count Int MDI Reset Count Number mdc_read_datetime Datetime Reading Date & Time of MDC db_datetime Datetime Record Entry Date & Time in Database Test Inspector: Name Designation

Signature

SMART METER TEST PROTOCOL STRATEGY 29 5.3.4 LOAD PROFILE DATA Energy consumption is being recorded with grid parameters by the smart meters with regular intervals. Typically, this interval is pre-set to 30 minutes by the DISCOs. However, the interval can be set by the Metering & Testing (M&T) department of the DISCO to any duration of choice. The consumption and grid profiles contain register- wise information of energy data as well as phase-wise information of the grid data. The itemized record of time-interval consumption helps DISCOs to assess the customer demand and load factor. Test Inspector will review the information obtained from ‘Load Profile Data’ view/API and compare it with data retrieved from the head-end system (via reports). Additionally, the data is to be verified with information displayed on the led screen of the meter by physically scrolling through the meter registers. All the values will be recoreded using the Form SGIT- 06 below:

30 SMART METER TEST PROTOCOL STRATEGY

SMART METER TEST PROTOCOL STRATEGY 31

32 SMART METER TEST PROTOCOL STRATEGY 5.3.5 EVENTS The ‘events’ packet received from smart meter are records of alarms and alerts with the time-stamp. The main events to record are configured in the smart meter as per relevant specifications. These alarms and alerts are required to be verified whether they appear similar to the information maintained by the head-end and the smart meter. Test Inspector will review the codes obtained from ‘Event Data’ view/API and compare it with data retrieved from the head-end system (via reports). Further, the data is to be verified with information displayed on the meter screen. All the values will be recoreded using Form SGIT- 07 below:

SMART METER TEST PROTOCOL STRATEGY 33 5.3.6 METER VISUALS Smart meters maintain parameterization as well as record of activities performed from time to time with appropriate credentials. The “Meter Visuals” provides a complete snapshot of the smart meter including meta data, master data and the latest transaction data as maintained within the head-end system. Test Inspector will review the information obtained from ‘Meter Visual’ view/API and compare it with data retrieved from the head-end system (via reports). All the values will be recoreded using Form SGIT- 08 below:

34 SMART METER TEST PROTOCOL STRATEGY

SMART METER TEST PROTOCOL STRATEGY 35

36 SMART METER TEST PROTOCOL STRATEGY 5.4 FORMS FOR COMMANDS There are several commands that may be required to pass on to meters for performing certain functions based on need basis. MDM being the central authority should pass on these commands to various MDCs on standard format through Universal Data Integration Layer. These commands and their parameters have been defined in the UDIL document and needs to be tested for conformity. MDCs are required to interpret these commands correctly and subsequently perform and acknowledge through UDIL. To ensure compliance to the UDIL specifications, the Test Inspector will perform each (or all commands within the checklist) and will record output in the appropriate SGIT Form provided in the following subsections.

5.4.1 AUX RELAY OPERATIONS This write function is to operate the disconnection/reconnection relay of the smart meter. The command is required to be passed on to the head-end system through the MDM interface available for the DISCO. Head-end system will send the wake-up command the smart meter and pass the “Aux Relay Operation” command for execution (Disconnect Command). Once the disconnection command has been executed, the meter status will be recoded with associated parameters and the Reconnect Command will be sent to the smart meter. For each stage of communication, an acknowledgement will be made by the system. The first acknowledgement is by the head-end system to user interface for accepting the write command post verification of the security key and the second acknowledgement is the successful execution of disconnection/reconnection. Test Inspector will review the acknowledgement packets for format and value compliance as per UDIL standard. Also, physical verification will be made for Disconnection/Reconnection. The test data will be recorded in Form SGIT – 09 below:

SMART METER TEST PROTOCOL STRATEGY 37

38 SMART METER TEST PROTOCOL STRATEGY 5.4.2 TIME SYNCHRONIZATION Write function “Time Synchronization” has been designed to synchronize the meter date time with the head-end time if so required. Generally, the date and time is set during parameterization but in case the “Time Synchronization” is required, this function will be executed. For each stage of communication, there will be an acknowledgement made between the systems. The first acknowledgement is by the head-end system to the user interface for accepting the write command post verification of security key while the second acknowledgement is the successful synchronization of meter time with the head-end system’s time. The test data will be recorded in Form SGIT – 10 below:

SMART METER TEST PROTOCOL STRATEGY 39 5.4.3 SANCTIONED LOAD CONTROL At time the customer sanctioned load needs to be changed for the Smart Meter. This function facilitates updating the sanctioned load limits and number of tries before the meter disconnects permanently to protect itself. The command is required to be passed on to the head-end system through interface available for the DISCO end-user. Head-end system will then pass over the command to the smart meter for execution. For each stage of communication, an acknowledgement will be made between the systems. The first acknowledgement is by the head-end system to user interface for accepting the write command post verification of security key while the second acknowledgement is the successful synchronization of meter time with the head-end system’s time. The test data will be recorded in Form SGIT – 11 below:

40 SMART METER TEST PROTOCOL STRATEGY 5.4.4 LOAD SHEDDING SCHEDULING / MANAGEMENT The “Load-shedding Scheduling / Management” function is to set the power schedule for individual or group of customers to achieve objectives, meeting the shortfall or improving the load factor by clipping the demand during peak hours without denying the power availability to the customers. Based on the schedule, the smart meter will operate the relay to disconnect/reconnect the power supply. The command is required to be passed on to the head-end system through MDM. Head-end system will then transmit the command to the smart meter for execution. The compliance information will be recorded in Form SGIT – 12 below:

SMART METER TEST PROTOCOL STRATEGY 41 5.4.5 TIME OF USE CHANGE The smart meter records various time of day usage and stores it in different registers; Daily, Weekly, Seasonal and Holidays. Through the use of this API, the user can update the time profile as necessary. The acknowledge based command processing has been designed. The Test Inspector will execute “Time of Use Change” and will record the parameters in Form SGIT-13 below:

42 SMART METER TEST PROTOCOL STRATEGY 5.4.6 DEVICE CREATION When a new smart meter is installed in the field, it requires to be created in the MDM as well as in the relevant MDC. Since MDC is acting as an interface for the smart meter, it requires meter credentials to authenticate the legitimacy before granting access for data retrieval and command transmission. With the use of the “Device Creation” API, a new metering point will be created to bring it online. The Test Inspector will create a meter and will verify the credentials. The smart meter credentials will be verified and documented in Form STIG – 14 below.

SMART METER TEST PROTOCOL STRATEGY 43

44 SMART METER TEST PROTOCOL STRATEGY 5.4.7 UPDATE IP PORT The objective of the write function is to change the IP address / port number of a smart meter. The command is required to be passed on to the head-end system through the MDM interface available for the end-user. Head-end system will then communicate the command to the smart meter for execution. For each stage of communication, an will acknowledgement will be made between the systems. The first acknowledgement is by the head-end system to user interface for accepting the write command post verification of security key while the second acknowledgement is the successful change of the IP address/port. The Test Inspector will execute “Update IP Port” and will verify and record the parameters in Form SGIT-15 below:

SMART METER TEST PROTOCOL STRATEGY 45 5.4.8 METER DATA SAMPLING The “Meter Data Sampling” API will be verified by executing this command and changing the data sampling rate. The sampling rate is a critical variable for calculating the metering determents by the smart meters. The Test Inspector will verify and document the pre and post-command values in Form SGIT-16 below:

46 SMART METER TEST PROTOCOL STRATEGY 5.4.9 ACTIVATE METER OPTICAL PORT API will be executed to activate and deactivate the smart meter optical port, “Activate Meter Optical Port”. The Test Inspector will be physically verifying the status of the optical port after execution of the command. All information will be recorded and verified in Form SGIT – 17 below:

5.4.10 WAKE UP SIM NUMBER UPDATE The smart meter remains in a hibernation mode till it receives a wake-up call from the head-end or automatically wakes up on pre-defined intervals to communicate data to the head-end system. The GSM/GPRS based smart meters can store three different numbers which are authorized to send a wake-up call to the meter. The “Wake UP SIM SMART METER TEST PROTOCOL STRATEGY 47 Number Update” API command will be executed to update the authorized numbers. The Test Inspector will verify the successful operation of this API command and record the compliance in Form SGIT – 18 below:

48 SMART METER TEST PROTOCOL STRATEGY 5.4.11 METER STATUS In order to find out the latest status of the smart meter, the Test Inspector will execute “Meter Status” API and change the meter status. Physical as well as data verifications will be performed in Form SGIT – 19 below:

SMART METER TEST PROTOCOL STRATEGY 49