| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| playground:techspec [2025/11/13 15:03] – rahul | playground:techspec [2025/11/13 15:29] (current) – rahul |
|---|
| <font 16.0pt/Aptos,sans-serif;;inherit;;inherit>**Chapters of ISV Knowledge Repository**</font> ** ** | Here is a detailed playbook and analysis for developing a technical reference design for an open Advanced Metering Infrastructure (AMI) stack using COTS hardware in Nigeria. |
| | This playbook is structured as a phased approach, from identifying the regulatory landscape to the final system audit and certification. |
| |
| - [[https://wiki.smartvillage.ieee.org/informationdigest|**Introduction **(mostly from https://wiki.smartvillage.ieee.org/informationdigest]]) **(Natalie//Rajan)** | == Phase 1: Define the Ecosystem (Key Players) == |
| - | Success in Nigeria requires engaging a specific set of regulatory and commercial stakeholders. Your reference design must meet the requirements of each. |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Mission and Vision, History and Background, Scope</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>ISV Pillars and Model, Solutions, Impact</font> - **ISV Organization (Editor//Rajan Kapur)** - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Introduction</font> | |
| |
| - | ^ **Category** ^ **Key Player** ^ **Role & Mandate in Your Project** ^ |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Executive Committee</font> | | **Primary Regulator** | **NERC** (Nigerian Electricity Regulatory Commission) | **The Rule Maker.** NERC issues all guidelines for the sector. Your entire AMI solution must comply with the **Nigerian Metering Code** and the **Meter Asset Provider (MAP) Regulations, 2018**. They are the ultimate approver of the system design. | |
| | | **Technical Enforcement** | **NEMSA** (Nigerian Electricity Management Services Agency) | **The Hardware Inspector.** NEMSA is responsible for the hands-on testing and certification of all hardware. They enforce technical standards for all meters and electrical equipment. Your COTS hardware must pass their certification. | |
| | | **Standards & Imports** | **SON** (Standards Organisation of Nigeria) | **The Gatekeeper.** SON sets general standards and manages the **SONCAP** (Standards Organisation of Nigeria Conformity Assessment Programme) for all imported goods. Your imported COTS hardware (meters, DCUs, comms modules) must have SONCAP certification. | |
| | | **Cybersecurity & Data** | **ONSA** (Office of the National Security Adviser) | **The National Security Guardian.** ONSA designates "Critical National Information Infrastructure" (CNII). A national AMI system is CNII. You must comply with the **Cybercrimes Act, 2015** and have an incident response plan linked to **ngCERT** (Nigeria's CERT). | |
| | | **Cybersecurity & Data** | **NITDA** (National Information Technology Development Agency) | **The Data Privacy Guardian.** NITDA enforces the **Nigeria Data Protection Regulation (NDPR)**. Your reference design must have robust controls for handling customer data, ensuring privacy and compliance. | |
| | | **The "Customers"** | **DisCos** (Distribution Companies) | The 11 DisCos (e.g., Ikeja Electric, Eko Electric) are the primary adopters and operators of the AMI stack. The reference design must solve their commercial and technical challenges (e.g., ATC&C loss reduction). | |
| | | | **MAPs** (Meter Asset Providers) | NERC-licensed companies that finance, procure, and install meters. They are your primary commercial channel. Your reference design will likely be procured by a MAP (or a DisCo acting as one) to service a DisCo's needs. | |
| |
| - | == Phase 2: Playbook for a COTS-Based Open AMI Stack == |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Regional Committees</font> | This is the step-by-step process for developing the reference design. |
| |
| - | === Step 1: Define the "Open" Architecture === |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Central Committees</font> | The core of your reference design is an "open" stack. In the AMI context, "open" does not mean "open source" software. It means **vendor interoperability through open standards**. |
| | Your reference design must be built on these components: |
| |
| - | * **Smart Meters (COTS):** The endpoint devices. |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Management Forum</font> | * **COTS Principle:** Sourced from any vendor (e.g., MOJEC, Landis+Gyr, Itron) whose meter is NEMSA-certified. |
| | * **Open Principle:** The meter must be fully compliant with the **DLMS/COSEM (IEC 62056)** standard. This is non-negotiable. It ensures any DLMS-compliant Head-End System can read the meter, regardless of the vendor. |
| | * **Communication Network (COTS):** This has two parts. |
| | * **Neighborhood Area Network (NAN):** Connects meters to a data concentrator. |
| | * **COTS Principle:** Use off-the-shelf, standards-based communication modules. Common COTS options are **Power Line Communication (PLC)** (e.g., G3-PLC, PRIME) or **RF Mesh** (e.g., Wi-SUN). |
| | * **Wide Area Network (WAN):** Connects data concentrators to the central HES. |
| | * **COTS Principle:** Use standard public or private telecom infrastructure. The most common COTS solution in Nigeria is **GPRS/3G/4G/LTE** via COTS-enabled SIM cards in the concentrator. |
| | * **Data Concentrator Unit (DCU) (COTS):** |
| | * **COTS Principle:** A ruggedized, off-the-shelf industrial gateway/computer. |
| | * **Open Principle:** The DCU must act as a DLMS/COSEM client to talk to the meters and a DLMS/COSEM server to talk to the HES. It aggregates data and manages the NAN. |
| | * **Head-End System (HES) (Software):** |
| | * **COTS Principle:** This is typically commercial software (e.g., from vendors like Siemens, Oracle, or AMI specialists) that runs on standard COTS servers (e.g., Intel-based, running Linux/Windows). |
| | * **Open Principle:** The HES must be "meter agnostic." It must use DLMS/COSEM to communicate with any certified COTS meter and DCU. It manages data collection, remote disconnect/connect, and tariff updates. |
| | * **Meter Data Management System (MDMS) (Software):** |
| | * **COTS Principle:** Commercial software running on COTS servers. |
| | * **Open Principle:** The MDMS must have standard-based Application Programming Interfaces (APIs), often based on **IEC 61968/61970 (Common Information Model)**, to integrate with other utility systems (billing, ERP, GIS). It receives validated data from the HES for storage, analysis, and billing. |
| |
| - | === Step 2: Select Hardware & Meet NEMSA/SON Certification === |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Task Forces</font> | This phase focuses on the physical hardware (meters, DCUs). |
| |
| - | * **Source COTS Hardware:** Identify manufacturers of meters, DCUs, and communication modules that are DLMS-compliant. |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Staff</font> | * **Achieve SONCAP (Imported Goods):** For any hardware imported, you must go through the SON-accredited conformity assessment process in the country of origin to get a SONCAP certificate. This is required for customs clearance. |
| | * **Achieve NEMSA Certification (The Critical Test):** Your hardware cannot be deployed without NEMSA certification. The process involves: |
| | * **Type Test Certification:** You submit samples of your new meter model to a **National Meter Test Station (NMTS)**. NEMSA tests the meter's design, accuracy, and anti-tamper features against the Nigerian Metering Code and IEC standards. This is the main certification for your COTS hardware model. |
| | * **Acceptance Test:** When a DisCo or MAP receives a batch (e.g., 1,000 meters), NEMSA may test a random sample from that batch before they can be installed. |
| | * **Routine Test:** In some cases, every single unit may be tested for accuracy. |
| | **Playbook Action:** Your reference design must specify COTS hardware that is already on NEMSA's list of "Type Test Certified" meters or budget for the time and cost of an 18-month Type Test process for any new hardware. |
| |
| - | === Step 3: Meet NERC System-Level Audit === |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>**Enterprise Lifecycle: Application and Execution (Christie//)//**</font> **//** | NERC audits the entire solution, not just the hardware. This "audit" is part of the **MAP/DisCo procurement and approval process**. |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Introduction</font> ** (Christie//Rajan CKGE_TMP_i ) CKGE_TMP_i ** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Application Process</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Regional Committee **(Pradeep//Sanjay Patki)//**</font> **//** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Project Development Committee</font> ** (Christie//Ola)** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Criteria/Process for Proposal/Project Selection **(Christie//Ola)//**</font> **//** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Payment Service Agreements (PSAs)</font> ** (Christie//Mike)** - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>PSA</font> | |
| |
| - | * **The "Audit" Event:** When a MAP or DisCo wants to deploy your reference design, they submit a technical and commercial proposal to NERC. |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>EFTR and Invoicing</font> | * **NERC's Checklist:** NERC will evaluate your design's documentation against: |
| | * **The Nigerian Metering Code:** Does your stack meet all technical specifications for AMI? |
| | * **MAP Regulations:** Does the solution enable the functions required by MAPs (e.g., remote reading, remote disconnection, load management, tariff updates)? |
| | * **Interoperability:** Is it truly open? You must prove DLMS/COSEM compliance for all relevant components. A **DLMS User Association certification** for your components is the strongest proof. |
| | * **Data & Security:** Has a cybersecurity audit been planned or completed? (See Step 4). |
| | * **Scalability:** Can the HES/MDMS architecture handle the number of meters (e.g., 100,000 or 1,000,000+)? |
| | **Playbook Action:** The technical reference design document itself is the primary tool for passing this audit. It must be exceptionally detailed, with clear compliance matrices mapping your design features to NERC's regulations. |
| |
| - | === Step 4: Meet Cybersecurity & Data Privacy Audits === |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Reports, Tranche Payments, Change-Request, and Monitoring **(Editor//Abdullateef Aliyu)//**</font> **//** | This is a system-level audit that runs parallel to the NERC approval. It is critical and often overlooked. |
| - **Enterprise Lifecycle: Operation (Editor//)** - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Enterprise Governance **(//Ashok Das, Sanjay Patki, Monica Brown, Jude Numfor)//**</font> **//** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Business Models</font> ** (//Ashok Das, Sanjay Patki, Monica Brown, Jude Numfor)** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Technology</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Solar Technology **(//Adam Sauer)//**</font> **//** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Other Technologies</font> ** (//Rahul Bhargava)** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Safety, Quality, Reliability, and Standards (SQRS) **(//Bruno)//**</font> **//** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Reports and Monitoring</font> ** (//Abdullateef)** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>**Initiatives**</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>CKGE_TMP_i Past Projects CKGE_TMP_i (**Kevin Lobo//)//**</font> **//** <font 12pt/Aptos,sans-serif;;inherit;;inherit>For each completed project:</font> - - - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Name, Region, Timeline, Team Members, etc.</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Objective</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Impact</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Major Hurdles/Challenges</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>How Challenges Were Overcome</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Lessons Learned</font> - - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>CKGE_TMP_i Current Projects CKGE_TMP_i (</font> **Nicole Kawaako//** ) | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>For each ongoing project:</font> | |
| |
| - - - | * **Legal Framework:** |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Name, Region, Timeline, Team Members, etc.</font> | * **Cybercrimes Act, 2015:** Your system will be **CNII**. You must protect it from breaches. |
| | * **Nigeria Data Protection Regulation (NDPR):** Your MDMS will hold personal data (name, address, consumption). You must protect it. |
| | * **The Audit Process:** |
| | * An independent auditor (or a regulator like NITDA) will audit your system. |
| | * The audit will be based on international standards: **ISO 27001** (for the Information Security Management System) and the **NIST Cybersecurity Framework** (for technical controls). |
| | * **Reference Design Requirements:** Your design must include: |
| | * **Technical Controls:** End-to-end encryption, role-based access control, network firewalls, and system hardening. |
| | * **Data Privacy:** Proof of how customer data is anonymized, encrypted at rest, and protected from unauthorized access, per NDPR. |
| | * **Incident Response Plan:** A formal plan that details how you will detect and respond to a breach, including the mandatory step of **reporting the incident to ngCERT**. |
| | **Playbook Action:** Your reference design must have a dedicated "Cybersecurity & Data Privacy" volume, detailing the controls and compliance with ISO 27001, NIST, and the NDPR. |
| |
| - | == Summary: Certification & Audit Checklists == |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Objective</font> | Use these checklists as a guide for your reference design. |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Expected Impact</font> | |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Progress Made So Far and Projections</font> | |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Major Hurdles/Challenges</font> | |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>How Challenges Are Being Addressed</font> | |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Additional Resources Needed</font> | |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Lessons Learned So Far</font> | |
| | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>**Resources (//)//**</font> **//** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Proposal Writing Help</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Learning Modules: Technical Guidelines, Research Papers</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Workshop Materials</font> - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>Regional Rules and Regulations</font> - **Best Practices (//Recent volunteer – name escapes me)** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>**Lessons Learned (Mureithi Kivuti//)//**</font> **//** | |
| - **Student Activities (//Toby Cumberbatch)** | |
| - | |
| <font 12pt/Aptos,sans-serif;;inherit;;inherit>**Membership (Salamatu//Salamatu Sani)//**</font> **//** - **Marketing (//Monica)** | |
| |
| | === Hardware (Meter/DCU) Certification Checklist === |
| | ^ **Item** ^ **Certifying Body** ^ **What It Is** ^ **Why It's Needed** ^ |
| | | **Type Test Certificate** | **NEMSA** | Lab test of a sample meter model. | **Mandatory.** No meter model can be deployed without this. | |
| | | **SONCAP Certificate** | **SON** | Conformity assessment for imports. | **Mandatory** for clearing customs with imported hardware. | |
| | | **DLMS/COSEM Certificate** | **DLMS User Assoc.** | Proof of interoperability. | **Not legally mandatory, but essential.** This is your only proof that your stack is "open." NERC will demand this. | |
| |
| | === System (Solution) Audit Checklist === |
| | ^ **Audit Type** ^ **Governing Body** ^ **Key Document/Standard** ^ **What is Audited?** ^ |
| | | **Technical Solution Audit** | **NERC** | Nigerian Metering Code, MAP Regulations | The entire AMI stack's functionality (remote read, disconnect, etc.), scalability, and compliance with regulations. | |
| | | **Cybersecurity Audit** | **ONSA / NITDA** | Cybercrimes Act, 2015, NIST/ISO 27001 | Protection of the system (CNII) from cyberattacks. | |
| | | **Data Privacy Audit** | **NITDA** | Nigeria Data Protection Regulation (NDPR) | Protection of customer personal data (PII) within the MDMS. | |
| | | **Incident Reporting** | **ONSA / ngCERT** | Cybercrimes Act, 2015 | The existence of a formal plan to report all security incidents to the national CERT. | |