TECHNICAL REQUIREMENT DOCUMENT FOR SMART ...

Israel Electric Corporation

ISRAEL ELECTRIC CORPORATION

(IECo)

TECHNICAL

REQUIREMENT DOCUMENT FOR SMART

METER PROJECT

Date: 07/2021

Status: Final

Technical Requirement Document for Smart Meter Project


Table of Contents

1 INTRODUCTION ............................................................................................................ 12

Background 12

Scope 12

Business vision 13

High-level bidder expectations 13

How to Read this Document 14 1.5.1 Document Structure 14 1.5.2 Requirements Format 15 1.5.3 Requirements Scoring 16

2 TECHNICAL REQUIREMENTS FOR THE AMI SYSTEM .......................................................... 17

Architectural Requirements 17

Requirements on Communication Interfaces 19 2.2.1 Ilocal_meter 20 2.2.2 Ilocal_DC 23 2.2.3 IDC_meter 24 2.2.4 IHES_meter 25 2.2.5 IHES_DC 27 2.2.6 Icustomer_meter 28 2.2.7 Communication unit for mobile communication 29 2.2.8 Requirements regarding PLC network quality 31

AMI Business Processes 31 2.3.1 Roadmap for business processes implementation 47

AMI System Use Cases 52

Documentation Requirements 60

3 TECHNICAL REQUIREMENTS FOR THE SMART METERS ...................................................... 63

Norms & Regulations 63 3.1.1 General Norms for metering equipment 63 3.1.2 Climatic conditions 64 3.1.3 Durability & Reliability 65 3.1.4 Metrology 65 3.1.5 Safety 68 3.1.6 Electromagnetic compatibility 69

Hardware Requirements 70 3.2.1 Electrical Ratings 70 3.2.2 Meter Casing 70 3.2.3 Seals 72 3.2.4 Markings 73 3.2.5 Terminal block 78 3.2.6 Meter mounting 80 3.2.7 Power supply 82 3.2.8 User interface 83 3.2.9 Real Time Clock 87 3.2.10 Breaker 88 3.2.11 Memory 89

Software Requirements 90 3.3.1 Data exchange & data model 90 3.3.2 Firmware 92

4 TECHNICAL REQUIREMENTS FOR THE DATA CONCENTRATORS .......................................... 93

Norms & Regulation Related Requirements 93 4.1.1 Climatic conditions 93 4.1.2 Durability & Reliability 94 4.1.3 Safety 94



4.1.4 Electromagnetic Compatibility 95

Hardware Requirements 96 4.2.1 Electrical Ratings 96 4.2.2 Casing 96 4.2.3 Seals 97 4.2.4 Markings 97 4.2.5 Power supply 98 4.2.6 Real Time Clock 99 4.2.7 Memory 99 4.2.8 Connection & Communication 100

Functional/Software Requirements 100 4.3.1 Data exchange & data model 100 4.3.2 Monitoring and Network Management 103 4.3.3 Synchronization 105 4.3.4 Firmware 106

5 TECHNICAL REQUIREMENTS FOR THE HEAD-END-SYSTEM............................................... 107

General Requirements 107

HES Integration Requirements 110

6 MASS PRODUCTION REQUIREMENTS ............................................................................ 112

General 112

HASS/Aging Test 114

Final Factory Verification Tests before shipping 115

Packaging requirements 116

Series Production and Acceptance Test 116

7 FAILURE MANAGEMENT REQUIREMENTS FOR METERS IN OPERATION ............................... 121

8 TECHNICAL REQUIREMENTS FOR PORTABLE TEST PC AND DIAGNOSTIC TOOLS................. 124

9 CYBER SECURITY REQUIREMENTS ................................................................................ 126

AMI System Security Requirements 126

Cyber Requirements for Smart Meters 137

DC Security Requirements 147

HES Security Requirements 157

Cyber Security Additional and Optional Requirements 166

10 E2E INTEGRATION AND FUNCTIONAL DESCRIPTION ....................................................... 172

Business goals 172

Business guidelines and IT principles 174

System architecture 174

Data management 181

Non-functional requirements 183 10.5.1 Delivery & implementation 183 10.5.2 Methodology & standards 184 10.5.3 Usability 186 10.5.4 Reliability 187 10.5.5 Safety 188 10.5.6 Scalability 189 10.5.7 Performance 189 10.5.8 Flexibility/interoperability 190

11 PROJECT DELIVERY EXPECTATIONS .............................................................................. 191

SAFe 191

Definition of business processes and/or use cases 191



Bidder roles within the project 192

Project timelines 194

Scope clarification 194

Transition to maintenance & operations 194

Expected plans as part of this tender 196

12 ADDITIONAL REQUIREMENTS FOR THE BIDDER ............................................................. 198

13 KPI FOR THE SMART METERING PROJECT ...................................................................... 206

General 206

Preparatory Phase 206

System Deployment Phase 206 13.3.1 Pilot & Ramp-up 206 13.3.2 Deployment & Operation 207

Post Deployment Phase 210 13.4.1 Stabilization and Operational Acceptance 210

PLC FILTERS ...................................................................................................... 211

A.1 Overview of needed filter types 211

A.2 Technical details 211 A.2.1 Technical details 1 Ph, 40 dB, 40A PLC filter 211 A.2.2 Technical details 1 Ph, 40 dB, 65A PLC filter 211 A.2.3 Technical details 1 Ph, 40 dB, 80A PLC filter 212 A.2.4 Technical details 3 Ph, 40 dB, 65A PLC filter 212 A.2.5 Technical details 3 Ph, 40 dB, 80A PLC filter 212

A.3 Mechanical details 213

A.4 Label 213

A.5 Safety 213

ENERGY REGISTERS MEASUREMENT METHOD ....................................................... 214

B.1 Dual and single Energy metering method modes 214

B.2 Energy Registers 214 B.2.1 Vector metering 215 B.2.2 Arithmetic metering 217 B.2.3 Use case example table for vector and arithmetic metering 219 B.2.4 Testability 220 B.2.5 Functional requirements from data model 220 B.2.6 Functional requirements in favour of Meter Data Management System 220

SPECIFICATIONS REGARDING CURRENT INSTRUMENT TRANSFORMERS .................. 222

C.1 Type of Current Instrument Transformers in Scope 222

C.2 Required Documents for Evaluation of Technical Proposal 222

C.3 Quality Control 224

C.4 Quality Assurance 225

C.5 Preliminary Batch for Approving Delivery 225

C.6 General 225 C.6.1 Scope 225 C.6.2 Standards and Codes 226 C.6.3 Relevant Regulations and Standards 227 C.6.4 Environmental Conditions 227

C.7 Technical Requirements 227 C.7.1 Electrical Requirements 227 C.7.2 General Construction Requirements 228

C.8 Tests 231 C.8.1 Type Tests 231 C.8.2 Routine Tests 231



C.8.3 Special Tests 231 C.8.4 Acceptance Tests 231

C.9 Warranty 232

C.10 Official Company Symbol 233

C.11 Summary of Data for Measuring Current Transformers 234

PACKAGING REQUIREMENTS FOR COMPONENTS ................................................... 237

D.1 Packaging 237 D.1.1 General 237 D.1.2 Primary Packaging 239 D.1.3 Secondary Packaging 240

D.2 Shipment Documents 240

D.3 Handling of DDP goods 241

D.4 Official Company Symbol 241

HASS REQUIREMENTS ........................................................................................ 242

E.1 HASS general definition 242

E.2 IECo HASS requirements 243 E.2.1 Thermal cycling tests 243 E.2.2 Vibration and free fall tests 243

METERS AND DC RAM REQUIREMENTS ................................................................. 245

F.1 Definitions 245

F.2 RAM Requirements 245

F.3 RAM Declaration 246

F.4 Reliability Demonstration 247

OFF THE SHELF PRODUCT DECLARATION ............................................................. 248

PROVISIONING TEST ......................................................................................... 250

METROLOGY REPORT FORMAT ............................................................................. 252

I.1 1Ph 252

I.2 3Ph 252

I.3 CT 253



Index of Tables

Table 1-1 Requirements format used in this document ................................................................. 15 Table 3-1: Special Days .............................................................................................................. 91 Table 7-1: Standard failure management requirements per IECo ................................................... 122 Table 11-1: Expected plans ....................................................................................................... 196 Table 13-1: Deployment KPIs .................................................................................................... 208 Table 13-2: Operations KPI's ..................................................................................................... 208 Table 13-3: Stabilization KPIs .................................................................................................... 210 Table 13-4: Thermal cycling tests .............................................................................................. 243 Table 13-5: Vibration test ......................................................................................................... 243 Table 13-6: Free fall test .......................................................................................................... 244 Table 13-7: Contents of Initial and Final provision tests ................................................................ 244

Index of Figures

Figure 1-1: Technical requirements scope ..................................................................................... 12 Figure 2-1 Example AMI Architecture of the MOACH project .......................................................... 17 Figure 2-2: Overview frequency bands in Israel ............................................................................. 29 Figure 2-3: Roadmap for business processes implementation as part of the new IECo’s AMI system .... 49 Figure 2-4: Serial and parallel implementation of BPs ..................................................................... 50 Figure 2-5: Business processes implementation principles ............................................................... 50 Figure 3-1: Example of single-phase direct connected meter nameplate ........................................... 74 Figure 3-2: Example of three-phase direct and CT connected meter nameplate ................................. 74 Figure 3-3: Example of Meter face and nameplate ......................................................................... 75 Figure 3-4: Connection diagram for single phase meter: L N N L’, (‘British Standard’) ........................ 77 Figure 3-5: Connection diagram for three phase meter, 4-wire meter: L1 L1’ L2 L2’ L3 L3’ N N’ , (‘DIN

Standard’) ................................................................................................................................ 77 Figure 3-6: Connection diagram for three phase CT meter 4-wire meter: L1 U1 L1’ L2 U2 L2’ L3 U3 L3’ N N’ , (‘DIN Standard’) .................................................................................................................. 77 Figure 3-7: Example of mounting bracket ..................................................................................... 81 Figure 3-8: ToU Table 2010 ........................................................................................................ 91 Figure 10-1: Simplified System Architecture ................................................................................ 174 Figure 10-2: Data Model Levels ................................................................................................. 182 Figure 10-3: Data Quality Criteria .............................................................................................. 182 Figure 13-1: Smart Metering Project Phases ................................................................................ 206 Figure 13-2: Installation method (illustration only) ...................................................................... 226 Figure 13-3: Cold and hot stress tests ........................................................................................ 242 Figure 13-4: Difference between HALT and HASS in stress margins ................................................ 242

https://dnv.sharepoint.com/teams/IECSmartMeterRoll-out/Shared%20Documents/General/IECo%20Execution/05%20-%20Deliverables%20working%20documents/Task%207/7.1%20Tender%201%20Devices/IEC%20Task%207_%20Draft%20Tender%201%20Devices%20Main%20working%20Document.docx#_Toc76643028

https://dnv.sharepoint.com/teams/IECSmartMeterRoll-out/Shared%20Documents/General/IECo%20Execution/05%20-%20Deliverables%20working%20documents/Task%207/7.1%20Tender%201%20Devices/IEC%20Task%207_%20Draft%20Tender%201%20Devices%20Main%20working%20Document.docx#_Toc76643038



Acronyms and abbreviations

Acronym/abbreviation Definition

1Ph Single phase

3Ph Three phase

AES Advanced Encryption Standard

AMI Advanced Metering Infrastructure

BP Business Process

COSEM Companion Specification for Energy Metering

CT Instrument Current Transformers

CV Curriculum Vitae

DC Data Concentrator

DFT Design For Testability

DLMS Device Language Message Specification

DSO Distribution System Operator

EAL Evaluation Assurance Level

ECDSA Elliptic Curve Digital Signature Algorithm

EMC Electromagnetic Compatibility

E-meter Electricity Smart Meter

EN European Standards

ESB Enterprise Service Bus

eSIM embedded Subscriber Information Module

eUICC Embedded Universal Integrated Circuit Card

FAT Factory Acceptance test

FCC Federal Communications Commission

FRB Failure Review Board

GCF Global Certification Forum

GMAC Galois Message Authentication Code

GMC Galois/Counter Model

G3PLC Generation 3 – PLC: An OFDM PLC specification maintained by the G3PLC Alliance.

GUI Graphical User Interface

HDLC High-Level Data Link Control

HES Head End System

HHU Hand Held Unit

HLD High :Level Design

HLS High Level Security

HSM Hardware Security Module

IAM Identity Access Management



IDIS Interoperable Device Industry Specification: DLMS/COSEM based

companion specification for smart meters. The specification was developed and is maintained by the IDIS Association.

IEC International Electrotechnical Commission

IP Internet Protocol

IT Information Technology

KMS Key Management System

NB-IoT Narrow Band-Internet of Things

LED Light Emitting Diode

LLD Low Level Design

LTE Long Term Evolution

MTTF Mean Time To First Failure

MOACH Smart Meter roll-out project

MDMS Meter Data Management System

MID Measuring Instruments Directive

OBIS Object Identification System

OFDM Orthogonal Frequency Division Multiplexing

OS Operating System

OT Operational Technology

PKI Public Key Infrastructure

PLC Power Line Communications

PLMN Public Land Mobile Network. Group name for all kind of cellular mobile communication technologies, like LTE, NB-IoT

PT Penetration Testing

RAM Reliability, Availability, and Maintainability

RCA Root-Cause Analysis

RFD Reliability Field Demonstration

RJ Registered Jack

RTO Recognised Test Organisation

SAT Site Acceptance test

SOAP Simple Object Access Protocol

SOW Statement Of Work

SSO Single-Sign-On

STD Standard Test Description

STP Standard Test Procedure

TCP Transmission Control Protocol

ToU Time of Use

TR Technical Requirement

TTF Time To First Failure

UC Use Case



UI User Interface

UX User Experience

UDP User Datagram Protocol

VA Vulnerability Assessment

VEE Validation, Estimation, Editing

WELMEC EUROPEAN Cooperation in Legal Metrology (originally Western European Legal Metrology Cooperation)

XML eXtensible Mark-up Language

Terms and definitions

Term Definition

Contracting Entity Israel Electric Company

Contractor The party delivering products and/or services to the contracting authority and as such the successful bidder.

Field devices Components of the AMI solutions that are deployed in the field: E-meters and Data Concentrators.

Bidder The party answering this RFP and as such applying to become contractor.

Referenced norms

Reference Title

EN 50065 Signalling on low-voltage electrical installations in the frequency range 3 kHz

to 148,5 kHz

EN 50470-1 Electricity metering equipment (a.c.) - Part 1: General requirements, tests and

test conditions – Metering equipment (class indexes A, B and C)

EN 50470-3 Electricity metering equipment (a.c.) - Part 3: Particular requirements – Static

meters for active energy (class indexes A, B and C)

EN 55022 Information technology equipment – Radio disturbance characteristics – Limits

and methods of measurement

IEC 60068-2-1 Environmental testing - Part 2-1: Tests - Test A: Cold

IEC 60068-2-2 Environmental testing - Part 2-2: Tests - Tests B: Dry heat

IEC 60068-2-14 Environmental testing - Part 2-14: Tests - Test N: Change of temperature

IEC 60068-2-30 Environmental testing - Part 2-30: Tests - Test Db: Damp heat, cyclic (12 h +

12 h cycle)

IEC 60068-2-78 Environmental testing - Part 2-78: Tests - Test Cab: Damp heat, steady state



IEC 60529 Degrees of protection provided by enclosures (IP Code)

IEC 61000-4-2 Electromagnetic compatibility (EMC) – Part 4-2: Testing and measurement

techniques – Electrostatic discharge immunity test


techniques – Radiated, radiofrequency, electromagnetic field immunity test


techniques – Electrical fast transient/burst immunity test


techniques – Surge immunity test


techniques – Immunity to conducted disturbances, induced by radio-frequency

fields


techniques – Power frequency magnetic field immunity test


techniques – Voltage dips, short interruptions and voltage variations immunity

tests


techniques – Oscillatory waves immunity test. Basic EMC publication

IEC 61000-4-13 Electromagnetic compatibility (EMC) - Part 4-13: Testing and measurement

techniques - Harmonics and interharmonics including mains signalling at a.c.

power port, low frequency immunity tests

IEC 62052-11 Electricity metering equipment (a.c.) - General requirements, tests and test

conditions - Part 11: Metering equipment

IEC 62052-21 Electricity metering equipment (a.c) - General requirements, tests and test

conditions - Part 21: Tariff and load control equipment

IEC 62052-31 General requirements, tests and test conditions - Part 31: Product safety

requirements and tests

IEC 62053-23 Electricity metering equipment (a.c.) - Particular requirements - Part 23: Static

meters for reactive energy (classes 2 and 3)

IEC 62053-52 Electricity metering equipment (a.c.) - Particular requirements - Part 52:

Symbols

IEC 62054-21 Electricity metering (a.c.) - Tariff and load control - Part 21: Particular

requirements for time switches

IEC 62056-21 Electricity metering - Data exchange for meter reading, tariff and load control -

Part 21: Direct local data exchange



IEC 62056-7-6 Electricity metering data exchange - - The DLMS/COSEM suite – Part 7-6 -

The 3-layer, connection-oriented HDLC based communication profile

IEC 62056-8-5 Electricity metering data exchange - The DLMS/COSEM suite - Part 8-5:

Narrow-band OFDM G3-PLC communication profile for neighbourhood

networks.

IEC 62056-9-7 Electricity metering data exchange - The DLMS/COSEM suite - Part 9-7:

Communication profile for TCP-UDP/IP networks

IEC TR 62059-21 Electricity metering equipment - Dependability - Part 21: Collection of meter

dependability data from the field

IEC 62059-31-1 Electricity metering equipment - Dependability - Part 31-1: Accelerated

reliability testing - Elevated temperature and humidity

IEC 62059-41 Electricity metering equipment - Dependability - Part 41: Reliability prediction

FCC Part-15 (Title

47 CFR Part 15)

FCC Part-15 Rules: Unlicensed RF Devices (TITLE 47—Telecommunication,

CHAPTER I—FEDERAL COMMUNICATIONS COMMISSION, SUBCHAPTER A—

GENERAL, PART 15—RADIO FREQUENCY DEVICES)

IEC 11770-1 Information technology — Security techniques — Key management — Part 1:

Framework

Latest version of referenced norm applies, unless explicitly stated differently.



1 INTRODUCTION

Background

The Israel Electric Corporation is preparing for the rollout of a new generation of Smart meters from

2024 onwards. This document will form part of the tendering specifications for equipment suppliers that

will meet the technical requirements for deployment in Israel specific to IECo. This document describes:

The technical requirements for Smart metering associated devices (e.g. meters, DCs, current

instrument transformers) of the AMI solution selected by IECo.

The integration requirements of the smart meters with the peripheral systems within IECo and

additional services to be developed, resulting in successful end-to-end processes, which go

beyond an MDM solution.

The requirements for end-to-end co-ordination and implementation by the bidder.

Scope

This document is part of the tender documentation for the AMI system mass rollout planned by IECo.

The document formally specifies the technical requirements related to the AMI system, including system

architecture and protocols, business processes, use cases, cyber security, integration and IT landscape,

key components (HES, DC, E-meters, and current instrument transformers) and communication

interfaces. Regulation, security, and functionality applicable to the AMI system are main drivers of the

requirements stated in this specification.

Figure 1-1: Technical requirements scope



Business vision

To successfully perform a mass smart meter roll-out, customer-facing & technical processes need to be

aligned. In the past years IECo has performed a roll-out of ~50k smart meters within Israel to learn

from the challenges of a smart meter roll-out and to define the requirements for the large-scale

implementation.

Smart meter deployments are reaching critical mass where AMI data can be harvested to deliver benefits

in different business areas. That means the integration of metering processes with different business

processes & systems is crucial to align the different processes within different internal departments and

with external stakeholders.

As part of the project IECo would like to achieve a high-level of integration of AMI data within the core

business processes. This means improving existing business processes of meter data integration, but

also introducing services that are currently not available within IECo.

A successful project goes beyond the roll-out of smart meters, IECo expects a large improvement of the

end-to-end processes and truly unlocking the value of AMI data. The vision is to create this value in

multiple areas, among which:

Increased efficiency of IECo’s processes

Improved security & quality of supply

Improved customer experience and public image

Allowing the introduction of potential new services

High-level bidder expectations

IECo is looking for a bidder to achieve its business vision. The bidder will take the end-to-end co-

ordination of the smart meter roll-out and the design & integration of services within the IECo business

processes and system landscape. This means the bidder is the single & main contractor and

accountable for the services delivered. Any potential subcontractors, working for the bidder,

will perform their services under the accountability of the bidder.

IECo is planning to deploy approximately 300k meters per year. IECo doesn’t want to wait until the end

of the full deployment to start unlocking the value of AMI data, and expects them to be available as soon

as possible. IECo understands it might not fully unlock all value for its processes when the roll-out

doesn’t have a critical mass yet for certain services, but there shouldn’t be a limitation that the

integration of business processes and/or corresponding system architecture won’t be ready.



How to Read this Document

1.5.1 Document Structure

This document consists on the following sections:

Section 1 – Introduction (current section)

Section 2 – Technical Requirements for the AMI System (applying for the end-2-end system)

Section 3 – Technical Requirements for the Smart Meters

Section 4 – Technical Requirements for the Data Concentrators

Section 5 – Technical Requirements for the Head-End-System

Section 6 – Mass Production Requirements for the Smart Meters

Section 7 – Failure Management Requirements for Meters in Operation

Section 8 – Technical Requirements for Portable Test PC

Section 9 – Cyber Security Requirements

Section 10 – Functional Description

Section 11 – Project Delivery Expectations

Section 12 – Additional Requirements for the Bidder

Section 13 – KPIs for the Smart Metering Project

This document further contains the following Appendices:

Appendix A – PLC Filters: This appendix contains the requirements regarding the PLC filters that the

bidder must provide in this project

Appendix B – Energy Registers Measurement Method: This appendix contains more information

regarding the applicable metering methods and energy registers

Appendix C – Specifications regarding current instrument transformers: This appendix contains the

requirements regarding the different types of current instrument transformers that the bidder must

provide in this project

Appendix D – Packaging Requirements for smart meters: This appendix contains requirement related to

packaging of components to be delivered to IECo

Appendix E – HASS Requirements: This appendix contains additional requirements related to “Highly

accelerated stress screen” (HASS) tests

Appendix F – Meters and DC RAM requirements

Appendix G – Off the Shelf Product Declaration

Appendix H - Provisioning Test

Appendix I – Metrology report format: This appendix provides formats for the metrology reports



1.5.2 Requirements Format

The technical requirements presented in this document are based on the format below.

Table 1-1 Requirements format used in this document

No: Number

Description: Description of the technical requirement

Component: ‘AMI’ xor [ ‘HES’ or ‘DC’ or ‘METER [1Ph, CT, 3Ph, PLMN, PLC]]’

Required Maturity: ‘STANDARD’ xor ‘STANDARD or TO BE DEVELOPED’

Priority: ‘REQUIRED’ xor ‘PREFERRED’

Fit criterion: Criteria of compliance

Evidence of

compliance:

‘Compliance with this specification is verified by evaluation of a sample’ or ‘Test

report or documented evidence from bidder’ or ‘Certificate / Test report +

Declaration of conformity from external laboratory’.

XOR means: Exclusive OR. A XOR B means either A or B, so not both.

The Requirement number provides unique identification within the present technical

specification. Section Number-[#]

The Description offers an overview of the requirement and gives a general idea of what is

required. Other attributes will provide the specifics for the requirement.

The Component indicates the targeted element for which the technical requirement is

applicable. There are 4 options:

o ‘AMI’ refers to all components in the Advanced Metering Infrastructure system;

o ‘HES’ refers to the Head End System;

o ‘DC’ refers to the Data Concentrator;

o ‘METER [1Ph, 3Ph, PLMN, PLC]’ refers to the E-meters which can be single phase (1Ph)

or three-phase (3Ph) and implement CELLULAR MOBILE COMMUNICATION (PLMN) or

POWER LINE COMMUNICATION (PLC) technologies.

Example 1: A requirement with METER [1Ph, 3Ph, PLMN, PLC] in the component field, applies for both

single phase and three-phase meters. The requirement applies for meters that implement Mobile

communication as well as for meters that implement Power Line Communication.

Example 2: A requirement labelled with METER [3Ph, PLC] applies only for three-phase meters that

implement PLC communication.



Required maturity:

o STANDARD means: Product(s) that are available at the time of responding to the tender,

comply to this requirement.

o STANDARD or TO BE DEVELOPED means: STANDARD, or a development will be done (or

will be allowed) after award of the contract (during the implementation phase of the

project).

Priority:

o ‘REQUIRED’ indicates a requirement the bidder must comply with. Non-compliance will

result in exclusion.

o ‘PREFERRED’ indicates a requirement that is very important, but not mandatory.

Solutions that comply with these technical requirements are awarded with points

contributing to the evaluation of the tender.

The Fit criterion provides insight on the criteria to be used to verify the requirement

compliance.

The Evidence of compliance prescribes how the bidder shall prove compliance to the

requirement.

1.5.3 Requirements Scoring

Regarding the scoring of requirements, numerous requirements are included in scoring sheets. The

following types of requirements can be included in the scoring:

Requirements with the priority label ‘PREFERRED’

Requirements with priority label ‘REQUIRED’ and required maturity label ‘STANDARD or TO BE

DEVELOPED’. In this case, the bidder must clearly indicate if this feature/requirement is already

available and implemented, or if he has to develop this. In the first case, the bidder will receive

more points.



2 TECHNICAL REQUIREMENTS FOR THE AMI SYSTEM

Architectural Requirements

The AMI architecture of the MOACH project is sketched in Figure 2-1. On the residential side, the meter

setup consists of an electricity meter (E-meter). Depending on the communication used, the E-meter

communicates directly with the head-end system (HES), or the end-to-end communication is facilitated

via a data concentrator device in the neighbourhood network.

Figure 2-1 Example AMI Architecture of the MOACH project



No: 2.1-1

Description: The AMI system architecture shall consist of a Head End System (HES), point to point connected E-meters and E-meters that communicate via Data Concentrators

(DCs).

Component: AMI

Required Maturity: STANDARD

Priority: REQUIRED

Fit criterion: The system architecture similar as described in section 2.1 and drawn in Figure 2-1

shall be implemented.

Evidence of

compliance:

Documented evidence from bidder.

No: 2.1-2

Description: The AMI system shall be scalable up to 4.2 million E-meters.

Component: AMI


Priority: REQUIRED

Fit criterion: The system shall comprise in total ~3,000,000 single and three phase E-meters

throughout Israel. The system shall be scalable: It shall be possible to manage up to 4.2 million E-meters in Israel.

Evidence of

compliance:

Test report or documented evidence from bidder.

No: 2.1-3

Description: The system shall provide network topology and connectivity information.

Component: AMI

Required Maturity: STANDARD or TO BE DEVELOPED

Priority: REQUIRED

Fit criterion: The system shall provide, for its segment of the LV network:

Topology information (including number of switch/nodes to each G3-PLC meter).

Communication status of each meter. Integration with the peripheral systems.

Evidence of

compliance:




The following interfaces are present to facilitate data exchange between the system components:

Ilocal_meter: This interface is used for communicating with an external device during on-site

maintenance or installation of the meters.

IHES_meter: This interface is used for the communication between the E-meter and the head-end

system (HES). The application protocol used on this interface is the DLMS/COSEM protocol. The

‘Annexure B2 - MOACH DLMS COSEM profile for communication interfaces’ companion specification is

used to further fine-tune the use of the DLMS/COSEM application protocol. Direct communication

with the HES is applied via a public mobile telecommunication network. LTE (4G) is the selected

communication technology. However, in cases where LTE (4G) communication is not available,

fallback to GPRS shall be used.

IDC_meter: This is the communication interface between the E-meter and the Data Concentrator (DC).

The lower layers of the protocol stack are based on G3-PLC; the meters and the DCs shall be G3-PLC

certified. Again, on the application layer DLMS/COSEM is used with Annexure B2 - MOACH DLMS

COSEM profile for communication interfaces as the companion specification.

IHES_DC: This is the interface between the DC and the HES. The application protocol that is used

between the HES and the DC may not be based on DLMS/COSEM. In this case proprietary application

protocols can be used (e.g. web services). On the lower layers of the protocol stack, communication

with the HES is applied via a public mobile telecommunication network. LTE (4G) is the preferred

communication. In cases where 4G communication is not available, fallback to GPRS shall be used.

Icustomer_meter: Unidirectional communication interface for data exchange from meter and customer.

Requirements on Communication Interfaces

No: 2.2-1

Description: The AMI system components shall implement a defined set of communication

interfaces.

Component: AMI


Priority: REQUIRED

Fit criterion: The communication interfaces as indicated in Figure 2-1 shall be implemented:

IHES_meter: Communication interface for data exchange between HES and meter

directly.

IHES_DC: Communication interface for data exchange between HES and DC. IDC_meter: Communication interface for data exchange between DC and meter.

Ilocal_DC: Interface for local configuration and troubleshooting on DC. Ilocal_meter: Interface for local configuration and troubleshooting on E-meter. Ilocal_meter: Unidirectional communication interface for data exchange from meter and customer.

If any other communication interface is implemented on the field devices, it shall be disabled. Bidder shall inform contracting entity on any additional interface.



Evidence of

compliance:


2.2.1 Ilocal_meter

No: 2.2.1-1

Description: The communication protocol stack for Ilocal_meter shall comply to the specification of the 3-layer Connection Oriented DLMS communication profile.

Component: METER [1Ph, 3Ph, CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: Ilocal_meter shall implement the 3-Layer Connection Oriented DLMS Communication profile as specified in IEC 62056-7-6 and described in DLMS Green Book 10 section

10.2: The 3-layer, connection-oriented HDLC based communication profile.

Evidence of

compliance:


No: 2.2.1-2

Description: Application layer communication over the Ilocal_meter shall be implemented according

to the Annexure B2 - MOACH DLMS COSEM profile for communication interfaces companion specification.


Required Maturity: STANDARD OR TO BE DEVELOPED

Priority: REQUIRED

Fit criterion: DLMS Client/Server Associations, messages, data model and security shall be according to Annexure B2 - MOACH DLMS COSEM profile for communication interfaces companion specification. A DLMS Client that connects to the meter via the local interface, connects to the

same application layer as a DLMS Client that connects via the remote interface. Ilocal_meter shall be used by the local client to communicate with an Annexure B2 - MOACH DLMS COSEM Profile compliant meter.

All security requirements that apply for the remote interface apply also for the local

interface. No other protocols shall be implemented. The contracting entity shall commit to implement improvements and changes made in future versions of the companion specification during the implementation project. The companion specification is customized for IECo, and there will be most likely

corrections or improvements that pop up during the project implementation phase.



Evidence of

compliance:


No: 2.2.1-3

Description: The meter shall have a local optical interface and the physical properties of this interface shall be standardized.



Priority: REQUIRED

Fit criterion: The physical properties of this interface are compliant with the specifications in IEC 62056-21 section 4.3.

The optical interface and meter shall also function properly in a high ambient light environment of at least 80k lux.

Detachment strength of at least 5 Newton between probe and port, while the probe is touching the port.

Detachment strength of at least 1.5 Newton between probe and port, while the probe is 2mm away from the port.

The optical ports shall be interoperable with Reallin probes. Upon winning the tender the specifications of these probes will be supplied.

This port shall be located on the front panel of the meter, and be fully accessible.

The baud rate shall be 9600 bit/s

Evidence of

compliance:

Test report or documented evidence from bidder. (DLM/COSEM or IDIS certificate

shall include HLDC interface testing. )

No: 2.2.1-4

Description: Tools (software) for local configuration and troubleshooting via Ilocal_meter shall be delivered as part of the solution and should be integrated with IECo NADAV/Lab/HHU application.



Priority: REQUIRED

Fit criterion: 1. A tool (software) for local configuration and troubleshooting shall be available.

This tool supports at least the following functions: read out of registers and load

profiles, configuration of all configurable parameters, troubleshooting, firmware upgrade, breaker operation and clock configuration.

2. Requirements for NADAV application based PC/ tablet driver tool: Reading meters current billing data and billing profile (last 4 entries) and

general meter data

Meter parameters configuration (TOU, DST and etc.)

Synchronize meter's clock

Driver will be based on Windows OS version for which Microsoft provides

support.

The communication will be based on a RS232 optical adapter with

optional way to choose comport.



Support firmware upgrade

3. Requirements for PAAMON application based HHU driver: Reading meters current billing data and billing profile (last 4 entries) and

general meter data

Meter's parameters configuration (TOU, DST and etc.)

Synchronize meter's clock

Support firmware upgrade

Driver will be based for Android for business 10 operating system

The communication will be based on a RS232 optical adapter with

optional way to choose comport.

4. Events, Load Profile, Monthly Billing, Daily Billing, General Data – all should be able to be collected both using android & windows drivers.

5. As LP/Daily billing can consist of a lot of data – The driver should provide the ability to collect partial data.

Output file:

The file’s data general structure should be in DLMS COSEM OBIS standard.

All data will be in one structure, including the communication result field. Communication error codes: No error: 0.Error: Error code in OBIS-Error Code structure.

The interface structure for meter reading will be an API

Each OBIS field code will contain the field value as well.

Active energy import total register example:

< CaptureObject> < ClassId>3</ClassId>

< OBIS>0100010800FF</OBIS>

< Data>750298</Data>

< AttributeIndex>2</AttributeIndex>

< DataIndex>0</DataIndex>

/< CaptureObject>

The required data:

Date and time

Active energy import registers:

total, rate1, rate2, rate3, rate4, accumulating max peak demand,

monthly max peak demand, monthly max peak demand date and time.

Active energy export registers:



Reactive energy import registers:



Reactive energy export registers:



requirements are for 45 daily billings, 15 monthly readings, load profile,

events.

Technical data:

Meter serial number.

Meter code.

Current table name Holidays

Current table name TOU (TIME OF USE)

Meter clock

Meter version

Load profile status YES/NO



Data readings time limitation is 5 minutes for full reading and 8 minutes for full reading + load profile. Preferably an unlimited number of licenses shall be provided for the software tool, but at least 30.

Evidence of

compliance:


2.2.2 Ilocal_DC

No: 2.2.2-1

Description: The communication protocol stack of Ilocal_DC shall be well documented.

Component: DC


Priority: REQUIRED

Fit criterion: The contractor provides information the communication protocol stack used on Ilocal_DC.

Evidence of

compliance:


No: 2.2.2-2

Description: Tools (software) for local configuration and troubleshooting via Ilocal_DC shall be delivered as part of the solution.

Component: DC


Priority: REQUIRED

Fit criterion: A tool (software) for local configuration and troubleshooting shall be available. This tool supports at least the following functions: read out of meter related data, read

out of status information like event logs, configuration of all configurable parameters, troubleshooting. Additionally, this tool shall be able to configure the meters via DC during the DC testing stage when the an HES is not connected yet.

Software tool shall run on a Windows OS version for which Microsoft provides support.

Evidence of

compliance:


No: 2.2.2-3

Description: Contractor shall deliver as part of the solution a cable with suitable connector that is interoperable with the DC’s Ilocal_DC communication port.



Component: DC


Priority: REQUIRED

Fit criterion: Contractor shall deliver compatible cables. The number of cables will be aligned between contracting entity and contractor. If Ilocal_DC communication port is implemented as an ethernet port (RJ-45) on the DC side, the contractor is dismissed from the obligation to provide these cables.

Evidence of

compliance:


2.2.3 IDC_meter

No: 2.2.3-1

Description: The communication protocol stack of the IDC_meter shall be based on open standards and use DLMS/COSEM on top of G3-PLC communication.

Component: DC, METER [1Ph, 3Ph, CT, PLC]


Priority: REQUIRED

Fit criterion: The communication stack is based on DLMS/COSEM in the application layer.

The DLMS communication profile as specified in IEC 62056-8-4:

The DLMS communication profile as specified in IEC 62056-8-5: Narrow Band OFDM G3-PLC communication profile for neighbourhood networks shall be implemented for G3-PLC meters.

Evidence of

compliance:


No: 2.2.3-2

Description: Application layer communication over the IDC_meter shall be according to the Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification.



Priority: REQUIRED

Fit criterion: Associations, messages, data model and security shall comply with the Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification.

IDC_meter shall be used by the DC to communicate with an Annexure B2 - MOACH DLMS COSEM Profile compliant meter that implements the Annexure B2 - MOACH DLMS COSEM profile.



No other protocols shall be implemented.

The contracting entity shall commit to implement improvements and changes made in future versions of the companion specification during the implementation project. The companion specification is customized for MOACH, and there will be most likely corrections or improvements that pop up during the project implementation phase.

Evidence of

compliance:


No: 2.2.3-3

Description: AMI components that implement the IDC_meter interface shall be able to operate both in the CENELEC A and FCC bands.



Priority: REQUIRED

Fit criterion: The AMI system components that implement the IDC-meter interface can be configured to use either the CENELEC A or FCC bands for G3-PLC devices.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: G3-PLC certificate.

No: 2.2.3-4

Description: AMI components that implement the IDC_meter shall be certified products.



Priority: REQUIRED

Fit criterion: AMI components that implement the IDC_meter shall be certified G3-PLC products.

It is not sufficient to use certified platforms; the complete product shall be certified.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: G3-PLC certificate that shows that the product is certified.

2.2.4 IHES_meter

No: 2.2.4-1

Description: The communication protocol stack for IHES_meter shall comply to the specification of the ‘DLMS/COSEM over IP networks communication profile.’

Component: HES, METER [1Ph, 3Ph, CT, PLMN]


Priority: REQUIRED



Fit criterion: The communication protocol stack for IHES_meter shall comply to the specification of

the DLMS/COSEM over IP networks communication profile, as specified in IEC 62056-9-7: Communication profile for TCP-UDP/IP networks and described in DLMS Green Book 10, section 10.3

Evidence of

compliance:


No: 2.2.4-2

Description: Application layer communication over the IHES_meter shall be implemented according to the Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces

companion specification.

Component: METER [1Ph, 3Ph, CT, PLMN]


Priority: REQUIRED

Fit criterion: DLMS Client/Server Associations, messages, data model and security shall be

according to Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification. IHES_meter shall be used by the HES to communicate with an Annexure B2 - MOACH DLMS COSEM Profile compliant meter that implements the Annexure B2 - MOACH DLMS COSEM ‘Mobile Network’ profile.

Evidence of

compliance:


No: 2.2.4-3

Description: The communication unit in the E-meter shall support LTE (4G) communication technology.



Priority: REQUIRED

Fit criterion: The communication unit supports LTE (4G). Fall-back to GPRS technology in case of unavailability of 4G shall be supported.

Evidence of

compliance:


No: 2.2.4-4

Description: The communication unit of the E-meter shall by default be equipped with an internal antenna.





Priority: REQUIRED

Fit criterion: The device has an antenna for the supported mobile communication technologies. The antenna is located within the housing of the E-meter.

The modem/antenna should be certified for use in the Israeli market.

Evidence of

compliance:


No: 2.2.4-5

Description: The communication unit of the E-meter shall have the option to connect an external antenna. The external antennas are delivered as part of the solution.



Priority: REQUIRED

Fit criterion: The E-meter shall have an option to connect an external antenna. The external antennas are delivered as part of the solution. The external antenna connector

should be a female SMA connector. The length of the cable of the antenna and the number of external antennas will be agreed upon between contractor and contracting entity.

Evidence of

compliance:


2.2.5 IHES_DC

No: 2.2.5-1

Description: The communication protocol stack of IHES_DC shall be based on standardized technologies and well documented.

Component: HES, DC


Priority: REQUIRED

Fit criterion: The IHES-DC shall be based on open, international standards. The contractor provides documentation about the standards and technologies used on this system interface (Webservices, XML, SOAP). The communication shall be TCP-IP based.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder describes how this interface is implemented. The bidder describes the communication protocol stack that is used on this interface.

No: 2.2.5-2

Description: The communication unit in the DC shall support ETHERNET.

Component: DC




Priority: REQUIRED

Fit criterion: The communication unit shall implements ETHERNET (RJ45) for connectivity with an external firewall (provided by IECo) that will be installed in close proximity of the DC.

Note: the communication with the central systems shall be provided via this external firewall, i.e. this firewall will be provided with 4G-LTE communication technology.

Evidence of

compliance:


2.2.6 Icustomer_meter

No: 2.2.6-1

Description: The meter shall have a local consumer information interface. The physical properties

of this interface shall be according to the DSMR v5.0.2 P1 Companion Standard. This document can be found here: https://www.netbeheernederland.nl/_upload/Files/Slimme_meter_15_a727fce1f1.pdf

Component: METER [1Ph, 3Ph, PLMN, PLC]

Required

Maturity:

STANDARD OR TO BE DEVELOPED

Priority: REQUIRED

Fit criterion: The physical properties of this interface are compliant with the specifications in DSMR v5.0.2 P1 Companion Standard

Evidence of

compliance:


No: 2.2.6-2

Description: Application layer communication over the Icustomer_meter shall be according to the Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification.



Priority: REQUIRED

Fit criterion: Messages and data model shall comply with the Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification. Icustomer_meter shall be used for unidirectional data exchange from meter to customer with an MOACH DLMS COSEM Profile compliant meter that implements the Annexure B2 - MOACH DLMS COSEM profile.

No other protocols shall be implemented. The contracting entity shall commit to implement improvements and changes made in future versions of the companion specification during the implementation project.



The companion specification is customized for IECo, and there will be most likely

corrections or improvements that pop up during the project implementation phase.

Evidence of

compliance:

Test report or documented evidence from bidder. Compliance with this specification is verified by evaluation of a sample.

2.2.7 Communication unit for mobile communication

The following requirements apply for the communication unit for mobile communication in both E-meters

and DC’s.

No: 2.2.7-1

Description: The communication unit of the device shall support cellular mobile communication

frequencies used by the Israel telecommunication providers.

Component: DC, METER [1Ph, 3Ph, CT, PLMN]


Priority: REQUIRED

Fit criterion: The communication unit shall support the frequency bands used in Israel. See Figure

2-2. The communication unit shall support Data Roaming between MNOs.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a GCF certification of the modem by a GCF Recognised Test Organisation (RTO).

Figure 2-2: Overview frequency bands in Israel

No: 2.2.7-2

Description: The communication unit of the device shall be an exchangeable module.



Priority: PREFERRED

Fit criterion: The communication unit shall support exchangeability.

Evidence of

compliance:


No: 2.2.7-3

Band B8 B3 B8 B1 B1 B3 B8 B20 B28 B3 B28

Frequency 900 1800 900 2100 2100 1800 900 800 700 1800 700

UL (MHz) 880-915 1710-1785 880-915 1920-1980 1920-1980 1710-1785 880-915 832-862 703-748 1710-1785 703-748

DL (MHz) 925-960 1805-1880 925-960 2110-2170 2110-2170 1805-1880 925-960 791-821 758-803 1805-1880 758-803

2G 3G 4G-LTE 4G-NB



Description: The Contractor shall be responsible for transportation of SIM cards to the cellular

meter manufacturer.



Priority: REQUIRED

Fit criterion: For each draw order for cellular meters, and before manufacture of the meters, the Contractor shall be responsible to collect SIM cards from IECo and transport them to the cellular meter manufacturer. The cellular meters manufacturer shall insert the SIM cards received, into the communication modules during the meters manufacturing process, so that the meters will be delivered with the SIM cards already installed.

Evidence of

compliance:

Commitment from bidder.

No: 2.2.7-4

Description: The communication unit of the device shall be compatible with eSIM/eUICC.



Priority: PREFERRED (without scoring)

Fit criterion: The contracting entity shall be able to switch from one telecom provider to another. This feature is possible if eSIMs/eUICC are deployed. The communication unit shall

be compatible with eSIMs/eUICC. If eSIM is offered, IECo can supply the relevant information.

Evidence of

compliance:


No: 2.2.7-5

Description: The communication unit of the device shall be configurable.



Priority: REQUIRED

Fit criterion: There shall be a GUI to configure the modem of the device. The GUI can be part of the meter software.

Evidence of

compliance:


No: 2.2.7-6

Description: Communication technology usage.





Priority: REQUIRED

Fit criterion: The bidder should bring at least 20% of the required meters with cellular communication technology. The remaining 80% of meters can use either cellular or G3-PLC technology, as long as the bidder can comply to the required KPIs.

Evidence of

compliance:


2.2.8 Requirements regarding PLC network quality

No: 2.2.8-1

Description: Tools for evaluating the quality of the PLC network

Component: PLC network


Priority: REQUIRED

Fit criterion: The bidder shall be able to provide tools to analyse and evaluate, in the field, the quality of the PLC network (e.g. determine noise level and sources of noise)

Evidence of

compliance:

Documented evidence of the bidder describing the tools that he will offer.

No: 2.2.8-2

Description: Availability of PLC filters

Component: PLC Filter


Priority: REQUIRED

Fit criterion: The bidder shall be able to deliver PLC filters to improve the data communication

quality in the PLC network. The details regarding the PLC-filters can be found in Appendix A (in this document).

Evidence of

compliance:

Documented evidence from the bidder describing the PLC filters he will offer.

AMI Business Processes

The AMI system shall support the business processes of IECo.

Notice that the business processes not only encompasses AMI system requirements but also E2E

services to/from SAP IS-U or SAP PM. The requirements mentioned in this section focus on the AMI

system part, while the integration requirements are stated in chapter 10.



The AMI system shall support the following business processes (BPs):

No: 2.3-1

Description: The AMI system shall support ‘BP1: Commissioning of the meter’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of integrating installed meter devices into the

system.

This process can be decomposed in the following steps:

1. Physical installation in the LV grid.

2. Connection to the communication network. To HES directly or via

DC/gateway (depending on the adopted communication technology).

3. Registration of meters

‘BP1: Commissioning of the meter’ implementation encompasses the support of the

following Use Cases (UCs):

UC1: Meter registration (refer to requirement 2.4-1)

UC3: Provide Meter reading (refer to requirement 2.4-4)

This business process shall be implemented in conjunction with ‘BP16: Manage

meter configurations’ (refer to requirement 2.3-16).

Details on ‘BP1: Commissioning of the meter’ are aligned between Contracting entity

and Contractor.

The selection of communication technology will depend on an up-front

communication survey done by IECo.

Evidence of

compliance:


The bidder shall describe how this business process is implemented, including a

work flow which describes it in detail.

No: 2.3-2

Description: The AMI system shall support ‘BP2: Update meter master data’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of updating meter master data, which refers

to the default configuration of the meter when it is installed for the first time. This



information is stored in the MDMS and integrated with SAP, GIS and WFM (see

chapter 10).

‘BP2: Update meter master data’ implementation encompasses the support of the


UC1: Meter registration (refer to requirement 2.4-1)

UC9: Power quality reporting (refer to requirements 2.4-10 and 2.4-11)

Details on ‘BP2: Update meter master data’ are aligned between Contracting entity

and Contractor.

Evidence of

compliance:




No: 2.3-3

Description: The AMI system shall support ‘BP3: Remove meter’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of removing a meter from the field. Before the

meter is removed, the last billing data has to be collected and all events/logs have

to be read (even locally/manually if, for commissioning or maintenance reasons, the

meter does not allow the remote option). For PLC-based meters, the MDMS/HES

executes the corresponding actions to remove the meter from the DC database

permanently after making sure that: all required meter data has been collected

completely and consistently. For LTE-based meters, ceasing of provision from

communication systems (cellular network core) takes place.

This business process shall be implemented in conjunction with ‘BP8: Metering data

validation’ (refer to requirement 2.3-8).

‘BP3: Remove meter’ implementation encompasses the support of the following Use

Cases (UCs):

UC2: Provide billing data (refer to requirements 2.4-2 and 2.4-3)

UC3: Provide meter reading (refer to requirement 2.4-4)

UC7: Meter supervision (refer to requirement 2.4-8 and system integrations

with SAP)

Details on ‘BP3: Remove meter’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:






No: 2.3-4

Description: The AMI system shall support ‘BP4: Switching supplier’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of switching consumer from Energy Supplier.

If the consumer switches from supplier, the actual billing data has to be collected so

that the old supplier can make up the final bill. The new supplier has to get the

actual meter reads. This business process shall be implemented in conjunction with

‘BP8: Metering data validation’ (refer to requirement 2.3-8).

‘BP4: Switching supplier’ implementation encompasses the support of the following

Use Cases (UCs):



Details on ‘BP4: Switching supplier’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:




No: 2.3-5

Description: The AMI system shall support ‘BP5: Switching customer’.

Component: AMI


Priority: REQUIRED

Fit criterion: Consumers who move to house need a bill based on the last consumption. The

meter can disconnect the premises from the grid until the new consumer moves in.

This process is supported by the AMI system.

‘BP5: Switching customer’ implementation encompasses the support of the following

Use Cases (UCs):





UC6: Disconnect/Reconnect (optional) (refer to requirement 2.4-7)

Details on ‘BP5: Switching customer’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:




No: 2.3-6

Description: The AMI system shall support ‘BP6: Initiate, execute and close field activities’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of maintenance of the LV network, including

AMI components maintenance (e.g. meter, DC, etc.). The events related to

operation of the breaker can be collected afterwards.

‘BP6: Initiate, execute and close field activities’ implementation encompasses the

support of the following Use Cases (UCs):

UC6: Disconnect/Reconnect (refer to requirement 2.4-7)

UC7: Meter supervision (refer to requirement 2.4-8)


Details on ‘BP6: Initiate, execute and close field activities’ are aligned between

Contracting entity and Contractor.

Evidence of

compliance:




No: 2.3-7

Description: The AMI system shall support ‘BP7: Metering data acquisition’.

Component: AMI


Priority: REQUIRED



Fit criterion: Meter readings (consumption registers) can be collected for other reasons than for

billing purposes, e.g. on customer request. Meter reads can be collected on demand

or scheduled (in MDMS, HES, DC, or in meter). This process is supported by the AMI

system.

‘BP7: Metering data acquisition’ implementation encompasses the support of the



Details on ‘BP7: Metering data acquisition’ are aligned between Contracting entity

and Contractor.

Evidence of

compliance:




No: 2.3-8

Description: The AMI system shall support ‘BP8: Metering data validation’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall support the process of validating metering data. Validation is

implemented in the MDMS, based on the profile status bits as set in the meter

(invalid entries, clock adjusted, incorrect meter configuration, mismatch between

load profile,register data, exceed maximal contracted consumption, etc.). It

comprises also the management of gaps of information in terms of meter data

collection (remotely or locally). Management includes detecting, trying to fetch the

data from the field device, and estimating.

This is a business process to be applied as regular basis, which includes the

implementation of VEE method(s).

Below, common triggering conditions considered by IECo to enable VEE process are

listed:

When at MDMS level it is diagnoses that there is no possibility to get the

data from the meter (e.g. in case of absence of information in the meter or

meter removal).

When there is a request from the billing system to get the meter reading,

and AMI fails to collect it from the meter.

When it is the time to reporting meter data for meters that are subjected to

an agreement to provide meter data at the end of the month+7days.

If real data comes available after the estimate, the real data should

overwrite the estimate.



‘BP8: Metering data validation’ implementation encompasses the support of the




Details on ‘BP8: Metering data validation’ are aligned between Contracting entity

and Contractor.

Evidence of

compliance:



work flow which describes it in detail. It will include a description of the triggering

conditions implemented to enable VEE process, and a detailed description of the VEE

method itself.

No: 2.3-9

Description: The AMI system shall support ‘BP9: Managing distributed generation’.

Component: AMI


Priority: REQUIRED

Fit criterion: In order to get insight in production / consumption, meter readings for energy

import / export are done. Load management operations are also included within the

scope of managing distributed generation. This process is supported by the AMI

system.

‘BP9: Managing distributed generation’ implementation encompasses the support of

the following Use Cases (UCs):


Details on ‘BP9: Managing distributed generation’ are aligned between Contracting

entity and Contractor.

Evidence of

compliance:




No: 2.3-10

Description: The AMI system shall support ‘BP10: EV and smart charging integration’.

Component: AMI




Priority: REQUIRED

Fit criterion: In order to get insight in consumption, meter readings for energy import are done.

Load management operations are also included within the scope of EV and smart

charging integration. This process is supported by the AMI system.

‘BP10: EV and smart charging integration’ implementation encompasses the support

of the following Use Cases (UCs):


Details on ‘BP10: EV and smart charging integration’ are aligned between

Contracting entity and Contractor.

The bidder must explain how his AMI solution supports DER and EV integration.

Evidence of

compliance:




No: 2.3-11

Description: The AMI system shall support ‘BP11: Meter to bill’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of collecting data that is used to establish the

invoices for the customers. At the end of a billing period, the AMI system provides

the consumption data for the different tariffs. For valid billing data, the consumption

data must be correctly time-stamped.

For external suppliers who are IECo customers, they are billed according to load

profile data. This data is collected from the DWH daily. This is also considered part

of the scope of this business process.

NOTE: Nowadays, IECo uses customer billing periods spread all over the month.

Most of the household customers are billed once per two months.

‘BP11: Meter to bill’ implementation encompasses the support of the following Use

Cases (UCs):


UC4: Apply Tariffs (refer to requirement 2.4-5)

UC5: Clock Synchronisation (refer to requirement 2.4-6)

Details on ‘BP11: Meter to bill’ are aligned between Contracting entity and

Contractor.



Evidence of

compliance:




No: 2.3-12

Description: The AMI system shall support ‘BP12: Handling notification & events / Fraud

Detection’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of supervising any events which could

compromise the meter and the system. The AMI system shall detect attempts of

fraud (based on energy consumption trends for individual consumers, meter events,

and other relevant information) and generate alarms for specific events on the

meter.

‘BP12: Handling notification & events / Fraud Detection’ implementation

encompasses the support of the following Use Cases (UCs):



Details on ‘BP12: Handling notification & events / Fraud Detection’ are aligned

between Contracting entity and Contractor.

Evidence of

compliance:




No: 2.3-13

Description: The AMI system shall support ‘BP13: Transformer metering / load (Energy)

Balancing’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the implementation of methods/algorithms using smart

meter data to determine loading frequently enough with the aim of monitoring and



alert of imbalance, to determine a plan to correct the load balance, and to advise

system planners and engineers. It can be also used as input for fraud detection.

‘BP13: Transformer metering / load (Energy) Balancing’ implementation



Details on ‘BP13: Transformer metering / load (Energy) Balancing’ are aligned


Evidence of

compliance:




No: 2.3-14

Description: The AMI system shall support ‘BP14: Load Management’.

Component: AMI


Priority: REQUIRED

Fit criterion: Load management can be done for network balancing purposes or to prevent that

consumers connect load above their contracted power. Thresholds can be

programmed in the meter and if thresholds exceed, the breaker opens.

‘BP14: Load Management’ implementation encompasses the support of the following

Use Cases (UCs):

UC8: Power limitation (refer to requirement 2.4-9)

Details on ‘BP14: Load Management’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:




No: 2.3-15

Description: The AMI system shall support ‘BP15: Load Profiling’.

Component: AMI


Priority: REQUIRED



Fit criterion: The AMI system supports processing of historical consumption data to be used to

predict future consumption of groups of consumers. This includes load profile (LP)

estimation and validation, managed by the MDMS.

‘BP15: Load Profiling’ implementation encompasses the support of the following Use

Cases (UCs):


Details on ‘BP15: Load Profiling’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:




No: 2.3-16

Description: The AMI system shall support ‘BP16: Manage meter configurations’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of managing configurations (e.g. tariff tables,

thresholds, etc.) in the meters remotely without need of accessing locally the meter.

This will be managed from the MDMS/HES.

‘BP16: Manage meter configurations’ implementation encompasses the support of


UC4: Apply Tariffs (e.g. renew tariff table) (refer to requirement 2.4-5)

UC5: Clock synchronisation (e.g. update meter time) (refer to requirement

2.4-6)

UC8: Power limitation (e.g. set thresholds) (refer to requirement 2.4-9)


UC14: Measurement method (vector/arithmetic method) (refer to

requirement 2.4-16)

UC15: Meter display configuration (refer to requirement 2.4-17)

UC16: Event Configuration (refer to requirement 2.4-18)

AMI system shall implement the capability to fix configuration of ‘not-aligned’

meters (with wrong configuration, not consistent, etc.). The AMI system shall

implement the capability for mass meter configuration updates, for example in case

that a new TOU configuration is introduced to the energy market.



AMI will include a tool to prepare configuration files for the meters such as TOU,

Special days, DST and display.

Details on ‘BP16: Manage meter configurations’ are aligned between Contracting


Evidence of

compliance:




No: 2.3-17

Description: The AMI system shall support ‘BP17: Provide customer feedback regarding

consumption’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of providing readings directly to the customer

and any third party designated by the consumer with the aim of running demand

response services, taking ‘online’ energy-saving decisions and effective integration

of distributed energy resources.

Refer to section 2.2.6 Icustomer-meter for more detail about local consumer information

interface.

‘BP17: Provide customer feedback regarding consumption’ implementation



UC11: Provide Consumer information (refer to requirement 2.4-13)

Details on ‘BP17: Provide customer feedback regarding consumption’ are aligned


Evidence of

compliance:




No: 2.3-18

Description: The AMI system shall support ‘BP18: Operational reporting & Communication

Network Fault Management’.

Component: AMI




Priority: REQUIRED

Fit criterion: The AMI system shall support the process of identifying, avoiding and solve

communication problems in the network that can hamper the performance of the

AMI system. This is linked with reporting on events from the field and

communication performance between AMI system components.

Fault management analysis is performed by the MDMS. Field activities will only be

initiated in case that the issue cannot be managed remotely. If an issue can be

managed remotely, the system set a specific alarm to indicate the required action to

solve the issue remotely.

In case field activity is required, aggregation should be made to

structure/segment/DC level.

‘BP18: Operational reporting & Communication Network Fault Management’

implementation encompasses the support of the following Use Cases (UCs):



UC12: Communication supervision & System wide fault overview (refer to

requirement 2.4-14)

Details on ‘BP18: Operational reporting & Communication Network Fault

Management’ are aligned between Contracting entity and Contractor.

Evidence of

compliance:




No: 2.3-19

Description: The AMI system shall support ‘BP19: Power Quality Monitoring’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall support the process of recording and publishing of power

quality parameters like voltage sags and swells (and their durations), and related

events. In addition, the AMI system shall support the configuration of those quality

parameters.

This process is managed from the MDMS.

‘BP19: Power Quality Monitoring’ implementation encompasses the support of the





Details on ‘BP19: Power Quality Monitoring’ are aligned between Contracting entity

and Contractor.

Evidence of

compliance:




No: 2.3-20

Description: The AMI system shall support ‘BP20: Outage management’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall support the process of being alerted about outages and act on

it, by analysing outage information. This means that AMI provides data on duration

of outages and can alert management system if an outage occurs.

This process is managed from the MDMS. Information related to LV network outages

will be forwarded to an external system (ADMS).

‘BP20: Outage management’ implementation encompasses the support of the




Details on ‘BP20: Outage management’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:




No: 2.3-21

Description: The AMI system shall support ‘BP21: Remote Firmware Upgrade’.

Component: AMI


Priority: REQUIRED



Fit criterion: The AMI system supports the process of upgrading new firmware in an AMI device,

like smart meters and data concentrators.

Firmware upgrade process is managed from MDMS, which will use the HES for

upgrading remotely the firmware of DC and meters connected to it.

Massive meter firmware upgrade shall be supported.

‘BP21: Remote Firmware Upgrade’ implementation encompasses the support of the


UC3: Provide meter reading (refer to requirement 2.4-4). This is considered

optional, to perform before smart meter firmware upgrade.

UC10: Firmware upgrade (refer to requirement 2.4-12)

Details on ‘BP21: Remote Firmware Upgrade’ are aligned between Contracting entity

and Contractor. The AMI system shall implement the capability to fix firmware of

‘not-aligned’ meters.

Evidence of

compliance:




No: 2.3-22

Description: The AMI system shall support ‘BP22: Prepayment’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports prepayment schemes implemented in the IT system.

‘BP22: Prepayment’ implementation encompasses the support of the following Use

Cases (UCs):

UC6: Disconnect/Reconnect (refer to requirement 2.4-7)

UC13: Prepayment (refer o requirement 2.4-15)

Details on ‘BP22: Prepayment’ are aligned between Contracting entity and

Contractor.

Evidence of

compliance:




No: 2.3-23



Description: The AMI system shall support ‘BP23: Business Intelligence processes’.

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports the process of collection, integration, analysis and

prestation of business information to support better business decision making.

‘BP23: Business Intelligence processes’ implementation encompasses the support of






UC11: Provide Consumer information (refer to requirement 2.4-13)

UC12: Communication supervision & System wide fault overview (refer to

requirement 2.4-14)

Details on ‘BP23: Business Intelligence processes’ are aligned between Contracting


Evidence of

compliance:






2.3.1 Roadmap for business processes implementation

Together with the list of business processes described in the previous section, a roadmap for guiding

their implementation has also been defined. The objective is to establish certain basis for the

prioritization on the integration of the different business processes and the consequent smart metering

functionality applicable to the new AMI system to be deployed by IECo in the incoming years. This

section refers to the list of main AMI processes to be implemented; please be aware that chapter 10 also

provides business processes and E2E integration beyond the HES/MDMS, which must be seen in addition

to the processes and use cases described here.

The defined roadmap considers two main periods of implementation of business processes:

1ST PERIOD (MOACH PROJECT) 2024 – 2026

2ND PERIOD (GOING FURTHER, EXPLOITING POTENTIAL AMI CAPABILITIES) 2026 - 2029

Commonly, in the investment plans for AMI, a technology life of 15-20 years is expected. In a 3-year

time perspective, which is the planning established for the MOACH project, the new AMI system itself will

be already installed. This means that the deployment finalization is scheduled by the end of 2026.

The first period of business processes implementation encompasses the MOACH project duration and

should focus on warranting the continuity without interruption of the basic metering operations and

ensuring also the communication with the customer/consumer. This means that basic functionality, for

example related to billing processes, needs to be enabled with high priority to avoid any interruption in

the basic services to be provided to the customer. In addition, this period will be the time to provide AMI

system certain degree of maturity, by including and validating certain advanced smart metering

functionalities. It will allow IECo to learn and get confidence on the newly deployed AMI system and

being prepared to approach the implementation of more complex business processes.

Based on this criteria, the following business processes have been included in this period of

implementation:

BP1: Commissioning of the meter

BP2: Update meter master data

BP3: Remove meter

BP4: Switching supplier

BP5: Switching customer

BP6: Initiate, execute and close field activities

BP7: Metering data acquisition

BP8: Metering data validation

BP11: Meter to bill

BP12: Handling notification & events / Fraud Detection

BP16: Manage meter configurations

BP17: Provide customer feedback regarding consumption

BP18: Operational reporting & Communication Network Fault Management

BP20: Outage management



BP21: Remote Firmware Upgrade

BP22: Prepayment

After the AMI deployment finalization by the end of 2026, the subsequent implementation of business

processes by IECo will focus on exploiting potential capabilities of the AMI system. From then on, the

integration of new functionalities is expected to be mainly related to opportunities/limitations related to

the upgrade of internal systems in the meter and adjacent systems such as software systems, operating

systems, and communication systems of IECo.

Therefore, at the second period, the main drivers will be the resources and strategy of IECo to develop

their own advanced functionalities and their ambition to obtain the most useful information from the

smart meters and the AMI system itself for operation, planning and maintenance purposes. In this

sense, the following business processes have been selected for being implemented in this period:

BP9: Managing distributed generation

BP10: EV and smart charging integration

BP13: Transformer metering / load (Energy) Balancing

BP14: Load Management

BP15: Load Profiling

BP19: Power Quality Monitoring

BP23: Business Intelligence processes

Below illustrated in Figure 2-3 are the two periods defined for the business processes implementation.

Business processes appear differentiated by colours, to identify the existing maturity degree of

implementation considering the current MENIV AMI system: in green are the business processes fully

implemented, in yellow those that are partially and in blue those that are not implemented at all.

In this sense, it is important to point out that those business processes that already exist in the MENIV

AMI system will be maintained and shall be improved by the bidder to support new challenges that will

come up during this project.

Figure 2-3: Roadmap for business processes implementation as part of the new IECo’s AMI system

Some relevant aspects when planning the implementation of business processes in each period need to

be considered. As part of the implementation roadmap a decision must be made on the implementation

principles with regards to a sequence of activities. The integration between the different business

processes, and within the respective business processes in a period, will go in series or parallel

depending on available resources, preparation of logistics and project management capabilities and

capacity.

Figure 2-4: Serial and parallel implementation of BPs

Below illustrated in Figure 2-5 are the business processes implementation principles. All business process

implementations have to follow a defined process, in which all personnel involved is trained. The

implementation process will be subject to continuous improvement as part of a Quality Management Plan

and should be a subject in joint IECo and solution provider project meetings. Existing BPs should be

operational all the time, excluding short periods of time caused by operational reasons.

Figure 2-5: Business processes implementation principles

This implementation per busines process can be divided into two main stages:

BP implementation planning

BP implementation

The stage of “BP implementation planning” comprises activities focused on the evaluation of the existing

business process implementation (maturity degree, integration efforts, etc.), the prioritization with

regards to other BPs in the same period (common use cases and smart metering functionalities), and the

communication to all personnel involved to make the preparations required. The main goal of this stage

is to ensure that everything is ready before starting the business process implementation.

The second stage, “BP implementation”, encompasses the following list of activities:

1. Coordination phase. Ensure that all personnel who is required to be involved in the business

process implementation is informed and prepared.

2. BP implementation. Execution task.

3. Implementation control. Control of the business process implementation from different

perspectives: operational, resourcing, quality, etc.

4. Validation phase: Intermediate phase for validating partial business process implementation

before going for the full implementation.

5. Stabilization phase. Final approval period, monitoring the performance of the implemented

business process as part of the new AMI System.

6. Closing phase. BP implementation process with the solution provider is concluded.

All the above-mentioned activities will be made in joint by IECo and the solution provider. Business

processes and new functions are expected to be delivered in an agile way-of-working, which is further

described in chapter 11.

Notice that for every business process, as indicated in the requirements 2.3-1 to 2.3-23, the bidder shall

describe how the business process is implemented, including a work flow which describes it in detail.

Business processes need to be designed to handle both ‘happy’ flows and ‘non-happy’ flows.

So when a business process fails, the step at the failure happens shall be easily tracked, facillitating the

failure identification by the user. To that aim, business process failures shall be tracked by implementing

a specific self-discovery mechanism that helps to understand the reason of failure. For analysis

purposes, the user will be able to create a report that shows statistical data regarding: the business

process, total number of executions, number of successful executions, number of failures from each

error type, etc.

AMI System Use Cases

The AMI system shall implement the following system Use Cases (UCs):

No: 2.4-1

Description: The AMI system shall support meter registration in the MDMS after a meter is installed in the field (‘UC1: Meter registration’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system supports seamless installation of smart meters. After installation, a

message from the meter is sent (e.g. triggered by connection to telecommunication network) to indicate that the meter is installed successfully. For LTE-based meters

this message is directly send to the MDMS/HES while for PLC-based meters this message is send to the DC and the DC will forward this to the MDMS/HES. The message contains all data needed in the system to identify the meter in the MDMS. Details are aligned between Contracting entity and Contractor, so that the meter registration supports the Contracting entities provisioning process.

Linking the metering point ID to the meter ID is not part of this system use case.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder shall describe how this system use case is implemented and what (if any) on site actions are needed on the meter to trigger the registration as ‘active’ meter in the MDMS.

No: 2.4-2

Description: The AMI system shall provide energy consumption data for billing purposes (‘UC2: Provide billing data’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system provides cumulative meter readings to the MDMS to support the ‘meter to bill process’. Consumption data is time stamped and comes with applicable status information. At least data (load profile and consumption data) for billing shall be available. Monthly billing data shall be stored in the E-meter for the last 15 months.

In addition to periodic meter readings for billing, providing data to settle the bill in the following cases shall also be supported:

customer move-in/move-out change of energy supplier meter replacement

Details are aligned between Contracting entity and Contractor, so that the use case supports the Contracting entity’s part of the ‘meter to bill’ process.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder shall describe how this system use case is implemented.

No: 2.4-3

Description: The AMI system shall provide energy consumption data for billing purposes (‘UC2: Provide billing data’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall provide historical and actual cumulative meter readings. Values shall be recorded in a buffer in the billing profile. Captured values shall be

configurable.

Historical measurement data shall be stored in the E-meter and MDM. The E-meter shall implement at least 3 profiles: monthly billing, daily billing, and load profile. The load profile shall store measurement data for the last 60 days. Daily billing data shall be stored in the E-meter for the last 15 days. Monthly billing data shall be stored in the E-meter for the last 15 months.

The capture interval time of the historical load profiles is configurable. The set of captured data in the profiles is also configurable. The End-2-End AMI system shall be designed to at least support daily meter reads of 15-minute values.

In special cases, (e.g. prepayment), the meter readings are done more frequent. Details on ‘provide billing data’ are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-4

Description: The AMI system shall allow on demand and scheduled meter readings (‘UC3: Provide

Meter reading’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall allow remote reading of meters by MDMS/HES/DC (on demand

and scheduled) and also local/manual reading by someone authorized to this aim.

The meter reading periodicity should be configurable by the MDMS/HES.

The use of virtual channels and virtual meters can support the remote meter reading

(e.g.: transformer energy balancing or suppliers’ aggregation).

Details on ‘meter readings’ are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-5

Description: The AMI system shall implement a Time of Use tariff system (‘UC4: Apply Tariffs’).

Component: AMI


Priority: REQUIRED

Fit criterion: The E-meter holds a Time of Use (ToU) tariff table and counts energy in separate

registers for each tariff.

Via the MDMS/HES, the ToU tariff table can be updated and activated. Activation can

be done immediately or scheduled.

The actual tariff code is available in the MDM via the HES.

At least 4 tariffs shall be supported.

The AMI will support the use of two different ToU tables. One of the ToU tables can

be assigned to any specific meter.

Details on the ToU tariff system are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-6

Description: The AMI system shall keep clocks of all system components synchronised with a reliable external clock (‘UC5: Clock Synchronisation’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall implement a clock synchronisation scheme that guarantees accurate time stamping of energy measurement data and supervision data (e.g.

system events).

The clock in AMI components shall not deviate more than 7 seconds. Details on clock synchronisation are aligned between Contracting entity and Contractor.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder shall describe how this system use case is implemented (e.g. via NTP server)

No: 2.4-7

Description: The AMI system shall allow remote disconnection and reconnection of energy supply via the E-meter (‘UC6: Disconnect/Reconnect’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall allow remote disconnection and reconnection of energy supply

via a breaker integrated in the E-meter. Operating the breaker is triggered via the HES and initiated by SAP or by MDMS. Operation of the breaker can be scheduled by a scheduler programmed in the E-

meter. For safety reasons, the energy supply shall be restored by manual intervention

(push button on the E-meter or by manual switching of the customer main switch) of the consumer. See figure 19 BB14. Details on disconnection and reconnection are aligned between Contracting entity and Contractor. All 6 operation modes according to DLMS blue book.

Evidence of

compliance:


No: 2.4-8

Description: The AMI system shall provide supervision data of field devices (‘UC7: Meter

supervision’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system provides supervision data such as:

fraud detection events (e.g. magnetic field detection, phase/neutral loss

detection).

event loggings of parameter change, state change of breaker in E-meter,

firmware updates, etc. so that operations on the meter are logged.

Events are stored together with a time stamp in the field devices. Full event list to

be found in IECo COSEM MOACH v1.0.

The system allows that certain events are configured to be set spontaneously to the

systems and other to be configured as alarms, that result too in active notification of

the MDMS/HES. Event analysis is done in the MDMS. The event mapping shall be

according to the IECo COSEM MOACH v1.0 data model so events from all devices

(even from different manufacturers) can be processed in a standardized way.

Details on supervision of field devices are aligned between Contracting entity and

Contractor.

Evidence of

compliance:


No: 2.4-9

Description: The AMI system shall support load limitation via the E-meters (‘UC8: Power

limitation’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system shall support limitation of load via the E-meters. The MDM via the HES allows programming of the load thresholds in the E-meters (Import Active Power Threshold and Export Active Power Threshold). Exceeding the threshold results in interruption of the energy supply via the breaker

in the E-meter. Details on load limitation are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-10

Description: The AMI system shall provide quality of supply data (‘UC9: Power quality reporting’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system provides quality of supply data. This data is measured by the E-

meters and published by the HES.

The following quality of supply data shall at least be available:

Recording and publishing of power quality parameters like voltage sags and

swells, and their durations.

Recording and publishing of outages and their duration.

Power quality events can be configured to raise alarms, so that HES is notified

instantly.

Details on quality of supply reporting are aligned between Contracting entity and Contractor.

Voltage level of the sag and/or swell and its duration will be configurable, by default it will be considered when +/- 5% V and above 30 sec.

Evidence of

compliance:


No: 2.4-11

Description: The AMI system shall provide a Last Gasp message via E-meters in case of an

outage (‘UC9: Power quality reporting’).

Note: Last Gasp shall be only implemented for meters that use mobile

communication (PLMN).

Component: HES, METER [1Ph, 3Ph, PLMN]


Priority: REQUIRED

Fit criterion: The AMI system provides a ‘Last Gasp message’ in case of an outage so that the

MDM is notified via the HES were and when an outage occurs.

The E-meters send out the last gasp message.

Details on last gasp function are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-12

Description: The firmware of AMI system components shall be upgradable (‘UC10: Firmware

upgrade’).

Component: AMI


Priority: REQUIRED

Fit criterion: Firmware for all field installed components (E-meters, data concentrators) of the

AMI system shall be able to be upgraded remotely. The communications solution

should support firmware upgrade for all field devices.

Details on the firmware upgrade are aligned between Contracting entity and

Contractor.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder shall describe how this system use case is implemented for the E-meters and DC’s.

No: 2.4-13

Description: The AMI system shall provide consumer information (‘UC11: Provide Consumer information’).

Component: METER [1Ph, 3Ph, PLMN]


Priority: REQUIRED

Fit criterion: The AMI system provides information for consumers. The consumer information is

published to enable end-consumers to get insight in their energy consumption.

The readings shall be updated frequently enough to allow the information to be used to achieve energy savings. Collection should be “Near Real Time”. Telecommunication solution shall support reading of profiles “Near Real Time”. This

will be implemented at least for meters that use mobile communication (PLMN).

In this sense, local meter port will be also available to get access to consumers to

their consumption data. Refer to section 2.2.6 Icustomer-meter for more detail about

local consumer information interface.

Details on consumer information are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-14

Description: The AMI system shall provide communication supervision data collected by field devices (‘UC12: Communication supervision & System wide fault overview’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system components provide information on communication performance on their interfaces, such as signal qualities and communication retries. As well as analysis/diagnosis based on collected data: meter events, failed meter management processes, failed interfaces, failed tasks, etc. The communication supervision data is available via the HES.

Details on communication supervision are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-15

Description: The AMI system shall support Prepayment schemes implemented in the IT systems (MDMS and/or systems from energy supplier(s)) (‘UC13: Prepayment’).

Component: AMI

Required Maturity: STANDARD OR TO DEVELOPED

Priority: REQUIRED

Fit criterion: The AMI system implements support for prepayment schemes implemented in the IT

system.

The MDM via the HES triggers actions on the E-meters that result from prepayment

schemes. The consumer is disconnected or reconnected to the electricity supply by

the HES switching of the breaker if the prepayment schemes prescribes this.

The available credit can also trigger load limitation via the meter.

The prepayment support shall not affect the meter hardware.

Daily data collection will be applied for all meters including those users with a

prepayment contract. For prepayment, SAP will request meter reading on a daily

basis. The meter reading periodicity should be configurable by the MDMS/HES.

Details on prepayment support are aligned between Contracting entity and

Contractor.

Evidence of

compliance:


No: 2.4-16

Description: The AMI system shall support changing the configuration in the meter for the Measurement method (vector/arithmetic method) (‘UC14: Measurement method’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system implements support for changing the Measurement method.

The E-meter implements different measurement methods: vector method and

arithmetic method, that can be configurable from remote (HES/DC). By default, the

measurement method will be vectorial.

Switching between vectorial and arithmetical is enabled by function and not by firmware. Details on changing measurement method support are aligned between Contracting entity and Contractor.

Evidence of

compliance:


No: 2.4-17

Description: The AMI system shall support changing the configuration in the meter for the Meter display (‘UC15: Meter display configuration’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system implements support for changing the Meter Display.

The E-meters implements different modes of display configuration, that can be configurable from local or remote (MDMS/HES/DC). Details on changing meter display support are aligned between Contracting entity

and Contractor.

Evidence of

compliance:


No: 2.4-18

Description: The AMI system shall support changing the meter configuration to switch between

the two options to notify Events (‘UC16: Event Configuration’).

Component: AMI


Priority: REQUIRED

Fit criterion: The AMI system implements support for changing the event notification

configuration.

The E-meter implements two options to notify events: spontaneously (communicated automatically from the meter to the MDMS/HES via DC if applicable) and/or upon request from the MDMS/HES (logged). The spontaneous and/or logged event notification is configurable in the meter per event from local or remote (MDMS/HES/DC).

Details on changing events support are aligned between Contracting entity and Contractor.

Evidence of

compliance:


Documentation Requirements

No: 2.5-1

Description: The bidder is required to submit specific documentation in English and referring

to the specific plant where the proposed components are manufactured.

Component: Meter [1Ph, 3Ph, CT, PLMN, PLC, DC]


Priority: REQUIRED

Fit criterion: The Bidder is required to submit, with the technical proposal, the following documentation: A copy of a certificate of type (pattern) approval including test report from

an Accredited Laboratory that proves compliance with IEC 62052-11, IEC 62053-21 and IEC 62053-22,

Or alternatively, a Certificate / Declaration of conformity including test report from a valid Notified Body listed on NANDO website that proves

compliance with EN 50470-1, EN 50470-3 and a Certificate / Declaration of conformity including test report from an Accredited Laboratory that proves compliance with IEC 62053-23 or IEC 62053-24.

EN 50470-1 and EN 50470-3 MID Certificate shall be accepted only if performed and signed by an MID notified body from the list provided at NANDO website with 2014/32/EU Measuring Instruments Directive legislation.:

https://ec.europa.eu/growth/tools-databases/nando/index.cfm?fuseaction=directive.notifiedbody&dir_id=154161 Accredited laboratories are: NMI, OFGEM, NATA, KEMA, PTB, METAS or IECEE Certified Body Test List: https://test.iecee.org/dyn/www/f?p=106:41:0

RAM (Reliability, Availability, and Maintainability) Declaration - Further

details about the RAM declaration are provided in Appendix F. Calibration certificates and traceability charts for all relevant test and

calibration equipment. The manufacturer shall attach with the technical offer a complete

description of the meter with all its properties and its detailed relation to each item of this specification.

A signed “Off the shelf product declaration”, see Appendix G.

Evidence of

compliance:

Requested documentation provided by the bidder

No: 2.5-2

Description: The bidder is required to submit specific documentation in English and referring

to the specific plant where the proposed components are manufactured.

Component: Meter [1Ph, 3Ph, CT, PLMN, PLC, DC]


Priority: REQUIRED

Fit criterion: The bidder is required to submit, with the technical proposal, the following documentation:

A copy of a certificate of compliance with ISO 9001:2015 issued by a Certification Body (CB) which is qualified by an Accreditation Body.

The certificate shall bear the logo of the CB and of its Accreditation Body and/or the logo of the IAF MLA.

The certificate shall be valid on the date set for submission of the proposal.

The certificate shall be valid for the scope of activities specified in the request for proposal.

Evidence of

compliance:

Requested documentation provided by the bidder.

https://ec.europa.eu/growth/tools-databases/nando/index.cfm?fuseaction=directive.notifiedbody&dir_id=154161



https://test.iecee.org/dyn/www/f?p=106:41:0

No: 2.5-3

Description: Technical manuals regarding all proposed devices.

Component: Meter [1Ph, 3Ph, CT, PLMN, PLC, DC, Filter]


Priority: REQUIRED

Fit criterion: The bidder is required to submit, with the technical proposal, the following

documentation: Meter installation and operation manual/documentation Meter SW operation manual/documentation DC installation and operation manual/documentation

DC SW operation manual/documentation Manual/documentation of all other proposed devices

Evidence of

compliance:

Requested documentation provided by the bidder.

3 TECHNICAL REQUIREMENTS FOR THE SMART METERS

The specifications detailed in this section are applicable (if indicated in the requirements under

Component) for the following types of meters:

For residential E-meters

ID Type of

Connection

# of wires Voltage Imax (A)

1 Ph Direct 2 1 x 230V 60 A

3 Ph Direct 4 3 x 230V

3x100 A

Apart from the residential E-meters, also CT-meters are needed. These types of meters will be

installed in transformer substations and apply indirect metering by using current instrument

transformers. The requirements regarding the current instrument transformers are detailed in

Appendix C.

Norms & Regulations

3.1.1 General Norms for metering equipment

No: 3.1.1-1

Description: Preferred MID conformity assessment route is module B + module D.

Component: Meter [1Ph, 3Ph, CT, PLMN, PLC]


Priority: PREFERRED

Fit criterion: Preferred MID conformity assessment route is module B (meter type testing during design phase) + module D (meter manufacturing audit).

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides an EU type approval certificate issued by a Notified Body and all other relevant documents specified in MID.

No: 3.1.1-2

Description: The E-meter shall meet the requirements for electricity metering equipment (a.c.)



Priority: REQUIRED

Fit criterion: The E-meter will meet electricity metering equipment characteristics stated in:

• IEC 62052-11: General requirements, tests and test conditions - Metering equipment

• IEC 62053-21: Particular requirements, static meters for active energy • IEC 62053-23: Particular requirements, static meters for reactive energy

(classes 2 and 3) • IEC 62053-24: Particular requirements, static meters for reactive energy

(classes 0.5S, 1S, 2, and 3)

The E-meter is compliant with the specified electricity metering equipment (a.c.)

requirements. Alternative accepted standards are EN 50740-1, 3 respectively.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a documented test report from an Accredited Laboratory that proves compliance with IEC 62052-11(or EN 50470-1), IEC 62053-21(or EN 50740-

3) and IEC 62053-23. The Laboratory must be an MID notified body.

No: 3.1.1-3

Description: The E-meter shall meet the requirements for immunity in the frequency range of the

CENELEC-A band as well as in FCC band.

Components: Meter [1Ph, 3Ph, CT, PLC]


Priority: REQUIRED

Fit criterion: EN 50065 and FCC Part-15 compliance implies that the E-meter meets the specified requirements in terms of frequency bands and electromagnetic disturbances,

immunity requirements, low voltage decoupling filters and equipment impedance.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory:

The bidder provides a documented test report from an Accredited Laboratory that proves compliance with EN 50065 and FCC Part-15.

3.1.2 Climatic conditions

No: 3.1.2-1

Description: The E-meter shall withstand the specified climatic conditions without damage or

degradation.

Component: Meter [1Ph, 3Ph, CT, PLMN]

Required maturity: STANDARD

Priority: REQUIRED

Fit criterion: The E-meter shall withstand the specified climatic conditions for indoor meters as defined in IEC 62052-11 (section 8) without damage or degradation. On top of these, the climatic conditions in Israel requires a specified operating range of at least -10 °C to 65 °C, without damage or degradation. The test report gives an overview of the performed tests and the test results to prove that the meter can withstand the specified climatic conditions without damage

or degradation of all characteristics when subsequently operated under rated operating conditions.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a test report from an Accredited Laboratory for the tests specified in IEC 62052-11 sections 8.

3.1.3 Durability & Reliability

No: 3.1.3-1

Description: The E-meter shall meet the requirements for lifespan expectancy.



Priority: REQUIRED

Fit criterion: The metrological properties of the E-meter shall be durable and reliable during the entire lifetime of the meter.

The lifespan is applicable to the entire meter including, but not limited, to communication units and additional functionalities like breaker or limiter. Special care needs to be taken for components that easily lose performance due to ageing. For instance, display, breaker, or backup power supply.

The expected minimum lifetime of the meter is at least 15 years, starting at the

installation date, and under the climatic conditions indicated in this document.

Evidence of

compliance:

Test report or documented evidence from bidder, or Certificate / Test report + Declaration of conformity from external laboratory:

The bidder provides a report that includes the reliability predictions according to IEC 62059-41 and estimation of the product lifetime according to IEC 62059-31-1.

3.1.4 Metrology

No: 3.1.4-1

Description: The E-meter shall meet the accuracy requirements for active energy measurement.



Priority: REQUIRED

Fit criterion: The E-meter meets the accuracy requirements for class 1 as specified in IEC 62053-21 or class B as specified in EN 50470-3 (or better).

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a test report from an Accredited Laboratory for the tests specified in IEC 62053-11 section 8 and/or EN 50470-3 section 8.

No: 3.1.4-2

Description: The E-meter shall meet the accuracy requirements for reactive energy

measurement.



Priority: REQUIRED

Fit criterion: The E-meter meets the accuracy requirements for class 2, as specified in IEC

62053-23, and for class 1 or better, as specified in IEC 62053-24.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a test report from an Accredited Laboratory for the tests

specified in IEC 62053-23 section 8 for class 2, and for the test specified in IEC 62053-24 section 8 for class 1. Lab must be an MID notified body from NANDO website (2014/32/EU Measuring Instruments Directive). Subcontractors of NANDO list will not be accepted.

No: 3.1.4-3

Description: The E-meter shall measure the specified set of electricity quantities.



Priority: REQUIRED

Fit criterion: The E-meter shall measure the following power quantities:

Instantaneous active power (|+A|+|-A|)

Instantaneous active import power (+A) Instantaneous active export power (-A) Instantaneous reactive import power (+R) Instantaneous reactive export power (-R)

The E-meter shall measure the following energy quantities:

Active energy import (+A), total for all rates and per rate. Active energy export (-A), total for all rates and per rate. Active energy (|+A|+|-A|) combined total.

Active energy (|+A|- |-A|) combined total. Reactive energy import (+R) (QI + QII), total for all rates. Reactive energy export (-R) (QIII + QIV), total for all rates. Reactive energy per quadrant (QI – QIV), total for all rates.

The E- meter shall measure the following voltage and current quantities:

Instantaneous voltage per phase. Instantaneous current per phase. Instantaneous current, sum over all phases.

Evidence of

compliance:


No: 3.1.4-4

Description: The E-meter shall measure apparent energy.



Priority: REQUIRED

Fit criterion: The E-meter shall measure the apparent energy:

Apparent energy import (+VA) Apparent energy export (-VA)

Evidence of

compliance:


No: 3.1.4-5

Description: Measurement method to determine the net energy flow

Component: Meter [3Ph, CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: The measurement method to determine the net energy flow can be either the

algebraic sum of the energy in the 3 separate phases (algebraic method) or the sum of the energy for all 3 phases together (vectorial method). The vectorial method sums the net energy flow over all phases (with maintaining the sign per phase) before the net result is stored in a register (resulting in net import or net export). The algebraic method sums consumption with the same sign separately and stores the outcome in the appropriate register(s).

The meter shall use by default the vectorial measurement method but shall have an option to switch to the algebraic measurement method. By default, the measurement method will be vectorial. Switching between vectorial and arithmetical is enabled by function and not by firmware. In Appendix B there is a description of the energy metering method modes.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a test report from an Accredited Laboratory that includes test cases with simultaneous import and export on different phases, using both the algebraic and vectorial measurement methods.

3.1.5 Safety

No: 3.1.5-1

Description: The E-meter shall comply with the product safety requirements for electricity metering equipment.



Priority: REQUIRED

Fit criterion: The meter shall comply with the IEC 62052-31:

Protection against electrical shock (protective class II) Protection against mechanical hazards

Resistance to mechanical stresses (IK02 or better per IEC 62262) Protection against spread of fire Equipment temperature limits and resistance to heat Protection against penetration of dust and water (at least IP51) Protection against liberated gases and substances explosion and implosion –

Batteries and battery charging (only if relevant) Components and sub-assemblies (only if relevant)

Hazards resulting from application – Reasonably foreseeable misuse Risk assessment

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a documented test report from an Accredited Laboratory to prove compliance with the relevant specifications of IEC 62052-31.

For safety specifications which are also covered in EN 50470-1 or -3, a test report according to that standard can also be accepted.

No: 3.1.5-2

Description: The E-meter shall withstand a free fall test



Priority: REQUIRED

Fit criterion: The meter shall withstand a free fall test according to IEC 60068-2-32 (including Amendment 2). In short: 1-meter high vertical fall, followed by a full functional and visual test. The meter shall be placed in two positions: vertical and rotated 90

degrees horizontally.

For meters packed in a common box, the test conditions are as follows: height 500 mm; number of falls 50. For a single unpacked meter (without its terminal cover), the test conditions are as follows: height 500 mm; number of falls 2.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a documented test report from an Accredited Laboratory (according to ISO17025) to prove compliance with the relevant specifications of IEC 60068-2-32. IECo may conduct its own free fall test to verify.

3.1.6 Electromagnetic compatibility

No: 3.1.6-1

Description: The E-meter shall provide electromagnetic compatibility (EMC).

Components: Meter [1Ph, 3Ph, CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: The E-meter will meet the electromagnetic compatibility (EMC) criteria stated in IEC 62052-11 section 9.3.

The E-meter is compliance with the specified electromagnetic compatibility (EMC) criteria.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a documented test report from an Accredited Laboratory that proves compliance with IEC 62052-11 section 9.3.

No: 3.1.6-2

Description: The meter shall be protected against external continuous magnetic flux levels

Components: Meter [1Ph, 3Ph, CT, PLMN, PLC]


Priority: PREFERRED

Fit criterion: 1. The meter shall be protected against external continuous magnetic flux levels of

up to 1.5kG.

2. IECo requires that there shall be a flag at events log when magnetic flux value exceeds the value stated at IEC 62052-11, paragraph 9.3.12. The event log shall include a date+ time stamps of on/off event triggering. Event shall be triggered and logged if duration of influence is at least 15 sec. The manufacturer shall take measures so as not to flood the event log buffer.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory:

The bidder provides a documented test report from an Accredited Laboratory that proves compliance with IEC 62052-11 section 9.3.12. + evaluation and approval by IECo of a sample using neodymium DC magnet.

Hardware Requirements

3.2.1 Electrical Ratings

No: 3.2.1-1

Description: The 3Ph meter shall comply to defined electrical ratings.

Component: METER [3Ph, CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: The electrical ratings for the 3Ph meter are as follows:

Reference voltage Un: 3x230V (400V) Maximum current for direct connection meters Imax: 3x100A or higher

Reference current for CT meters: 3x 100/5 A". Reference frequency: 50Hz Number of wires: 4 (3 phases and neutral)

Evidence of

compliance:


No: 3.2.1-2

Description: The 1Ph meter shall comply to defined electrical ratings.

Component: METER [1Ph, PLMN, PLC]


Priority: REQUIRED

Fit criterion: The electrical ratings for the 1Ph meter are as follows:

Maximum current Imax: 60A or higher Reference frequency: 50Hz Number of wires: 2

Evidence of

compliance:


3.2.2 Meter Casing

No: 3.2.2-1

Description: The meters should be of robust construction, compact, all insulated indoor pattern, with wall mounting case, with front connections and insulated terminal block with extended terminal cover.



Priority: REQUIRED

Fit criterion: The materials used in the construction of the meters are to be of the highest quality and selected particularly to meet the duties required of them. Workmanship and

general finish are to be of the highest class throughout.

Evidence of

compliance:

Compliance with this specification is verified by evaluation of a sample.

No: 3.2.2-2

Description: The maximum dimensions of the meter casing of the 3Ph meter and the CT meter

shall not exceed specific dimensions.



Priority: REQUIRED

Fit criterion: The maximum dimensions for meter casing are:

Height: 320 mm (including terminal cover)

Width: 180 mm (between bottom mounting holes axes)

Depth: 140 mm

Evidence of

compliance:


No: 3.2.2-3

Description: The maximum dimensions of the meter casing of the 1Ph meter shall not exceed

specific dimensions.



Priority: REQUIRED

Fit criterion: The maximum dimensions for meter casing are:

Height: 180 mm (including terminal cover)

Width: 90 mm (between bottom mounting holes axes)

Depth: 140 mm

Evidence of

compliance:


3.2.3 Seals

No: 3.2.3-1

Description: The seals applied on the E-meter shall prevent intruding into the E-meter and tampering.



Priority: REQUIRED

Fit criterion: The E-meter is protected by seals in order to prevent intruding into the E-meter and tampering with the E-meter without removing the seals or damaging the meter casing.

All separate covers are protected by independent seals, for example: The meter cover The terminal cover Communication module cover

1. The meter shall be sealed in such a way to show and confirm the initial calibration performed on the meter. The metrological mark shall contain

calibration date, calibration equipment and operator info. 2. The meter base and cover could be either ultrasonically welded or

permanently glued together to prevent access to internal components. 3. Alternatively, screw(s) securing the meter cover to the base shall be either

unidirectional, or be featured by sheared head, so as to be irremovable. 4. In case of screws solution seal(s) of the same type made of tin-coated

electrolyte copper and crimped on a galvanized or stainless-steel cable

("rope") shall seal the meter cover to its base. 5. The seal shall be adjacent as much as possible to the screw, which is to be

sealed, and the surplus cable ends shall be cut adjacent to the sealing.

6. The seals shall be "sunk" into slits at the meter housing, in order to prevent user wounding from sharp edges.

Evidence of

compliance:

Compliance with this specification is verified by evaluation and approval by IECo of a sample.

No: 3.2.3-2

Description: The input voltage connection (link), if any, shall not be available for opening using

conventional means and shall be protected to prevent opening.

Component: METER [1Ph, 3Ph, PLMN, PLC]


Priority: REQUIRED

Fit criterion: The meters will be supplied to IECo with the link, if any, closed and checked for continuity. There shall not be access to internal parts of the meter through the terminals.

Evidence of

compliance:


3.2.4 Markings

No: 3.2.4-1

Description: The markings on the meter shall be compliant with international standards.



Priority: REQUIRED

Fit criterion: The marking on the meter shall be compliant with IEC 62052-11 (section 6.2), and IEC 62052-31 (section 5). All characteristics that have a standard symbol defined in IEC 62053-52 are marked

accordingly. The markings are logically grouped on the front side of the meter so that they can easily be read when the meter is installed in a meter cabinet. Additional information should include at least the following: Manufacturing country

Official IECo logo Encircled code number consisting of 3 or 4 digits. The code number will be given

to the Bidder who is awarded the order IECo meter serial number – unique and different for each meter

(appropriate numbers will be given by IECo). The 6-digit serial number shall be marked with digits at least 4 mm high height. Added to the 6-digit serial number are two digits to reflect the year of manufacture.

Barcode with IECo serial number and code number. The marking shall be done in code 128C with 12 digits; the first four digits for the meter code and 8 digits for the serial number + year of manufacture, adding leading zeros if necessary.

The minimum height of the bar-code mark shall be 10mm in medium density. The bar-code coding and readability shall be checked and confirmed by IECo. The result shall be at least 95% and light reflection at least 80%.

The communication mode (e.g. PLC, cellular) should be marked on the nameplate, with the relevant logo (IDIS, DLMS/COSEM, G3-PLC).

Exact marking shall be agreed between IECo and the contractor. Examples of

nameplates are shown in Figure 3-1, Figure 3-2, and Figure 3-3.

Evidence of

compliance:

Compliance with this specification is verified by evaluation of a sample. DLMS/COSEM, IDIS and G3-PLC certificated issued by the corresponding official user associations.

Figure 3-1: Example of single-phase direct connected meter nameplate

Figure 3-2: Example of three-phase direct and CT connected meter nameplate

Figure 3-3: Example of Meter face and nameplate

No: 3.2.4-2

Description: Markings shall be durable.



Priority: REQUIRED

Fit criterion: The bidder provides proof of durability of the markings based upon the test described in IEC 62052-31 (section 5.2.2).

Evidence of

compliance:

Compliance with this specification is verified by evaluation of a sample and the Test report or documented evidence from bidder.

No: 3.2.4-3

Description: The connection diagram for the single-phase meter is shown in the terminal cover.



Priority: REQUIRED

Fit criterion: A connection diagram compliant to IEC 62052-11 (section 6.3) is shown in the

terminal cover.

The connection diagram shall comply with Figure 3-4 for the single-phase meter.

The sequence is: L N N L' (‘British Standard’).

Evidence of

compliance:


No: 3.2.4-4

Description: The connection diagram for the three-phase meter is shown in the terminal cover.



Priority: REQUIRED

Fit criterion: A connection diagram compliant to IEC 62052-11 (section 6.3) is shown in the

terminal cover.

The connection diagram shall comply with Figure 3-5 for the three-phase meter.

The sequence is: L1 L1’ L2 L2’ L3 L3’ N N’ , (‘DIN Standard’)

Evidence of

compliance:


No: 3.2.4-5

Description: The connection diagram for the CT meter is shown in the terminal cover.

Component: METER [CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: A connection diagram compliant to IEC 62052-11 (section 6.3) is shown in the terminal cover.

The connection diagram shall comply with Figure 3-6 for the three-phase CT meter.

The sequence is: L1 U1 L1’ L2 U2 L2’ L3 U3 L3’ N N’ , (‘DIN Standard’)

Evidence of

compliance:


L

N

Figure 3-4: Connection diagram for single phase meter: L N N L’, (‘British Standard’)

Figure 3-5: Connection diagram for three phase meter, 4-wire meter: L1 L1’ L2 L2’ L3 L3’ N

N’ , (‘DIN Standard’)

Figure 3-6: Connection diagram for three phase CT meter 4-wire meter: L1 U1 L1’ L2 U2 L2’ L3 U3 L3’ N N’ , (‘DIN Standard’)

3.2.5 Terminal block

No: 3.2.5-1

Description: The terminals of the 1Ph meter shall follow the sequence: L N N L' (‘British Standard’).



Priority: REQUIRED

Fit criterion: The connection sequence shall comply with Figure 3-4. The sequence is: L N N L'

(‘British Standard’) in accordance with BS 7856:1996

Evidence of

compliance:


No: 3.2.5-2

Description: The terminals of the 3Ph meter shall follow the sequence: L1 L1’ L2 L2’ L3 L3’ N N’ , (‘DIN Standard’). The terminals of the CT meter shall follow the sequence: L1 U1 L1’ L2 U2 L2’ L3 U3 L3’ N N’.



Priority: REQUIRED

Fit criterion: The terminals of the 3Ph meter shall follow the sequence: L1 L1’ L2 L2’ L3 L3’ N N’ , (‘DIN Standard’).

The terminals of the CT meter shall follow the sequence: L1 U1 L1’ L2 U2 L2’ L3 U3 L3’ N N’.

Evidence of

compliance:


No: 3.2.5-3

Description: Terminal screws shall be of sufficient quality and allow installation of meters.



Priority: REQUIRED

Fit criterion: For single-phase and poly-phase meters for direct connection the screw

diameter must be at least M6 The tightening torque to ensure a good connection shall be less than 3 Nm. This

value shall be specified by the manufacturer. With a value of 1.5 times the value specified by the manufacturer, with a

minimum of 3.5 Nm, it should be possible to tighten and loose the screws 25 times without damage.

The terminal screws must be made either of Steel 8,8 and be Nickel plated (5 microns minimum) or made of brass and be protected against corrosion.

There shall be no galvanic couple between the screws, terminals, and copper conductor/thimble. Joined alloys potential difference must not exceed 0.15V (refer to ASTM G82 Standard).

The screw bottom must be chamfered, without rough edges. The meters must be supplied with all terminal screws fully inserted into the

terminals and tightened enough to prevent being loosened due to vibrations during transportation.

Evidence of

compliance:


No: 3.2.5-4

Description: Terminal blocks shall be of heavy-duty type.



Priority: REQUIRED

Fit criterion: Each terminal shall have two screws associated to it. The terminal blocks shall be made either of Steel 8,8 and be Nickel plated (5

microns minimum), or made of brass and be protected against corrosion. There shall be no galvanic couple between the screws, terminals, and copper

conductor. Joined alloys potential difference must not exceed 0.15V (refer to ASTM G82 Standard).

Evidence of

compliance:


No: 3.2.5-5

Description: The terminals shall ensure robust connection of the wires.



Priority: REQUIRED

Fit criterion: Connection of wires to the terminals of the meter shall always be reliable and save.

For direct meters each terminal must be provided with two screws to tighten copper conductor/thimble directly (so-called "pillar-bar-type" terminal), or by means of lift-clip which pinches a conductor (so-called "lift-type" terminal).

For single-phase meters for direct connection the bore diameter for external

cable connection shall be at least 8.0 -0.22 mm in accordance with ISO 286-1, 282-2 tolerances specifications.

For poly-phase meters for direct connection the bore diameter for external cable connection shall be at least 9.0 -0.22 mm in accordance with ISO 286-1, 282-2 tolerances specifications.

For CT-connected meters only pillar bar-type terminals shall be accepted. The bore diameter for external cable connection shall allow easy accommodation of 2

mm2 and 4 mm2 wires.

The terminals are designed so that wrong/improper connection is reduced to a minimum. Following cases are taken in consideration, but not limited to these:

Possibility to connect wires to the wrong side of the clamping unit Possibility to connect wires beside the screws Degradation of clamping force after wire connection

Evidence of

compliance:


No: 3.2.5-6

Description: The terminals shall have a cover.



Priority: REQUIRED

Fit criterion: The terminal cover shall be of the extended type made of non-breakable, self-

extinguishing insulating material Class V-2 according to IEC 60695-11-10. The cover shall be extended type with free space for the connecting cables of:

o At least 40 mm for single-phase direct and CT connected meters. o At least 60 mm for three-phase meters.

The cover shall be firmly attached to the case with one or two screws. The cover shall be packed for shipping unscrewed, together with the meter. The screw/s, however, shall be inserted into their places in the cover.

The screws shall be protected from slip out from the cover when not tightened. After the meter is mounted, no access to the installation screws as well as

terminals or cables shall be possible without breaking the seal or the cover itself.

The connection diagram of the meter with terminals marking shall be attached to or stamped on the inner side of the cover.

The cover and the screws must be sealable.

Evidence of

compliance:


3.2.6 Meter mounting

No: 3.2.6-1

Description: Mounting brackets to allow easy mounting are required.



Priority: REQUIRED

Fit criterion: Mounting brackets to allow easy mounting are required for all meter model types, except for single-phase meters. The mounting bracket could be integral part of the meter base, slide-out, reversible or a clip-on accessory. The distance between the top of the meter case to the center of the extended mounting hole shall be 10-15 mm.

The mounting bracket should be of sufficient strength not to separate/break under the weight of the meter

The mounting hole shall enable mounting on a screw with diameter of 4-5 mm. The mounting hole shall be accessible for a screwdriver from the meter front side.

Examples of the mounting bracket are shown below in Figure 3-7.

Evidence of

compliance:


Figure 3-7: Example of mounting bracket

No: 3.2.6-2

Description: The meter shall have mounting holes

Component: METER [1ph, 3Ph, CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: For single phase direct meters: The mounting holes spacing shall be in accordance with BS 7856:1996, The top mounting hole (hanging point) is optional.

For three phase meters (direct and CT connected): The meter shall have two bottom holes for its fixing by means of 5 mm diameter screws. The bottom holes must be covered by the terminal cover after its setting and sealing.

Evidence of

compliance:


3.2.7 Power supply

No: 3.2.7-1

Description: The polyphase meter shall function when connected to any one phase.



Priority: REQUIRED

Fit criterion: The polyphase E-meter is operational when connected between any line and the neutral line.

Evidence of

compliance:


No: 3.2.7-2

Description: The polyphase meter shall function with only the neutral disconnected, or with 1 or 2 phases disconnected with the neutral still connected. The errors in energy measurement shall not exceed the limits allowed in the standards regarding single phase energizing.



Priority: REQUIRED

Fit criterion: The polyphase E-meter is operational with only the neutral disconnected, or with 1 or 2 phases disconnected with the neutral still connected.

Evidence of

compliance:


No: 3.2.7-3

Description: The polyphase meter shall withstand overvoltage between the phase and the neutral.



Priority: REQUIRED

Fit criterion: Meters shall withstand the following tests:

1. If a voltage of up to 400 V rms is applied between the phase and neutral, the meter shall not be damaged, and continue to operate properly when the over-voltage condition is removed.

2. "Worst case test" scenario is when inputs over-voltage been applied upon all three phases (for three-phase meters) during two hours simultaneously. There shall not be any change of the meter metrological features when over-

voltage is removed.

3. The meter must run for two hours at Uth, and immediately afterwards for two hours at Un. The meter error values before and after the test will be

compared. The test load is Un, Ib and PF=1.

Evidence of

compliance:


No: 3.2.7-4

Description: The meter shall have a back-up power supply that maintains meter functions.



Priority: REQUIRED

Fit criterion: The E-meter contains a back-up power supply that can maintain the following

functions while the meter is not powered via the mains:

Allow the E-meter to register complete power failures (in non-volatile memory),

Keep the RTC running The back-up power supply meets the specifications in IEC 62052-21 sections 7.1.6

and 7.1.7.

Evidence of

compliance:


3.2.8 User interface

3.2.8.1 Meter display

No: 3.2.8.1-1

Description: The E-meter shall have a digital display.



Priority: REQUIRED

Fit criterion: The display is compliant with IEC 62052-11 (section 5.6).

Evidence of

compliance:


No: 3.2.8.1-2

Description: It shall be possible to perform a display test.



Priority: REQUIRED

Fit criterion: It is possible to trigger a display test in order to verify the proper functioning of the display.

Evidence of

compliance:


No: 3.2.8.1-3

Description: The meter display shall be able to show measurement values in auto-scroll mode.



Priority: REQUIRED

Fit criterion: (Measurement) values are indicated by: Value field: The value field should support at least 6 digits with digit height of at

least 8 mm, with leading zeros if necessary. Energy measurement values are by

default shown with 0 decimals. Value identification: Reduced OBIS codes are used to identify the values. Fields

A, B and F of the OBIS code are not shown. Unit of the displayed value. The units (e.g. kWh, kVAh, kVArh, W, A, ...) are

placed adjacent to the value. The order for each display item shall be programmable The interval for auto-scrolling shall be configurable.

Format for energy – 6 digits with no decimals – 000000 - >999999 then roll over

Format for Max Demand – 3 digits with 1 decimal – 000.0 to 999.9 Format for Cumulative Max demand – 5 digits with 1 decimal -00000.0 to

99999.9 Format Date & Time: DD/MM/YY 24 h

The values are shown in auto-scroll mode. Exact set of values are aligned between Contracting entity and Contractor.

Evidence of

compliance:

Test report or documented evidence from bidder. Alternatively, the display roll-over can be checked by evaluating a sample. For this purpose the samples should be

delivered with the register values of 999998 so that roll-over can be verified.

No: 3.2.8.1-4

Description: The display shall permanently show status information when the meter is powered.



Priority: REQUIRED

Fit criterion: The display shows at least the following status items: Disconnector status indicator (Disconnected / ‘Ready for Reconnection’)

Indication per phase that voltage is present Instantaneous energy direction (import or export) Active tariff Negative consumption flag (the flag shall be removed after reading) Failure indication and code (if any) Battery

These items are permanently shown on the display (not in scroll mode). In case text is used to display the disconnector status, the text message and the register value are shown simultaneously or alternating.

Evidence of

compliance:


No: 3.2.8.1-5

Description: The meter shall have a manual scroll mode.



Priority: REQUIRED

Fit criterion: By pressing the button on the meter, a consumer accesses the manual scroll mode. The same button is used to visualize the next item of the ‘display list for manual scroll mode’.

After a period of inactivity, the meter returns to automatic scroll mode.

The exact set of values shown in manual-scroll mode are aligned between contracting entity and contractor.

Evidence of

compliance:


No: 3.2.8.1-6

Description: The default display language shall be English.



Priority: REQUIRED

Fit criterion: If text messages on the display are used, then the display language is English.

Evidence of

compliance:


No: 3.2.8.1-7

Description: The E-meter shall indicate the reception of the communication signal with distinguished signal strength levels.



Priority: REQUIRED

Fit criterion: The E-meter indicates whether the signal level of the network is enough for good

communication. This is done by displaying signal strength levels. In addition, the signal level indication will be updated periodically. The signal level indication must be made visible on the display.

Evidence of

compliance:


No: 3.2.8.1-8

Description: High resolution display mode



Priority: REQUIRED

Fit criterion: The meter shall have a high-resolution display mode of at least 10wh/varh for dial

test /accuracy testing. Changing to this mode shall occur by the meter push buttons

and/or software for at least 60 minutes. It shall not be possibility to enter the high-resolution display mode unauthorized. The meter shall reset to normal at power off.

Evidence of

compliance:

Compliance with this specification is also verified by evaluation of a sample.

3.2.8.2 Push button

No: 3.2.8.2-1

Description: The E-meter shall have at least one push button.



Priority: REQUIRED

Fit criterion: The meter shall have at least one push button to at least trigger the following functions:

Scroll through menu (manual scroll mode)

To safely reconnect the breaker

Evidence of

compliance:


3.2.8.3 Test output

No: 3.2.8.3-1

Description: An optical test output (flashing LED indicator) shall be available.



Priority: REQUIRED

Fit criterion: An optical test output for active energy is present on the meter. The test output complies with IEC 62052-11 (section 5.8).

In case multiple optical test outputs are available (e.g. one for active and one for reactive energy), then markings on the nameplate indicate the function of each

optical output. The ratio (energy/pulse) shall also be indicated on the nameplate.

Evidence of

compliance:

The bidder provides a test report from an Accredited Laboratory that proves that the optical test output complies with IEC 62052-11 (section 5.8).

3.2.9 Real Time Clock

No: 3.2.9-1

Description: The RTC clock of the E-meter shall be accurate.



Priority: REQUIRED

Fit criterion: The clock shall not deviate more than 0.5 seconds per 24 hours. (According to IEC 62054-21 Electricity metering (a.c.) Tariff and Load Control Part 21: Requirements for time switches, Clause 7.5.2.2 Requirements for crystal-controlled time switches)

Evidence of

compliance:


No: 3.2.9-2

Description: The E-meter shall handle daylight savings time.



Priority: REQUIRED

Fit criterion: The E-meter autonomously switches to daylight savings time according to Israeli law:

DST Entry: the Friday before the last Sunday of March DST Exit: the last Sunday of October

Or: The DST can be (locally) configured via a table for at least 4 years ahead

The DST definition shall have a unique ID

Evidence of

compliance:


3.2.10 Breaker

No: 3.2.10-1

Description: A meter shall have a breaker that switches ON or OFF all load phases.



Priority: REQUIRED

Fit criterion: For 3Ph meter: All phases are switched simultaneously. The neutral shall not be switched. The breaker shall comply to the switch requirements in IEC 62052-31. The breaker performance shall be in accordance with IEC 62055-31.

Of the total number single phase direct and three phase direct meters supplied, 10% shall be equipped with a breaker. CT meters do not have a breaker. PLC meters do not have a breaker, only meters with PLMN communication technology shall have a breaker. Breaker shall support all modes types according to DLMS Blue Book.

Evidence of

compliance:

Design of breaker: Test report or documented evidence from bidder. Compliance to IEC 62052-31 and IEC 62055-31: Certificate / Test report + Declaration of conformity from external laboratory or Test report or documented evidence from bidder.

No: 3.2.10-2

Description: Breaker shall be autonomously triggered by events (configurable)



Priority: REQUIRED

Fit criterion: Breaker shall act (OPEN) triggered by events (configurable). Default events that trigger breaker are:

- Exceed Active Power threshold import - Exceed Active Power threshold export

Other meter events (such as neutral loss) may be added by IECo in the Sprint0/HLD phase.

Evidence of

compliance:


3.2.11 Memory

No: 3.2.11-1

Description: When the meter is not powered, the data in the meters shall stay in non-volatile memory for a minimum specified period.



Priority: REQUIRED

Fit criterion: When powered up again after a power down, the E-meter must become operational with no loss of data or configuration settings.

The meter complies with the minimum retention time of 12 months for measurement data, as specified in IEC 62052-11 (section 5.7) This applies also to other data, at least: Event-logs Power quality logs The meter will not lose configuration data needed for a functioning of the meter, at

least: Security parameters. Communication settings.

Evidence of

compliance:


No: 3.2.11-2

Description: The meter shall have sufficient memory capacity.



Priority: REQUIRED

Fit criterion: The E-meter shall have sufficient memory for at least 3 profiles: monthly billing, daily billing, and load profile. The load profile shall store measurement data for the

last 60 days. Daily billing data shall be stored in the E-meter for the last 15 days. Monthly billing data shall be stored in the E-meter for the last 15 months. The capture interval time of the historical load profiles is configurable. The set of captured data in the profiles is also configurable.

The End-2-End AMI system shall be designed to at least support daily meter reads of 15-minute values. In special cases, (e.g. prepayment), the meter readings are done more frequent.

Evidence of

compliance:


Software Requirements

3.3.1 Data exchange & data model

No: 3.3.1-1

Description: The Annexure B2 - MOACH DLMS COSEM PROFILE for mobile communication

interfaces shall be implemented.



Priority: REQUIRED

Fit criterion: The meter implements the Annexure B2 - MOACH DLMS COSEM PROFILE for

communication interfaces for Mobile communication.

Evidence of

compliance:

Test report

No: 3.3.1-2

Description: The Annexure B2 - MOACH DLMS COSEM PROFILE for communication interfaces MOACH Smart Meters – G3-PLC communication, shall be implemented.

Component: METER [1Ph, 3Ph, CT, PLC]


Priority: REQUIRED

Fit criterion: The meter implements the Annexure B2 - MOACH DLMS COSEM PROFILE for communication interfaces MOACH Smart Meters for G3-PLC communication.

Evidence of

compliance:

Test report

No: 3.3.1-3

Description: The E-meter shall have a Time of Use (ToU) table implementation



Priority: REQUIRED

Fit criterion: The E-meter holds a Time of Use (ToU) tariff table and counts energy in separate registers for each tariff.

It shall be remotely configurable and robust to communication failures.

The general definitions of the ToU structure are according to Figure 3-8.

IECo preserves the right and shall test, ability to modify ToU configuration, for up to four tariffs per day.

The ToU table below shall be programmed through configuration file or via its communication interface to arriving meters.

IECo requires that it shall be possible to re-program ToU table as defined in IECo requirements.

The meter shall input and store any ToU table covering at least 12 seasons per year, at least 4 tariffs per season, 3 day types per season, calculation of Maximum demand for each of the 4 tariffs, and 18 points for definition of

"special days" and holidays (Table 3-1, Israel calendar - in accordance with

17 special days per year), at least 3 types of days, at least 24 tariff change points per day (rates: high, medium #1, medium #2, low) indicating the beginning of tariff and the beginning and dates of day light saving time period. There should be at least space for 100 special days in the total to cover 6 years of special days.

Evidence of

compliance:

Test report or documented evidence from bidder. Special days implementation is to be agreed upon between the parties before implementation.

Table 3-1: Special Days # Holiday Name Day Type Date Day of week

1 Pesach Holiday evening 22-4-2024

2 Pesach Holiday 23-4-2024

3 Pesach 2 Holiday evening 28-4-2024

4 Pesach 2 Holiday 29-4-2024

5 Atzmaout Holiday evening 13-5-2024

6 Atzmaout Holiday 14-5-2024

7 Shavuot Holiday evening 11-6-2024

8 Shavuot Holiday 12-6-2024

9 Rosh-Hashana Holiday evening 2-10-2024

10 Rosh-Hashana Holiday 3-10-2024

11 Rosh-Hashana Holiday 4-10-2024

12 Yom-Kippur Holiday evening 11-10-2024 Friday

13 Yom-Kippur Holiday 12-10-2024 Saturday

14 Sukkoth Holiday evening 16-10-2024

15 Sukkoth Holiday 17-10-2024

16 Simchat Torah Holiday evening 23-10-2024

17 Simchat Torah Holiday 24-10-2024

Figure 3-8: ToU Table 2010

3.3.2 Firmware

No: 3.3.2-1

Description: The legally relevant (=metrological) firmware shall be separated from the other

part(s) and cannot be upgraded.



Priority: REQUIRED

Fit criterion: The metrological (= legally relevant) firmware cannot be upgraded and has its own

version number and checksum. The version number of the metrological firmware is accessible via the display.

Evidence of

compliance:


No: 3.3.2-2

Description: Updates of legally non-relevant firmware shall not affect the operation of the E-meter or stored data.



Priority: REQUIRED

Fit criterion: The legally non-relevant part(s) of the firmware, including the firmware of the communication components, has the possibility to be updated. During an update, the execution of measurements by the metrological part is not impacted. Data

stored in the E-meter is not impacted by a firmware upgrade, nor does a firmware update result in configuration changes.

Evidence of

compliance:


4 TECHNICAL REQUIREMENTS FOR THE DATA CONCENTRATORS

Norms & Regulation Related Requirements

4.1.1 Climatic conditions

No: 4.1.1-1

Description: The DC shall withstand specified temperature ranges without damage or

degradation.

Component: DC


Priority: REQUIRED

Fit criterion: The DC will meet the following environmental characteristics, according to the criteria stated in IEC 60068-2-1 (cold), IEC 60068-2-2 (dry heat) and IEC 60068-2-14 (temperature variation):

Operating temperature range: -10ºC to 65ºC The test report gives an overview of the performed tests and the test results to

prove that the DC can withstand the specified temperature ranges without damage or degradation of all characteristics when subsequently operated under rated operating conditions.

Evidence of

compliance:

Test report or documented evidence from bidder or

Certificate / Test report + Declaration of conformity from external laboratory*: The bidder provides a test report for the tests specified in IEC 60068-2-1, IEC 60068-2-2, and IEC 60068-2-14.

* In this case, self-certification is allowed.

No: 4.1.1-2

Description: The DC shall withstand specified humidity ranges without damage or degradation.

Component: DC


Priority: REQUIRED

Fit criterion: The DC will meet the following environmental characteristics, according to the criteria stated in IEC 60068-2-78 (damp heat):

Humidity range: 5% to 95%. The DC is suited for the specified relative humidity conditions for operation under condensing humidity.

Evidence of

compliance:

Test report or documented evidence from bidder or Certificate / Test report + Declaration of conformity from external laboratory*: The bidder provides a test report for the tests specified in IEC 60068-2-78. * In this case, self-certification is allowed.

4.1.2 Durability & Reliability

No: 4.1.2-1

Description: The DC shall meet the requirements for lifespan expectancy.

Component: DC


Priority: REQUIRED

Fit criterion: The expected minimum lifetime of the DC is at least 15 years, starting at the installation date, and under the climatic conditions indicated in this document.

The lifespan is applicable to the entire DC including, but not limited, to communication units and additional functionalities. Special care needs to be taken for components that easily lose performance due to ageing. For instance, backup power supply.

Evidence of

compliance:

Test report or documented evidence from bidder, or Certificate / Test report +

Declaration of conformity from external laboratory. The bidder provides a report which includes reliability predictions and estimation of the product lifetime in such a detail that ensure that predictions methods are clearly reported, and they justify accordingly the stated values.

4.1.3 Safety

No: 4.1.3-1

Description: The DC shall be marked in accordance to relevant Israeli

Parliament/Council/Commission Decisions, Directives, and Regulations.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall be marked in accordance to relevant Israeli Parliament/Council/Commission Decisions, Directives, and Regulations, related to low voltage electrical equipment.

Evidence of

compliance:

Certificate / Test report + Declaration of conformity from external laboratory.

The bidder provides relevant declaration of conformity for the DC offered.

No: 4.1.3-2

Description: The DC shall provide the specified protection degree against water and dust.

Component: DC


Priority: REQUIRED

Fit criterion: Protection degree provided by DC enclosures against water and dust will be at least IP51 per IEC 60529.

Evidence of

compliance:


4.1.4 Electromagnetic Compatibility

No: 4.1.4-1

Description: The DC shall comply to electromagnetic compatibility (EMC) norms.

Components: DC


Priority: REQUIRED

Fit criterion: The DC will meet at least the electromagnetic compatibility (EMC) criteria stated in:

IEC 61000-4-2 (electrostatic discharge): 15 kV IEC 61000-4-3, (radiated, radiofrequency and electromagnetic field): 10

V/m and 30 V/m IEC 61000-4-4, (electrical fast transient/burst): 4 kV IEC 61000-4-5, (surge immunity test): 4 kV, 50 Hz

IEC 61000-4-6, (conducted disturbances)

IEC 61000-4-13 (harmonics and interharmonics including mains signalling at a.c. power port, low frequency)

Evidence of

compliance:

Test report or documented evidence from bidder or Certificate / Test report + Declaration of conformity from external laboratory.

The bidder provides a documented test report. The test report gives an overview of the performed tests and the test results to prove that the meter is compliance with the above-specified immunity.

No: 4.1.4-2

Description: The DC shall meet the requirements for radio electric disturbance.

Components: DC


Priority: REQUIRED

Fit criterion: The DC (the device but also the communications) shall meet the requirements for radio electric disturbance (emission) according to the criteria stated in EN 55022.

Evidence of

compliance:

Test report or documented evidence from bidder or Certificate / Test report + Declaration of conformity from external laboratory: The bidder provides a documented test report from an Accredited Laboratory. The test report gives an overview of the performed tests and the test results to prove

that the meter is compliance with the specified radio electric disturbance characteristics.

Hardware Requirements

4.2.1 Electrical Ratings

No: 4.2.1-1

Description: The DC shall comply to defined electrical ratings.

Component: DC


Priority: REQUIRED

Fit criterion: The electrical ratings for the DC are as follows:

Reference voltage Un: 230V/400V Maximum consumption Pmax: 10W (peak power consumed by the DC when

it is in operation and transmitting information in the worst case) Reference frequency: 50Hz Number of wires: 2 (any phase and neutral) or 4 (3 phases and neutral)

Evidence of

compliance:


4.2.2 Casing

No: 4.2.2-1

Description: The maximum dimensions of the casing of the DC shall not exceed specific

dimensions.

Component: DC


Priority: PREFERRED

Fit criterion: The maximum dimensions for DC casing are:

Height: 290 mm

Width: 210 mm

Depth: 130 mm

Evidence of

compliance:


4.2.3 Seals

No: 4.2.3-1

Description: The seals applied on the DC shall prevent intruding into the DC and tampering.

Component: DC


Priority: REQUIRED

Fit criterion: The DC is protected by seals in order to prevent intruding into the DC and tampering with the DC without removing the seals or damaging the DC casing. All separate covers are protected by separate seals, for example the:

DC cover Terminal cover

Evidence of

compliance:


4.2.4 Markings

No: 4.2.4-1

Description: The DC shall be labelled with the specified information.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall be labelled with at least the following information:

Manufacturer Complete model identifier

Electrical Characteristics: power supply voltage, maximum current consumed, transceiver type, etc.

Year / Month manufacturing MAC Address Barcode with IECo Serial Number ‘Property of IECo’ or IECo logo

IECo Purchase Order number

Evidence of

compliance:


No: 4.2.4-2

Description: DC markings shall be durable.

Component: DC


Priority: REQUIRED

Fit criterion: The bidder provides proof of durability of the DC markings based upon the test described in IEC 62052-31 (section 5.2.2).

Evidence of

compliance:

Compliance with this specification is verified by evaluation of a sample. / Test report or documented evidence from bidder.

No: 4.2.4-3

Description: The markings on the DC shall be compliant with international standards.

Component: DC


Priority: REQUIRED

Fit criterion: The marking on the DC shall be compliant IEC 62052-31 (section 5).

All characteristics that have a standard symbol defined in IEC 62053-52 are marked accordingly. In case of PLC communication there shall be the G3-PLC logo The markings are logically grouped on the front side of the DC so that they can easily be read when the DC is installed in a DC cabinet.

Evidence of

compliance:


4.2.5 Power supply

No: 4.2.5-1

Description: The DC shall be fully operational when connected to any one phase.

Component: DC


Priority: REQUIRED

Fit criterion: The DC is operational when connected between any line and the neutral line.

Evidence of

compliance:


4.2.6 Real Time Clock

No: 4.2.6-1

Description: The DC shall implement a RTC according to the defined clock requirements.

Component: DC


Priority: REQUIRED

Fit criterion: DC device must have a real-time clock (RTC).

Back-up solution (only through battery) to guarantee operation of the clock and

calendar in the event that main power is lost for at least 1 week for the lifetime of

the DC.

Battery for RTC and calendar that shall be operational for 15 years from which 2

years of storage.

Evidence of

compliance:

Test report or documented evidence from bidder. / Compliance with this specification is verified by evaluation of a sample.

4.2.7 Memory

No: 4.2.7-1

Description: When the DC is not powered, the data in the DC related to its own configuration as well as meter related data shall stay in non-volatile memory for a minimum specified period.

Component: DC


Priority: REQUIRED

Fit criterion: When powered up again after a power down, the DC must become operational with no loss of data or configuration settings. The DC complies with the minimum retention time of 4 months for meter related

data as well as configuration data.

The DC shall implement sufficient memory to store the required billing and load profile data for at least 250 meters.

Evidence of

compliance:


4.2.8 Connection & Communication

No: 4.2.8-1

Description: The DC shall comply to defined meter connection & communication requirements.

Component: DC


Priority: REQUIRED

Fit criterion: Each DC shall be able to support communication with at least 250 meters.

Each DC shall be able to communicate with first meter distant at least 150 m

without peripheral equipment (such as repeater, amplifier). Filters are not

considered as peripheral equipment.

DC with integrated CT are not accepted.

Evidence of

compliance:


No: 4.2.8-2

Description: DC communication with external firewall

Component: DC


Priority: REQUIRED

Fit criterion: Together with the DC a local external firewall (provided by IECo) will be installed in

close proximity with the DC.

The connection and communication between the DC and external firewall shall apply

the “plug-and-play” principle, i.e. an ethernet connection is established between the

DC and external firewall and the DC will have a network connection and be

reacheable by the HES.

Evidence of

compliance:


Functional/Software Requirements

4.3.1 Data exchange & data model

No: 4.3.1-1

Description: For configuration and data exchange with the E-meters, the DC shall support the defined E-meter data model.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall be compatible with the E-meter data model defined in the “Annexure B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification”. The DC shall be able to read/write E-meter data according to the access rights as

defined by the E-meter data model in the mentioned IECo’s specification. Any action that can be done locally on the meter shall also be possible to perform via the DC.

Evidence of

compliance:


No: 4.3.1-2

Description: Implemented DC-HES communication interface solution shall be made available to IECo.

Component: DC


Priority: REQUIRED

Fit criterion: The bidder will provide comprehensive information about the DC-HES communication interface solution implemented on the side of the DC. This information will include, at least but not limited to:

Supported communication protocols/services

Description of supported functionality (e.g. DC/meter events logging and reporting, monitoring and network management, remote DC/meter firmware update, profile meter readings reporting, etc.)

All this information will be made available for IECo.

Evidence of

compliance:


No: 4.3.1-3

Description: DC shall respond and send data to HES/MDMS on-demand or periodically according to configurable schedule.

Component: DC


Priority: REQUIRED

Fit criterion: DC will respond and send data to HES/MDMS per configurable scheduled requests or direct requests from the HES/MDMS. There shall be a pull and a push mechanism between the DC and the HES.

Evidence of

compliance:


No: 4.3.1-4

Description: DC shall be able to perform meter readings/operations on-demand and per

scheduled request.

Component: DC


Priority: REQUIRED

Fit criterion: DC shall be able to perform on-demand meter readings/operations for all its

dependent E-meters (broadcast, multicast or for a specific selected meter).

DC shall be configurable for scheduled request that will be periodically executed for

meter reading/operation purposes. At least the following parameters shall be

configurable inside the request:

Periodicity (in seconds, minutes, hour, day, month, and year)

Start and end date

Group of meters to execute the request

Priority

Information to read

Evidence of

compliance:


No: 4.3.1-5

Description: DC shall implement a robust mechanism against power/communication failure for meter data exchange (reading/writing).

Component: DC


Priority: REQUIRED

Fit criterion: In case of power/communication failure when DC is exchanging data with meters

and/or HES/MDMS, the DC shall implement robust mechanisms to ensure that:

Meter configuration is uncorrupted

Meter database in the DC is uncorrupted and comprehensive

Information reported to the HES/MDMS is uncorrupted and comprehensive

These mechanisms can be based on meter reading/writing retries, management of

gaps of information in the DC database, etc.

Evidence of

compliance:


No: 4.3.1-6

Description: DC shall never alter the data from the meter.

Component: DC


Priority: REQUIRED

Fit criterion: The DC will never under any circumstances alter the data from the meter.

In case of corrupted or uncompleted data, there will be a retry mechanism. If

unsuccessful there should be a notification.

Evidence of

compliance:


4.3.2 Monitoring and Network Management

No: 4.3.2-1

Description: The DC shall support Automatic Meter Registration (Plug & Play mechanism).

Component: DC


Priority: REQUIRED

Fit criterion: DC shall automatically discover meters on installation (when a new meter is

physically installed and connected to the communication network).

In this sense, DC shall keep updated HES/MDMS.

The DC shall provide the status of the keys & communication.

Evidence of

compliance:


No: 4.3.2-2

Description: DC will be identified unambiguously by the HES/MDMS.

Component: DC


Priority: REQUIRED

Fit criterion: DC shall allow to be managed by HES/MDMS, as a unique device identified by a

unique DC identifier parameter.

Evidence of

compliance:


No: 4.3.2-3

Description: The DC shall be able to automatically detect the network topology.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall be able to automatically detect the network topology, including

repeaters. The DC shall be able to detect number of communication switching

(transmit/receive) with a specific meter. Any change in network topology scheme

will be detected and reported for the users in order to analyse the problematics

points in the network.

Evidence of

compliance:


No: 4.3.2-4

Description: The DC shall provide some statistics about communication quality.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall provide some statistics about communication quality, at least but not

limited to:

Size of transmitted/received data chunks

Lost data

Communication between DC and meters (e.g. latency time between DC and

meters, total number of readable meters in terms of communication, etc.)

Communication between DC and HES

The statistics should be able to be exported for reporting purposes and

available to the HES.

Evidence of

compliance:


4.3.3 Synchronization

No: 4.3.3-1

Description: The DC shall allow to be synchronized by the HES.

Component: DC


Priority: REQUIRED

Fit criterion: The data-time of the DC will allow to be synchronized on-demand or per scheduled

request from HES.

Evidence of

compliance:


No: 4.3.3-2

Description: The DC shall be able to synchronize all its dependent meters.

Component: DC


Priority: REQUIRED

Fit criterion: The DC will be able to synchronize all dependent meters once per day per scheduled

request, on-demand and manually by accessing local web client in the DC.

Evidence of

compliance:


No: 4.3.3-3

Description: The DC shall handle daylight savings time.

Component: DC


Priority: REQUIRED

Fit criterion: The DC autonomously switches to daylight savings time according to Israeli law:

DST Entry: the Friday before the last Sunday of March DST Exit: the last Sunday of October

Or: The DST can be (locally) configured via a table for at least 4 years ahead. The DST definition shall have a unique ID.

Evidence of

compliance:


4.3.4 Firmware

No: 4.3.4-1

Description: DC shall support robust remote and local firmware upgrade.

Component: DC


Priority: REQUIRED

Fit criterion: DC shall support remote firmware upgrade. Firmware transmission shall be initiated

by the HES/MDMS.

DC shall support also local firmware upgrade, by direct connection.

Firmware updates for DC shall be robust to power and communication failures. In

case of power/communication failure during DC firmware upgrade process, the DC

will ensure that its firmware version remains uncorrupted (keeping the existing one

and/or trying to start/continue with the DC firmware upgrade process when

communication is restored).

Evidence of

compliance:


No: 4.3.4-2

Description: DC shall support robust remote meter firmware upgrade.

Component: DC


Priority: REQUIRED

Fit criterion: DC shall be capable to perform remote meter firmware upgrade, for a single meter

or for multiple meters via multicast or broadcast request.

DC shall implement a robust mechanism against power/communication failure for

the meter firmware upgrade. The mechanism shall allow that the meter firmware

upgrade process is restarted/continued when communication is restored or aborted

in case of reiterative communication problems.

Evidence of

compliance:


5 TECHNICAL REQUIREMENTS FOR THE HEAD-END-SYSTEM

The HES interfaces with the E-meters (PLMN) and the DC’s to execute the system use cases as described

in section 2.4.

General Requirements

No: 5.1-1

Description: The HES shall implement a GUI to support an actual view on the status of the AMI system.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall implement a GUI to support management and viewing on the status

of the AMI system. It includes at least: smart meter information, data concentrators information network information such as topology and communication status.

All the operations and actions will be done directly through the MDM, further details can be found in the integration section.

Details on this requirement will be aligned between Contractor and Contracting Entity.

Evidence of

compliance:


No: 5.1-2

Description: The HES shall implement a web-based GUI.

Component: HES


Priority: PREFERRED

Fit criterion: The HES shall implement a web-based GUI to support management and viewing on the status of the AMI system.

Web-based GUI is accessible via standard browser. Details on this requirement will be aligned between Contractor and Contracting Entity.

No specific tooling needs to be installed on client’s PC.

Evidence of

compliance:


No: 5.1-3

Description: For configuration and data exchange with the E-meters, the HES shall support the defined E-meter data model.

Component: DC


Priority: REQUIRED

Fit criterion: The HES shall be compatible with the E-meter data model defined in the “Annexure

B2 - MOACH DLMS COSEM Profile for communication interfaces companion specification”. The HES shall be able to read/write E-meter data according to the access rights as

defined by the E-meter data model in the mentioned IECo’s specification. Any action that can be done locally on the meter shall also be possible to perform

via the HES.

Evidence of

compliance:


No: 5.1-4

Description: HES shall be able to acquire meter data automatically (scheduled) and on-demand.

Component: HES


Priority: REQUIRED

Fit criterion: HES shall be able to acquire E-meter data automatically (scheduled).

Additionally, it shall be possible to perform on-demand E-meter data requests

triggered by the HES.

The E-meter data collected by the HES will be processed by the MDMS, according to

the business processes and use cases stated in sections 2.3 and 2.4.

Evidence of

compliance:


No: 5.1-5

Description: HES shall never alter the data from the meter.

Component: HES


Priority: REQUIRED

Fit criterion: The HES will never, under any circumstances, alter the data from the meter.

Evidence of

compliance:


No: 5.1-6

Description: HES shall support roll-out and Operations & Maintenance (O&M) activities

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall comply with the following requirements in terms of roll-out and O&M activities:

Support project rollout (meter/DC installation, removal, and replacement).

Network and smart meter field operations and maintenance.

The HES shall support a meter population of minimally 4.2 million meters in

a single region.

The O&M activities are done via the MDM

Evidence of

compliance:


No: 5.1-7

Description: The HES shall support specified functionalities regarding:

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall support the following minimum functionalities:

Provide communications and data collection reliability indices (KPIs) to allow for monitoring capabilities.

Ability to manage several communications channels for each smart meter/DC.

Support MDMS in communication network diagnostics and management (communication network topology, equipment, etc.).

Allow for remote connect (with manual assistance)/disconnect of smart

meters. Meter data reading management (configures scheduled readings, processes

readings, performs on-demand readings, etc.) for single, grouped, and arbitrary sets of meters.

Remote firmware upgrades/downgrades/management for individual or groups of meter/DC.

Reception of meter/DC events and alarms. Ability to remotely configure and validate meter/DC configuration.

Evidence of

compliance:


HES Integration Requirements

The AMI solution shall integrate in the IT landscape. In the Contracting Entity’s IT environment, systems

exchange data via an Enterprise System Bus. The AMI solution interfaces with the ESB at the HES.

No: 5.2-1

Description: The contractor shall provide all necessary software applications needed to fully operate the AMI system.

Component: HES


Priority: REQUIRED

Fit criterion: The contractor shall provide all necessary software applications needed to fully

operate the AMI system, such as but not limited to: HES related software. Troubleshooting tools. Configuration tools for field devices. Software applications for authentication of field devices. Monitoring dashboards

Evidence of

compliance:


The bidder shall provide a list of software applications that will be delivered in the

AMI project.

No: 5.2-2

Description: The HES shall be supplied as a fully operational software solution and shall be integrated on the existing virtualized hardware infrastructure of the contracting entity.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall be installed on the existing virtualized hardware infrastructure (server park) of the contracting entity.

Regarding operating systems: The software shall run on either: RedHat Enterprise Linux

Windows Server (Version that still receives active support from Microsoft)

Regarding DBMS: Oracle databases are used.

Evidence of

compliance:


No: 5.2-3

Description: The AMI system shall be integrated in the contracting entities IT landscape via a

webservice interface on the HES.

Component: HES


Priority: REQUIRED

Fit criterion: The bidder shall offer a web services interface to integrate the AMI system into the

contracting entities IT landscape.

The web services shall provide the interface for other systems to interact with the

HES. From the ESB perspective, the web service interface of the HES is the entry

point to the AMI system.

The solution shall comply to the MDMS web services to interact with the MDMS.

The web service interface shall facilitate the AMI use cases as described in section 0.

The contractor aligns with the provider of the MDMS on the design and details of the

web services and the interface with the ESB.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder shall describe its

approach to this integration.

6 MASS PRODUCTION REQUIREMENTS

General

No: 6.1-1

Description: The E-meter shall meet the quality requirements for mass production.



Priority: REQUIRED

Fit criterion: The contractor/bidder shall have an internal system in order to be able to trace

components that are included in the construction of an E-meter device. If

subcontractors are used for E-meters, this requirement also applies to them. The

contractor/bidder shall describe its tracing system.

The contractor/bidder shall describe how it ensures that the E-meters are of such a

quality that they are not disapproved when controlled by IECo or any other third

party authorized by IECo.

IECo experts may ask to visit the contractor/bidder's plant at the technical

evaluation stage or later: i.e. an IECo representative, at IECo sole discretion, may

visit and inspect the active production line being used to manufacture and assemble

the meters in order to assure the suitability and compatibility of the new (or

renewed) meter deliveries with all the requirements of this specification at any stage

of the contract.

Evidence of

compliance:

Test report or documented evidence from bidder:

The bidder provides a document describing its internal quality system to trace

components and E-meter production. Periodical audits/verification processes may be

performed by IECo or by a third party authorized by IECo after signing of contract.

No: 6.1-2

Description: Meter manufacturer and integrator shall propose certain Design For Testability (DFT)

technology.



Priority: REQUIRED

Fit criterion: It is mandatory to implement some DFT technology (as considered by industry and

the scientific community). Technology encompasses: meter hardware, firmware, and

test bench nail bed software.

E-meter must be provided with a declaration indicating the number of electronic

components covered by the DFT technology.

The manufacturer must specify which DFT technology is used, and what its

functional coverage (percentage) of logic and analoge signals scenarios.

Evidence of

compliance:


The bidder provides a document declaring and describing how DFT technology

requirements specified by IECo are fulfilled and which technology from which

company is used.

No: 6.1-3

Description: Proposed DFT technology will be evaluated by IECo and scored accordingly.



Priority: PREFERRED

Fit criterion: IECo will use known estimations for various DFT technologies to evaluate and

validate the provided information, such as:

ICT/FCT (e.g. SPEA technology);

JTAG boundary scan;

ATPG, SDD, path delay;

Memory redundancy repair process;

Power domain blocks.

IECo may evaluate other standard DFT methods not included in the previous list. To

that aim, bidder will provide all needed information to detail its DFT technology

implementation.

Evidence of

compliance:


The bidder provides a document declaring and describing how DFT technology

requirements specified by IECo are fulfilled.

HASS/Aging Test

No: 6.2-1

Description: The mass production of E-meters will be optionally subjected to HASS testing

procedures.



Priority: PREFERRED

Fit criterion: IECo does not require to perform HASS testing compulsorily; however, the

contractor/bidder that includes HASS testing as part of its offer will obtain higher

scoring.

When a batch of particular meter types from particular production line is submitted

to IECo for the first time, a sample of 100 meters from that batch shall be subjected

to HASS testing.

HASS can be performed either at contractor/bidder's premises or at a third-party

laboratory authorized by IECo.

Details about the scope of the required HASS tests are exhibited in Appendix E.

If more than one meter failed during the required HASS testing, contractor/bidder

must perform Root cause analysis and suggest corrective actions for IECo approval.

After the corrective actions are approved and implemented the HASS test must be

successfully repeated.

Evidence of

compliance:


The bidder provides a document describing HASS testing procedures that will be

followed for each item related to: thermal cycling tests, vibration, and free fall tests,

requested by IECo. The bidder provides a declaration of conformity based on full

quality assurance, whereby he undertakes to fully comply with the obligations laid

down by the requirements stated by IECo. Periodical audits/verification processes

may be performed by IECo or by a third party authorized by IECo after signing of

contract.

No: 6.2-2

Description: The mass production of E-meters shall be subjected to mandatory routine Aging

Test when no HASS testing is implemented.



Priority: REQUIRED

Fit criterion: In the event that the bidder does not provide evidence of compliance for the

required HASS testing (check requirement no. 6.2-1) when a batch of a particular

type of meters from a particular production line is submitted to IECo for the first

time, and also during subsequent mass production specified aging tests (accelerated

life tests) shall be performed mandatorily as a minimum requirement.

In this case, 100% of meters of each delivery must undergo aging test before final

factory verification tests, under the following conditions: powered 3x230V L-N,

during 8 hours at least, at extended temperatures (at highest rated operating

temperature at least) in order to demonstrate its reliability and long service life. The

test shall be carried out per IEC 62059-41 methodology (check requirement 3.1.3-

1).

Evidence of

compliance:


The bidder provides a document describing aging test procedures that will be

followed for every E-meter delivered to IECo. The bidder provides a declaration of

conformity based on full quality assurance, whereby he undertakes to fully comply

with the obligations laid down by the requirements stated by IECo. Periodical

audits/verification processes may be performed by IECo or by a third party

authorized by IECo after signing of contract.

Final Factory Verification Tests before shipping

No: 6.3-1

Description: The mass production of E-meters shall be subjected to Final Factory Verification

Tests.



Priority: REQUIRED

Fit criterion: Accuracy, AC voltage and functionality tests results including initial calibration data

of each shipped meter shall be sent to the Meter Test Station Department of IECo

prior to each shipment, for purpose of metrology normalcy.

The manufacturer must state whether accuracy test is performed on the meters with

closed or open voltage links. If the meters are calibrated with open voltage links,

quality control routine must be implemented to ensure correct meter functionality

after their sealing (closed links).

Metrology report required format including required test points are exhibited in

Appendix I.

The results of tests that are performed on samples at the manufacturer plant for

Manufacturer's quality inspection purposes shall also be provided in the same

format.

Evidence of

compliance:


The bidder provides a document describing Final Factory Verification Test procedures

that will be followed for mass E-meter production. The bidder provides a declaration

of conformity based on full quality assurance, whereby he undertakes to fully

comply with the obligations laid down by the requirements stated by IECo. Periodical

audits/verification processes may be performed by IECo or by a third party

authorized by IECo after signing of contract.

Packaging requirements

No: 6.4-1

Description: The shipment of E-meters shall be subjected to a set of packaging requirements

stated by IECo.



Priority: REQUIRED

Fit criterion: General packaging conditions, including primary and secondary packaging

requirements, shipment documentation and handling of DDP goods, which are

exhibited in Appendix D, shall be implemented for the shipment of E-meters.

Evidence of

compliance:


The bidder provides a declaration of conformity based on full quality assurance,

whereby he undertakes to fully comply with the obligations laid down by the

requirements stated by IECo. Periodical audits/verification processes may be


Series Production and Acceptance Test

No: 6.5-1

Description: E-meters shall be manufactured and calibrated in homogeneous production series

and supplied in batches.



Priority: REQUIRED

Fit criterion: The batches on appropriate pallets will be grouped for shipping in standard

containers, trucks, or other simultaneously shipped aggregate platforms. An

inspection shall follow the “serial quality” approach regarding units of such

containers or trucks.

Evidence of

compliance:






No: 6.5-2

Description: E-meters must be manufactured under ISO 9001(2015) over a whole contract

period.



Priority: REQUIRED

Fit criterion: Valid ISO 9001(2015) approval certificate issued by a Certification Body (CB) which

is a qualified by an Accreditation Body (AB) must be available at any stage of the

contract.

Evidence of

compliance:






No: 6.5-3

Description: Acceptance lot-by-lot inspection shall be performed at IECo premises.



Priority: REQUIRED

Fit criterion: Acceptance lot-by-lot inspection by attributes will be performed at the Meter Test

Station (IECo premises) according to IEC62058-11, ISO2859-1 and IEC62058-31.

Lot for the acceptance inspection will be defined as cumulative quantity of batches

that have been delivered to IECo Metering Unit premises within one container or

truck. Alternatively, IECo may define a lot at its sole discretion.

Inspection level II will be used. Single sampling plan for normal inspection, AQL=1

will be used regarding non-critical nonconformities (as per table 4 in IEC62058-31).

For critical nonconformities (as per Table 4 in IEC62058-31), single sampling plan

for normal inspection with acceptance number 0 will be used.

If lot will be rejected next lots will be tested according to Double sampling plan for

normal inspection.

Other meter's attributes may be tested for conformity. Failures in these tests will be

considered as non-critical nonconformities.

Regarding nonconforming meters, applicable procedures are given by IEC62058-11

and shall be continued by the following measures. In case of rejection the whole lot

will be replaced by reshipping, or arresting on the place with 100% revision before

presenting for re-inspection. The Contractor will be responsible for bearing all

associated costs. The Contractor will be notified by phone/e-mail. Rejection of 5 or

more lots upon the same order delivery will be considered as Contractor’s failure,

and will lead to legal action.

The results of the acceptance tests will be reported to the IECo Import Department

that will notify the manufacturer about the acceptance tests failure.

The nonconforming meters within a lot in quantities, which are still within

acceptance criteria, will be subject to replacement if claimed by the Purchaser.

In order to prevent any holdback in IECo to install newly purchased meters due to

rejected lots, the Manufacturer will be obligated to expedite extra deliveries, above

and beyond the agreed timetable.

If 3 or more meters delivered according to the same order are found with a same

failure caused by production failure, or wrong meter construction, or component

failure, which affects normal operation of the meter, the failure will be considered as

"serial failure" and will lead to legal action. The same approach is to any field failure

of rate ≥ 0.5% of total field installed meter. Along with the legal actions, in case of

"serial failure" the winning Bidder is requested to provide:

Root cause analysis submission to IECo within 30 days

Uninstallation of entire meter population of the problematic batches and

replacement.

The winning Bidder is required to inform IECo regarding similar to the provided to

IECo meters' failures at other customers.

Evidence of

compliance:






No: 6.5-4

Description: During the life cycle of the meters IECo may conduct periodical Type Test

procedures.



Priority: REQUIRED

Fit criterion: During the life cycle of the meters IECo may conduct from time to time and at its

sole discretion number of tests detailed in IEC 62052 series for Type Test (mainly

IEC 62052-11, IEC 62052-21 and IEC 62052-31), in order to ascertain the stability

of the meter metrology characteristics. If the meters fail to comply with the test

requirements, the manufacturer will assume responsibility.

IECo representative, at IECo sole discretion, may visit and inspect the active

production line being used to manufacture and assemble the meters in order to

assure the suitability and compatibility of the new meter deliveries with all the

requirements of this specification at any stage of the contract.

Evidence of

compliance:






No: 6.5-5

Description: The awarded bidder must send to IECo the meters, DC, CTs, Filters, FW ( if

applicable ), analysing PLC tool as preliminary (preproduction) series for a

Conformity of Compliance agree to time table.

Component: Meter [1Ph, 3Ph, CT, PLMN, PLC] , DC , CTs , Filter , FW ( if applicable ), analysing

PLC tool.


Priority: REQUIRED

Fit criterion: The awarded bidder must send following IECo order:

20 meters for each type,

10 DCs for each type ,

5 CTs for each type,

6 Filters for each type, 10 FWs ( if applicable ),

1 analyzing PLC tool

as first preliminary (preproduction) series for a Conformity of Compliance according to accepted time table.

The equipment described above must be in its final version, manufactured or

assembled in the same plant where the remaining equipment will be produced, tested with the same equipment that will be used in the course of manufacturing, and packed in the same form that the future goods will be supplied.

The smart metering equipment (described above) delivery must be accompanied by the data reading software, and the files described in sections 2.2.1-4, 2.2.2-2, D.2, C.3

After approval of first preliminary (preproduction) series the awarded bidder must send to the IECo the smart metering equipment as second preliminary (preproduction) series, for end-to-end testing of the smart metering equipment with the AMI system of the awarded bidder. This time by quantity of:

2 full pallets of poly-phase meters for each type. 1 full pallet of single-phase meters for each type. 10 DCs for each type , 1 full pallet of CTs for each type,

5 Filters for each type, 10 FWs ( if applicable ).

100% inspection will be applied to these batches.

If the goods and the packing of the preliminary series are found to be in full compliance with IECo requirements they will be approved by IECo, and issue of further withdrawal orders will be permitted.

Evidence of

compliance:

The bidder declares that he has understood this requirement, and agrees to comply with this requirement.

7 FAILURE MANAGEMENT REQUIREMENTS FOR METERS IN OPERATION

No: 7-1

Description: IEC TR 62059-21 shall be considered for the definition of the criticality of failures

and standard classifications of failures to functional modules.



Priority: REQUIRED

Fit criterion: IEC TR 62059-21 shall be considered when implementing methods for the collection

and analysis of field failure data of smart meters using field failure reports and

sampling plans.

Definition of criticality of failures shall be according to Table 6 included in IEC TR

62059-21. Definition of standard classifications of failures to functional modules

shall be according to Table 4 included in IEC TR 62059-21.

Evidence of

compliance:




requirements stated by IECo.

No: 7-2

Description: Failure correctness procedures specified by IECo shall be implemented.



Priority: REQUIRED

Fit criterion: Final decision about failure correctness will be taken by IECo.

Integrator may reject a failure as "not a problem" only once. Final decision will be

taken by an IECo expert user in the specific technical issue. A failure cannot be

rejected more than once.

Failures shall be managed through Quality Center defect tracking system from

micro-focus.

Evidence of

compliance:





No: 7-3

Description: Service Level Agreement between IECo and integrator shall be established

complying with IECo requirements.



Priority: REQUIRED

Fit criterion: For smart meters some standard failures apply for meter failures (hardware,

firmware and software tools). There are defined failures for the ‘infancy stage’ and

for the ‘mature stage’. The ‘infancy stage’ will comprise failures that arise during the

first 1,5 years from installation. ‘Mature stage’ will continue after ‘infancy’ stage. On

the other hand, there are failures that exist in 100% of meters and failures existing

only in a small number of meters and evolving over time.

The Service Level Agreement between IECo and integrator shall comply to what it is

indicated in Table 7-1.

Evidence of

compliance:





Table 7-1: Standard failure management requirements per IECo

No Standard failure criticality (IECo

terminology)

% of meters installed or at

storage

Perform Root-Cause Analysis

or replace meter

Response time (work hours)

Resolution time

(work days)

Infancy stage (≤1,5 years from installation)

1 Critical firmware/software failure (critical)

≥ 0.5 ≤ 0.5

RCA Fix

24 5

2 Critical hardware

failure (critical)

≥ 0.5 ≤ 0.5

RCA

And replace meter

24 10 or extend

with IECo approval only

3 Major failure (high)

≥ 0.5

≤ 0.5

Hardware: RCA and replace

meter

Replace meter Software: Always RCA and fix

24 5 IECo may

postpone schedule

4 Minor failure

(medium) *

≥ 0.5 ≤ 0.5

Hardware:

No RCA replace

24 45

5 Minor failure (low) *

≥ 0.5 ≤ 0.5

Hardware: No RCA

24 45

IECo may postpone

schedule

Mature stage (>1,5 years from installation)

1 Critical

firmware/software failure (critical)

≥ 0.5 ≤ 0.5

RCA

Fix

24 10

2 Critical hardware failure

(critical)

≥ 0.5 ≤ 0.5

RCA And replace

meter

24 15 or extend with IECo

approval only

3 Major failure (high)

≥ 0.5

≤ 0.5

Hardware: RCA and replace meter

Replace meter

Software: always RCA and fix

24 10 IECo may postpone

schedule

4 Minor failure

(medium) *

≥ 0.5 ≤ 0.5

Hardware:

No RCA replace

24 45

5 Minor failure (low) *

≥ 0.5 ≤ 0.5

Hardware: No RCA

24 45 IECo may postpone schedule

* Notice that IEC TR 62059-21 does not include ‘medium’ and ‘low’ classification, they are stated as ‘minor’.

8 TECHNICAL REQUIREMENTS FOR PORTABLE TEST PC AND DIAGNOSTIC TOOLS

No: 8-1

Description: Minimal technical (physical) specifications for portable PC for laboratory for meters/DC configuration

Component: Portable PC


Priority: REQUIRED

Fit criterion: The bidder shall provide two (2) laptops that meets, at least, the following

requirements: Recent CPU (i.e. Intel core i5 or later) Minimum screen size 15.6 inch 8 GB RAM or more 500 GB SSD or more USB-ports: at least 2x USB3.0 Integrated Bluetooth

Integrated LAN-card Integrated WiFi-card Graphic Card: either Intel or Nvidia GeForce

The laptop shall be a ruggedized model.

Evidence of

compliance:

The tender agrees to comply to this requirement and is able to deliver such laptops

No: 8-2

Description: Portable PC – Operating System



Priority: REQUIRED

Fit criterion: The portable PC shall come pre-installed with a recent Windows (64 bit) version still receiving official support from Microsoft. The portable PC shall include installed and activated MS Office package.

Evidence of

compliance:

The tender agrees to comply to this requirement and is able to deliver such laptops

No: 8-3

Description: Portable PC – Warranty



Priority: REQUIRED

Fit criterion: The warranty for the laptops shall be provided by a company located in Israel.

Evidence of

compliance:

The tender agrees to comply to this requirement.

No: 8-4

Description: Additional software and software licences



Priority: REQUIRED

Fit criterion: The laptops shall be pre-installed with all software tools to:

Locally configure the meters Locally configure the DCs Troubleshooting software for meters and DCs Troubleshooting software for diagnosing the PLC

All software licences (from the bidder and potential subcontractors) should be for unlimited time duration

Evidence of

compliance:

The tender agrees to comply to this requirement.

No: 8-5

Description: Test equipment for testing and diagnosing of PLC



Priority: REQUIRED

Fit criterion: Features of remote diagnostics that shall be suitable for proposed PLC protocol.

Minimum required features: Signal-Power (dBm)

Signal-Noise-Ratio (SNR) Attenuation Power spectrum; differentiation of noise A local tool/facility for readout of data and log file Facility for local reconfiguration of the DC

Availability of GUI map/flowchart/diagram which shows the status of all meters connected to the DC

Evidence of

compliance:

The tender describes his solution in detail, and agrees to comply to this

requirement.

9 CYBER SECURITY REQUIREMENTS

AMI System Security Requirements

In this section, the security requirements on system level are described.

The security goals that the complete AMI infrastructure must meet, by introducing security measures

and controls in several areas of the AMI architecture are:

Security goal 1: It is a necessary requirement to receive information/data from authenticated field

devices (meters and DCs) in a confidentiality and integrity protected manner.

Security goal 2: Every component of the infrastructure should get messages only from

authenticated and authorized entities and processes.

Security goal 3: field devices (meters, DCs) have to be physical and software tempering protected

for example digital signed software, secure seal for physical tampering detection, etc.

The requirements formulated in this section 9.1 are applicable to all AMI components (meters, DC,

HES, ..), unless a requirement addresses a specific AMI component.

In his answers the bidder must be complete and provide an answer for each AMI system component

(unless the requirement is only about one AMI system component). For example requirement 9.1-15

asks about secure software development lifecycle practices. This requirement is applicable for the

development of the E-meter and DC firmware as well as for the HES software. The bidder should provide

an answer for all these components.

No: 9.1-1

Description: The contractor shall apply a process that guarantees secure key generation and

secure provisioning of initial keys into the field devices and the HES.

Component: AMI


Priority: REQUIRED

Fit criterion: Cryptographic key material is necessary for authentication of the field devices and to secure the communication (confidentiality and integrity protection of the communication) between the field devices and the HES.

The bidders shall have a secure environment in place where the initial security keys can be generated in a secure way.

The bidder shall have a secure way of provisioning these initial keys in the field devices.

The bidder shall have a process in place to securely exchange the initial security keys credentials to the grid operator and install these credentials in the HES. Store these keys in a secure way for HES function access.

The bidder describes how the initial keys can be securely imported and stored for HES function access. in the HES.

The bidder describes how the initial E-meter keys are exchanged between HES and DCs.

Evidence of

compliance:


The bidder shall describe how all initial cryptographic keys are generated in a secure way and provisioned into the field devices (E-meters and DCs) and the HES.

No: 9.1-2

Description: All initial master keys and working keys shall be unique per field device.

Component: AMI


Priority: REQUIRED

Fit criterion: All initial master keys and working keys shall be randomly generated (and stored)

per field device. This applies for keys that are used in supporting communication layers as well as

application layer.

Evidence of

compliance:


The bidder shall describe how security keys are generated and stored.

No: 9.1-3

Description: Key renewals shall be done in a secure way.

Component: AMI


Priority: REQUIRED

Fit criterion: It shall be possible to renew working keys for protecting data exchange between the system components. This shall be done in a secure way.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder provides information

on the key renewal process that is applied to renew the working keys in field

devices.

No: 9.1-4

Description: Crypto mechanisms and key management mechanisms shall be based on open standards or protocols.

Component: AMI


Priority: REQUIRED

Fit criterion: The used cryptographic algorithms and key management mechanisms shall be

publicly available and based on open STANDARDs, such as IEC 62056. The cryptographic algorithms and protocols as required in the “IECo DLMS COSEM Profile for communication interfaces. MOACH Smart Meters” shall be supported.

Evidence of

compliance:


The bidder shall provide a list of all implemented cryptographic algorithms and key management mechanism and indicate on which standards they are based.

No: 9.1-5

Description: All security requirements related to communication interfaces are active when the

field devices leave the factory (security by default).

Component: AMI


Priority: REQUIRED

Fit criterion: All AMI components shall have a default configuration (i.e. when they leave the factory) that enforces secure communication.

That is, all communication protocols supported on the AMI components shall be

configured in such a way that secure communication is guaranteed.

Evidence of

compliance:


The bidder describes the default communication configuration of AMI components and indicates how communication security is guaranteed.

Additionally, compliance with this specification is verified by evaluation of a sample

(for meters and DC).

No: 9.1-6

Description: Secure key export shall be possible for local troubleshooting on field devices

Component: AMI


Priority: REQUIRED

Fit criterion: For E-meter and DC troubleshooting, in the field or in an in-house lab environment,

expert tools will be used. For meter installation, and in some cases meter reading after installation, a hand-held unit (HHU) will be used. These tools will make a connection with the devices (E-meters and DCs). The tools must have the valid keys in order to be able to communicate with the devices. Therefore, it must be possible to securely provision these tools with the E-meter

keys and DC keys. The tools should protect the keys by reliable encryption method. To this end, it must be possible to extract the keys from the HES DB and securely

transport the keys to the tools. Exported keys should be marked in the HES DB as being exported and time period of export key validity. The bidder provides detailed information describing how dedicated tools (for installation, maintenance and troubleshooting) can be integrated with his HES so

that a secure provisioning of cryptographic keys to these tools is accomplished.

Evidence of

compliance:


No: 9.1-7

Description: The end-to-end security of the firmware, between the manufacturer(s) and its field components, shall be guaranteed.

Component: AMI


Priority: REQUIRED

Fit criterion: End-to-end security shall be provided for the firmware of the E-meters and the Data

concentrators. The bidder shall explain:

How he foresees to securely exchange new firmware with IECo. How the E-meters and DCs will verify the integrity and authenticity of the

new firmware.

Evidence of

compliance:

Test report or documented evidence from the bidder.

No: 9.1-8

Description: Secured versioning – All AMI firmware or software components shall have unique

version numbers.

Component: AMI


Priority: REQUIRED

Fit criterion: The bidder shall identify each firmware or software release with a unique version number for all AMI components during the lifecycle.

Evidence of

compliance:


The bidder shall describe the version number policy.

No: 9.1-9

Description: Password complexity for local accounts on each component in the system

Component: AMI


Priority: REQUIRED

Fit criterion: If passwords are used on a AMI component in the system, then the guidelines for strong passwords should be applied. This means:

Password must be six or more characters long.

Password must contain characters from three of the following four categories:

o Uppercase characters A-Z (Latin alphabet) o Lowercase characters a-z (Latin alphabet) o Digits 0-9

o Special characters (!, $, #, %, etc.)

Evidence of

compliance:


No: 9.1-10

Description: Hide passwords during typing

Component: AMI


Priority: REQUIRED

Fit criterion: 1. Password characters will be hidden on the screen as you type

2. Do not allow the user to enable the Show Passwords feature

Evidence of

compliance:

Technical documentation or documented evidence from the bidder.

No: 9.1-11

Description: Handling of default accounts

Component: AMI


Priority: REQUIRED

Fit criterion: The bidder must notify IECo of any default accounts present in any of the AMI

components.

For these default account is must be possible to either:

Disable or delete the default account or

Change the password of the default account (and optionally rename the

default account)

Evidence of

compliance:


No: 9.1- 21

Description: Secure communication between system components.

Component: AMI


Priority: REQUIRED

Fit criterion: If a system (like the HES) is implemented as a distributed system, it shall be possible that the sub-system components communicate in a secure way with each

other.

Evidence of

compliance:

Documented evidence from the bidder. The bidder describes how the sub-components of a system can securely communicate with each other.

No: 9.1-13

Description: Equipment/ Components from the project cannot be connected to the Internet

Component: AMI


Priority: REQUIRED

Fit criterion: At each stage of the project: development, testing, installation and maintenance No

component of the system will be connected to the Internet for any purpose

Evidence of

compliance:

Company policy, contract, and NDA agreement.

No: 9.1-14

Description: Configuration backup.

Component: AMI


Priority: REQUIRED

Fit criterion: For configuration files and rules - backup should be performed whenever a

significant change is made to them.

Evidence of

compliance:


No: 9.1-15

Description: Apply Secure Software Development lifecycle pratices.

Component: AMI, HES, DC, METERS [1Ph, 3Ph, CT, PLMN, PLC]


Priority: REQUIRED

Fit criterion: The bidder shall apply secure software development lifecycle practices which include

for example:

1. Compliance with secure development best practice

2. Compliance with secure development process based on company policies

3. Compliance with secure development STANDARDs (NIST SP800-160 V1, SP800-

37 Rev.2)

4. OWASP Top10

5. Code review execution: Static and Dynamic analysis

The manufacturers shall integrate security testing into the development life cycle (hardware and software testing). For each new firmware and software release, security testing and Code review

execution- Static and Dynamic shall be performed.

Evidence of

compliance:

Technical documentation, company policies and technical procedures, code review result reports.

No: 9.1-16

Description: Secure code development.

Component: AMI


Priority: REQUIRED

Fit criterion: 1. Do not allow hard-coded identification data in the application code

2. Do not allow hard-coded identification data in the configuration files of the

application

Evidence of

compliance:

Technical documentation or documented evidence from the bidder

No: 9.1-17

Description: Vulnerability assessment and management process

Component: AMI


Priority: REQUIRED

Fit criterion: 1. The vendor should perform vulnerability assessment/tests on software

components periodically according to NERC CIP-010-03 or similar best

practices

2. The relevant manufacturer/vendor shall notify IECo about any vulnerabilities

found immediately.

3. Patching the vulnerabilities will be in accordance requirement 18-19. (patch

management process)

4. Vulnerabilities testing tools will be approved by IECo

5. A detailed report will be supplied to IECo

Evidence of

compliance:

Technical documentation and vulnerability assessment and management policy

vulnerability assessment.

No: 9.1-18

Description: Patch management process.

Component: AMI


Priority: REQUIRED

Fit criterion: 1. If vulnerabilities exist, immediately report to IECo

2. Supply patches to amend the vulnerabilities:

a. Critical severity – Within one week from finding the vulnerability

b. High severity – Within one month from finding the vulnerability

c. Low severity – Within the following quarter from finding the vulnerability

3. The supplier is required to check the patch in an operating environment and

make sure there is no operational impairment.

Evidence of

compliance:

Technical documentation and patch management policy.

No: 9.1-19

Description: Compliance with international and Israeli laws, regulations, standards, and

procedures.

Component: AMI


Priority: REQUIRED

Fit criterion: The vendor should supply official information about compatibility with the

international and Israeli cybersecurity laws and standards like:

1. ISO27001/2

2. NIST 800-64

3. NIST 800-53

4. DLMS Green Book Ed.10

5. NIST SP800-160 V1

6. NIST SP800-37 Rev.2

7. IEC 62056

8. NERC CIP-010-03

Evidence of

compliance:

Technical documentation, company policies, technical and managerial procedures.

No: 9.1-20

Description: Technical documents and cyber solution architecture.

Component: AMI, HES, DC, METERS [1Ph, 3Ph, CT, PLMN, PLC], IHD


Priority: REQUIRED

Fit criterion: The vendor will provide a unified cyber architecture document and drawings:

1. Design documents 2. SOW 3. HLD

4. LLD 5. SAT and FAT

Evidence of

compliance:

Technical documentation and cyber architecture document.

No: 9.1-21

Description: Vulnerability Assessment Audits & Penetration tests should be done by external independent company.



Priority: REQUIRED

Fit criterion: The penetration tests (including physical, network and application security tests) shall provide details, among other things about:

The feasibility to tamper with the device and retrieve E-meter cryptographic keys

The feasibility to tamper unnoticed with other security relevant settings

If there are still any backdoors present implemented by the E-meter vendor

If the functionality of the development interface (e.g. JTAG) is still present. It there are still other communication interfaces and protocols implemented

than the ones allowed. The feasibility of attack vectors success according to business process and

use cases risk assessment that has been done by IECo (the document will be supplied as part of the process)

These penetration tests shall be executed by an independent professional security

lab. The security lab shall not be affiliated to the bidder, nor have been involved at any stage in the product design.

Evidence of

compliance:

Certificate / Test report / Declaration of conformity from external laboratory. The bidder provides an overview of all penetration tests that have been executed on their components.

No: 9.1-22

Description: Sharing of security test results.

Component: AMI


Priority: REQUIRED

Fit criterion: Under NDA, the vendor/ manufacturer is willing to share the results of their security testing.

Evidence of

compliance:

The bidder agrees to comply with this requirement

No: 9.1-23

Description: Supply Chain Cyber Protection Requirements.



Priority: REQUIRED

Fit criterion: 1. Physical random checks on equipment arriving at IECo

2. Receive installation files with a digital signature of the vendor 3. Block Malicious File Uploads – scan all files before inserting them into the

system by using “sanitization system” (i.e. multiple anti-virus engines and content disarm and reconstruction (CDR))

Evidence of

compliance:

Full certification plan and report. NDA document and contract with an Israeli company.

No: 9.1-24

Description: Cyber FAT (factory acceptance test).



Priority: REQUIRED

Fit criterion: 1. Experience of design, planning and execution of Cybersecurity FAT in

information security issues. 2. The vendor will submit the FAT plan for IECo approval 3. Penetration testing(White Box), Vulnerability Assessments and full risk

assessment as defined in NIST Special Publication 800-39, these tests

should be done by 3rd party company, the vendor will be responsible to hired and contract with the proper company and arranging all test timeslots and meetings, IECo will approve the company

4. Demonstrate compliance with the information security requirements written in the tender

5. IECo approval is needed between the phases and the tests

6. Detailed risk assessment report will be supplied to IECo

7. Detailed VA report will be supplied to IECo 8. Detailed PT report will be supplied to IECo 9. Detailed FAT report will be supplied to IECo

Evidence of

compliance:

Detail information about cyber security company/ companies and CV’s of cyber security specialists that were partners for Risk assessment, VA, PT and Cyber

security FAT. Follow Evidence based on bidder previous experience for similar technology and infrastructure size during the previous 5 years.

1. The example of Cyber FAT technical design 2. The example of Cyber FAT plan 3. The example of Cyber FAT execution report

4. Examples of full risk assessment reports and Gap analysis reports done by

the bidder at least during the previous 5 years for similar technology and

size infrastructure

No: 9.1-25

Description: Cyber SAT (site acceptance test).



Priority: REQUIRED

Fit criterion: Experience of design, planning and execution of Cybersecurity SAT in

information security issues. The vendor will submit the SAT plan for IECo approval

Penetration testing(White Box), Vulnerability Assessments and full risk assessment as defined in NIST Special Publication 800-39, these tests should be done by an Israeli 3rd party company, the vendor will be responsible to hired and contract with the proper company and arranging all test timeslots and meetings, IECo will approve the company

Demonstrate compliance with the information security requirements written in

the tender IECo approval is needed between the phases and the tests Detailed risk assessment report will be supplied to IECo Detailed VA report will be supplied to IECo Detailed PT report will be supplied to IECo Detailed SAT report will be supplied to IECo

The vendor will correct the gaps from the cyber SAT

Evidence of

compliance:

Detail information about cyber security company/ companies and CV’s of cyber security specialists that were partners for Risk assessment, VA, PT and Cyber security SAT. Follow Evidence based on bidder previous experience for similar technology and infrastructure size during the previous 5 years.

1. The example of Cyber SAT technical design 2. The example of Cyber SAT plan 3. The example of Cyber SAT execution report

4. Examples of full risk assessment reports and Gap analysis reports done by

the bidder at least during the previous 5 years for similar technology and

size infrastructure

5. NDA document and contract with an Israeli company

No: 9.1-26

Description: Check content and files “in the center of the network” before transferring them to

Meters and DC’s

Component: AMI


Priority: REQUIRED

Fit criterion: All messages and file will be checked “in the center of the network” before

transferring them to meters and DCs. This includes

1. Anti-virus checking of files before installation (this includes checking of E-

meter and DC firmware files, HES software, …)

2. Check the message structure in F5 or Data power (see for example also req.

9.4-13)

3. Check the content of the message

The bidder must be able to implement and support these processes.

Evidence of

compliance:

Technical documentation or documented evidence from the bidder The bidder explains how he plans to implement these processes.

No: 9.1-27

Description: Security related to the HHU (Hand Held Unit)

Component: AMI


Priority: REQUIRED

Fit criterion: Regarding cyber security requirements for the HHU, the following security features

must be implemented on the HHU:

User authentication

The communication between the HHU and the E-meter must be secured

The HHU must receive in a secure way the security credentials (meter keys,

DC keys or passwords) Needed to execute the work orders

In case a HHU is reported lost/stollen, the keys of the meters that were

stored on the HHU must be replaced in the HES and on the E-meters.

The bidder must explain in detail how he plans to implement this.

Note: The HHU will be provided by IECo, and is not part of this tender.

Evidence of

compliance:

For each of the security features indicated, the bidder must provide a detailed description how this will be implemented.

Cyber Requirements for Smart Meters

No: 9.2-1

Description: One-way data transmission from consumer interface port Icustomer_meter

Component: METER [1Ph, 3Ph, CT, PLMN, PLC], technician interface


Priority: REQUIRED

Fit criterion: The bidder shall provide a Uni-directional consumer interface port, based on optical decoupling. A technical description must be provided that the communication is

indeed one-way.

Evidence of

compliance:

The bidder explains how the consumer interface port is physically implemented.

No: 9.2-2

Description: The meter should log all technical information about all technician operations

performed in the field and send it to a central log management system.

Component: METER [1Ph, 3Ph, CT, PLMN, PLC], technician interface


Priority: REQUIRED

Fit criterion: Detailed technical description.

Evidence of

compliance:

Technical documentation.

No: 9.2-3

Description: Security on the PLC-layer.

Component: METER [PLC]


Priority: REQUIRED

Fit criterion: The information security measures provided at the PLC communication level should

be specified against the following cyber-attacks:

1. Man in the middle

2. Impersonation

Evidence of

compliance:

Technical documentation

No: 9.2-4

Description: The vendor shall implement a rogue infrastructure association prevention

mechanism.

Component: METER [PLMN]


Priority: REQUIRED

Fit criterion: The E-meters shall only access and authenticate the mobile network provided by IECo. The bidder provides a detailed technical description of the mechanisms in

place (implemented in his meters) to protect against rogue infrastructure attacks.

Evidence of

compliance:

Technical information documentation.

No: 9.2-5

Description: The vendor shall specify other communication protocols, apart from DLMS/COSEM,

implemented on the meters and the information security measures on them.



Priority: REQUIRED


Evidence of

compliance:


No: 9.2-6

Description: All key material shall be securely stored in the E-meter.



Priority: REQUIRED

Fit criterion: Key material is securely stored on the E-meter. It should not be possible to read out

any key via any of the interfaces on the E-meter. Secure (key) storage on the E-meter is preferably implemented by using a microprocessor with dedicated storage for a unique key per meter (or per processor) inside the microprocessor chip. This unique key is used to secure the DLMS/COSEM communication keys.

Evidence of

compliance:

Documented evidence from bidder: The bidder explains how this is implemented on his E-meters, include a detailed description of the technology used for key material protection.

No: 9.2-7

Description: Messages within a DLMS association shall be protected with dedicated keys.



Priority: REQUIRED

Fit criterion: The meter uses dedicated keys per association. This shall be implemented according to DLMS/COSEM in accordance with the IEC 62056-5-3 standard.

Evidence of

compliance:

Certified test report or documented evidence from bidder and technical description of the solution.

No: 9.2-8

Description: The E-meter shall only accept associations from the defined DLMS clients.

Component: METER [1Ph, 3Ph, CT, PLMN ,PLC]


Priority: REQUIRED

Fit criterion: Only the following Application Associations shall be implemented on the E-meters:

Public Client Management Client Secure Client

Evidence of

compliance:

Test report or documented evidence from the bidder. Compliance with this specification is verified by the evaluation of a sample.

No: 9.2-9

Description: The E-meter shall only accept HLS mechanism id 5 authentication during Association

Establishment, except for the public client.



Priority: REQUIRED

Fit criterion: For the management client, the pre-established client and secure client:

The E-meter shall only accept associations that use the HLS mech_id = 5 (HLS AES-GMAC) authentication mechanism.

Association requests with any other authentication mechanism shall be rejected.

Evidence of

compliance:


No: 9.2-10

Description: The meters shall by default apply secure DLMS/COSEM communication.



Priority: REQUIRED

Fit criterion: The security policy of the meters should be configured on the factory in a way to permit only secure/ protected communication:

This means that for the Management (Client) Association and the Pre-established client the security policy will require:

Authenticated and encrypted requests Authenticated and encrypted responses

For the Secure Client, the security policy will require:

Authenticated and encrypted requestsAuthenticated and encrypted responses

Evidence of

compliance:

Test report or documented evidence from the bidder. Compliance with this specification is verified by evaluation of a sample.

No: 9.2-11

Description: Data model and Access Rights



Priority: REQUIRED

Fit criterion: The E-meter shall implement the access rights as defined by the data model in the “IECo DLMS COSEM Profile for communication interfaces. MOACH Smart Meters”.

Evidence of

compliance:


No: 9.2-12

Description: Allowed interfaces on the E-meter



Priority: REQUIRED

Fit criterion: Only the E-meter interfaces as described in section 2.1 shall be present. That is the Ilocal_meter, IHES_meter ,and IDC_meter, and Imeter_customer Apart from this, also push buttons as described in section 3.2.8.2 shall be present.

No other interfaces and push buttons than those specified shall be present.

Evidence of

compliance:


No: 9.2-13

Description: Data and configuration parameters in the E-meter shall be protected against tampering.



Priority: REQUIRED

Fit criterion: It shall not be possible to change any configuration parameter in an unauthorized

way, e.g. by tampering with the meter. The E-meter implements protection mechanisms in order to preserve the confidentiality and integrity of data stored locally in the equipment.

Evidence of

compliance:

Documented evidence from bidder. The bidder explains how this is implemented on

his E-meters

The bidder provides a penetration test document indicating that it is impossible to change any configuration parameter in an unauthorized way by tampering with the meter.

No: 9.2-14

Description: Disable developer interfaces.



Priority: REQUIRED

Fit criterion: The E-meter shall have all debug ports on its circuit board (such as JTAG) disabled so that they cannot be used to read from or write to memory.

Evidence of

compliance:

Test report or documented evidence from the bidder. Penetration test report indicating that this functionality is disabled.

No: 9.2-15

Description: The E-meter must implement security suite 0.



Priority: REQUIRED

Fit criterion: Regarding the security suites and algorithms, the E-meter must support the following algorithms for the Management Client, Pre-Established Client and the Reading and Secure Client:

Authenticated Encryption: AES-GCM-128

Key Wrap: AES-128 key wrap

Evidence of

compliance:


No: 9.2-16

Description: No other cryptographic algorithms, with weaker security, than those currently specified, shall be implemented.



Priority: REQUIRED

Fit criterion: Cryptographic algorithms with weaker security than those specified in req. no. 9.2-9, 9.2-15, 9.5-1 or 9.5-5 shall not be implemented in the E-meter.

Evidence of

compliance:


No: 9.2-17

Description: It shall not be possible to disable the logging functionality of the meter.



Priority: REQUIRED

Fit criterion: In order to be able to guarantee the integrity of the meter, it shall not be possible to disable the logging functionality of the meter.

Evidence of

compliance:


No: 9.2-18

Description: The following security events shall be implemented, and logged in the E-meter



Priority: REQUIRED

Fit criterion: At least the following events shall be implemented:

Terminal cover removed Terminal cover closed Meter cover removed Meter cover closed

Strong magnetic DC field detected No strong magnetic DC field anymore

Evidence of

compliance:

Compliance with this specification is verified by the evaluation of a sample. Test report or documented evidence from the bidder. The bidder describes which security/fraud detection-related events are

implemented.

No: 9.2-19

Description: The vendor must ensure that there is a security mechanism against manipulating

the meter and using it as a pivoting vector (A network bridge).



Priority: REQUIRED


Evidence of

compliance:


No: 9.2-20

Description: Security events and logging



Priority: REQUIRED

Fit criterion: The meters shall implement the management of events, error and alarms as

described in the “IECo DLMS COSEM Profile for communication interfaces. MOACH

Smart Meters” so that IECo can decide and configure which events the meters should send to the HES or DC.

Evidence of

compliance:


No: 9.2-21

Description: The vendor must ensure that there is a security mechanism against manipulating

the meter and using it as a pivoting vector (A network bridge).



Priority: REQUIRED


Evidence of

compliance:


No: 9.2-22

Description: Secure and reliable clock synchronization



Priority: REQUIRED

Fit criterion: It is important that the clock of the meters is synchronized with the clock of other

AMI components (e.g. the HES or MDMS). To this end, the meters will receive clock

information from another system component.

For both PLMN-based and PLC-based meters, the bidder explains the options for

receiving clock information and how these messages will be secured.

Evidence of

compliance:

Detailed technical description from the bidder.

No: 9.2-23

Description: E-meter firmware authenticity and integrity protection.



Priority: REQUIRED

Fit criterion: It must be possible to verify (by IECo) the authenticity and integrity of new E-

meter firmware before uploading this new firmware to the meters. The E-meters must also be able to verify the authenticity and integrity of the

new firmware, and must be able to verify that the new firmware is applicable for the device (e.g. device type/version check)

Evidence of

compliance:

Documented evidence from the bidder. The bidder explains how this is implemented in his E-meters and how IECo can

verify the authenticity and integrity of the new firmware before uploading the new firmware.

No: 9.2-24

Description: A secure boot mechanism shall be implemented on the E-meter



Priority: REQUIRED

Fit criterion: During rebooting of the E-meter, the integrity and authenticity of the firmware is verified before reloading the firmware

Evidence of

compliance:

Documented evidence from the bidder.

The bidder explains in detail how the secure boot mechanism is implemented

No: 9.2-25

Description: Vulnerability Assessment Audits & Penetration tests by external independent security lab.



Priority: REQUIRED

Fit criterion: The penetration tests (including physical, network and application security tests)

shall provide details, among other things about: The feasibility to tamper with the device and retrieve E-meter cryptographic

keys The feasibility to tamper unnoticed with other security relevant settings

If there are still any backdoors present implemented by the E-meter vendor If the functionality of the development interface (e.g. JTAG) is still present. It there are still other communication interfaces and protocols implemented

than the ones allowed. These penetration tests shall be executed by an independent professional security lab. The security lab shall not be affiliated to the bidder, nor have been involved at any stage in the product design.

Evidence of

compliance:

Example Report, Certificate / Test report + Declaration of conformity from external

laboratory. The bidder provides an overview of all penetration tests that have been executed on their meters.

No: 9.1-26

Description: The E-meter must be security suite 1 ready.



Priority: REQUIRED

Fit criterion: The E-meter will have the appropriate resources and capabilities to support security suite 1: CPU, Memory, Storage, Bandwidth and network, firmware, etc.

Evidence of

compliance:

Technical documentation, Certificate / Test report + Declaration of conformity from external laboratory.

No: 9.2-27

Description: Use up-to-date software versions and advanced programming languages.



Priority: REQUIRED

Fit criterion: 1. There is no use of outdated software versions without support and/or End of

life

2. There is no use of outdated programming languages without support and/or End of life

Evidence of

compliance:


No: 9.2-28

Description: The E-meter should support manually or automatic changing/renewing meter keys.



Priority: REQUIRED

Fit criterion: An operator shall be able to change/renew the E-meter keys in a secure way. New keys should be transferred to meter in an encrypted way according to the IEC 62056

standard. The result of process should be detail logged.

Evidence of

compliance:

Certified test report, documented evidence from bidder: The bidder explains how this is implemented on his E-meters, include a detailed description of the technology used for key material protection.

DC Security Requirements

No: 9.3-1

Description: All key material related to connected E-meters shall be securely stored in the DC.

Component: DC


Priority: REQUIRED

Fit criterion: Key material is securely stored on the DC. It shall not be possible to read out any keys.

Evidence of

compliance:


The bidder explains how this is implemented on his DCs.

No: 9.3-2

Description: All DC specific security credentials, including passwords, shall be securely stored in the DC.

Component: DC


Priority: REQUIRED

Fit criterion: DC specific security credentials, including passwords, are securely stored on the DC.

Evidence of

compliance:

Test report or documented evidence from bidder: The bidder explains how this is implemented on his DCs.

No: 9.3-3

Description: Integrated security element (security chip) in the DC

Component: DC


Priority: REQUIRED

Fit criterion: The DC should use dedicated secure hardware for keys and cryptographic processes protection:

The key that is used for master and working key encryption and decryption will be stored in dedicated secure memory and not exportable.

Cryptographic processes will be done by a dedicated CPU. The security element in the DC shall be certified according to the common criteria,

at least level EAL 4.

Evidence of

compliance:

Dedicated secure hardware technical documentation Security test report from bidder and the secure hardware manufacturer. Security test report from the DC manufacturer

Or (if available): Certificate / Test report / Declaration of conformity from external laboratory.

No: 9.3-4

Description: Integrated security element (security chip) in the DC.

Component: DC


Priority: PREFERRED

Fit criterion: The DC should use dedicated secure hardware for keys and cryptographic processes protection:

The key that is used for master and working key encryption and decryption will be stored in dedicated secure memory and not exportable.

Cryptographic processes will be done by a dedicated CPU. The security element in the data concentrator should be certified according to the common criteria, preferably level EAL 5+ or better.

Evidence of

compliance:

Dedicated secure hardware technical documentation Security test report from bidder and the secure hardware manufacturer. Security test report from the DC manufacturer

Or (if available): Certificate / Test report / Declaration of conformity from external laboratory.

No: 9.3-5

Description: RBAC – Implement Role-Based Access Control for the DC.

Component: DC


Priority: REQUIRED

Fit criterion: 1. User type

a. Technician – Malfunction handling and maintenance

b. Administrator – In addition to Technician permissions, will be

responsible of other users, permissions, and configuration

management (e.g., version upgrades)

c. Application user – for application services

2. Security alerts on user activities such as permission addition/modifications

with an emphasis on administrator users.

Evidence of

compliance:


No: 9.3-6

Description: Password complexity for local accounts on DC.

Component: DC


Priority: REQUIRED

Fit criterion: Password must be six or more characters long.

Password must contain characters from three of the following four categories:

o Uppercase characters A-Z (Latin alphabet) o Lowercase characters a-z (Latin alphabet) o Digits 0-9

o Special characters (!, $, #, %, etc.)

Evidence of

compliance:


No: 9.3-7

Description: Messages within a DLMS association shall be protected with dedicated keys.

Component: DC


Priority: REQUIRED

Fit criterion: Between the DC and the E-meter dedicated keys are used to secure the data exchange within the established association. This shall be implemented according to DLMS/COSEM and the IECo data model.

Evidence of

compliance:


No: 9.3-8

Description: Management and interfaces communication - usage of secure protocols and secured

authentication.

Component: DC


Priority: REQUIRED

Fit criterion: If applicable for DC (i.e. if these protocols are used):

1. HTTPS (TLS 1.2 and above)

2. SFTP - version 4 and above

3. SSH version 2

4. SNMP version 3

5. IPSEC

If additional protocols are used, they must be secure/ cyber-attack resilient.

Evidence of

compliance:

Technical documentation, detailed description, and cyber certification for the additional protocols.

No: 9.3-9

Description: DC firmware authenticity and integrity protection.



Priority: REQUIRED

Fit criterion: It must be possible to verify (by IECo) the authenticity and integrity of new DC

firmware before uploading this new firmware to the DCs. The DCs must also be able to verify the authenticity and integrity of the new

firmware, and must be able to verify that the new firmware is applicable for the device (e.g. device type/version check)

Evidence of

compliance:

Documented evidence from the bidder. The bidder explains how this is implemented in his DCs and how IECo can verify

the authenticity and integrity of the new firmware before uploading the new firmware.

No: 9.3-10

Description: A secure boot mechanism shall be implemented on the DC



Priority: REQUIRED

Fit criterion: During rebooting of the DC, the integrity and authenticity of the firmware is verified

before reloading the firmware

Evidence of

compliance:


The bidder explains in detail how the secure boot mechanism is implemented

No: 9.3-11

Description: The DC shall support association establishment with the E-meters by using only the

defined DLMS clients.

Component: DC


Priority: REQUIRED

Fit criterion: Only the following Application Associations shall be implemented on the DC:

Public Client Management Client Pre-established Client Secure Client

Evidence of

compliance:


No: 9.3-12

Description: The DC shall only use HLS mechanism id 5 authentication during association establishment with the E-meters, except for the public client.

Component: DC


Priority: REQUIRED

Fit criterion: For the management client, the pre-established client and secure client, the DC shall only implement association requests that uses the HLS mech_id = 5 (HLS AES-GMAC) authentication mechanism.

Evidence of

compliance:


No: 9.3-13

Description: The DC shall by default apply secure DLMS/COSEM communication.

Component: DC


Priority: REQUIRED

Fit criterion: The security policy of the meters should be configured in the factory in a way to permit only secure/ protected communication: This means that for the Management (Client) Association and the Pre-established association the security policy will require:


For the Secure Client, the security policy will require:


Evidence of

compliance:


No: 9.3-14

Description: For communication and data exchange with the E-meters, the DC will support the defined E-meter data model and access rights.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall implement the access rights as defined by the E-meter data model in the “IECo DLMS COSEM Profile for communication interfaces. MOACH Smart Meters”

and according to the IEC 62056 standard.

Evidence of

compliance:


No: 9.3-15

Description: DC shall implement ‘Session Locking’.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall lock a (user) session or logout the user, and prevent further access to the DC, after a certain (configurable) time of inactivity in a session. Details on this requirement will be aligned between Contractor and Contracting

Entity.

Evidence of

compliance:


The bidder describes how the DC fulfils this requirement.

No: 9.3-16

Description: Secure and reliable clock synchronization.

Component: DC


Priority: REQUIRED

Fit criterion: It is important that the clock of the DCs is synchronized with the clock of other AMI

components (e.g. the HES or MDMS). To this end, the DCs will receive clock

information from another system component.

The bidder explains the options for the DCs to receive clock information and how

these messages will be secured.

Evidence of

compliance:


No: 9.3-17

Description: Network connectivity.

Component: DC


Priority: REQUIRED

Fit criterion: 1. DC will be supplied without a cellular modem

2. DC will be supplied with an available ethernet port for external FW

connectivity

Evidence of

compliance:


No: 9.3-18

Description: Data Concentrator external Firewall

Component: DC


Priority: REQUIRED

Fit criterion: Data Concentrator FW will be supplied by IECo. This FW will contain the cellular

network connectivity.

The vendor will be responsible to implement and integrate them end-to-end with

IECo and project network:

1. The vendor should define explicitly network requirements for FW

configuration

2. IPSEC based traffic protection

3. Certificate-based identification against the IECo central FW

4. DPI for allowed communication protocols

5. Network management and identification process will be against a central

database (MDM)

6. Logging, monitoring, and analysis for cybersecurity events (SNMP V3)

7. Clock synchronization by using secure clock synchronization protocol

Evidence of

compliance:


No: 9.3-19

Description: Data and configuration parameters in the DC shall be protected against tampering.

Component: DC


Priority: REQUIRED

Fit criterion: It shall not be possible to change:

Any configuration parameter in an unauthorized way. Alter stored data (e.g. stored meter readings) in an unauthorized way, e.g.

by tampering with the DC.

The DC implements protection mechanisms in order to preserve the confidentiality and integrity of data stored locally in the equipment.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder provides a penetration test document indicating that it is impossible to

change any configuration parameter in an unauthorized way by tampering locally or remotely.

No: 9.3-20

Description: The DC shall log security events.

Component: DC


Priority: REQUIRED

Fit criterion: The DC shall store in a local log the following time stamped security related DC events, for example:

Successful and failed (user) authentication attempts Successful and failed firmware updates

Successful and failed attempts to change cryptographic keys or credentials Changing the DC system time Opening the cover of the DC Shutting down the device Booting the device Attempted replay attacks Attempts to disable the logging functionality of the DC.

Attempts to delete log files in an unauthorized way

Failures in message verification (failures in encryption/decryption and integrity verification)

Further, the DC shall also log the security events and alarms it receives from the connected E-meters. The DC shall also log from which E-meter the event originated.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder describes which security events are logged.

No: 9.3-21

Description: Content of the log records and alert/alarm messages

Component: DC


Priority: REQUIRED

Fit criterion: The log records should contain the following information:

Date and time (including seconds) – a timestamp

Event description, a description of the action taken in order to support an

incident investigation

Action initiator identifier

Activity severity

Alert/alarm messages, i.e. message that requires a response from the

infrastructure/system security team, should include at least the following

information:





Activity severity

Log source identifier – The identifier of the component which sent the

message

Messaging protocol – Details the type of protocol that was used to relay the

message (e.g., Syslog, SNMP)

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder describes the structure of the log records and alert/alarm messages

No: 9.3-22

Description: It shall not be possible to disable the logging functionality of the DC.

Component: DC


Priority: REQUIRED

Fit criterion: In order to be able to guarantee the integrity of the DC, it shall not be possible to disable the logging functionality of the DC.

Evidence of

compliance:


No: 9.3-23

Description: Critical DC events shall trigger alarm.

Component: DC


Priority: REQUIRED

Fit criterion: Critical events shall trigger alarms. The criteria for a critical event are defined and configurable. Details on the set alarms will be aligned between contracting entity and contractor.

Evidence of

compliance:


No: 9.3-24

Description: Vulnerability Assessment Audits & Penetration tests shall be provided.

Component: DC


Priority: REQUIRED

Fit criterion: The penetration tests (including physical, network and application security tests) shall provide details, amongst other topics about:

The feasibility to tamper with the DC and retrieve E-meter and DC specific cryptographic keys.

The feasibility to tamper unnoticed with other security relevant settings It there are still other communication interfaces and protocols implemented

on the DC apart from the ones specified and documented by the bidder (no backdoors).

If the functionality of the development interface (e.g. JTAG) is still present.

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder provides an overview of all penetration tests that have been executed on their DCs.

No: 9.3-25

Description: Protection application interfaces.

Component: DC


Priority: REQUIRED

Fit criterion: For the communication between the DC and the HES, the DC is required to support APIs, based on XML \ SOAP so that the content can be verified and filtered by the F5 or DataPower

Evidence of

compliance:


No: 9.3-26

Description: Use up-to-date software versions and advanced programming languages.

Component: DC


Priority: REQUIRED

Fit criterion: 1. There is no use of outdated software versions without support and End of

life 2. There is no use of outdated programming languages without support and

End of life

Evidence of

compliance:


HES Security Requirements

No: 9.4-1

Description: HES should:

1. Protect based on encryption: payload and authentication process.

2. Decrypt the message that comes from the meters.

Component: HES


Priority: REQUIRED

Fit criterion: All cryptographic operation must be done by HES in secure way, like: secure

authentication tag rendering and payload rendering HES will not store and use encryption keys as clear text. Keys will be stored in a secure way.

The symmetric keys will be stored in a DB in encrypted way Authentication process with DB should be certificate based mutual

authentication. The HES shall have an integrated secure key management system (KMS).

Evidence of

compliance:

Detailed processes description, technical documentation, and security test report Certificate and/or test report of the security module.

Done by external laboratory.

No: 9.4-2

Description: The HES shall support a key life cycle model of basic key management services.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall support a key life cycle model of basic key management services as

described in ISO/IEC 11770-1:2010.

At least the following key management services shall be supported by the HES in a

secure way:

Key generation

Key registration (associating a key with an entity, e.g. with an E-meter or DC)

Key storage

Key backup and restore

Key archival

Evidence of

compliance:


The bidder must explain in detail how his KMS implements these basic key

management services.

Detailed processes description, technical documentation, and security test report

Done by external laboratory.

No: 9.4-3

Description: Meter key export from KMS in HES.

Component: HES


Priority: REQUIRED

Fit criterion: Via the KMS in HES it shall be possible to export keys. The exported keys will be used by tools of technician to locally install, troubleshoot and configure the E-meter (e.g. a HHU or dedicated expert tools installed on a laptop). The KMS should raise an alert and log record indicating that a particular meter key

has been exported. The KMS should keep track of this status, providing operators a view on which meter keys have been exported and should be changed.

Evidence of

compliance:

The bidder must explain in detail how his KMS implements this, or similar,

functionality.


No: 9.4-4

Description: Manually changing/renewing meter keys

Component: HES


Priority: REQUIRED

Fit criterion: Via the HES, an operator shall be able to change/renew the E-meter keys in a secure way. It should be possible to create a group of meters and schedule an action to change the meter keys for that group of meters after an operator approval. New keys should be transfered to the E-meter in encrypted way according to the IEC 62056 standard.

The result of process should be detail logged.

Evidence of

compliance:


The bidder describes how this is implemented in his HES system.

No: 9.4-5

Description: Automatic replacement of meter keys

Component: HES


Priority: REQUIRED

Fit criterion: In a case that meter keys are marked as being exported, the HES should have

the functionality to replace the meter keys after a certain (configurable) period of time.

In case the (configurable) key lifetime of a meter key expires, the HES should have the functionality to automatically replace the meter keys (this allows, for

example, to replace meter keys every 3 years) An operator of the KMS (in the HES) must approve this action before it is actually executed.

Evidence of

compliance:

The bidder must explain in detail how his KMS implements this, or similar,

functionality.


No: 9.4-6

Description: For user authentication, the HES should integrate with Active Directory.

Component: HES


Priority: PREFERRED

Fit criterion: It should be possible to integrate the HES with Active Directory, this way, user account defined in Active Directory can be used to logon to the HES, and no HES specific user accounts are necessary. The bidder provides detailed information describing if and how his HES fulfils this requirement.

Evidence of

compliance:


No: 9.4-7

Description: HES shall implement Role Based Access as part of its account management policy.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall support role-based access. For every role, it must be possible to configure which actions are allowed on the

HES.

It shall be possible to define new roles or remove roles. The HES must have a user-friendly manner to grant rights to roles. The HES must also have a user-friendly manner to show which rights are

granted to which roles, and which users are granted certain roles (e.g. an authorization matrix). User type:

Technician – Malfunction handling and maintenance

Administrator – In addition to Technician permissions, will be responsible

of other users, permissions, and configuration management (e.g., version

upgrades)

Application user – for application services

Security alerts on user activities such as permission addition/modifications

with emphasis on administrator users

Details on this requirement will be aligned between contractor and contracting entity.

Evidence of

compliance:


The bidder describes how the HES fulfils this requirement.

No: 9.4-8

Description: HES shall limit the number unsuccessful (user) logon attempts.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall limit the number of unsuccessful consecutive login attempts (within a certain time period) and must lock the account, for a certain time or until the account is unlocked by a system administrator. Details on this requirement will be aligned between Contractor and Contracting

Entity.

Evidence of

compliance:



No: 9.4-9

Description: HES shall implement ‘Session Locking’.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall lock a session or logout the user, and prevent further access to the HES, after a certain (configurable) time of inactivity in a session.

Details on this requirement will be aligned between Contractor and Contracting Entity.

Evidence of

compliance:



No: 9.4-10

Description: HES shall implement Concurrent Session Control.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall limit the number of concurrent sessions, per user (e.g. that access the HES via a web client), to a definable maximum number. Details on this requirement will be aligned between Contractor and Contracting Entity.

Evidence of

compliance:



No: 9.4-11

Description: Clock synchronization.

Component: HES


Priority: REQUIRED

Fit criterion: 1. A synchronization mechanism that allows synchronizing the component’s

clock against the central time server by using the NTP protocol.

2. Need a detailed specification of the mechanism type and protection means

3. Need a detailed specification of the accuracy of the supportive system

4. Time offset support

Evidence of

compliance:


No: 9.4-12

Description: Communication between HES and the MDC application.

Component: HES


Priority: REQUIRED

Fit criterion: The communication between HES and the MDC application server should be based

on protocols that allow content filtering by the F5 or DataPower that is implemented

today in IECo, such as:

XML

JSON

REST API

Etc.

Evidence of

compliance:


No: 9.4- 31

Description: Secure communication.

Component: HES


Priority: REQUIRED

Fit criterion: A certificate based identification between HES and the F5/Data power is required.

Evidence of

compliance:


No: 9.4-14

Description: Software authenticity and integrity, and HES system integrity

Component: HES


Priority: REQUIRED

Fit criterion: It shall be possible for IECo to verify the authenticity and integrity of the HES

software (or software parts, like patches) before installing these on the system.

It shall be possible, on the HES, to detect and prevent malwares

The HES shall log alerts on:

o Addition of software/hardware components to the HES

o Configuration modifications

o Installation/Removal of files from the HES

Evidence of

compliance:


No: 9.4- 51

Description: The HES shall log security events.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall store in a local log the following time stamped security related events, for example:

Successful and failed (user) authentication attempts Successful and failed firmware updates Successful and failed attempts to change cryptographic keys or credentials Changing the HES system time Stop and restart the application Attempted replay attacks Attempts to disable the logging functionality of the HES

Attempts to delete log files on the HES in an unauthorized way Failures in message verification (failures in encryption/decryption and

integrity verification)

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder describes which

security events are logged.

No: 9.4- 61

Description: Content of log records and alert/alarm messages

Component: HES


Priority: REQUIRED

Fit criterion: The HES application should be able to log, store and send information security

events about meters, DC, and HES to a central management system.

The log records should include at least:





Activity severity

Alert/Alarm messages a message that requires a response from the

infrastructure/system security team





Activity severity

Log source identifier – The identifier of the component which sent the message

Evidence of

compliance:

Test report or documented evidence from bidder. The bidder describes the structure of the log records and alert/alarm messages.

No: 9.4-17

Description: Critical HES events shall trigger alarms.

Component: HES


Priority: REQUIRED

Fit criterion: Critical events shall trigger alarms. The criteria for a critical event are defined and configurable. Details on the set alarms will be aligned between contracting entity and contractor.

Evidence of

compliance:


No: 9.4- 81

Description: It shall not be possible to disable the logging functionality of the HES.

Component: HES


Priority: REQUIRED

Fit criterion: In order to be able to guarantee the integrity of the HES, it shall not be possible to

disable the logging functionality of the HES.

Evidence of

compliance:


No: 9.4-19

Description: HES shall support integration with external logging server.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall support integrations with dedicated external logging servers (e.g.

syslog servers). The bidder indicates how his HES fulfils this requirement.

Evidence of

compliance:


No: 9.4-20

Description: Protection of the audit logs.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall protect audit/log files and records against unauthorized access, modification, and deletion.

Evidence of

compliance:



No: 9.4- 12

Description: Availability of the audit functionality.

Component: HES


Priority: REQUIRED

Fit criterion: The HES shall provide a warning if the generation of audit records fails, and take appropriate measures (e.g. overwriting the oldest audit records, stop generating

audit records, etc.)

Evidence of

compliance:



Cyber Security Additional and Optional Requirements

IECo is required to prepare for the integration of technologies, tools and additional Cybersecurity layers

in the near future such as security suite 1 and 2, digital signature, HSM, FW’s, etc. The MOACH project

infrastructure should be able to support these optional requirements.

The Bidder must submit for the following optional requirements a separate price quote and timeline,

for implementation for each requirement individually. IECo will have the sole right to activate any or all

of these optional requirements.

These options shall not be considered in IECo's evaluation.

No: 9.5-1

Description: The E-meter and DC must support security suite 1.



Priority: REQUIRED

Fit criterion: Regarding the security suites and algorithms, the E-meter and DC must support the following algorithms for the Management Client and the Pre-Established Client:

Authenticated Encryption: AES-GCM-128 Key Wrap: AES-128 key wrap

For the Secure Client: Authenticated Encryption: AES-GCM-128 ECDSA digital signature with P-256 (with SHA-256)

Key Wrap: AES-128 key wrap Note: The key agreement methods and compression will not be used.

Evidence of

compliance:


No: 9.5-2

Description: Digital signatures for critical commands.



Priority: REQUIRED

Fit criterion: The vendor shall supply a digital signature validation mechanism for critical

commands sent remotely or executed from the technician's computer before execution, including the changing of dialing parameters.

Evidence of

compliance:


No: 9.5-3

Description: Digitally signed and ciphered requests from the Secure Client.



Priority: REQUIRED

Fit criterion: As the security policy for the Secure Client requires authenticated, encrypted and digitally signed requests the order of these operations must be defined. As indicated in the DLMS Green Book Ed.10, the digital signature should be applied first (using the general-signing APDU data structure) and then authenticated encryption. Message processing by the meter should include the next steps: (in accordance with the IEC 62056-5-3 standard)

1. Authentication tag validation 2. Message decrypt 3. Digital sign validation

4. Command execution

Evidence of

compliance:


No: 9.5-4

Description: All firmware parts shall be digitally signed by the meter and DC manufacturer.



Priority: REQUIRED

Fit criterion: The meter and DC manufacturer shall digitally sign every firmware part. To this end:

The digital signature algorithm defined in DLMS security suite 1 (ECDSA with P-256 and SHA-256) shall be used.

The public key used to verify the signature shall be pre-provisioned in the component.

The meter and DC shall only accept a new firmware if the verification of the firmware succeeds.

Evidence of

compliance:

Certified Test report or documented evidence from the bidder.

No: 9.5-5

Description: The supplier shall clarify readiness to support the defined security suite 2.



Priority: PREFERRED

Fit criterion: To be future-proof, the meter should be able to support the algorithms specified in security suite 2. Specifically, the E-meter should be able to support the following algorithms:

Authenticated Encryption: AES-GCM-256

ECDSA with P-384 Hash: SHA-384

Key Wrap: AES-256 key wrap

Evidence of

compliance:


No: 9.5-6

Description: The DC shall support digitally signed and ciphered requests for the Secure Client.

Component: DC


Priority: REQUIRED

Fit criterion: As the security policy for the Secure Client requires authenticated, encrypted and digitally signed requests, the order of these operations must be defined. As indicated in the DLMS Green Book Ed.10, the digital signature should be applied first (using the general-signing APDU data structure) and then authenticated encryption.

Evidence of

compliance:


No: 9.5-7

Description: Data Concentrator external Firewall

Component: DC


Priority: REQUIRED

Fit criterion: 1. Data Concentrator firewall (FW) will be supplied by the vendor of his choice

according to LEADERS quadrant vendors in the network firewalls category in

Gartner Magic Quadrant 2020 report, and according to the FW's amount that

is needed for the project and written in the tender

2. The firewall should contain cellular network connectivity

3. The vendor will supply a central management system for config, manage,

monitoring and maintain the FW’s including licenses

4. The vendor will be responsible to implement and integrate them end-to-end

with IECo and project network:

a. The vendor should define explicitly network requirements for FW

configuration

b. IPSEC based traffic protection

c. Certificate-based identification against the IECo central FW

d. DPI for allowed communication protocols

e. Network management and identification process will be against a

central database (MDM)

f. Logging, monitoring, and analysis for cybersecurity events (SNMP V3)

g. Clock synchronization by using NTP

Note: The data concentrator external Firewall is a device that will be installed close

to the data concentrator. The connection between the data concentrator and firewall

will be via ethernet cable.

Evidence of

compliance:


No: 9.5-8

Description: Data Concentrator Firewall

Component: DC


Priority: REQUIRED

Fit criterion: 1. Data Concentrator FW will be supplied by the vendor according to the IECo

detailed specification and will be approved by IECo, according to the FW's

amount that is needed for the project and written in the tender

2. In this case, the firewall should contain cellular network connectivity (i.e.

4G-LTE with fall-back to GPRS technology in case of unavailability of 4G),

and the unit shall be default be equipped with an antenna for 4G-LTE.

3. The vendor will supply a central management system for config, manage,

monitoring, and maintaining the FW’s including licenses

4. The vendor will be responsible to implement and integrate them end-to-end

with IECo and project network:

a. The vendor should define explicitly network requirements for FW

configuration

b. IPSEC based traffic protection

c. Certificate-based identification against the IECo central FW

d. DPI for allowed communication protocols

e. Network management and identification process will be against a

central database (MDM)

f. Logging, monitoring, and analysis for cybersecurity events (SNMP

v3)

g. Clock synchronization by using NTP

Note: The data concentrator external Firewall is a device that will be installed close

to the data concentrator. The connection between the data concentrator and firewall

will be via ethernet cable.

Evidence of

compliance:


No: 9.5-9

Description: All cryptographic operations in the HES should be implemented with the support of a

Hardware security module (HSM):

Component: HES


Priority: REQUIRED

Fit criterion: All cryptographic operations must be done by a hardware security module

(HSM), This includes: o Decrypting messages that comes from the meters o Encrypting messages that to be sent to the meters o DLMS/COSEM authentication tag rendering o Digitally signing of critical commands

The HES shall have an integrated secure key management system (KMS). The core of this KMS is a cryptographic module that is at least FIPS 140-2 level 3 certified or Common Criteria EAL 4+ certified.

HES will not store and use encryption keys as clear text. Keys will be stored securely based on the HSM hardware. The symmetric keys (meter keys, DC keys, …) will be stored in a DB in an encrypted way and decrypted by HSM with help of a unique key stored in the HSM

Authentication process with HSM should be certificate-based mutual authentication.

No: 9.5-10

Description: Installation and configuration of cyber components in the project.

Component: AMI


Priority: REQUIRED

Fit criterion: All information security components in the project (such as: HSM, PKI, FW’s, etc.) will be installed and configured from scratch on SDDC infrastructure owned by IECo by an Israeli company certified for working that will be approved by IECo

and the Israeli regulator.

Evidence of

compliance:

NDA document and a contract with an Israeli company.

10 E2E INTEGRATION AND FUNCTIONAL DESCRIPTION

The following chapter describes the business goals and systems impacted by the project.

Business goals

Beyond the smart meter implementation IECo has defined a set of business goals to achieve, for which

IECo requires the services of the bidder. These business goals are expected to be implemented at project

go-live, though can iteratively be developed to gradually create business value over time.

1. Improved billing accuracy and reduced electricity misuse

Standard asset registration throughout all IECo systems (processes & data)

Standard metering data acquisition & data validation processes

Creation & maintenance of smart tariff structures

Standard meter-to-bill processes

Standard cash collection processes (incl. disconnection/connection processes)

Anomaly detection processes for e.g. technical failures or fraud analysis

Standard processes to follow-up on anomaly detections

2. Improved customer satisfaction

Offering of different and customised products to B2C and B2B customers

Standard bill presentment and visualisations via different (digital) channels

Personal analysis and energy mgmt. advice to e.g. reduce energy usage and next best actions

Proactive alerts to customers (e.g. warnings for unexpected higher usage)

Creation of different types of marketing campaigns

Process of changing ToU and similar updates via customer and/or solution provider interaction

Ability for home assistant services directly connected to the meter

Standard services for collective billing and/or community-based platforms

3. Improved productivity of the field force: scheduling processes and field worker utilisation

Standard and optimised scheduling activities for metering services by the field force

Standard integrations for internal and external field force services (e.g. information provisioning,

updates on master data, feedback-loop for transactional data)

4. Increased worker safety and decrease of EH&S costs

Standard information provisioning of EH&S risks to the field force, tailored to the situation

Simplified logging of EH&S risks & issues found

Reduction of the amount of site visits needed

5. Improved return on investments and maintenance activities

Standard integration with Enterprise Asset Management processes for work orders & notifications

Data provisioning to optimise asset investment and maintenance strategies

Integration with portfolio management to group and prioritise investments and operations

6. Reduced inventory costs and reduced ordering times

Integration with purchasing and material management processes to optimise inventory and spare

parts management

Automation of meter calibrations and tests

Automation of meter replacement strategies

Definition of standard building blocks for meter (service) purchasing

7. Improved analytics and AI/ML

Integration of AMI for real-time grid operations (e.g. outage mgmt., events)

Integration of AMI with near-time or non-real-time analysis capabilities

Use of AI and ML capabilities for pattern recognition, process automation or simplification

Allowing decision-making processes based on automated processes

8. Improved forecasting, planning & reporting capabilities

Automated reporting capabilities and self-service BI with AMI data

Integration with state estimation and calculation mechanisms

Integration with different types of grid simulations and planning capabilities

9. Reduced load & outage mgmt. and improved power quality

Integration of AMI data with distributed energy capabilities (e.g. DERMS)

Automated load analysis and detection of devices that create disturbances in the grid

Improve network optimisation capabilities based on AMI data

IECo is interested to learn from bidder’s experiences to implement the defined business goals and

potentially define other value-added services to bring value to IECo’s core processes, linked to the

integration of AMI data.

Business processes should be modelled using standard/proven modelling approaches. IECo doesn’t have

a business process modelling tool in place, which can be used for this project. Bidder can provide the

best approach to model business processes.

Business guidelines and IT principles

IECo values clear business guidelines and IT principles, which need to be adhered to in the project. The

most relevant ones for this project are:

Integration: The more integrated the future process models and architecture will be, the more

efficient it will be. It must be possible to add new services without disruption of existing functionality.

Standardisation of business processes, data models and architectural components will greatly support

standard integrations

Data provisioning: A considerable rise of the amount of data is expected, via internal & external

sources. New policies & procedures are required to make full use of this data and allow data-driven

decision-making (availability, quality, security, and ability to combine)

Simplification: Reduction of complexity and redundancy on application, service, and infrastructure

level, allowing to share processes & data across the company

Security-by-design: Security controls have been built into to architecture and business risks are

considered when designing solutions. Information security and cyber resilience need to be managed

throughout

Build-to-operate: The development of the system architecture and services focuses on scalability,

usability, performance, and interoperability

System architecture

The MDMS will integrate with multiple (already available) peripheral systems. A simplified system

architecture is shown below.

Figure 10-1: Simplified System Architecture

The following systems are expected to be used in the future system architecture:

MDMS – Meter Data Management System

AS-IS Existing system – Honeywell Eiserver 9.1.

Standard MDUS integration with SAP IS-U.

Additional integrations for data warehouse, SIEM, cellular communication

provisioning (PVNO) and infrastructure configuration tooling.

TO-BE It is our expectation that during the project the Honeywell Eiserver 9.1 will be

upgraded to the latest Honeywell Connexo Suite. This upgrade is part of the project

and scope for the bidder

The Honeywell MDC will stay integrated with the Honeywell MDM. In parallel the

bidder’s HES needs to be connected via a separate integration with the MDM

Existing MDM functions need to be extended to meet the new requirements

CRM – Customer Relationship Management

AS-IS Existing system – SAP CRM.

Standard business partner replication available with SAP ECC (IS-U, ERP).

Containing all customer interactions, marketing campaigns for the mass roll-out,

contract management, products & prices, etc.

TO-BE Future CRM solution is under discussion, but won’t be part of this tender/project. It

is not expected the bidder will propose/provide new CRM solutions. E2E business

processes need to be defined with SAP CRM.

Portals

Out of scope IECo has capabilities for customer, installer, and service provider portals. Changes

to these portals are out-of-scope for this tender, though IECo expects that the

bidder enables standard webservices, which could be used for portal applications.

Billing/invoicing

AS-IS Existing system – SAP IS-U, on-premise ECC 6.08 (integrated solution with ERP).

Standard integrations via MDUS to the MDMS and CRM business partner replication.

Ensuring meter reads can be invoiced periodically and can be used for switching &

move in/out processes, dunning & cash collection procedures, meter configuration

(manual/automated reads), etc.

TO-BE Upgrade to SAP S/4HANA on-premise solution foreseen, in which SAP IS-U and ERP

will remain integrated. Project go-live foreseen around 2026/2027, so the defined

E2E business processes need to be running on SAP ECC. It’s not foreseen that SAP

Leonardo (e.g. PdMS, AIN) will be available for the project. It is expected that the

bidder provides their view on how the MDM, IS-U, EAM and GIS will be CIM

compliant (data model consistent) and ISO5500x compliant (processes consistent).

EAM – Enterprise Asset Management

AS-IS Existing system – SAP PM, FI, CO, CS, MM, SD, …, on-premise ECC 6.08 (integrated

solution with IS-U).

Limited standard integrations linked to metering. Standardisation of asset master

data across the different systems to be defined as part of this tender.

Construction & maintenance processes (work orders and notifications), high-level

planning, asset activation/depreciation, meter master data.

TO-BE Upgrade to SAP S/4HANA on-premise solution foreseen, in which SAP IS-U and ERP

will remain integrated. Project go-live foreseen around 2026/2027, so the defined

E2E business processes need to be running on SAP ECC. It’s not foreseen that SAP

Leonardo (e.g. PdMS, AIN) will be available for the project. It is expected that the

bidder provides their view on how the MDM, IS-U, EAM and GIS will be CIM

compliant (data model consistent) and ISO5500x compliant (processes consistent).

WFM – Workforce Management

AS-IS Existing system – Blå cockpit client of isMobile.

Integration with SAP PM (work orders, custom dev.), SAP IS-U (meter reads,

custom dev.) and MDMS.

Integration with field force, detailed planning of meter installations and/or

removals, physical meter reads, etc.

TO-BE It is expected that the Blå cockpit will stay in place. The large custom developments

for maintenance activities (SAP PM) or meter deployment (SAP IS-U) might need to

be revised to configurable standard processes.

GIS – Geographical Information System

AS-IS Existing system – ESRI

Standard integrations to call the GUI/representation function of ESRI from e.g.

MDMS and asset integration for grid data. Premises are being created in GIS

(currently not the meters) and linked with the MDM. Additional SAP CS order

integration, linked to the IS-U processes

XYZ co-ordinates of the (smart) meters, connectivity/topology information, phase

information (L1, L2, L3).

TO-BE ESRI will remain in place during the project. It is expected that the bidder provides

their view on how the MDM, IS-U, EAM and GIS will be CIM compliant (data model

consistent) and ISO5500x compliant (processes consistent).

SCADA/ADMS – Control centre real-time systems

AS-IS Existing system – a SCADA/ADMS solution is in place

No integration for smart meter data and SCADA/ADMS yet

Real-time monitoring & control, alarming/events, outage management

TO-BE It is expected that the MDMS (or potential other systems) can send external

alarms/events to the SCADA/ADMS solution (e.g. for larger outages on LV level

when multiple meters in the same area suddenly don’t have energy).

BI/Analytics – Business Intelligence

AS-IS Existing system – DWH, SAS Viya

There is a periodic update from the MDMS towards a DWH, which syncs with SAS

Viya (3-step approach). Data can be made available from different source systems

(near) real-time data collection & mapping, analytics, and insights/reports to

provide (automated) triggers to the transactional systems

TO-BE An optimised integration of the BI/Analytics is needed to realise the expected

business value. IECo is discussing potential new data collection processes, storage,

analytics, and insights; these discussions are out of scope of this tender. It is

expected to keep SAS Viya in the to-be solution, though the bidder should show its

competence with multiple BI/Analytics solutions (on-premise).

Integration layer

AS-IS IECo has a complex system architecture with multiple integration technologies.

Most integrations are using SOAP, some JSON. TIBCO Staffware, IBM WebSphere

and SAP PO are the most important integration technologies, for which IECo

expects the bidder to have experience with.

Since portal functions are out of scope and WFM is already in place, it is not

expected that the bidder will change current external API integrations.

TO-BE It is likely that the existing integration technologies will be reused, potentially

adding RES to avoid solely using SOAP in future. There is currently no expectation

for IoT solutions (e.g. MQTT, Kafka). A potential upgrade to S/4HANA will likely

change the current SAP PO to SAP’s preferred integration platform.

Infrastructure

All infrastructure services are on-premise. There is no cloud hosting on any service, which

means cloud solutions can’t be offered as part of this tender.

Used platforms/technologies within IECo are based on Windows, Oracle, and Unix. It is

expected that the bidder has the experience with different infrastructure platforms and

technologies.

System monitoring tools are available. Centerity is in use for infrastructure monitoring, alerts,

and configuration. The bidder should understand the capabilities of solutions such as

Centerity.

The standard database platforms and operating systems etc. are expected to be at the latest

versions, such as Oracle Database 19C and above, and Linux Servers Red Hat 8.3 and above.

If the infrastructure solution is based on Oracle, it should be an Oracle Enterprise solution.

Multiple technical infrastructure & monitoring servicesare in place

o The following are commercial services, available in IEC environments, integrated to

MENIV system and need to be integrated to MOACH systems:

AD: Active Directory

Radius: cellular network core, radio service (provision IP addresses)

o The next one is a commercial tool, its improvement and maintenance, as well as

integration, is part of the bidder's responsibility.

ELK: platform for system/server logging & analysis Elastic, Logstash, Kibana

o The following are custom tools, developed as part of MENIV project, and their

improvement and maintenance, as well as integration, is part of the bidder's

responsibility.

IEC_util: custom tool, file transfer, resend csv

ITF handler: custom tool, comms with industrial HES

MBAM: linked to Tibco, resend/review interfaces

Easy to analyze process logs that will allow quick troubleshooting

This project is expected to be a long-term project. During this time it is expected that cloud solution

will become part of the IECo infrastructure & services. Hence IECo is interested to understand the

cloud roadmap of bidder’s portfolio to understand how this might work in the future system landscape.

Security

Systems User management & user profiles in place (IDM/IAM).

A SIEM is in place to monitor events, communications, etc.

Design,

development

The new integrations and information flows will introduce new cyber security risks,

which need to be managed. IECo has a separate entity, which manages the cyber &

information security. It is expected that the bidder, besides PM & architecture, will

provide a technical counterpart with in-depth knowledge in security design.

Other

Peripheral

systems

PVNO (cellular communication provisioning) is highly relevant for the smart meter

communication, since IECo operates its own network.

Key extraction tooling for maintenance purposes is in place.

Separate (custom) system solutions are available for large industrial customers at

meter data gathering, but this data should follow similar E2E system integrations.

No: 10.3-1

Description: Upgrade of the Honeywell Eiserver 9.1

Component: MDM


Priority: REQUIRED

Fit criterion: It is expected that the bidder will perform the upgrade of the existing Honeywell Eiserver 9.1 to the latest Connexo version, before 2028. Honeywell is still the vendor of the MDM. Honeywell, as the vendor, is needed to perform some activities,

but the bidder will ensure the upgrade is done during the project. The bidder can propose if the upgrade should be at the beginning of the project or after a certain time when the first meters and functions have been rolled-out. IECo would like to see quick roll-out of the new meters, but also wants to enable the

latest services. The final decision will be made by IECo (and the bidder) in the Sprint0/HLD phase, the pricing given should reflect to allow both scenarios (1 price

for the different scenarios) Additional items need to be taken into account:

The current Eiserver 9.1 doesn’t have a standard CIM-based integration to the HES. When the Eiserver 9.1 will be used by the bidder a new & complex interface between the Honeywell MDM and bidder’s HES needs to be developed (integration either via flat-file CSV, SOAP or JSON)

Idem for CIM-compatibility upwards to peripheral systems the Eiserver 9.1 might not offer all required functionality

The Connexo suite is expected to offer standard CIM interfaces to the HES and upwards to peripheral systems, ensuring smoother integration and less complex developments

Evidence of

compliance:

Confirmation of the bidder that the upgrade of Eiserver 9.1 towards the latest

Connexo Suite is in scope of the project. The chosen scenario by IECo (and the

bidder) is part of the cost estimations (1 price for the different scenarios).

As part of the project delivery plan a clear explanation on how and when the

upgrade is being performed.

No: 10.3-2

Description: HES interface integrations.

Component: HES


Priority: REQUIRED

Fit criterion: It is expected that the bidder’s HES will need to be connected to the Honeywell MDM (irrelevant of which version of the Honeywell system bidder needs to interface with)

Evidence of

compliance:

Documented evidence from bidder on how the integration of the bidder’s HES with

Honeywell’s MDM will be developed & maintained.

No: 10.3-3

Description: CIM compliancy and ISO 5500x compliancy.

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder has proven experience regarding implementation of the CIM standards and the ISO 5500x standards for E2E processes. The bidder provides his view on how the MDM, IS-U, EAM and GIS can be made CIM compliant.

Evidence of

compliance:

The bidder can prove his experience regarding the CIM standards and ISO 5500x

standards.

The bidder can prove that he has experience with (different) MDM, SAP IS-U, SAP

PM and ESRI GIS

No: 10.3-4

Description: Availability of data towards BI/Analytics solutions.

Component: Systems


Priority: PREFERRED

Fit criterion: Although the development of the specific BI/Analytics solution is out of scope for this tender, it is expected that the bidder shows how the data of the different

platforms in scope can be made available to a BI/Analytics solution.

Evidence of

compliance:

The bidder describes with how data can be made available to BI/Analytics solutions

and how additional value can be generated for IECo.

No: 10.3-5

Description: Experience regarding system architecture and different types of integration

technologies.

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder must bring experience to the project to design/develop TIBCO Staffware, IBM WebSphere and SAP PO/PI/SCP

Evidence of

compliance:

The bidder can prove that he has experience with these type of integrations and

provides these services within the project

No: 10.3-6

Description: Experience in IoT-like protocols and integrations.

Component: Systems


Priority: PREFERRED

Fit criterion: Although there are currently no IoT use case, it might be advantageous (for the future) if the bidder has experience with IoT protocols and integrations, specifically MQTT and Kafka.

Evidence of

compliance:

The bidder indicates if he has the required experience, and presents some evidence

on how e.g. MQTT/Kafka could help with data streaming platforms.

No: 10.3-7

Description: Experience with different infrastructure platforms.

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder must have experience with different infrastructure platforms, specifically Windows, Oracle, and Unix. The bidder has experience with system virtualization

(VMware) and different technical monitoring system to manage & optimize infrastructure services

Evidence of

compliance:

The bidder can prove that he has the necessary experience.

No: 10.3-8

Description: Experience in security architecture and design.

Component: Systems


Priority: REQUIRED

Fit criterion: It is expected that the bidder, besides PM & architecture, shall provide a technical counterpart with in-depth knowledge in security design.

Evidence of

compliance:

The bidder indicates if he has the required security experience in smart metering,

SAP integration and utility services and provides evidence and a relevant CV of the

proposed project member

No: 10.3-9

Description: Future Cloud solutions

Component: Systems


Priority: PREFERRED

Fit criterion: All infrastructure services are on-premise. There is no cloud hosting on any service, which means cloud solutions can’t be offered as part of this tender. In the future cloud solutions might be considered. The bidders are requested to present their roadmap for future cloud solutions and include it in the bid.

Evidence of

compliance:

The bidder describes their ideas/vision for future cloud solutions.

Data management

To improve interoperability within the system landscape and data of different systems to be combined

IECo understands it is vital to have a clear data management strategy in place. The data management

strategy ensures standard definitions of the data models, and it includes processes to be in place to keep

the data consistent between the different systems (e.g. meters should be uniquely and consistently

defined within the MDMS, EAM, GIS, IS-U and potentially other systems).

IECo expects the bidder to define a clear data management strategy to ensure all relevant master data

are uniquely and consistently defined within the different systems, and transactional data is supporting

this standardisation. For technical data it is expected the CIM standards will be used as a basis (e.g. IEC

61968).

The data model should be defined on different levels. IECo expects the bidder to come with the

documentation guidelines on the data models and data management strategy.

Figure 10-2: Data Model Levels

IECo would like to understand bidder’s perspective on how to create and maintain high data quality to

enable usability and smooth processes.

Figure 10-3: Data Quality Criteria

The IECo reference data model needs to be updated to ensure the data model is properly defined across

all systems. IECo expects the bidder to provide the updated data model as part of this project.

No: 10.4-1

Description: Data management strategy & data model.

Component: Systems


Priority: PREFERRED

Fit criterion: IECo expects the bidder to define a clear data management strategy to ensure all

relevant master data are uniquely and consistently defined within the different

systems, and transactional data is supporting this standardisation.

For technical data it is expected the CIM standards will be used as a basis (e.g. IEC

61968).

Evidence of

compliance:

The bidder describes his experience regarding the development of data models and

his experience with the CIM standards (IEC 61968).

No: 10.4-2

Description: Guidelines regarding data models and data management strategy.

Component: Systems


Priority: PREFERRED

Fit criterion: The bidder shall provide documentation guidelines on the data models and data management strategy.

Evidence of

compliance:

The bidder describes his approach on how data management & data governance will

be put in place during the project to ensure consistent data models, quality

monitoring, correction processes and business/IT process alignment. Bidder shows

how he has managed this at 2 other utility customers

No: 10.4-3

Description: Development of an updated data model.

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder shall develop and provide an updated data model as part of this project.

Evidence of

compliance:

The bidder agrees to comply to this requirement.

Non-functional requirements

The following expectations are set for the non-functional requirements of the E2E processes

10.5.1 Delivery & implementation

IECo expects an agile project organisation, likely based on SAFe. The large amount of internal IECo

stakeholders, need for iterative design & development of business processes, data models and system

architecture, and the expectation to gradually introduce business value during project implementation

are some of the drivers for which IECo sees an agile project organisation as the preferred approach.

IECo expects a Sprint 0 (or high-level design) phase, in which, among others, following activities are

expected:

1. Drafting of expected Features for the project and first prioritisation

2. Defining the first E2E business processes, which are must-have at the start of the roll-out

(partly already existing)

3. Defining the key elements of the data model, which are a must-have at roll-out start

4. Agreeing on system architecture and expected versioning & initial integrations

5. Planning of required security requirements

6. Defining the User Stories, relevant for Increment 1 (potentially more User Stories)

7. Ensuring business continuity

The potential roles of the bidder in comparison with IECo will be described further down this document,

though as additional roles IECo would expect agile coaching and driving the agile project organisation

forward as expected roles for the bidder.

IECo has experience with agile way-of-working, but would like to have the option to use the preferred

tooling of the bidder (e.g. Jira of similar tooling).

10.5.2 Methodology & standards

IECo expects the bidder to show their experience in PMP project management (or equivalent). The

proposed project management should show strong experience in meter roll-out, metering processes and

system integration.

For documentation standards, IECo is currently using LLD (low-level design) and interface documents.

IECo expects that these existing documentation standards won’t be sufficient for the project to be

successful. IECo would like to understand the documentation approach of the bidder to ensure clear

documentation of requirements & deliverables, (automated) test cases and transition to maintenance &

operations. IECo would expect that documentation will be created on multiple levels, and not only in Jira

or similar tooling.

It would help if business process & architecture design follows standards like BPMN 2.0 & ArchiMate 3.1,

but IECo would like understand bidder’s vision on the modelling approach.

The bidder will working following a DTP development platform, which ensures that configuration changes

and developments are being dealt with in a structured manner.

The bidder will create user manuals for the new functions created.

No: 10.5.2-1

Description: Experience in PMP project management.

Component: Project delivery


Priority: REQUIRED

Fit criterion: The bidder has the necessary experience and skills in PMP (or equivalent) project management and the key resources for the delivery (e.g. Product Manager & RTE) have strong project management skills.

Evidence of

compliance:

The bidder can prove that he fulfils this requirement.

No: 10.5.2-2

Description: Experience with BPMN 2.0 and ArchiMate 3.1.



Priority: PREFERRED

Fit criterion: Regarding business processes and architecture design it is preferred if the bidder has experience with BPMN 2.0 and ArchiMate 3.1.

The bidder explains his vision on the modelling approach.

Evidence of

compliance:

The bidder indicates if he has experience with BPMN 2.0 and ArchiMate 3.1.

The bidder explains his vision on the modelling approach.

No: 10.5.2-3

Description: Agile development (SAFe methodology).



Priority: REQUIRED

Fit criterion: The bidder has experience in agile development and with the SAFe methodology.

Evidence of

compliance:

The bidder describes his experience regarding agile development and the SAFe

methodology. As part of the project delivery plan bidder shows how SAFe will be

used for the project implementation

No: 10.5.2-4

Description: User manuals



Priority: REQUIRED

Fit criterion: The bidder will provide user manuals (on top of requirements, documentation and

test documentation) for IECo when delivering (new) functionality or making changes in existing functionality. It is expected that at least per increment, user manuals will be provided

Evidence of

compliance:

Confirmation of the bidder to deliver user manuals

10.5.3 Usability

IECo expects that users can work from 1 system and don’t need to switch between systems

unnecessarily (one-stop-shop). Any user activity should be reversible, including operational errors that

will use interfaces. Fixes should be mainly done via existing user interfaces, instead of backend

alterations. This means that end-users should be able to work from the different systems independently,

e.g.:

1. MDM

2. SAP ECC (via the SAP GUI)

3. ESRI GIS

4. BI/Analytics

5. SCADA/ADMS

6. WFM

It is not expected that cockpits (like SAP Fiori or UI5) will be developed as part of this tender. It is also

not expected that internal/external portals will be designed/developed as part of this tender.

When there are integrations of different systems for the user to successfully complete their tasks, the

end-users shouldn’t see/realise they might be working in and/or using different systems.

When UI extensions are needed to enable E2E processes and have an intuitive user experience these

extensions should be made in such a way that it doesn’t conflict with future system upgrades, patches,

and related software/hardware upgrades.

No: 10.5.3-1

Description: Requirement regarding response time for UI/UX (user experience)

Component: Systems


Priority: REQUIRED

Fit criterion: Response times of the UI/UX should be as follows:

1. Loading data on screen, information mgmt., forms, response on actions: all

<1s

2. Simple reports: all <10s

3. Complex reports: <30s

IECo doesn’t have standard UI/UX guidelines for the design, so IECo would like to

use bidder’s experiences on intuitive designs of the UI/UX when required to

develop/configure as such. It is expected to have as little clicks as possible and

provide user support

Evidence of

compliance:

The bidder indicates if these values are realistic.

The bidder describes his ideas and experience regarding the design and

development of ergonomic user interfaces.

10.5.4 Reliability

The new HES and potential other systems need to meet the requirements for (critical) infrastructure

components, allowing back-up/restore processes and potentially failover/fallback mechanisms. The

requirements for the HES will follow the requirements of the existing Honeywell Eiserver 9.1. The

integrations towards other systems and definition of potentially new systems will follow IECo’s

guidelines. Interfaces between system components and interfaces to external systems should have built-

in confirmations and retry mechanisms. The sending systems should retry several (configurable) number

of times if confirmation was not received. These guidelines will further be discussed upon awarding.

IECo would like to understand how the proposed system(s) of the bidder can meet reliability

requirements and which experiences or expectations the bidder has to ensure reliability.

IECo expects the bidder to document how the systems & interfaces will meet the reliability requirements.

No: 10.5.4-1

Description: System Reliability

Component: Systems


Priority: REQUIRED

Fit criterion: The systems should have a high-availability and should be set up taking reliability

issues into account. This means:

24/7 availability of the systems involved

Redundancy in place of hardware & software, including failover/fallback

mechanisms (e.g. cluster setup active-active or active-passive)

Recovery Point Objective = 0, Recovery Time Objective = 0,5-2h

System back-up and restore

Confirmation & resend mechanisms of interfaces to the system

Interface monitoring services, integrated in the existing IEC services

Clear KPIs for system reliability available (e.g. MTBF, MTTR)

Upgrades & patches can be performed without system downtime

Clear description on how the bidder performs configuration management

(methods, procedures, etc.)

Evidence of

compliance:

The bidder indicates if the systems he provides support a high-availability and

reliable setup and shows how this is being achieved.

No: 10.5.4-2

Description: Data storage & archiving

Component: Systems


Priority: REQUIRED

Fit criterion: Data that is stored in the system on a regular basis should be accessible and

available for retrieval for no less than 7 years from the time it has been recorded

Data backup in IECo is done by utilizing commvault Storage Manager for System

Backup and Recovery. The suggested solution must comply with this method or

provide an alternative method for backup procedure

Evidence of

compliance:

The bidder indicates if the systems he provides support a high-availability and

reliable setup.

No: 10.5.4-3

Description: Data correction

Component: Systems


Priority: REQUIRED

Fit criterion: Mistakes in data inputs will happen, which means the processes & systems need to

support correction processes via the UI/UX. Even when data and/or process inputs

impact multiple systems, the design of the system should allow corrections using

these interfaces. It is not envisioned that correction processes need to be done via

IT and database updates.

End user should have the ability to the and fix data (in)consistency.

Evidence of

compliance:

The bidder confirms that the solutions provided will allow data corrections and will

show this also as part of their tests

10.5.5 Safety

IECo has high regard for the safety of its own personnel and external contractors. The mass roll-out of

smart meters will create many additional site visits, which enhances the risk of safety incidents. IECo

would like to understand from the bidder which processes they have in place to improve safety and

mitigate the increased safety risks due to the nature of the project. The bidder will work together with

the main supplier(s) of the field force as part of this project for the mass roll-out

It is expected that employees of the bidder, working at IECo premises, will follow a (standard) safety

training provided by IECo.

10.5.6 Scalability

IECo expects to roll-out 3M smart meters in total, of which ~500k might be in the existing MDC/MDM

and ~2.5M will be installed using the bidder’s HES and other solutions. Due to potential growth the

system architecture, interfaces and all components should be sized for 4.2M meters. IECo expects the

bidder to show the performance for 3M meters and towards 4.2M meters.

It is expected that meter roll-out would have 300k meters/year, evenly distributed over the days/months

of the year. This would mean that processes like meter install should at least accommodate ~1000/day,

but preferable more.

No: 10.5.6-1

Description: Scalability

Component: Systems


Priority: REQUIRED

Fit criterion: The systems should support a smart meter park of approximately 3M to 4.2M

meters.

The bidder should have experience with smart meter projects of similar size and

complexity.

Evidence of

compliance:

The bidder indicates if he has the required experience, and presents some evidence.

10.5.7 Performance

The most performance demanding process is expected to be the meter reading towards billing/invoicing

process. For 3M (4.2M) meters, with an expected billing rate of:

1. Every two months for standard meters (80%)

2. Every day for prepayment (10%)

3. Every month for other (10%)

Besides standard meter reads there will be additional meter reads for switching/moving processes,

meter change and other metering processes. IECo has extended the existing MDUS with customer

specific fields, still following the standard, but with extra data fields added for premise and additional

device data. The time needed to get the E2E automated meter read process from a trigger in SAP IS-U

towards the “ready for billing” should not be limited by interfaces between the HES/MDM and SAP. This

should be solely driven by the non-functional expectations of the communications from the smart meter

to the HES/MDM.

For meter install, when meter master data is being replicated between different core systems, like MDM,

SAP, and GIS, IECo expect a near-instant data exchange to guarantee compliancy across the systems.

Also when firmware upgrades and configuration changes take place the system should stay performant.

When alarms are created, which are relevant for the SCADA/ADMS, IECo expects the generation of these

alarms in 10s (starting at event recognition HES/MDM).

Data downloads towards the DWH and data collectors should be defined in such a way that they don’t

interfere with operational processes and timely deliver the data needed for required business actions.

10.5.8 Flexibility/interoperability

It is expected to build/maintain a modular approach of systems to allow new capabilities being added by

either extending a current system or introducing a new system with these capabilities. To allow such an

architecture, the bidder should support that point-2-point integrations are generally non-existing (except

e.g. within an ERP package when SAP uses BDOC). Integrations will go via an integration layer.

11 PROJECT DELIVERY EXPECTATIONS

The following chapter describes IECo’s expectation on project delivery and role of the bidder

SAFe

IECo expects an agile delivery framework for this project. SAFe is designed to continuously help the

business & IT stakeholders and more efficiently deliver value on a regular and predictable schedule. It

provides a knowledge-base of proven, integrated principles and practices to support enterprise agility.

IECo has experience with agile way-of-working, though not in every aspect of the smart metering

implementation. This means that IECo expects the bidder to bring agile coaching and ensure the project

team works in a consistent way.

It is expected that many different stakeholders are interested in the different deliverables. An agile

approach, following SAFe, provides insight in the portfolio to be realised and provides a good basis to

plan the right stakeholder discussions at the right time.

Definition of business processes and/or use cases

One of the key elements for the project is to create clarity in the new business processes to be defined

and underlying data models and architectural components. IECo expects that an approach and first

views will be presented by the bidder during this tender process. As part of a “Sprint 0” the portfolio will

be further refined. IECo expects the bidder to drive the definition of the end-to-end business processes

and requirements to data models and architectural components, including ensuring business continuity.

When defining the E2E business processes, bidder should be aware of that IECo would like to have one

way of business process definition of the typical metering processes within the HES/MDM and the E2E

business processes with peripheral systems.

No: 11.2-1

Description: Business processes and use case definition.

Component: Systems


Priority: PREFERRED

Fit criterion: The bidder shall:

Present an approach and first view regarding the business processes, data

models and architectural components

Drive the definition of the end-to-end business processes and requirements

to data models and architectural components.

The bidder must show the necessary experience in this field

Evidence of

compliance:

The bidder indicates if he has the required experience, and presents some evidence.

Bidder roles within the project

IECo expects the bidder to take co-ordination of the smart meter roll-out and the design & integration of

services within the IECo business processes and system landscape. This means the bidder is the single &

main contractor and accountable for the services delivered. Any potential subcontractors, working for the

bidder, will perform their services under the accountability of the bidder.

IECo has internal development departments, an internal infrastructure & security organisation and

existing framework partners for specific integrations and/or systems. It is expected that these different

teams will be part of the overall project team, not at bidder’s cost. The bidder will be the overall

responsible co-ordinator to drive the end-to-end business processes, data models linked to smart

meters, functional & technical design, architecture & infrastructure, security, etc. The bidder will drive

the “master project plan”. The bidder also facilitates necessary project meetings and an agile way-of-

working. IECo expects the bidder to make the overall project plan, including the expectations for the 3rd

parties.

IECo will provide the necessary (counterpart) roles for this project, but would like to understand bidder’s

view on which roles are expected.

IECo expects the bidder to be able to configure/develop the Honeywell HES/MDMS. IECo expects the

bidder to configure/develop SAP, ESRI and other peripheral systems in the system landscape, including

the different integration technologies used, and challenge the existing internal departments & external

framework agreement partners with their developments.

When the upgrade to the latest Honeywell Connexo Suite will be made, IECo expects the bidder to bring

its experience with upgrades and potential migrations. IECo then also expects what, according to the

bidder, is the best approach to upgrade to Connexo, at the "start" of the project or in the "end" of the

project, and to understand from the bidder what the impact is on the project processes for both

alternatives, though no additional pricing for the different scenarios will be accepted.

It is expected that bidder will infuse some IECo employees in the DevOps teams for IECo to bring

specific knowhow to the development teams and the bidder to bring delivery and transition-2-

maintenance knowhow to IECo.

It is expected that most project activities will be performed on-site in Israel due to the secure nature of

many activities. Expert roles can be fulfilled differently, but the System Integrator (SI) should have clear

local presence and delivery experience.

Expected project roles for the bidder are (not limited to):

1. Program manager (counterpart, stakeholder)

2. Co-product manager (supporting IECo, who is in the lead)

3. RTE (delivery lead)

4. Development manager

5. Co-product owners (supporting IECo)

6. Scrum masters

7. System architect

8. Solution architects (architecture, infrastructure, security, development, …)

9. Developers

10. Testers (not acceptance test)

11. DevOps

12. Agile coach

13. Transition to maintenance

Besides the agile organisation IECo would like to understand bidder’s view on how the agile organisation

will be integrated/merged with the meter roll-out organisation, which likely follows a different approach.

No: 11.3-1

Description: Co-ordination activities.

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder shall take the E2E co-ordination role for the smart meter roll-out and the

design & integration of services within the IECo business processes and system

landscape.

Even when there are other parties involved in the maintenance of existing systems,

the bidder will still take the E2E co-ordination to drive the project and move forward

Evidence of

compliance:

The bidder agrees to comply with this requirement.

The bidder indicates if he has the required experience in this field, and presents

some evidence (e.g. of similar projects).

No: 11.3-2

Description: Experience in system development and configuration.

Component: Systems


Priority: REQUIRED

Fit criterion: They shall be able to:

Configure/develop on het Honeywell (HES)/MDMS

Configure/develop SAP, ESRI, and other peripheral systems in the system

landscape

Enable the upgrade to the Honeywell Connexo Suite, and bring his experience

regarding system upgrades and migrations:

o What, according to the bidder, is the best (and thus chosen) approach to

upgrade to Connexo, at the "start" of the project or at the "end" of the

project.

Evidence of

compliance:

The bidder indicates he can perform the activities, as mentioned in the fit criterion

Project timelines

IECo is planning to deploy approximately 300k meters per year. IECo doesn’t want to wait until the end

of the full deployment to start unlocking the value of AMI data, and expects them to be available as soon

as possible. IECo understands it might not fully unlock all value for its processes when the roll-out

doesn’t have a critical mass yet for certain services, but there shouldn’t be a limitation that the

integration of business processes and/or corresponding system architecture won’t be ready.

Scope clarification

IECo is looking for the best plan to achieve the business goals and create the highest value for its

business processes. As such IECo would truly like to understand bidder’s views on the leading practices

and integrations of smart meters with IECo’s core business processes. It is possible that IECo will limit

several of the scope items to ensure that IECo business & IT stakeholders are ready to fully use the new

functionality. This will be discussed (potentially) during the orals and afterwards. IECo wants to give the

bidder the full opportunity to show how IECo can best create its business value using the smart meters

and its data.

Transition to maintenance & operations

No: 11.6-1

Description: Transition plans to maintenance & operations.

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder shall develop clear transition plans for each increment and/or delivery to

the production environment (e.g. configuration, patches). This should include at a

minimum:

Successful go/no-go meeting for the upgrades, including acceptance of

maintenance organisation(s) and operations

Clarification of known issues (open points, scope questions and bugs)

Finished documentation of the deliverables (release notes, test reports,

design documentation, unless otherwise agreed for e.g. patches)

Successful demo sessions and user manuals with the relevant stakeholders

Training plan and delivery of training session for IT maintenance group and

system end users from IECo. (estimated in about 100 users of devices,

HES/MDM, WFM, etc). For specific details for training plans for devices,

cybersecurity and HES/MDM, see req. 12-6,12-7 and 12-8.

Evidence of

compliance:


The bidder can present some evidence (e.g. of similar projects) that he has done

such activities before.

No: 11.6-2

Description: Maintenance plan after warranty support

Component: Systems


Priority: REQUIRED

Fit criterion: The bidder shall develop clear plan for maintenance of the system after transition

period is over. This should include at a minimum:

Level of support (availability)

Language of support

Criticality of issues and response time

Link to Quality System of IECo (HP Quality Center)

Escalation procedure

Upgrade planning

Operating system upgrades

System extension requirements

Response to ad-hoc request from IECo

Evidence of

compliance:


The bidder can present some evidence (e.g. of similar projects) that he has done

such activities before.

Expected plans as part of this tender

As part of the tender IECo expects the bidder to address the following plans:

Table 11-1: Expected plans

Expected plans

Project delivery Scope, project organisation, PMO, resource plan, training plan for

meters, DCs, and HES, project schedule/timelines, critical path &

dependencies, risk & issue management, changes/revision process,

project progress reports, monthly SteerCo and relevant reports,

documentation guidelines, assumptions, …

System architecture &

infrastructure

Applications, integrations, infrastructure, plan to adjust the existing

system architecture, …

Configuration &

development

Required configuration & developments, UI/UX designs, AI/ML

integration, …

Data management Defining the data model, master/slave, …

Integration Which integrations, technologies, …

Conversion (partial) When upgrading towards to latest Connexo Suite potential migration is

needed in the existing HES/MDMS (Eiserver 9.1) and potential

conversions are needed to update data in GIS/SAP PM for meter master

data

Cyber & information

security, business

continuity

Security-by-design, integration within IECo security framework,

policies, …

Transition to

maintenance

Post go-live support, training the maintenance teams, expected SLA,

ability to reproduce errors in dev/test environments, potential data

updates via scripts/programs, …

Test & cut-over Unit test, integration test, cut-over, handover to acceptance test

Provisioning test as described in Appendix H.

UAT are not in scope and will be performed by another party. IECo

expects the end-to-end co-ordination and (some) counterparts for

design, configuration & development to remain during these activities.

IECo would expect the bidder to provide demo sessions to the relevant

stakeholders for new/changed functionality.

Transition period There will be a transition required from the current MDM/MDC provider

and system integrator to the new bidder. Description of transition plan

Maintenance period after

warranty period

Expected maintenance plan for the period defined in general conditions

Internal & external communications (e.g. communications plan), change management (e.g.

organisational impact/changes) and supporting functions like finance and procurement are not in scope

of this tender.

No: 11.7-1

Description: Requirement regarding project approach and project plans.



Priority: PREFERRED

Fit criterion: The bidder shall be able to provide the foreseen project approach including the

underlying project plans as described above.

It is allowed to provide these plans in one document or in different documents as

long as it is clear to IECo how the different topics have been addressed.

Evidence of

compliance:

The bidder agrees to comply with this requirement and will deliver the requested

plans. It will play an important role in the validation of the project approach and E2E

accountability and business value creation.

No: 11.7-2

Description: Progress measurements.



Priority: PREFERRED

Fit criterion: The bidder shall provide clear insights in the day-to-day progress of the project (e.g.

via JIRA reports)

The bidder shall provide clear overviews in risks & issue management, potential

change/revision requests, progress reporting, explanation for schedule delays

The bidder shall provide clear SteerCo documentation, besides the day-to-day

reporting

Evidence of

compliance:

Confirmation of the tenderer with the fit criteria

The tenderer provides templates on how the different reports (day-to-day,

aggregation, SteerCo) could look like

12 ADDITIONAL REQUIREMENTS FOR THE BIDDER

No: 12-1

Description: Presence in Israel.



Priority: REQUIRED

Fit criterion: The bidder must confirm that the project delivery will be managed locally in Israel

on IECo’s premises (including project work).

Evidence of

compliance:


No: 12-2

Description: Accountability for the project implementation.



Priority: REQUIRED

Fit criterion: The bidder should confirm the end-to-end accountability of the project

implementation. In case certain areas can’t be covered the bidder will provide a

clear reasoning for this and present their mitigation plan (with potentially a

subcontractor).

Evidence of

compliance:

The bidder agrees to comply with this requirement, indicates which areas can’t be

covered and provides his suggested mitigation plan.

No: 12-3

Description: Project team and CVs of key resources.



Priority: PREFERRED

Fit criterion: The bidder must provide a clear org. chart on how the project will be delivered,

including presenting the project team. We understand that a project team can

slightly change between this tender phase and project start, but 75% of the team

should be available for the project.

Before project start (but not part of the tendering process) IECo wants to interview

the proposed resources to validate knowhow/experiences and see if there is a good

“click” with the IECo project team. These interviews are relevant for the key

resources (e.g. Product Manager, RTE, System Architect, Security Architect, Roll-out

co-ordination), not for all developers/testers, etc.

It is possible that after the interview IECo will object to the specific resource and a

different person needs to be proposed by the bidder.

When resources will need to be replaced by the bidder during the contract, IECo

shall be able to approve/disapprove the proposed resource. In case of disapproval,

the bidder will present a different proposal.

The bidder needs to provide the CVs for the critical roles. It is possible to share

multiple CVs for a role if this would help showing the required skills.

Evidence of

compliance:

The bidder confirms the envisioned project team, its availability and provides the

relevant CVs.

Bidder also confirms that IECo can object/refuse specific resources for the

critical/vital positions and will provide a different resource

No: 12-4

Description: Result-driven and limitation of changes



Priority: REQUIRED

Fit criterion: For the E2E process integration IECo has defined the vision and goals to achieve,

allowing the bidder to provide the best solution to achieve these goals. There might

be minor deviations when going into details of the process implementation. IECo

expects the bidder to bring their leading practices and challenge IECo to use these

as much as possible. IECo also expects that the bidder confirms the

configuration/development of these goals without going into a continuous change

request approach.

A clear change request process needs to be in place, but this is merely for changing

business visions, changing regulatory changes the bidder couldn’t be aware of and

similar items.

IECo doesn’t allow an approach by the bidder to go for many change requests

during the project, as a standard way-of-working. When the developments are in

line with the agreed business vision/processes it is expected to be in scope.

The specific change request process is described in the general conditions and

agreement documents. IECo and bidder will agree in an hourly rate for a certain

amount of hours (called work hours bank) as described in those documents.

Evidence of

compliance:

The bidder agrees to realise the business goals/vision without going into detailed

change request discussions.

No: 12-5

Description: Manual meter reads for smart meters.



Priority: REQUIRED

Fit criterion: There is a separate project within IECo to manage meter reads when the reading

infrastructure can’t be used. There will be new integrations with the MDM to ensure

these meter reads are properly received. For this tender we expect 2 new medium

interfaces to be developed to/from this system (main goal of this requirements is

that readings done with the HHU can be transferred to the system).

Evidence of

compliance:

The bidder agrees these 2 new medium bidirexional interfaces are in the

estimations, including potential discussions with the other project team.

No: 12-6

Description: Training requirements for HES/MDM and WFM components



Priority: REQUIRED

Fit criterion: The number of participants for the training will be up to 20 IECo person for

HES/MDM and 20 IECo person for WFM.

The training will be held at IECo premises or remotely (except where explicit

mentioned), to be agreed between bidder and IECo.

The training language will be only in English or Hebrew.

Two weeks prior of starting the training, the awarded vendor will sent detailed

syllabus including detailed daily time table of the relevant study contents.

Trainings will be held according to the progress of the project, and will be held in the

following points in time:

Before first release is going to be put on production– 4 training days on test

environment at IECo premises.

After first version is installed in production environment and it is interfacing

with the devices and external systems connected to it:

o 1st cycle of 4 training days at IECo premises

o 2nd cycle of 4 training days at IECo premises

o 3rd cycle of 4 training days at IECo premises (optional)

The content of the training will be agreed between bidder and IECo, focusing

in hand-ons experience from IECo when using the system.

After each release to production environment

o 2 training days remotely (can be consecutive or not consecutive

days, according to IEC request)

After Hotfix

o 1/2 training day, remotely

Training for WFM system shall have a duration up to 5 working days, to be agreed

between bidder and IECo

There should be an option, by IECo demand, for extra training (up to additional 10

workdays) for each device.

Training will include hands-on training prepared in advance, and done in test

environment.

Training will include step-by step documentation (user manual) of every action that

needs to be done manually by the operator.This documentation will be embedded in

the built-in help menu of the product/products and will include IECo specific content

if applicable.

Evidence of

compliance:

Delivery of training plan.

No: 12-7

Description: Training requirements for devices



Priority: REQUIRED

Fit criterion: Required training per each device and model (Meter / DC / Other) is 5 workdays

(workday: Sunday to Thursday).

The training per each device will also include training on the supplied software for

each device.

There should be an option, by IECo demand, for extra training (up to additional 5

workdays) for each device.

The number of participants for the training per each device will be up to 15 IECo

persons.

The training will be a face to face session held in IECo premises. IECo will supply the

necessary environment: classroom and teaching aids such as: projector, board and

etc. (In case there will be a problem with frontal study due to COVID19 then a

remote study should be considered as alternative)

The training will include supplying full documentation of the training and necessary

documentation per each device and software such as: user manuals, technical

sheets and etc.


Two weeks prior of starting the training, the awarded vendor will sent detailed

syllabus including detailed daily time table of the relevant study contents.

The instructors of the training should be an AMI professionals, with deep knowledge

and understanding of all the details of the equipment

Evidence of

compliance:


No: 12-8

Description: Training requirements for cybersecurity



Priority: REQUIRED

Fit criterion: The training will generally be delivered for at least 15 days

The number of participants for the training will be up to 15 IECo persons

The training will include supplying full documentation of the training and necessary

documentation

The training will be a face to face session held in IECo premises. IECo will supply the

necessary environment: classroom and teaching aids such as projector, board, etc.

(In case there will be a problem with frontal study due to COVID19 then a remote

study should be considered as an alternative)

Two weeks prior to starting the training, the awarded vendor will be sent a detailed

syllabus including a detailed daily timetable of the relevant study contents.


The training should include the following topics:

1) E-Meters Security

a) Hardware architecture.

i) Overview

ii) Cryptography operation protection

iii) Encryption keys protection

iv) P1/consumer port one-way protection/security

v) Firmware update process protection

b) Software architecture

i) Overview

ii) External interfaces and protocols overview

iii) External interfaces security

iv) Software hardening

v) Cryptography operations protection

vi) Encryption keys protection

vii) Firmware signing control

c) Authentication processing

i) Overview

ii) Technician local access

iii) IHD user access

d) Authorization processing

i) Overview

ii) Role-based access

e) Secure logs and alerts mechanisms

2) Data Concentrator security

a) Hardware architecture.

i) Overview.

ii) Cryptography operation protection

iii) Encryption keys protection

iv) Firmware update process protection

b) Software architecture

i) Overview

ii) External interfaces and protocols overview

iii) External interfaces security

iv) Software hardening

v) Cryptography operations protection

vi) Encryption keys protection.

c) Authentication processing

i) Overview

ii) Password policy enforcement

iii) Password protection.

iv) Technician local access

v) Technician remote access

d) Authorization processing

i) Overview


3) HES security

a) Software architecture.

i) Overview

ii) Key Management System overview

iii) Keys generation overview.

iv) External interfaces and protocols overview

v) External interfaces security

vi) Software hardening

vii) Cryptography operations protection

viii) Encryption keys protection

ix) Keys export protection

x) Automatic and manual keys enrolment

b) Authentication processing

i) Overview.

c) Authorization processing

i) Overview


4) General

a) System integration overview

b) Secure zoning and segmentation principles

c) DLMA COSEM security suite (0/1)

d) Data model security

e) Security event and logging

f) Authentication processing

g) Authorization processing

h) Other security elements in the project

Evidence of

compliance:


13 KPI FOR THE SMART METERING PROJECT

General

The smart metering project is a large and complex investment which combines new technology that will

impact operational processes, installation and logistics and integration between systems. The technology

will be procured from a solution provider, while IECo will do the installation of smart metering

components.

A smart metering project organization includes several roles needed to manage the project and

interfaces to adjacent projects and processes, e.g. the MDMS project and integrations.

To secure the right focus from project management and to secure commitment towards objectives, KPI’s

have been prepared. The bidder must provide a dashboard to monitor all KPI’s, or provide the raw data

for such a dashboard.

The smart metering project is designed into three phases; 1) the preparatory phase, 2) the system

deployment phase and 3) the stabilization phase. Each of the project phases should be broken into

manageable stages. The major milestones are included to the timeline together with the focus, actions

and deliverables for each of the stages. All KPI's will be measured End to END.

Figure 13-1: Smart Metering Project Phases

The project will have three distinct phases:

1. Preparatory phase.

2. System Deployment phase. 3. Post Deployment phase.

Preparatory Phase

The project team needs to cover the relevant subjects and IECo business areas that needs to be planned

for and contracted. This phase will require resources sufficient in capacity, but also resources that know

IECo operations, infrastructure and culture. No specific KPI’s or deliverables have been defined for this

phase.

System Deployment Phase

The project team will in this phase have two focus areas; a) to manage installation resources and

logistics, and b) to follow up deployment, verify, commission and approve stages. This stage will require

resources sufficient to execute on installation and to follow up the deliverables and to operate the

system after commissioning. Relevant are:

Pilot & Ramp-up

Deployment& Operation

13.3.1 Pilot & Ramp-up

For the pilot and ramp-up phase a number of deliverables and activities can be defined. No specific KPI’s

have been defined for this stage.

IECo will perform an Operational Acceptance test after finalisation of this phase and before start of the

deployment phase. Bidder will support this test.

13.3.2 Deployment & Operation

For the deployment and operation phase a number of deliverables, activities and KPI’s can be defined:

For the deployment phase the KPI’s as shown in Table 13-1 are defined.

Pilot & Ramp-up

Focus: Installing systems, integrating and test/verify roll-out processes (incl logistics), conclude on Area/Stages for roll-out. Deliverables /activities:

Prepare for acceptance tests

Technical test Integration test System integration pilot Installation and operations pilot (linked to procurement strategy) Logistics Conclude on Area/Stages for roll-out

Deployment & Operation


Deployment & Operations

Focus: Mass roll-out, commissioning stages, IEC system operations (hand-over depends on procurement strategy and contract), and continuous improvement.

Deliverables /activities:

Logistics Installation Stage approvals Stage commissioning (depends on procurement strategy) Improve processes (stabilization and change may start already here; depends on

strategy and contract)

Pilot & Ramp-up


Table 13-1: Deployment KPIs

For the Operations phase the KPIs as shown in Table 13-2 are defined.

Table 13-2: Operations KPI's

No KPI Frequency Target KPI Definition

5. On-demand

meter readings

Weekly >95% Total number of on-demand functionalities successfully tested weekly

/ (total number of on-demand functionalities tested weekly) X 100%

6. Metering

performance

(Billing)

Daily >90% 90% of the data originated in one day (from 00:00 to 12:00:00) must

be stored and available in the Central Database, no later than 5 hours

after the end of the analyzed day (05:00 AM).

7. Metering

performance

(Billing)




8. Metering

performance

(Billing)


be stored and available in the Central Database, no later than 24

hours after the end of the analyzed day.

9. Metering

performance

(Billing)


be stored and available in the Central Database, no later than 5 days

after the end of the analyzed day.

10. Metering

performance

(Billing)

Monthly 100% 100% of the data originated in a calendar month must be stored and

available in the Central Database, at the latest, after seven running

days after the end of the analyzed month. 100% of data should exist

after execution of the VEE process (Validation, Estimation, Editing

process).

11. Metering

performance

(Load Profile)





1. Manpower

deployed

Weekly >99% Total manpower deployed on ground / total manpower that should be

deployed on ground X 100%

2. Deployment

progress

Weekly >99% Total cumulative number of smart meters installed / total number of

smart meters to be installed up until that point in time X 100%

3. Smart meter

installation

success

Weekly >97% Number of smart meters registered in the AMI within 24 hours after

installation / total number of smart meters installed X 100%

4. Training

completion

Monthly >90% Total number of employees trained in the period / total number of

employees scheduled for training in the period X 100%

12. Metering

performance

(Load Profile)


be stored and available in the Central Database, no later than 24

hours after the end of the analyzed day.

13. Metering

performance

(Load Profile)


be stored and available in the Central Database, no later than 5 days

after the end of the analyzed day.

14. Metering

performance

(Load Profile)

Monthly 100% 100% of the data originated in a calendar month must be stored and

available in the Central Database, at the latest, after seven running

days after the end of the analyzed month. 100% of data should exist

after execution of the VEE process (Validation, Estimation, Editing

process).

15. Events and

Alarms

Monitoring

performance

Daily >95% 95% of the (AMI) Events and Alarms originated in one day (from

00:00 to 23:59:59) must be stored and available in the Central

Database, no later than 24 hours after the end of the analyzed day.

16. Events and

Alarms

Monitoring

performance

Daily >99% 99% of the (AMI) Events and Alarms originated in one day (from

00:00 to 23:59:59) must be stored and available in the Central

Database, no later than 5 days after the end of the analyzed day.

17. Disconnections1 Daily >90% 90% of the disconnections or limitations to Clients and / or Users in

one day (from 00:00 to 23:59:59) must be carried out successfully

within 1 hour of the disconnection request.

18. Disconnections1 Daily >98% 98% of the disconnections or limitations to Clients and / or Users in

one day (from 00:00 to 23:59:59) must be carried out successfully

within 3 hours of the disconnection request.

19. Reconnections1 Daily >90% 90% of the reconnections of Clients and / or Users in one day (from

00:00 to 23:59:59) must be carried out successfully within 15 minutes

of the reconnection request.

20. Reconnections1 Daily >98% 98% of the reconnections of Clients and / or Users in one day (from

00:00 to 23:59:59) must be carried out successfully within 30 minutes

of the reconnection request.

21. Firmware update Monthly >99% 99% of the firmware upgrade send to the meters in 30 days must be

carried out successfully.

22. Reporting Daily

Weekly

Monthly

100% Once the interval period as mentioned in the KPI’s has elapsed, the

data as mentioned in the KPI must be available in the data warehouse,

through information platforms or digital applications, within a period of

no more than one hour.

23. Reporting Daily 100% Provide up to date reports for maintenance in the field by 6 AM daily.

1 Note that disconnections are done massively in the morning of working days (can be thousands of simultaneous disconnection requests) and

reconnections are spread over the day and can be done at any time that the customer filled his credit

Post Deployment Phase

The project will in this phase follow up on the system operation, standardization of processes and to

close potential open issues. This phase is foreseen to be the less resource demanding. From a timing

perspective this is into the future, and is less likely to include a detailed plan further than best practice.

Relevant are:

Stabilization and Operational Acceptance

13.4.1 Stabilization and Operational Acceptance

For the stabilization and operational acceptance phase a number of deliverables, activities and KPI’s can

be defined.

For the stabilization phase the KPIs as shown in are defined.

Table 13-3: Stabilization KPIs

System shall comply with the above mentioned KPIs and the performance requested in 10.5.6 for the

whole contract duration, including maintenance period.


24. Defects

resolution

success

Monthly >90% Number of defects resolved within target resolution duration / (total

number of defects resolved + total number of defects not resolved and

past target resolution duration) X 100%

25. Affected

Devices

Monthly <2% Number of affected devices by cybersecurity incidents / total devices

deployed and connected X 100%

26. Response time Weekly >90% Total number of CONTRACTOR’s responses within 24 hours after

receiving written requests / total number of written requests X 100%

Stabilization

Focus: Final approval period, monitoring the performance of the deployed Smart Metering System Deliverables /activities:

Final approval period, conclude contract

Verify stable operations Clean-up and tuning (remaining) Standardize tools and methods Secure repeatability in operations, maintain quality and effectiveness Transfer to line operations

Post Deployment Phase

PLC FILTERS

A.1 Overview of needed filter types

The following types of PLC filters are needed (more technical details for each filter type can be found

below):

1 phase, 40 dB attenuation, 40 A





A.2 Technical details

A.2.1 Technical details 1 Ph, 40 dB, 40A PLC filter

Operating Voltage: nominal 230V.

Operating Frequency: 50Hz.

Operating Temperature Range: -10ºC to +50ºC.

Operating Current at ambient temp: 40A.

Attenuation Level: min. 35dB @ 36kHz-40kHz. 40dB @ 41kHz-90kHz.

In case of neutral connection, it should be solidly connected (without introducing any impedance

on neutral path).

Filter's response curve (attenuation vs. frequency) should be provided in a datasheet.








on neutral path).









on neutral path).



Operating three phase Voltage: nominal 400V.



Operating Current at ambient temp: 3x65A.



on neutral path).



Operating three phase Voltage: nominal 400V.



Operating Current at ambient temp: 3x80A.



on neutral path).


A.3 Mechanical details

Filter's dimensions in mm:

o For the 1 Ph Filters: Maximum 200L × 110W × 100H.

o For the 3 Ph Filters: Maximum 250L × 150W × 100H.

Terminal: min. 35mm² cable insertion with two screws. screw diameter should be at least M6.

Filter's case should consist of insulated material, to avoid any grounding connections.

The tightening torque to ensure a good connection shall be less than 3 Nm. This value shall be

specified by the manufacturer.

With a value of 1.5 times the value specified by the manufacturer, with a minimum of 3.5 Nm, it

should be possible to tighten and loose the screws 25 times without damage.

The screw bottom must be chamfered, without rough edges. The pinching screws must be made

either of Steel 8,8 and be Nickel plated (5 micron min), or made of brass and be protected

against corrosion.

In any case, there should be no galvanic couple between the screws, terminals, and copper

conductor/thimble. Alloys potential difference must not exceed 0.15V (refer ASTM G82

Standard).

The filters must be supplied with all terminal screws fully inserted into the terminals, and

tightened enough to prevent being loosened due to vibrations during transportation.

The construction of the terminals must protect the screws from dropping off or into the filter

terminals when loosing.

A.4 Label

The label shall include bar-code mark done in code 128C with 12 digits, the first four digits are for the

filter distinguishing code, that will be given for each type, 2 digits are for manufacturing year and 6

digits are for the serial number, adding leading zeros if necessary.

Thus, the bar-code and serial number should be in a format CCCCYYNNNNNN

A.5 Safety

Protection against electric shock according to IEC 61140 or similar known standard.

Ingress Protection: Class IP20 (finger proof), according to IEC 60529.

Case: Self-extinguishing class V-2, according to IEC 60695-11-10.

IECo experts may ask to visit the manufacturer's plant at the technical stage of proposal evaluation or

later in order to observe the filters production / testing processes.

ENERGY REGISTERS MEASUREMENT METHOD

B.1 Dual and single Energy metering method modes

IECo requires a dual energy metering method capability: arithmetic and vector. Arithmetic and vector

metering modes shall be selectable within configuration by flag or register. Vector metering mode shall be

a default mode and be in accordance with the implementation specification defined below.

B.2 Energy Registers

For direct meters the absolute values of active energy consumption shall be stored in the main energy

register (15.8.x), which will show the "absolute kWh total consumption". The content of this register

will be a default display, and also be readable via: optical port, PLC (PLC meter), cellular (cellular

meter or DC).

When a vector metering method is used then the "absolute metering" shall be based on vector

metering registers. When an arithmetic metering method is used then the "absolute metering" shall

be based on arithmetic metering registers using register 15.8.x. A detailed use case example is shown

at Table 5 - "vector and arithmetic metering use cases – phases energies and corresponding vector

reading" (Taken from reference [3]).

The meter shall support the following registers as described in table 1.

Table 1 – Active Energy Registers

Registration OBIS code

Active import Rate 1 1-0:1.8.1*255




Active export Rate 1 1-0:2.8.1*255




Active import total over all rates 1-0:1.8.0*255

Active export total over all rates 1-0:2.8.0*255

For CT meters the following energy registers shall also be available: reactive import, reactive

export for each rate in accordance with table 2

Table 2 – Reactive Energy Registers

Registration OBIS code

Reactive import Rate 1 1-0:3.8.1*255




Reactive export Rate 1 1-0:4.8.1*255




Reactive import total over all rates 1-0:3.8.0*255

Reactive export total over all rates 1-0:4.8.0*255

All the above registers should be displayed on the meter display according to the

configuration.

B.2.1 Vector metering

For billing IECo intends to use vector metering method. Attached herein specification: Vector metering

method implementation (as opposed to arithmetic method). In the vectorial method the meter calculates

the net real energy flow by vectorial summing the phase energy flows. In this method, the net energy

flow will be placed in only one quadrant being the net vector.

B.2.1.1 Standard References

Definition of vector metering method is based on standards [1], [2]. Reference [3] is European Union

forum (EBIX2) specification (not a standard).

B.2.1.2 Definition of vector metering method

Active import and Active export value energy metering (OBIS: 1.8.0, 2.8.0) is mandatory, and it shall be

used for billing and in accordance with following formula:

Billing registers formula:

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(1.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟): 𝑖𝑓( (𝐸𝐴,1 + 𝐸𝐴,2 + 𝐸𝐴,3) > 0)

𝑡ℎ𝑒𝑛 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 = |𝐸𝐴,1 + 𝐸𝐴,2 + 𝐸𝐴,3|, 𝑒𝑙𝑠𝑒 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 = 𝑢𝑛𝑐ℎ𝑎𝑛𝑔𝑒𝑑

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(2.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟): 𝑖𝑓( (𝐸𝐴,1 + 𝐸𝐴,2 + 𝐸𝐴,3) < 0)

𝑡ℎ𝑒𝑛 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 = |𝐸𝐴,1 + 𝐸𝐴,2 + 𝐸𝐴,3|, 𝑒𝑙𝑠𝑒 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 = 𝑢𝑛𝑐ℎ𝑎𝑛𝑔𝑒𝑑

Following flow-diagram puts it in clear presentation:

2 ebIX is a European platform in which TSO’s, DSO’s, suppliers and regulators work together. The

purpose of ebIX, the European forum for energy Business Information eXchange, is to advance, develop and standardise the use of electronic information exchange in the energy industry.

Yes

No

Fig. 1: flow diagram definition of active {import, export} billing registers

Comment: flow diagram is not an implementation. It is standard definition derived from

formula. References [1]-[2] are the standards

B.2.1.3 Load profile vector metering

Same flow-diagram as Fig. 1, and above formula must be applied to the load profile channels at periodic

level with the exception that instead of unchanged value, 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡/𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙shall be set to zero as

reflecting periodic differential energy rather than accumulative energy. IECo enables either incremental

or differential periodic metering. The definition changes accordingly.

B.2.1.4 Reactive vector metering

Reactive import and Reactive export value energy metering (OBIS: 3.8.0, 4.8.0) is mandatory, and its

corresponding load profile channels shall be used for following objectives, and not for billing, and in

accordance with following formula. On Fig. 1, and in above formula the following replacements must

occur:

Table 3: Active to Reactive parameters mapping in vector method definition of reactive energy

Active Energy parameter Reactive Energy parameter 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(1.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟) 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(3.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟)

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(2.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟) 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(4.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟)

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙

𝐸𝐴,1 𝐸𝑅,1



Reactive energy usage (is required for):

Table 4: implementations that require reactive energy load profile import/export channels

No. Usage Comments

1 Compute Power Factor (PF) as a mandate to oblige consumers

to improve PF.

Primary usage

2 Visualize reactive energy on a display, not use it for billing Primary usage

3 Use reactive load profile for AI application that identifies premise loads and perform remote predictive maintenance

4 Premise measurement: Use reactive load profile for AI application that identifies consumer fraud detection, phase polarity reversal, phase disconnects, and abnormal super-consumption

5 Same as 4) only for electric grid measurement.

Comment: Currently reactive load profile is required from the meter but the read data is in

accordance with the data model.

Definition: Same reactive vector metering formula as specified in above formula for active metering, except

following changes:

1) OBIS 3.8.0 reactive import register

2) OBIS 4.8.0 reactive export

3) The parameters must be replaced according to table 3 above.

B.2.1.5 Load profile formula

Channels are matching OBIS registers 3.8.0, 4.8.0. Same flow-diagram as Fig. 1 must be applied to the

load profile on periodic level, with exception that periodic value is zero when corresponding register value

is unchanged. IECo enables either incremental or differential periodic metering. The definition changes

accordingly.

Same reactive vector metering formula as specified in above formula for active metering, except following

changes:




B.2.2 Arithmetic metering

When configuration is set to Arithmetic metering then for billing IECo intends to use arithmetic metering

method. Attached herein specification: "Arithmetic metering" method implementation (as opposed to

vector method). In the arithmetic method the meter calculates the energy flow by arithmetic summing the

phase energy flows. In this method, the energy flow from load to grid is placed in export register.

B.2.2.1 Standard References

Definition of arithmetic metering method is based on standards [1], [2]. Reference [3] is European Union

forum (EBIX3) specification (not a standard).

B.2.2.2 Definition of arithmetic metering method

Active import and Active export value energy metering (OBIS: 1.8.0, 2.8.0) is mandatory, and it shall be

used for billing and in accordance with following formula:

Billing registers formula:

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(1.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟): ∑ 𝐸𝐴,𝑖𝑎𝑙𝑙 𝑝ℎ𝑎𝑠𝑒𝑠 𝑖 𝑤ℎ𝑒𝑟𝑒 𝐸𝐴,𝑖>0

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(2.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟) = ∑ 𝐸𝐴,𝑖𝑎𝑙𝑙 𝑝ℎ𝑎𝑠𝑒𝑠 𝑖 𝑤ℎ𝑒𝑟𝑒 𝐸𝐴,𝑖<0

Where:

∑i − mean "sum over all i such that <condition> is maintained"

𝐸𝐴,𝑖 > 0 means energy flowing from electric grid to load/customer

𝐸𝐴,𝑖 < 0 means energy flowing from load/customer to electric grid

3 ebIX is a European platform in which TSO’s, DSO’s, suppliers and regulators work together. The

purpose of ebIX, the European forum for energy Business Information eXchange, is to advance, develop and standardise the use of electronic information exchange in the energy industry.

Following flow-diagram puts it in clear presentation:

Fig. 2: flow diagram definition of arithmetic active {import, export} billing registers

Comment: flow diagram is not an implementation. It is standard definition derived from

formula. References [1]-[2] are the standards

B.2.2.3 Load profile arithmetic metering

Same flow-diagram as Fig. 2, and above formula must be applied to the load profile channels on periodic

level with the exception that instead of unchanged value, 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡/𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 shall be set to zero as

reflecting periodic differential energy rather than accumulative energy. IECo enables either incremental

or differential periodic metering. The definition changes accordingly.

B.2.2.4 Reactive arithmetic metering

Reactive import and Reactive export value energy metering (OBIS: 3.8.0, 4.8.0) is mandatory, and its

corresponding load profile channels shall be used for following objectives, and not for billing, and in

accordance to following formula. On Fig. 2, and in above formula the following replacements must occur:

Table 3: Active to Reactive parameters mapping in arithmetic method definition of reactive energy

Active Energy parameter Reactive Energy parameter 𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(1.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟) 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(3.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟)

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(2.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟) 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(4.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟)

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙 𝐸𝑟𝑒𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙




Reactive energy usage (is required for):

Table 4: implementations that require reactive energy load profile import/export channels

No. Usage Comments

1 Compute Power Factor (PF) as a mandate to oblige consumers to improve PF.

Primary usage

Yes

No

ራ ⬚⬚

𝐸𝐴,𝑖 > 0

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑖𝑚𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(1.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟) :

∑ 𝐸𝐴,𝑖𝑎𝑙𝑙 𝑝ℎ𝑎𝑠𝑒𝑠 𝑖 𝑤ℎ𝑒𝑟𝑒 𝐸𝐴,𝑖>0

𝐸 (2.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟)

𝐸𝑎𝑐𝑡𝑖𝑣𝑒,𝑒𝑥𝑝𝑜𝑟𝑡,𝑇𝑜𝑡𝑎𝑙(2.8.0 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟)

= ∑ 𝐸𝐴,𝑖𝑎𝑙𝑙 𝑝ℎ𝑎𝑠𝑒𝑠 𝑖 𝑤ℎ𝑒𝑟𝑒 𝐸𝐴,𝑖<0

2 Visualize reactive energy on a display, not use it for billing Primary usage

3 Use reactive load profile for AI application that identifies premise loads and perform remote predictive maintenance

4 Premise measurement: Use reactive load profile for AI application that identifies consumer fraud detection, phase polarity reversal, phase disconnects, and abnormal super-consumption

5 Same as 4) only for electric grid measurement.

Comment: Currently reactive load profile is required from the meter but the read data is in

accordance with the data model.

Definition: Same reactive arithmetic metering formula as specified in above formula for active metering,

except following changes:




B.2.2.5 Load profile formula

Channels are matching OBIS registers 3.8.0, 4.8.0. Same flow-diagram as Fig. 2 must be applied to the

load profile on periodic level, with exception that periodic value is zero when corresponding register value

is unchanged. IECo enables either incremental or differential periodic metering. The definition changes

accordingly.

Same reactive arithmetic metering formula as specified in above formula for active metering, except

following changes:




B.2.3 Use case example table for vector and arithmetic metering

The following table lists use cases and the required outcome vector and arithmetic metering result

Table 5: vector and arithmetic metering use cases – phases energies and corresponding vector reading (Taken from reference [3])

Absolute

(Arithmetic)

Absolute

(Vector)

Vector

Default metering mode

Arithmetic

|Import| +|Export|

|Import| +|Export|

Export Import Export Import Phase T Wh)

Phase S

(Wh)

Phase R

(Wh)

Period index

4 0 0 0 2 2 -1 -1 2 1

16 0 0 0 8 8 -8 4 4 2

B.2.4 Testability

IECo preserves the right to validate over meter samples submitted to IECo correct "vector and arithmetic

metering" implementation. Test segments are derived (implied) from "metering methods" following valid

standard and regulatory documentation [1]-[4] bellow.

Table 6: test cases

no Test description (for arithmetic in arithmetic mode and for vector in vector mode)

Comments

1 Test billing registers "Active import, export" under various conditions where simultaneous Active import, Active export energy flows exist

As compared to reference meter or power standard

2 Test load profile channels "Active import, export" under various conditions where simultaneous Active import, Active export energy flows exist

-"-

3 Test billing registers "Reactive import, export" under various conditions where

simultaneous Reactive import, Reactive export energy flows exist

-"-

4 Test load profile channels "Reactive import, export" under various conditions where simultaneous Reactive import, Reactive export energy flows exist

-"-

B.2.5 Functional requirements from data model

All above changes must be transparent to data model and all software tools, systems. No change of operation of these systems must occur. An event notifying that transition to specific vector/arithmetic mode must occur.

B.2.6 Functional requirements in favour of Meter Data Management

System

Regarding Meter configuration for Arithmetic and Vector metering: In order to manage this configuration from MDM, IECo requires the following information in MDM:

B.2.6.1 General firmware requirements:

a. Specific events are created in the meter during the transition from one metering method (arithmetic/vector) to the other (vector/arithmetic)

b. The transition from one metering mode to the other must be performed via configuration and not change of firmware version in accordance with section 1 above.

B.2.6.2 Regarding PLC meter

a. Configuration of the meter to change the metering method shall be performed via

using B09/B05/B12 and coordination of system with IECo. Metering method configuration must be specified to IECo and become available in MDMs.

10 4 0 4 3 7 4 3 -3 3

8 4 4 0 6 2 -4 2 -2 4

13 9 0 9 2 11 -2 4 7 5

51 17 4 13 21 30

Total

b. Reading ability of the meter configuration of metering method, must be enabled and

be included in S06 or S6B. Manufacturer must notify IECo which port taken.

B.2.6.3 Regarding Cellular meter

a. Configuration of the meter to change the metering method must be specified to IECo and become available in MDMs.

b. Reading the meter configuration of metering method must be available via OBIS register. This need to be included in general data reading

References: [1] IEEE 1459 -2010: IEEE Standard Definitions for the Measurement of Electric Power Quantities Under Sinusoidal, Nonsinusoidal, Balanced, or Unbalanced Conditions [2] DIN 40110-1, 3: QUANTITIES USED IN ALTERNATING CURRENT THEORY; TWO-LINE CIRCUITS

[3] "Smart meter reading method", European union document by Regulatory organization "European forum for energy Business Information eXchange" (EBIX), 2017. [4] "Power Definitions and the Physical Mechanism of Power Flow", IEEE, chapter 4, Prof. Alexander Eigeles Emanuel.

SPECIFICATIONS REGARDING CURRENT

INSTRUMENT TRANSFORMERS

C.1 Type of Current Instrument Transformers in Scope

The following type of current instrument transformers are in scope of this specification:

Rated Primary

Current

Accuracy Class Rated Burden Highest Voltage

for Equipment

Type

1000 A 0.2S 5 VA 0.72 kV Solid Core

1000 A 0.5 5 VA 0.72 kV Outdoor Split Core

1000 A 0.5 5 VA 0.72 kV Indoor Split Core

C.2 Required Documents for Evaluation of Technical Proposal

In order to show compliance with this specification, the bidder is required to submit the following

documents in ENGLISH, in the required format and form, and on a schedule as required herein:

A Reference list of Electricity Utilities to whom commercial quantities of the transformers have

been supplied during the last 3 years. The list shall include the name of the utility, the country,

the quantity of supplied items - detailed by types and date of supply.

The manufacturer shall have a Quality Management System (QMS) having a certificate

evidencing compliance with the requirements of the valid edition of ISO 9001, on the date

specified for submission of the proposal.

o Approval of conformance with the ISO 9001 requirements, as indicated in clause above,

shall be in a form of a certificate issued by a Certification Body (CB) which is accredited

by an Accreditation Body (AB).

o The certificate should bare the logo of the CB and of its AB and/or the logo of the IAF.

o The certificate shall be valid at least on the last date set for technical clarifications of the

proposal.

o The certificate shall be valid for the scope of activities requested in the request for

proposal.

Five (5) samples of each proposed transformers type. The samples will be subjected to tests at

IECo laboratories, at their sole discretion, to prove compliance with this specification.

A list of the active equipment in manufacturer’s laboratory, as a proof to its ability to perform

Routine Tests on each unit of the proposed transformer, according to section C.8.2, in this

specification.

The type tests' reports and results as performed in an accredited laboratory on the provided

sample transformer or similar type of the transformer, in which all the relevant tests have

successfully passed. Refer specifically to section C.8.1 of this specification. The type tests should

have been performed within the last 10 years from the date of the tender publication.

o Remark: In the context of this paragraph, a "similar type" means a CT which:

Has the same constructions;

Is manufactured at the same plant, with the same technology and the same

materials;

Is designed to operate at the same environmental conditions.

The routine tests report and results as performed on the proposed transformer, in which all the

relevant tests have successfully passed. Refer specifically to section C.8.2 of this specification.

A copy of the Quality Assurance Manual and the Quality Control System as per section C.3 and

C.4 in this specification.

A copy of the following documents and drawings:

o Drawings of construction, detailed dimensions as per section C.7.2 of this specification,

clearly stating. All dimensions shall be in Metric Units.

o Drawing of the rating plate markings (nameplate drawings).

o Details of construction like bolts or screws and terminals with their tightening torques.

o Definition of each Insulation Material used for manufacturing the transformers.

o Instructions for installation, handling, use and maintenance.

o Complete and filled-in Summary of Data of this specification per transformer type.

(section C.10).

Besides the Quality Assurance Certificate requested above, the bidder shall submit copies of:

o Design of Control Procedures (as applicable).

o List of qualified suppliers of the main parts, components and raw materials (as

applicable).

The manufacturer statement that the proposed transformers comply with the requirements of

this specification and if there are deviations, the manufacturer has to clearly state them for the

Purchaser's knowledge.

Definition:

CB – An independent external body authorized to confirm that the bidder / supplier's Management

System conforms to the requirements specified in the standard, by issuing a certificate. The CB should

be accredited to certify by an AB.

AB – An independent body, being a member of the International Accreditation Forum Multilateral

Arrangement – IAF MLA, having authority to formally approve, by means of document, the competence

of a certification body to provide certification services.

C.3 Quality Control

The Bidder/Supplier shall submit with its proposal a preliminary Inspection and Test Plan (I&T Plan)

which is applied during the production of the equipment.

Inspection and Test certificates as required in the Specification and the applicable Standards, shall

be submitted immediately following their generation. The certificates shall be original, signed by the

Bidder/Supplier and contain actual measured values. The generation of certificates, including those

generated by subcontractors and sub-suppliers, shall bear no extra cost to purchaser.

An Inspection and Test Plan including witnesses and hold points shall be mutually agreed between

the Purchaser and the Bidder/Supplier. Any subsequent alteration to this program shall require the

Purchaser agreement prior to start of any work affected by these alterations.

The Bidder/Supplier shall prepare and submit a schedule for the Routine tests, according to the

requirements of this specification before the testing.

Any equipment non-conforming with drawings’ specifications or any other purchase order

requirements, which are considered by the Contractor as “acceptable as is” or "for repair”, shall be

submitted to the Purchaser for approval, with their recommended disposition. All such non-

conformances shall be approved by the Purchaser (IECo) in writing, and a copy of the approval shall

accompany each shipment.

All Materials used in the manufacturing of the equipment shall conform to the Specification,

approved drawings and accepted Standards.

The Bidder/Supplier shall submit 1 (one) copy of:

o Manufacturing Quality Plan

o Procedures’ Quality Control.

o The Following documentation as applicable:

Special process procedures.

Non-Conformances and Deviation Control Procedures.

Electrical testing Procedures as per applicable Standards.

Certificates of Mechanical and Electrical Tests, complying with this specification.

Inspection and Test Reports.

Any change in the materials used in the manufacturing of the equipment and/or by subcontractors

and/or technology shall be reported in written to the Purchaser. The purchaser reserves the right to

accept or reject the change.

Deviation from Specifications:

Any deviation/change from specification suggested/made by the Bidder/Supplier, shall appear in a separate chapter of the proposal:

o 'Deviations/Changes/Comments'.

o The chapter will include the suggested/made deviations from the specification and their reasons

o The Purchaser reserves the right to accept or reject the proposed deviations /changes. In the last case, it will be a sufficient reason to reject the bid.

Remark: If Bidder/Supplier has not stated any deviation/change the purchaser will consider the

proposal as its conforming to the requirements of this specification.

C.4 Quality Assurance

The Manufacturer’s Quality Assurance Program shall meet the requirements described in the Quality

Assurance System.

The Purchaser shall have the right to audit and comment on Manufacturer’s Quality Assurance

System regardless of whether it was previously audited by a certifying agency or any other body.

The Bidder/Supplier shall be responsible for assuring that his Quality Assurance/Quality Control

program and his subcontractor’s as well, including their organizations, procedures, personal

qualifications, etc. indeed meets IECo’s quality requirements.

C.5 Preliminary Batch for Approving Delivery

IECo demands from the awarded Bidder/Supplier to ship to IECo a preliminary batch, which consists

of 5 units of each type of transformer.

IECo at their own judgments will perform tests as specified in section C.8 of this specification. Should

any of the transformers fail to pass the performed tests, IECo reserves the right to reject the whole

order.

Awarded Bidder/Supplier will send the remaining of the order, only after the Bidder/Supplier receives

written authorization from IECo's Import Department, in portions as defined by IECo's Import

Department.

The certificates' QMS should be valid for the whole period of the current supply.

C.6 General

C.6.1 Scope

This specification applies to: A Measuring Current Transformer (hereinafter called "CT") for low

voltage system, 50 Hz.

CT shall be used for Electricity Meters at existing transformation stations.

Figure 13-2: Installation method (illustration only)

CT for indoor and outdoor installation shall be used in environmental conditions as described in

section C.6.4.

Each unit shall be supplied complete with appurtenances and accessories as specified herein, to form

a complete unit which will achieve and assure safe and reliable operation with best overall

performance.

C.6.2 Standards and Codes

Standards and codes referenced in this Specification, and in supplements to this Specification, form

an integral part of this Specification unless otherwise indicated. All such standards and codes

referred to the most current issue, including all amendments, supplements etc., as of the date of the

Contract, unless otherwise indicated.

The Equipment that is provided under this specification including all appurtenances and accessories,

shall be designed, fabricated, inspected, tested and preserved to the extent indicated and to the

standards and codes as specified herein. All component parts not so specified shall be designed,

fabricated, inspected, tested and preserved, as applicable, to currently recognized Industrial and / or

Supplier’s Standards, so as to insure their fitness for use and for the purpose they are designed.

The Bidder/Supplier may propose Standards and codes as alternates for, or additions to those

specified herein. The information about of each proposed standard and code, if any, shall be included

with the proposal. In the case IECo acceptance of such alternates or additions to standards and

codes, manufacturer remains responsible for assuring that the design, and the equipment supplies

by others, which conform to IEC Standards and DIN Standards are completely compatible.

C.6.3 Relevant Regulations and Standards

The CTs must comply with:

o IEC Publications 61869-1 and 61869-2

o IEC Standard 61000-4-8, actual edition. EMC. Testing and measurement techniques – Power

frequency magnetic field immunity test.

o DIN 42600-1 and - DIN 42600-2

o IEC Publication 60695-11-10

If the requirements of the present specification differ from those of the above-mentioned standards,

the requirements of this specification shall take precedence.

C.6.4 Environmental Conditions

C.6.4.1 Environmental Conditions for Indoor Installation

The maximum ambient air temperature is 50 C and its average value measured over a period of 24

hr. is up to 35C. The minimum ambient air temperature is -5C. Maximum temperature difference

between day and night: 25C.

The installation altitude does not exceed 1000m.

The average value of the relative humidity, measured during a period of 24 hr. does not exceed

95%. The average value of the humidity does not exceed 90%, for a period of one month.

C.6.4.2 Environmental Conditions for Outdoor Installation

The maximum ambient air temperature is 50 °C and its average value measured over a period of 24

hr. is up to 35 °C. The minimum ambient air temperature is -10 °C. Maximum temperature

difference between day and night: 25 °C.

The installation altitude does not exceed 2000 m.

The maximum value of the relative humidity does not exceed 95%. The average annual value of the

humidity does not exceed 70%. The average value of the humidity for a period of one month does

not exceed 90%

Long summer periods with solar radiation of up to 1120 W/m2.

C.7 Technical Requirements

C.7.1 Electrical Requirements

Rated insulation level: 0.72 kV, according to IEC Publication 61869-1 clause 5.2, table 2.

Rated primary current: 1000 Amps

Rated secondary current: 5 Amps.

Rated frequency is 50 Hz

Rated output: 5 VA at PF=0.8. 7.5 VA and 10 VA values may be considered during samples

evaluation.

Instrument security factor: FS = 10 or smaller.

Accuracy classes:

o 0.2S (for solid core) or better according to IEC Publication 61869-2 Clause 5.6.201 and Table

202.

o 0.5 or better according to IEC Publication 61869-2 Clause 5.6.201 and Table 201.

Extended current ratings: 1.2 In.

C.7.2 General Construction Requirements

C.7.2.1 MCT, accuracy class 0.2S

The CT must have the casing made of double insulating thermoplastic material

o The limit of temperature rise for winding shall be 75K, according to table 5 in clause 6.4 of

IEC standard 61869-1.

o The casing must be heat and impact resistant.

o The casing must be of self-extinguishing classes HB40 and V-0 according to IEC 60695-11-

10.

o The casing should have a uniform surface. Significant apertures (larger than 0.3 mm) or

cavities on the surface are not acceptable

Dimensions:

o Height up to 140 mm

o Width up to 120 mm

o Depth up to 45 mm

Note: round transformer shape with outer diameter of up to 120 mm is also acceptable

The aperture should be located in the center of the CTs

The aperture should be suitable for cables from 70 up to 80 mm diameter. The aperture should

be such that cables with diameter larger than 80 mm will not fit.

Secondary terminals shall have two pinch screws for each terminal. The screws shall withstand the

tightening torque of at least 4.0 Nm. The screws shall be made of nickel plated or passivated brass.

The terminals shall be suitable for 10 mm2 ferrules.

C.7.2.2 MCT, accuracy class 0.5, in outdoor design

The cast insulating material must be durable for the intensive UV irradiation and for the tropical

environmental conditions.

The class of insulation shall be E or B (class E preferable), according to table 5 in clause 6.4.1 of IEC

Publication 61869-1.

The cast insulating material must be heat and impact resistant.

The casing must be of self-extinguishing classes HB40 and V-0 according to IEC Publication 60695-

11-10.

The cast insulating material should have a uniform surface. Any cavities on the surface are not

acceptable.

Overall dimensions:

o Height (a): ≤ 200 mm;

o Width (b): ≤ 145 mm;

o Depth (c): ≤ 60 mm

The aperture should be either round with 60-70 mm diameter or rectangular with (60-70 mm) / (60-

80 mm) dimensions. Slight deviations can be accepted after samples evaluation.

Each Secondary terminal shall have two pinch screws, or alternatively 4-6 mm2 copper secondary

conductors of 12 m length shall come out from inside the mould.

Each terminal shall ensure good contact pressure on pin-shaped or fork/spade tongue connector of

secondary wire of 4-6 mm2, according to DIN 46237 (if applicable).

The manufacturer shall indicate the recommended maximum tightening torque of the secondary

terminal’s screws in Nm (if applicable).

The screws shall be made of nickel plated or passivated brass (if applicable).

A protective terminals cover confirming with IP65 class according to IEC publication 60529 shall be

provided (if applicable). Provision shall be made for the cover sealing (if applicable).

C.7.2.3 MCT, accuracy class 0.5, in indoor design

The CT's case insulating material of the must be durable for the tropical environmental conditions.

The class of insulation shall be E or B (class E prefer), according to table 5 in clause 6.4.1 of IEC

Publication 61869-1.

The case insulating material must be heat and impact resistant.

The casing must be of self-extinguishing classes HB40 and V-0 according to IEC Publication 60695-

11-10.

The case insulating material should have the uniform surface. The significant apertures (larger than

0.3 mm) or cavities on the surface are not acceptable.

Overall dimensions:

o Height (a): ≤ 200 mm;

o Width (b): ≤ 145 mm;

o Depth (c): ≤ 60 mm.

The aperture should be either round with 60-70 mm diameter or rectangular with (60-70 mm) / (60-

80 mm) dimensions. Slight deviations can be accepted after samples evaluation.

Each Secondary terminal shall have two pinch screws.

Each terminal shall ensure good contact pressure on pin-shaped or fork/spade tongue connector of

secondary wire of 6 mm2, according to DIN 46237.

The manufacturer shall indicate the recommended maximum tightening torque of the secondary

terminal screws in Nm.

The screws shall be made of nickel plated or passivated brass.

A protective terminals cover shall be provided. Provision shall be made for the cover sealing

C.7.2.4 Markings

Terminals shall be marked as per IEC Publication 61869-1 and 61869-2. The polarity markings P1,

P2 and secondary terminals markings S1 and S2 shall be placed on the top surface of CT and be

clear and readable.

The rating label shall bear all the data as per IEC Publication 61869-2 clauses 6.13.201 and

6.13.202, including serial number, and IECo catalog number. It will be steadily fixed on the top

surface of the CT (e.g. with acrylic adhesive). The terminals block IP value shall be clearly indicated.

The rating label shall include bar-code mark done in code 128C with 12 digits, the first four (4) digits

are for the CT distinguishing code, that will be given by IECo for each type, 2 digits are for

manufacturing year and 6 digits are for the serial number, adding leading zeros if necessary:

CCCCYYNNNNNN, and the IECo logo as per section C.11.

The rating label shall be protected against environmental impacts.

C.7.2.5 Installation and Maintenance

Bidder/Supplier shall submit with the proposal maintenance, cleaning, storage, handling and installation

instructions, taking into consideration the service conditions.

C.8 Tests

C.8.1 Type Tests

Type test of CT should be performed according to IEC Publications 61869-1 Clause 7.2 and 61869-2

Clause 7.2 as specified:

Temperature-rise test according to IEC Publication 61869-2 Clause 7.2.2.

Impulse voltage withstand test on primary terminals according to IEC Publication 61869-2 Clause

7.2.3.

Test for accuracy according to IEC 61869-2 Publication Clauses 7.2.6.

Short-time current tests according to IEC Publication 61869-2 Clause 7.2.201.

The bidder shall provide the necessary test reports

C.8.2 Routine Tests

Each CT individually, shall be routine tested according to IEC Publication 61869-2 Clause 7.3 as specified

hereinafter, by the Bidder/Supplier prior to shipment. The test reports shall be submitted to the

Israel Electric Corp, attached to the CT.

Power-frequency voltage withstand test on primary terminals according to IEC Publication

61869-1 Clause 7.3.1.

Power frequency withstand test on secondary terminals according to IEC Publication 61869-1 Clause

7.3.4.

Test for accuracy according to IEC Publication 61869-2 Clause 7.3.5.

Determination of the secondary winding resistance (Rct) according to IEC Publication 61869-2

Clause 7.3.201

Test for rated knee point e.m.f (Ek) and exciting current at Ek according to IEC Publication

61869-2 clause 7.3.203.

Verification of markings according to IEC Publication 61869-1 Clause 7.3.6.

Inter-turn overvoltage test according to IEC Publication 61869-2 clause 7.3.204.

C.8.3 Special Tests

The IECo may make a special request for additional routine tests and additional special tests to evaluate

the workmanship of the CT.

Any CT subjected to special tests shall be performed by manufacturer and approved by IECo.

C.8.4 Acceptance Tests

The routine test results as per the above section C.8.2 will be compared with the limits given in standard

IEC 61869-2 and will serve as the acceptance criteria.

Verification of dimensions:

The tolerance on height (1.5 + 0.008h) mm. The tolerance on width (0.2 + 0.01w) mm.

IECo will carry out acceptance tests in order to approve the conformance of the purchased transformers

to this specification by using one of the following inspection methods:

1. 100% inspection, when all shipped transformers will be tested. Each consignment of delivered transformers will be considered as a batch. A batch containing more critically defective transformers than the number in the below-cited table will be considered as a rejected batch.

Batch Size Permitted number of defective

transformers

Up to 89 0

90 – 149 1

150 – 249 2

250 – 349 3

350 – 449 4

2. Sampling inspection is specified with risks of Bidder/Supplier and Purchaser, using standardized inspection plans, chosen from ISO 2859-1, ISO2859-2 tables and which will be notified to the awarded Bidder/Supplier. For this purpose: AQL = 1.0 %, LQ = 5 %, α=3%, β=10%. Failure to pass the inspection plan, all the transformers of the rejected batch will be replaced, and the supplier will bear the costs of shipment of the replacement batch.

Repeated rejections will lead to disqualification of a Bidder/Supplier.

C.9 Warranty

All the units will have a Manufacturer warranty for a period of 3 years, from the date of delivery to IECo.

The warranty shall include the replacement of any unit that failed to pass the tests performed by IECo,

according to any part of section C.8 of this specification.

The supplier will bear the costs of shipment of any replaced unit.

C.10 Official Company Symbol

SYMBOL DESIGN: The symbol basic design is a positive square.

It is important to keep the proportions in of the form in order to get the right performance.

REMARK: The square dimensions in the drawing are for proportional reference only.

C.11 Summary of Data for Measuring Current Transformers

Bidders are requested to fill in this form the list of non-conforming data of the offered CTs, per

transformer type.

Name of Bidder: _________________________________________________________

Manufacturer’s name and address: ____________________________________________

Offered type: _____________________________________

Rated primary / secondary current: _______________________

Clause Subject Conformity:

Yes / No, or

Comments

C2 to C5 Documents and samples submitted with the proposal:

Detailed description of the proposed CT.

Valid ISO 9001(2015) or equivalent certificate.

Type tests certificate and results

Equipment traceability chain of the Lab that performed Type Test

Routine tests results of the samples

Equipment traceability chain of the Lab that performed Routine

Test

A declaration of manufacturing experience.

A customer list with CT's types and quantities which have been

supplied in the last 3 years.

Drawings showing dimensions and structure of proposed CT

Drawings of terminal and polarity markings.

Drawings of nameplates.

Completed and filled-in of Manufacturer Qualification

Questionnaire.

A preliminary Test and Inspection Plan.

A Quality Management Manual including Quality Control’s

Procedures.

One sample of proposed CT.

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

Yes / No

pcs/year

The manufacturer's statement on manufacturing capacity of the

proposed CT

The manufacturer's statement on tests capacity of the proposed

CT.

pcs/year

C.6.4 Service conditions range:

Outdoor

Indoor

°C

°C

C.7.1 Technical Data

Highest voltage for equipment RMS.

Rated power-frequency-withstand voltage for secondary

windings insulation: RMS.

Rated primary current:

Rated secondary current:

Accuracy class

Rated output: (see C.7.1)

Extended current ratings: 1.2 In.

Short time current rating:

Thermal current Ith-1 sec: 60 x In

Instrument security factor:

IP level for outdoor model terminals cover

KV

KV

A

A

CI.

VA

In

FS

C.7.2 Design and construction:

Enclosure self-extinguishing classes (HB…,V-…)

Dimensions (outdoor / indoor)

o Height:

o Width:

o Depth:

o Aperture:

Insulating material class

Limit of temperature rise for winding

Each secondary terminal with 2 nickel plated screws, suitable for

10mm2 ferrules (only applicable for MCT with accuracy class

0.2S)

Class

mm

mm

mm

mm

Class

K

Each secondary terminal with 2 nickel plated screws suitable for

4 – 6 mm2 fork connector (only applicable for MCT with accuracy

class 0.5, outdoor / indoor)

Protective terminals sealable cover

Markings & IECo logo

12 digits Bar-Code including CT code and s/n

Packaging and Labels

Conformity with Proposal Documents:

Bidder hereby certifies that he agrees to all provisions of the Proposal Documents unless exceptions are

specifically and clearly listed in the Proposal and identified as exceptions.

Bidder’s printed terms and conditions are not considered specific exceptions.

Any exceptions, or non-conformity which Bidder has taken, are listed in this page.

Bidder hereby certifies that he agrees to all conditions of the Covered Letter of Israel Electric Corporation

Limited, which accompanied the Proposal Documents

Signature of Bidder _________________ Date of Proposal _________________

PACKAGING REQUIREMENTS FOR COMPONENTS

The packaging requirements shall apply to meters (all types), current instrument transformers (see

Appendix C), Data Concentrators, PLC Filters, and Firewall components.

D.1 Packaging

D.1.1 General

Types of Pallets:

Contractors supplying goods to IECo's stores are to pack them on any one of the following types of

pallet:

a) Pallet with dimensions: 1,000*800 mm, acc. to DIN-15146, part 2 standard.

b) Pallet of any other dimensions suitable for the size and weight of the goods, and allowing easy

offloading of goods, where proposed by Bidder, are subject to receipt of IECo's approval in

advance.

Instructions for arrangement of goods on pallets:

Height: The height of the goods packed on the pallet, incl. pallet, is to be no more than 1,050

mm.

Weight: The weight of the goods packed on the pallet, incl. pallet, is to be no more than 250 kg.

10

50

-1

00

250 ±20100 -10

800 -40

11

0 +

10

15

0 -

10

150 -10

1200 -200

KMKM

Cardboard Hood Polyethylene Hood

(All dimensions are in mm)

Maximum gross weight: 250 kg. Note:

The wooden pallet should be treated and protected against woodworms and other vermin.

The cardboard and polyethylene hood design could be in any of the following forms:

a. Both the cardboard and polyethylene hoods could be opened at the bottom;

b. The cardboard hood could be an inverted box, and be easily separated from the base, either manually or with a box cutter;

c. The polyethylene hood could be a close-fitting cover, and be easily separated from the base, either manually or with a cutter;

If options "b" or "c" are used, then a separation line – about 10 mm above the pallet – should be clearly marked.

The pallet shall also carry a unique label (for example, "Pallet 1 out of 24") to distinguish it in the

total shipment. An impact detector ("ShockWatch") label shall be attached to the cardboard hood of

several pallets in each container, to warn of possible rough handling during shipment, transport and

storage.

The packaging will protect the goods against shock and vibration, preventing damage due to the

road conditions during transportation. The electrical and mechanical properties shall not be affected

by these disturbances.

Each pallet may contain up to 300 meters. The actual number of goods on each pallet shall be

agreed with the I.E.Co.

Goods should be packed together in a group box such that the weight of the group box will not

exceed 10 kg. This box shall be marked – on the front (wide side) and on the narrow side –

with the manufacturer name, device type, device code, I.E.Co catalog number, production serial

numbers (or these numbers' lot borders), serial number bar-codes (or barcodes' borders), IMEI

numbers including barcode for cellular equipment (if applicable, depending on component type),

manufacturing year, the sign “FRAGILE” and the Israel Electric Co. logo.

The boxes shall prevent, as much as possible, penetration of dust during long storage period. The

boxes must be designed for multiple use and be robust, with wall thickness of at least 4 mm.

For shipping the group boxes shall be close packed by stockpiles of suitable quantities on pallets. The

serial numbers sequence (without partition) shall be kept in each stockpile. A stockpile will be

protected against moisture by a polyethylene hood, covered with a cardboard cover (hood), and

fixed onto the pallet by parallel polypropylene bands, using protection angle bars at the corners. The

hood shall be marked – on the front (wide side), on the narrow side and on the top – with I.E.Co

logo, the manufacturer's name, device type, device code, I.E.Co catalog number, production serial

numbers' borders, serial number bar-codes borders, IMEI numbers including barcode for cellular

equipment (if applicable, depending on component type), manufacturing year, the I.E.Co order

number, the sign “FRAGILE”.

Specific for meters (of all types):

o Each meter must be packed, together with its not tightened terminal cover in an individual

cardboard box, which can be opened and re-closed without need of adhesives. Measures

should be taken to prevent the cover from "self-tightening" during transportation. The

screws, however, shall be inserted into their places in the cover.

o The box shall prevent, as much as possible, penetration of dust during long storage period.

The box must be designed for multiple use and be robust, with wall thickness of at least 4

mm.

Freight of more than 50 kg, is to be delivered in suitable packaging, allowing offloading with suitable

means.

Quantity: The quantity of goods on each pallet (in units or according to secondary packages) is to be

stated, according to each type.

Mixed freight: The same or different types of freight may be packed on pallets. Preferably same

types of freight are to be packed on each pallet. For freight of small quantities, different types of

freight may be packed on one pallet, provided that each type is packed in a separate secondary

package, whilst the lighter freight shall be on top.

Arrangement of pallets: The heaviest goods or goods with biggest quantity are to be packed on the

bottom of the pallet, provided they are not breakable or fragile goods.

Maintaining Equilibrium: The weight of the packages is to be divided evenly on the pallet.

Freight Stability: Freight packed on pallets is to be wrapped with "Shrink" nylon or tied with bands to

prevent any movement of freight on the pallet.

Use of supports: Wooden or Cardboard supports are to be mounted on all corners of the package,

such that the final package will take a cubic and more stable form.

Pallet boundaries: Freight is not to protrude outside of the pallet boundaries.

Packed freight on pallet must be arranged such that a 3 cm boundary is left on each side, between

the freight and outer edges of the pallet.

For circular freight (reels / spools), appropriate wedges are to mounted on pallets to prevent sliding

or rolling of freight.

Cleaning: The freight is to be clean and free of contaminating substances.

Secondary Package: Weight of each secondary package may be up to 10 kg. In the event heavier

secondary packages are inevitable, freight must include suitable lifting apparatus / device (hook or

handle).

D.1.2 Primary Packaging

General terms:

Wooden boxes shall be used in the following cases:

o where requirements exist for freight to be hermetically closed for preservation or storage in

special conditions.

o for goods of irregular dimensions not able to be packed on pallets.

o where requirements exist for protection of freight.

The dimensions of the bottom layer of the wooden box shall allow access of forklift for easy

transportation and offloading.

Wooden boxes shall be specially made to fit the dimensions, weight and offloading of the freight

required, proposed by the Contractor and approved by IECo.

Freight requirements for wooden boxes:

Wooden boxes may contain similar or different items packed in secondary packages as defined

herein.

Storage period, terms of storage and technical requirements shall dictate whether freight needs to

be preserved.

Marking of the packed freight shall be according to common practice.

Secondary packages are not to be packed too tightly, allowing easy handling of each secondary

package inside box.

Package dimensions are to be according to the freight's weight and size.

Mixed freight: The same or different types of freight may be packed in wooden boxes. Preferably

same types of freight are to be packed together in box. For freight of small quantities, different types

of freight may be packed on one pallet, provided that each type shall be packed in a separate

secondary package, whilst the lighter freights shall be on top.

Arrangement of pallets: The heaviest goods or goods with biggest quantity shall be packed on the

bottom of the pallet, provided they are not breakable or fragile goods.


secondary package are inevitable, freight must include suitable lifting apparatus / device (hook or

handle).

D.1.3 Secondary Packaging

Secondary packaging shall be according to size of goods, dimensions of secondary packaging shall

allow loading of packages on to pallets or wooden boxes, accordingly, such that several secondary

packages may be loaded together on pallets or boxes.


secondary package are inevitable, freight must include suitable lifting apparatus / device (hook or

handle).

Goods of especially small volume in large quantities, are to be packed in suitable bags, with the

quantity stated on the outside of the package.

Fragile goods are to be padded and include suitable partitions between items.

D.2 Shipment Documents

The Manufacturer shall attach one set of the Bill of materials to the shipment.

The Manufacturer shall submit detailed storage instructions for storage (if necessary). Such

information shall be available to the Purchaser in ample time to prepare the required facilities.

If applicable, each shipment shall be accompanied by certification attesting the conformance of the

shipment to the specifications. Certificate shall contain routine test results identifiable to the

acceptance criteria and the items shipped. Documentation shall be submitted in English.

If applicable, the certificates shall include the signature and name of the entity performing the tests

and shall be subject to the review and acceptance of IECo.

D.3 Handling of DDP goods

On arrival at the Israeli Port the Goods on the pallets shall be offloaded from containers (if so delivered)

and loaded by the Supplier at Supplier's risk and cost onto open trucks for transportation to IECo stores.

D.4 Official Company Symbol

SYMBOL DESIGN: The symbol basic design is a positive square.

It is important to keep the proportions in of the form in order to get the right performance.

REMARK: The square dimensions in the drawing are for proportional reference only.

HASS REQUIREMENTS

E.1 HASS general definition

HASS stands for "Highly accelerated stress screen" tests, and is performed in order to identify design

weaknesses, improve product reliability and reduce life cycle.

HASS screens are performed in the same type of chamber that is used for HALT. The vibration in HASS is

randomly applied over a broad frequency range producing energy to 10,000 Hz in 6 degrees of freedom.

HASS is performed after termination of design cycle during manufacturing cycle.

Figure 13-3: Cold and hot stress tests

Figure 13-4: Difference between HALT and HASS in stress margins

E.2 IECo HASS requirements

HASS required by IECo involves the following tests:

E.2.1 Thermal cycling tests

Table 13-4: Thermal cycling tests

No Feature Work point Criteria

1 Initial functional and metrology

tests

Refer to Table 1-1to Table

1-1Table 13-7. Verify that

all meters pass.

All meters pass

2 standard IEC 62059-31-1

3 low temperature ≤ −5℃

4 high temperature ≥ 65℃

5 Rate of temperature change 5-10℃ per minute

7 Dwell time One hour

8 Total duration At least five working days –

24 hours/day

9 Final functional and metrology tests Refer to Table 1-1Table

13-7. Compare results

including numeric results.

If no more than one meter

failure is occurring than

HASS test is considered

pass

E.2.2 Vibration and free fall tests

A sample of the meters that passed Thermal cycling shall be subjected to either Vibration or Free fall

test.

E.2.2.1 Vibration test

Vibration test shall be performed on a sample of 30 meters out of the meters that passed Thermal

cycling tests.

Table 13-5: Vibration test

No Feature Work point

1 Initial functional and metrology tests Refer to Table 1-1to Table 1-1Table 13-7. Verify

that all meters pass.

2 Standard IEC 62052-11, 5.2.2

IEC 600068-2-6

3 Final functional and metrology tests Refer to Table 1-1Table 13-7. Compare results


E.2.2.2 Free fall test

Free fall test shall be performed on a sample of 5 meters out of the meters that passed Thermal cycling

test.

Table 13-6: Free fall test

No Feature Work point

1 Initial functional and metrology tests Refer to Table 1-1to Table 1-1Table 13-7.

Verify that all meters pass.

2 standard IEC 60068-2-32

3 Test conditions 0.5-meter height

in any two axes

unpacked meter, without terminal cover

number of falls 2.

4 Final functional and metrology tests Refer to Table 1-1Table 13-7. Compare results


Table 13-7: Contents of Initial and Final provision tests

No Main chapter Description

1 display LCD display, LED indicator

2 Communication LTE, optical probe, PLC

3 Error Handling and Alarm Handling

4 Contactor open/close

5 RTC Compare with reference time

6 Push button

7 Energy registers Read them

8 Visual inspection

9 Automatic acceptance test If include some or all of above do not repeat

twice

METERS AND DC RAM REQUIREMENTS

F.1 Definitions

The following definitions are valid for all Reliability, Availability, and Maintainability (RAM) purposes in the

Specification for meters and DCs.

The RAM parameters are characteristics of the meter/ DC design and production only when they are

properly used and maintained.

a. Failure – Failure is any event where a meter/DC has stopped functioning, or exceeds its

specification limits, and requires repair or replacement.

b. Failure Rate – The failure rate of a meter/DC is the number of failures per operating time unit.

The system failure rate for the meter/DC will mean the sum of the failure rates of its components,

i.e.

= 1 + 2 + 3 + … + n.

c. MTTF – MTTF is the mean time between the meter/DC installation and operation, and the first

failure.

d. Reliability – Reliability is a design characteristic defining the ability of a product to perform

satisfactorily. Reliability is the probability that a meter will perform without failures, for a pre-

defined period of time, when used under stated conditions (at IECo site). MTTF is a reliability

parameter, in accordance with definitions of IEC 60050-192.

e. Life Length – Life length of a meter/DC is the time until the first failure in operation.

f. Maintenance – Maintenance is any action taken to replace a faulty meter/DC with a properly

working one, after a failure, and test the operable condition of a replaced meter.

g. Maintainability – Maintainability is a design characteristic defining the ability of an item to be

replaced quickly and checked for its operable condition after a failure

F.2 RAM Requirements

The Bidder is required to provide IECo with meters/DC with the following RAM properties:

Reliability

Operational TTF (time to first failure): At least 15 years.

Operational service life time: At least 15 years, without the need for maintenance or recalibration.

Maintainability – The meter/DC will be “preventive maintenance” free for its entire life length.

F.3 RAM Declaration

A RAM Declaration shall be provided for each of the meter/DC components. The following RAM information

shall be submitted to IECo with the technical proposal:

The Bidder shall state:

1) The minimum guaranteed MTTF

2) The life length values of the proposed meters/DC, when operated within their specified environmental

extreme conditions, as per the Specifications.

3) The sum rate and these components values as predicted and verified (tested) will be reflected at

MTTF state.

4) The historical RAM field data of proposed meters/DC, for all installed meters/DC (identical to the ones

proposed), at all sites, supplied during the last 5 years. The RAM report should include specific model

type, and years of the collected data.

5) Reliability prediction report according to IEC 62059-41.

6) Information about RAM activities and optimization in the manufacturing plants concerning the proposed

meters/DC including:

a) Criticality (long supply time, high price, short life length, high failure rate, single supply source,

sensitive or vulnerable materials, etc.

b) Latent failure rate ( ), and induced failure rate (caused by human).

c) Turn Around Time (door to door).

d) Quantity in service.

e) Recommended “probability of no shortage” (spares availability) on shelf.

f) Cost

The Bidder shall state the rationales for his above-mentioned declarations

(usage/tests/analysis/estimation).

total

F.4 Reliability Demonstration

IECo has the privilege to exercise a Reliability Field Demonstration (RFD) concerning the supplied

meter/DC during the technical evaluation stage. The purpose of the RFD is to verify that the meters meet

the reliability requirement.

If carried out, the RFD will be conducted in accordance with the following principles:

1) The RFD shall be objective, quantitative and based on data collection from returned faulty meters (see

IEC 60300-3-2 Application Guide, IEC 62059-21).

2) The Bidder has nothing to do in the RFD, except to participate in the Failure ReviewBoard (FRB).

However, the Bidder has to do his best in his plant in the following areas, in order to supply to IECo

with reliable meters, and this to pass the RFD with high probability:

a) Design and Development

b) Parts, materials, and components

c) Manufacturing Processes

d) Quality Assurance and Control

e) Tests and inspections

f) Sub Bidders, Suppliers, and Vendors supervision

g) Packaging, Handling, Storage, and Transportation (PHST)

3) The FRB is the only body entitled to classify failures as “Relevant”, or “Non-relevant” for the purpose

of the RFD.

4) The Bidder is responsible for productive agency of RFD results.

5) The RFD shall be ended with either ACCEPT, or REJECT result.

6) The meaning of REJECT result is violation of the specification, and the contract will deal with such a

situation.

7) The RFD will be framed in accordance with standard reliability test methods.

OFF THE SHELF PRODUCT DECLARATION

An "off-the shelf product declaration, is a formal statement, signed by senior manufacturer officer, such

as VP sales, at which the manufacturer guarantees by statement, that the proposed product is an off-the-

shelf product, sold as such to other utilities, and not tailor made product. Minor adaptations to IECo spec,

are enabled through firmware, only after IECo enables them.

Bidder’s Off The Shelf Product Declaration & Undertaking:

Statement of Compliance

I, the undersigned, ___________ [name of Bidder’s authorized signatory], in my capacity as

____________ [title or position of authorized signatory] of

_____________ [name of Bidder] (the “Bidder”), do hereby declare as follows:

1. The Bidder has received the Tender Documents and has carefully read all their contents;

2. The Bidder undertakes to comply with the terms and conditions of the tendering process, as set forth

in the Tender Documents;

3. The Bidder represents and warrants that it is capable of supplying the Products and rendering all the

Services within the time frames detailed in the Tender Documents and undertakes to abide by them.

4. The Meters and the software and all other services proposed by the Bidder hereunder will be

provided in accordance with the requirements set forth in the Tender Documents;

5. All representations, warranties, proposals and descriptions made by the Bidder are true, accurate and

complete;

6. Our Proposal shall be binding upon us in accordance with the terms and conditions set out in the

Tender Documents.

7. The Meter (and SW ) that is proposed in this tender is Off the Shelf Products and complying with the

requirements defined below:

7.1. Is completely defined (design, construction and performance) by a formal technical specification.

7.2. Is manufactured in accordance with formal production drawings, processes and procedures which

govern all stages and aspects of the manufacturing process.

7.3. Have successfully passed all qualification tests and the environmental tests in particular.

7.4. Is manufactured with strict adherence to the prescribed quality assurance procedures, which have

to include in-process inspection procedures.

7.5. "Similar" meter type in accordance with IEC 62052-11, section 3.1.8.2, is currently manufactured

with at least 400 units installed/at electrical power utilities at the last two years and the

accumulated operational data proves high reliability indicating the Product is mature.

7.6. Is regularly checked for reliability by field data collection, collation and corrective action taken

when needed.

7.7. Is accompanied by a complete set of manufacturing drawings and procedures, reliability

prediction, user manuals and maintenance manuals.

Bidder's Information

Bidder’s Full Name:

Bidder’s Address

Street:

City State / Province Zip/Postal Code

Country

Bidder's Contact Information

Telephones:

Fax:

e-mail:

Signature ____________________ Date:____________________

PROVISIONING TEST

No Scope of provision validation work

1 All system versions relating to the HLD contents shall be validated with defined and agreed

provisioning –tests in the development (DEV) environment. The result of these tests shall

be available to IECo.

At least a single Dead-Or-Alive (DOA) test must be executed in the TEST environment prior

to release.

2 New functionality testing and regular regression testing must be executed before

submission

3 Each provisioning testing program shall be presented to IECo for approval. Testing will

commence only after approval is received from IECo.

A Standard STP, STD documentation shall be provided to IECo as a-priory and be approved

by IECo prior to execution of said test programs.

STP – Standard Test Procedure

STD – Standard Test Description

4 Each provisioning testing program, and including version release, shall be backed-up with a

standard test program report (STR).

5 A new version shall only be accepted by IECo if the Dead-Or-Alive test suit was passed

successfully by IECo E2E acceptance test validation team.

6 Provisioning testing must be performed by the integrator validation team. According to the

IECo requirements they must hire an Israeli team from a known software validation

company.

No Bugs Issuing policy (by all involved parties)

7 Any issues that are identified during testing by the integration team, and remaining

outstanding issues, shall be identified and logged within the "Quality Center" system. Within

the “Quality Center" system the issue shall be identified according to QC defects tracking

specification.

8 Critical and High priority issues (as defined in Chapter 7 of this Smart Metering Tender)

shall be resolved within a period defined by and according to chapter 7 of this tender (High,

Critical, Medium, Low).

9 An ‘issue board’ meeting shall be held approximately every two weeks. The presence of a

nominated “Integrator” coordinator is required at all issue board meetings.

Effort will be made to reach mutual agreement on issue's details. In case of a dispute, the

issue decision is determined by IECo expert users.

10 Reject conduct: an issue cannot be modified to “Not a problem” twice.

11 Latency: the integrator must react, in writing, to each high priority issue within two work

days.

12 Information from the integrator to the IECo End-to-End validation automation team must be

provided on-demand. Contents to be defined by IECo.

13 IECo requires that the integrator has exceptional knowledge of installation of software such

as "MDM", "WFM system", and shall assist the E2E validation on-demand.

No Global

14 At every validation the final mandate is by IECo, although effort is made to reach

agreement.

15 The final E2E and quality validation responsibility is by IECo

16 There shall be no multiplication of duties to a single validation job title, payment is per

single job title. The following personnel is required:

Team leader.

Senior testing person that is not a team-leader

Junior testing person.

The team must be hired in Israel, speak fluent Hebrew, and stay at IECo facilities if possible

due to COVID-19 pandemic.

17 There shall be a result oriented payment section for each milestone.

Not withstanding the milestone objective – IECo has a bonus/penalty payment mechanism.

METROLOGY REPORT FORMAT

I.1 1Ph

I.2 3Ph

open √ √

closed

PF=0.5L PF=1.0

Imax Ib 0.05Ib Ib 0.05Ib

1 YY000001 √ √ √ x.xx x.xx x.xx x.xx x.xx x.xx x.xx √ OK



starting

Error Error

startingPF=1.0 dial test

1kWh

dial test

1kWh

Type：______ Code: ____ specification：230V _(__)A Class：__ Meter constant：___imp/kWh temperature：TT℃ humidity：HH％

Tested with voltage linkscontinuity checked after meter sealing

Import inspection Export inspection

conclusionNo.

Serial

Number

AC

Voltage

test

no load

open √ √

closed

R T RST

PF=0.5L PF=1.0

Imax Ib 0.05Ib Ib Ib Ib 0.05Ib

1 YY000001 √ √ √ x.xx x.xx x.xx x.xx x.xx x.xx x.xx √ x.xx x.xx OK



starting

Error, %

RST

dial test 1kWhPF=1.0 PF=1.0

Import inspection Export inspection

conclusionNo.

Serial

Number

AC

Voltage

test

no load starting

Error, %

dial test

1kWh

Type：_____ Code: ____ specification：230V _(__)A Class：__ Meter constant：___imp/kWh temperature：TT℃ humidity：HH％

Tested with voltage linkscontinuity checked after meter sealing

I.3 CT

R T RST R T RST

PF=0.5L PF=1.0 PF=0.5L PF=1.0

Imax In 0.02In In In In 0.02In Imax In 0.02In In In In 0.02In

1 YY000001 √ √ √ x.xx x.xx x.xx x.xx x.xx x.xx x.xx √ x.xx x.xx √ x.xx x.xx x.xx x.xx x.xx x.xx x.xx √ x.xx x.xx OK



PF=1.0 PF=1.0starting

Error, %

starting

Error, %

starting

Error, %

dial test 10kWh (primary)

RST dial test

10kVarh

(primary)

dial test

10kVarh

(primary)

No.Serial

Number

AC

Voltage

test

no load starting

Error, %

RST dial test

10kWh

(primary)

PF=1.0 PF=1.0

Type：_____ Code: ____ specification：230V _(__)A Class：__ (act), _._ (react) Meter constant：____imp/kWh, imp/kVarh temperature：TT℃ humidity：HH％

Active Energy Import inspection Active Energy Export inspection Reactive Energy Import inspection Reactive Energy Export inspection

conclusion

TECHNICAL REQUIREMENT DOCUMENT FOR SMART ...

Documents

Transcript of TECHNICAL REQUIREMENT DOCUMENT FOR SMART ...