TECHNICAL REQUIREMENT DOCUMENT FOR SMART METER … Meter System/Annexure B... · TECHNICAL REQUIREMENT DOCUMENT FOR SMART METER PROJECT ... Energy Registers ... Technical Requirement

ISRAEL ELECTRIC CORPORATION (IECo)

TECHNICAL REQUIREMENT

DOCUMENT FOR SMART

METER PROJECT

Date: 03/2016

Status: Final Draft edition

Annexure B - Technical Requirement Document for Smart Meter Project

2

Israel Electric Corporation

CONTENT

Content _____________________________________________________________ 2

Tables list ___________________________________________________________ 6

Figures list ___________________________________________________________ 8

1. Introduction ______________________________________________________ 9

1.1. Smart Metering In IECo ________________________________________ 9

1.2. Tariff Trial _______________________________________________ 9

1.3. Structure of the document _______________________________ 10

1.4. How to reply to this document ____________________________ 10

1.5. Phases of project ____________________________________________ 13

1.6. Meters and DCs installation ______________________________ 15

2. Definitions and Abbreviations ________________________________________ 15

3. Architectural Overview _____________________________________________ 18

3.1. General ______________________________________________ 18

3.2. High level description of the Project ________________________ 18

3.3. IECo enterprise systems ______________________________________ 22

3.4. Architecture and integration guidelines _____________________ 24

3.5. Proposed architecture for the Project _______________________ 25

4. Meter ______________________________________________________ 26

4.1. Meter model types __________________________________________ 26

4.2. General Metrology Requirements __________________________ 27

4.3. General Technical Features _______________________________ 50

4.4. Static single-phase kWh meters for direct connection _________ 51

4.5. Static Poly-Phase kWh meters for direct connection ___________ 52

4.6. Poly-Phase Static CT-Connected Electricity Meter _________ 54

4.7. Diagrams, Sealing ___________________________________________ 56

4.8. Functionalities ______________________________________________ 58


3


4.9. Performance Characteristics ______________________________ 69

4.10. Software Tools ______________________________________________ 69

5. Instrument Current Transformers ____________________________________ 70

5.1. Norms & Regulations _________________________________________ 70

5.2. Documentation _____________________________________________ 70

5.3. Design and construction ______________________________________ 72

5.4. Technical Requirements ______________________________________ 73

6. Data Concentrator ________________________________________________ 75

6.1. Communication Technology in DC _________________________ 75

6.2. General Requirements _______________________________________ 78

6.3. Functionalities ______________________________________________ 80

6.4. Software Tools ______________________________________________ 86

7. Meters and DCs RAM requirements ___________________________________ 87

7.1. Definitions ______________________________________________ 87

7.2. RAM requirements __________________________________________ 88

7.3. RAM Declaration ____________________________________________ 88

7.4. Reliability Demonstration _____________________________________ 89

8. Meter Data management (MDM) ____________________________________ 91

8.1. General ______________________________________________ 91

8.2. Business processes __________________________________________ 93

8.3. Functional Requirements – General _______________________ 115

8.4. Functional Requirements – Business Process ________________ 117

8.5. Interfaces Requirements _____________________________________ 125

9. Head End System ________________________________________________ 130

10. Monitoring (MOC/NOC) ___________________________________________ 132

10.1. General _____________________________________________ 132

10.2. Overlapping / duplicate requirements _____________________ 132

10.3. MOC - Meter Operations Center __________________________ 132


4


10.4. NOC - Network Operations Center ________________________ 136

11. Deployment Tool ________________________________________________ 140

11.1. General _____________________________________________ 140

11.2. Business processes _________________________________________ 140

11.3. Functional requirements for rollout solution ________________ 142

11.4. Interface Requirements ______________________________________ 142

12. Software systems general Requirements _____________________________ 144

12.1. General _____________________________________________ 144

12.2. High availability ____________________________________________ 144

12.3. Performance Requirements ______________________________ 146

12.4. Disaster Recovery Requirements _________________________ 146

12.5. Data availability Requirements ___________________________ 147

12.6. Data backup Requirements ______________________________ 147

12.7. Scalability requirements _____________________________________ 148

12.8. Configuration management requirements __________________ 148

12.9. Hardware environment specifications _____________________ 149

13. Information security (IS) requirements _______________________________ 153

13.1. IS requirements for meters and data concentrators __________ 154

13.2. Password management system ___________________________ 155

13.3. Information security between DCs and HES _________________ 156

13.4. Information security between HES and MDMs ______________ 156

13.5. IECo IS methodology ________________________________________ 157

14. Quality Assurance and Testing _____________________________________ 158

14.1. General _____________________________________________ 158

14.2. QA and testing for Meters, DCs and CTs ____________________ 159

14.3. QA and testing for software systems and end-to-end _________ 171

15. Project Management and Governance _______________________________ 190

15.1. Contractor Responsibility _______________________________ 190


5


15.2. Project Management ________________________________________ 190

15.3. Environments Policy ________________________________________ 205

15.4. Delivery of Meters, DCs, CTs and associated components ______ 206

15.5. Warranties _____________________________________________ 211

15.6. Support and Maintenance _______________________________ 214

16. Training _____________________________________________________ 222

16.1. Training Principles __________________________________________ 222

16.2. General Training Requirements __________________________ 223

16.3. Training for meters and DCs and associated components ______ 226

16.4. Training for Software systems ____________________________ 227

16.5. Additional Training and Knowledge Transfer ________________ 227

17. Organization and Experience _______________________________________ 229

17.1. Organization _____________________________________________ 229

17.2. Experience _____________________________________________ 232

18. Solution Implementation Plan ______________________________________ 235

18.1. General _____________________________________________ 235

18.2. How to Fill the Work Packages Template ___________________ 236

18.3. Work Packages Description ______________________________ 240

19. Schedule _____________________________________________________ 246

Appendices ________________________________________________________ 247

Appendix A – IT landscape _____________________________________________ 247

Appendix B – Applicable standards _________________________________________ 253

Appendix C – TOU special dates & DST dates tables ___________________________ 255

Appendix D – Requirements regarding the DLMS application layer and COSEM data

model _____________________________________________ 258

Appendix E – Load Profile and Event Log structure ____________________________ 272

Appendix F – Software tools _____________________________________________ 274

Appendix G – Off The Shelf Product Declaration __________________________ 279


6


TABLES LIST

Table 4.1 - Required meter types ................................................................................ 26

Table 4.2 – Maximum dimensions for meters ............................................................. 31

Table 4.3 – Energy Registers ........................................................................................ 39

Table 4.4 – Energy Registers ........................................................................................ 39

Table 4.5 – Communication protocol standards ......................................................... 42

Table 4.6 – Electric parameters specification .............................................................. 50

Table 4.7 – Single phase model types according to communication .......................... 51

Table 4.8 – three phase direct meters model types .................................................... 53

Table 4.9– Three phase CT connected meters model types ....................................... 54

Table 4.10– Required energy parameters for all model types .................................... 59

Table 4.11 – Performance characteristics ................................................................... 69

Table 6.1 Communication Standards ........................................................................... 75

Table 6.2- List of general DC requirements ................................................................. 78

Table 6.3- List of DC Functional Requirements ............................................................ 80

Table 8.1 - MDMs process by phases .......................................................................... 93

Table 8.2 – General MDM Functional Requirements ................................................ 115

Table 8.3 – Business Process Functional Requirements ............................................ 117

Table 8.4 – Interface Requirements .......................................................................... 128

Table 9.1 – Head End Requirements .......................................................................... 131

Table 10.1 – MOC Functional Requirements ............................................................. 135

Table 10.2 – NOC Functional Requirements .............................................................. 138

Table 11.1 – Deployment solution Functional Requirements ................................... 143

Table 12.1 – Software system general Requirements ............................................... 150

Table 13.1 - IECo SI methodology .............................................................................. 157

Table 15.1 - Project Manager Roles & Responsibilities Description .......................... 192

Table 15.2- Program Manager Roles & Responsibilities Description ........................ 192


7


Table 15.3 - List of Subcontractors ............................................................................ 199

Table 15.4 - Data Management Key Activities ........................................................... 200

Table 15.5 - Data Management Procedures .............................................................. 201

Table 15.6 - Data Management Tools ........................................................................ 201

Table 15.7 - Risk Management Table ......................................................................... 205

Table 15.8 - Table of Environments ........................................................................... 205

Table 15.9 - Problem Severity Levels ......................................................................... 216

Table 15.10 – Response Time .................................................................................... 218

Table 16.1 - List of Potential Roles to be Included .................................................... 231

Table 18.1 - work package template.......................................................................... 239

Table B.1 – Applicable Documents ............................................................................ 253

Table C.1 – IECo special days of year 2016 ................................................................ 255




Table C.5 – Day light saving time dates ..................................................................... 257

Table D.1- List of Attributes Required ....................................................................... 260

Table E.1 - Load profile Duplicate Data Fields ........................................................... 272

Table F.1 - Software operations and required types ................................................. 275

Table F.2 - Software to be supplied by manufacturer ............................................... 276


8


FIGURES LIST

Figure 1.1 – Project time line ....................................................................................... 14

Figure 1.2 – Implementation phases of project ........................................................... 14

Figure 3.1 – Expected high level architecture.............................................................. 21

Figure 3.2 – Interface Diagram .................................................................................... 21

Figure 4.1 – Example of mounting bracket .................................................................. 36

Figure 4.2 – Example of single-phase direct connected meter nameplate ................. 49

Figure 4.3 – Example of three-phase direct connected meter nameplate ................. 49

Figure 4.4 – Example of three-phase CT connected meter nameplate ....................... 49

Figure 4.5 – Connection Diagram according to BS 7856 ............................................. 52

Figure 4.6 – Three phase connection diagram ............................................................ 54

Figure 4.7 –Connection diagram of CT connected meter ............................................ 55

Figure 4.8 - IECo Company Symbol .............................................................................. 56

Figure 4.9 – Sealing still wire schematic ...................................................................... 56

Figure 4.10 – Sealing schematic ................................................................................... 57

Figure 4.11 –TOU ......................................................................................................... 66

Figure 15.1 – Packaging Instructions ......................................................................... 208

Figure 17.1 - Contractor's Proposed Project Organization Chart .............................. 229

Figure A.1 – General IECo integration guideline ....................................................... 252


9


1. INTRODUCTION

The following document describes the requirements and guidelines for the Smart

Meter Project, including all technical and functional requirements for smart meters,

communication, data concentrators and all software elements, and the project

implementation.

1.1. Smart Metering In IECo

During 2013-2014, IECo completed a technology trial of ~4300 mostly residential

smart meters in the cities of Binyamina, Givat Ada and Ceasaria Industrial Park. The

purpose of the trial was to test different technologies, to gain learning about

technology performance, and challenges with installation and operation. Two PLC

standards (Prime & IDIS S-FSK), a proprietary S-FSK and GPRS were tested. For the

purpose of the trial and in ongoing operations data from each Head End, as supplied

by concentrator manufacturers, is currently being managed separately, on a semi-

manual basis.

1.2. Tariff Trial

IECo plans to conduct a primarily residential tariff trial in an number of sites across

Israel on approximately one third of the meters (~32,000). It is planned that various

tariffs, including "time of use"/"critical peak price"/and "critical peak rebate" will be

tested. The aim of the trial is to gain information about customer behavior in

response to various tariffs, to understand better the potential for demand

management and to provide the basis of a cost-benefit-analysis for full roll-out of

~2.7m smart meters.


10


1.3. Structure of the document

The overall purpose of this document is to provide the contractor an exhaustive list

of guidelines and requirements regarding the Smart Meter Project.

The document includes the technical and functional requirements for each of the

components in the project as well as requirements related to project management.

The technical requirements covering meters, data concentrators, software, and

security (chapter 4 – chapter 13) are presented here in two different manners; the

first way includes a general overview of the requirements that will be expected as

part of the suggested solution, the second is presented as a detailed requirement list

split up in a number of broad categories. Project management requirements

including requirements for Quality Assurance and Testing are covered in chapters

14-19.

1.4. How to reply to this document

This section describes how the Bidder should reply to the Specification in the Bidder's technical proposal.

In every paragraph or table that the Bidder is instructed to do so, the Bidder shall respond as described in this chapter.

If the Bidder does not provide a response in any individual paragraph or table that

the Bidder is instructed to do so, IECo will assume that the Bidder's proposed

System is not in conformance with requirement of the Specification.

1.4.1. General instructions

1) The proposal will be submitted in English.


11


2) In the event of a long answer, it is recommended to attach an additional

document at the end of the proposal. The document will clearly indicate the

Specification section to which it refers. Professional and promotional material

(not forming part of the attachments to the Specification) will also be attached.

1.4.2. Instruction for each Bidder Response

1) Each Bidder response will be classified as belonging to one AND ONLY ONE of the

following three categories:

Conform (Yes): The Bidder's currently available proposed system meets the

requirements in the manner indicated by the Specification.

Not-Conform (No): The Bidder's proposed system does not meet the

requirements of the Specification and no alternative is proposed.

Alternative (A): The Bidder's currently available proposed system uses an

approach at variance (or partial solution) with the Specification, which the

Bidder believes meets the intent of the Specification, the Bidder shall explain

the proposed alternative. In addition, the Bidder shall specify, where

applicable, the effort in man days, required to provide a fully conforming

item. This option does not apply for Chapters 4,5,6,7 and mandatory

requirements in Chapter 13.

2) Responses shall provide details of all the characteristics of his proposed System

which are relevant to the said requirement.

3) Responses must be sufficient to demonstrate how the Bidder proposes to comply

with the requirement(s), including full explanations of the techniques, disciplines

and procedures to be utilized. Failure to submit all required technical information

for the purpose of evaluation of a proposal may result in a lower proposal

evaluation score or failure for mandatory requirements.


12


4) Bidders shall indicate the link(s) of the relevant publication(s) of the Standards

and/or specifications on the Internet.

1.4.3. Bidder expected answer to conform tables

Table format for Chapters 4, 5, 6, 13 & 14:

1) Section as referenced in the Specification.

2) Name - the title of the section as in the Specification.

3) Conform

Chapters – 4,5,6 & 13 – (Yes/No)

Chapter 14 (QA and testing) - (Yes / No /A).

4) Ref to the document and section where the fulfillment with the requirement is

described: Bidder shall specify where in the document they have provided

description. The Bidder will include an indication to attachment / relevant link

e.g. drawings, QA Manual, description.

5) Comments. In case Bidder has additional comments. Where specified bidder

shall provide specific data required in the table. e.g. Class, Wight.

Table format for Chapters 8- 12:

1) Chapter - as referenced in the Specification.

2) Requirement - Requirement description.

3) Implementation Phase – In which phase of the Project this Requirement should

be implemented.

4) Remarks.

5) Conform (Yes/No/A)


13


6) Bidder Response – Bidder clarification where applicable.

1.5. Phases of Project

The Smart Meter Project is planned to be implemented in three different

consecutive phases as described in Figure 1.2 according to the timetable shown in

Figure 1.1. The reason for splitting the process implementation into these phases is

to save time by allowing parallel actions to take place.

Phase A will include implementation of basic functionalities enabling the process and

functionality needed for deployment of meters and creating the needed entities in

the MDM system.

Phase A will include delivery of meters, CTs, DCs and associated components -

delivery ofapproximately 60% of meters shall be completed during Phase A. Phase A

will also include preliminary series tests and production acceptance tests of the

meters and DCs. During Phase A a limited number of meters and DCs will be installed

for testing purposes.

Phase B will begin once the MDM operates with all basic processes and functionality

specified in order to support meters installation. In Phase B, there will be further

delivery of meters, CTs, DCs and associated components and installation of meters,

DCs and communication infrastructure will commence. Phase B will also include, in

parallel, implementation of processes and interfaces specifically with SAP-ISU that

are needed for carrying out the Project and were not implemented during phase A.

During this phase once a meter is installed it will be treated as a regular meter with

flat rate tariff for billing purposes (until the end of the overall installation of meters

in the Project).


14


Phase C will start once the defined scope of work in Phase B will be finished, and will

include low priority functionality including: load energy balance, contractual load

shedding - incentive scheme, outage - event handling. These low priority

functionalities are not mandatory to the Project, but are mandatorily required from

the MDM, for future use. During phase C, Meter Data acquired via the System may

be used for billing purposes in some roll out areas. The System shall be prepared for

this task at this stage. Further delivery of meters, CTs, DCs and associated

components will also occur in Phase C.

Once phase C is complete and the System is in production, Meter Data acquired via

the System shall be used for billing purposes for the all the roll out meters.

Figure 1.1 – Project time line


15


Figure 1.2 – Implementation phases of Project

1.6. Meters and DCs installation

IECo will be responsible for physical installation of meters and DCs. Contractor shall

be responsible for correct integration of the installed meters and DCs in the System.

1. DCs shall be installed prior to installation of corresponding meters.

2. Meter installers shall not require prior knowledge of the low voltage network

topology in order to be able to carry out installation process.

3. When meters are installed, installer will check for communication between DC

and meter (if meters have capability to indicate communication.)

4. Checks and studies of the network communications shall be performed once all

the DCs are installed in the field.

2. DEFINITIONS AND ABBREVIATIONS


16


The System is defined as including all components from Meters, to DCs, to

HES/MDM.

The Project refers to the Smart Meter Project.

"Meter Data" includes numerical registers, load profile, technical and event log.

"Bidder" Anyone who received this Tender request to present proposals and / or

the Bidder who presents an offer in response to this request

to submit proposals.

Service provider" or "Supplier" or "Contractor" - The Bidder whose proposal was

awarded the Tender

"Offer" or "Proposal" or "Bid" - The Bidder’s response to this Specification

"IEC" or IECo" or "The Company" or "The Electric Company The Israel Electric

Corporation.

Following are common abbreviations used across the document:

Table 2.1 –

Abbreviations

Table#

Abbreviation Meaning

1 MOC Meter Operations Center

2 MV Medium Voltage

3 OMS Outage Management System

4 OT Operations

5 POD Point of Delivery

6 PV Photo Voltaic

7 SM Smart Meter

8 VEE Validation, Estimation & Editing

9 WAN Wide Area Network

10 AMR Automatic Meter Reading

11 C&I Commercial & Industrial


17


Table 2.1 –

Abbreviations

Table#

Abbreviation Meaning

12 COSEM Companion Specification for Energy Metering

13 DC Data Concentrator

14 CT Instrument Current Transformers

15 DG Distributed Generation

16 DLMS Device Language Message Specification

17 DMS Distribution Management System

18 DST Daylight Saving Time

19 HV High Voltage

20 IT Information Technologies

21 LAN Local Area Network

22 LV Low Voltage

23 MDM Meter Data Management

24 DR demand reduction

25 DG Distributed Generation

26 M2M Machine to Machine – Meters with cellular

communication

27 PLC Power Line Communications

28 Prime PLC standard, specification for narrow band PLC

29 S-FSK IEC 61334 - standard for low speed reliable PLC

30 GPRS General packet radio service – 2.5G cellular

31 HES Head End System

32 Shoval The CIS – implemented with SAP CRM and SAP-

ISU

33 OSS Operational Support Systems

34 MF Main Frame

35 "taklot vhafraot" Legacy system for outage management

36 HHU Hand Held Device

37 "Paamon" System for managing meters operations in the

field

38 "Nakal" System for managing requests for meter reading

39 OSS Operations support systems


18


3. ARCHITECTURAL OVERVIEW

3.1. General

In this Specification a Smart Metering Architecture is not specifically defined.

Instead, IECo has defined the functionality required from the each of the Project’s

elements along with a set of constraints. On top of these, IECo has specified

guidelines and standards in term of integration and architecture to which the

proposed architecture will need to follow. The high-level architecture expected is

shown in Figure 3.1.

3.2. High level description of the Project

The Smart Meter Project will realize the following layers:

Meter layer

Communication layer

Metering data layer - this layer will include Data Warehouse, MDM, MOC, NOC,

HES, Deployment management system. These systems will interface with CIS

(SAP – ISU) and other IECo enterprise operational systems (see Figure3.2).

The Project will involve:

Meters

o Installation of about 70,000 – 163,000 single-phase/three-phase meters.

o Majority of meters will be PLC, approximately 70% (Prime/IDIS S-FSK).

o In certain cases cellular (3G or above) meters are expected to be

deployed.

DCs


19


o about 760 – 1,780 DCs

o CT meters for energy balancing

Instrument Current Transformers (CT) – about 4,300.

HES - metering data collection layer

MDM – metering data management system, the MDM system will be scalable for

a full national rollout

OSS - Operations Support System systems – MOC, NOC and deployment tool

(these components can be either separate modules or an integral part of the

MDM/HES product).

The expected volume of data is as follows:

98,000-228,200 meter readings per day. Calculation based on;

o 70,000 – 163,000 * 1.4(number of reads per meter per day)

The majority of the meters read two channels

12 events per meter per day

Number of estimated values – between 5 to 10%

Data shall be held for up to 3 years in the live system, older data shall be

archived for an additional 5 years

The expected number of System users is:

User category Number

Manager 20

Operational 30

Backend office 20

Others 10

Total 80


20



21


Figure 3.1 – Expected high level architecture

Figure 3.2 – Interface Diagram


22


3.3. IECo enterprise systems

3.3.1. CIS (Shoval)

The billing system that the MDM will interface to, will be the "Shoval" system,

currently in development due to go live by the end of 2016. The "Shoval" project

includes SAP-ISU and SAP-CRM. Interfaces between the MDM and the SAP shall be

based on "out of the box" solutions and will include aggregated data for billing

purposes.

The Customer relationship management (CRM) is in charge of the company’s

interaction with customers. The CRM will support the customer care center, the

billing unit, the sales strategy unit, etc.

NOTE: IECo has licenses for SAP-MDUS, and Prologa

3.3.2. NIS

The Network Information System (NIS) that is based on Geographic Information

System (GIS) and includes Outage Management System (OMS) systems is currently

live but is still being rolled out in different geographic areas.

The NIS is a GIS based application that will support: LV outage management, planned

outages, topological information of the electric chain from the customer to the

transformer, and further network topology toward the substation.

The new NIS may not be rolled out in the project area to be live in time for the

Project. In this case, the fallback will be to connect the MDM to the currently

working OMS ("taklot vhafraot" MF).


23


3.3.3. Portal / Mobile app

IECo has a Customer portal and mobile application that provides data to the

customers regarding their consumption and billing information.

The IECo portal/mobile app is currently connected to the central systems of IECo.

This includes the Billing system, and the CRM system, to enable historical and other

comparisons. For example to historical values such as same week last year, same day

last week, and comparison to the “average user”, tariffs, TOU information bills, and

customer information.

3.3.4. Existing remote reading systems

There are several existing systems in use in IECo for remote reading of meters, using

M2M and PLC methods (ITF, L+G, ZIV etc.).

3.3.5. HHU / "Paamon" / "Nakal"

Today meter readings that are not transferred via remote reading in the IECo, are

being read manually by field workers using HHU (data acquisition done by manually

insert or by using an optic probe). This data is being handled by the "Nakal" system.

Paamon - Systems for managing meter operations in the field (removal, installation,

and checkup), related requests for operations in the field are transferred to the field

worker (HHU or a laptop computer).


24


3.4. Architecture and integration guidelines

Below are the IECo’s guidelines towards building the architecture and integration of

the System. These architecture and integration guidelines play a critical role in

accelerating and future-proofing the design of a smart metering solution. In the

following chapters, the Contractor will be requested to present his architecture

solution for the Project as well as explain how his proposed architecture conforms to

these guidelines or alternatively, why it does not.

The proposed solution shall:

Support the defined functions of Smart Metering

Be a configurable and modular solution

Be standards based

Transferable to a reference architecture that can be implemented in steps

Have a security framework

Have an analytics platform

Usage of a BUS (as opposed to P2P) for Head-end integration with the back office

(MDM, OMS, Etc.)

Specify level of latency and integration

Aligned with IECo’s application integration policies

Aligned with Code management dictated by IEC standards

Use IECo’s resources when possible

Supportive of ongoing innovation

Scalable from Project to full deployment


25


Services Oriented Architecture (SOA)

Compliance to CIM

MDM analytics – Contractor solution for duplicated repository

All the solution’s physical components (whether cloud based or not) shall be

located in Israel

3.5. Proposed architecture for the Project

In this chapter the Contractor is required to present his architecture solution for

IECo’s Project. The solution shall be no more than 10 pages long; IECo expects to see

as much detail as possible as well as an explanation of the Contractor’s long term

vision.

The solution should adhere to IECo architecture and integration guidelines.

The architecture solution should cover (but is not limited to) the following subjects:

Application architecture

Integration architecture

Communication architecture

Information security architecture

Operational architecture

Deployment plan


26


4. METER

4.1. Meter model types

Several meter types are required. Communication module shall be embedded and it

may be extractable or external. In the case of cellular communication modules,

approval from the Israeli Ministry of Communications is required.

Contractor shall supply PLC meters from 2 different manufacturers.

The following table lists all the required meter types:

Table 4.1 - Required meter types

# Meter type Breaker

(Disconnector)

Communication module (embedded extractable or

external)

1 Single phase direct with BS 7856:1996 connection scheme.

No PLC (either Prime or IDIS S-FSK)

2 Single phase direct With BS 7856:1996 connection scheme.

No

Cellular (generation 3G and above)

3 Three phase direct With DIN 43857-2 connection scheme.

No PLC (either Prime or IDIS S-FSK)

4 Three phase direct With DIN 43857-2 connection scheme.

Yes PLC (either Prime or IDIS S-FSK)

5 Three phase direct with DIN 43857-2 connection scheme.

No Cellular (generation 3G and above)

6 Three phase Indirect CT- connected With DIN 43857-2 connection scheme.

No PLC (either Prime or IDIS S-FSK) Or cellular (both options are acceptable)


27


Contractors shall also supply split-core Instrument Current Transformers (CTs) for

low voltage electricity metering. Requirements for CTs are described in Chapter 5.

Modules

1) For PLC meters, the meter shall contain:

PLC MODULE – remote low voltage Interface Unit (Terminal Unit): This unit shall

be embedded in electric meter, and shall communicate with the DC by means of

PLC (PRIME or IDIS S-FSK). The unit may not contain batteries of any type. The

PLC module can be replaceable or fixed.

2) For 3-ph PLC meters with disconnector, the meter shall contain:

Breaker (Disconnector) – 80A Main Breaker: this unit shall be controlled by the

meter and shall be supplied by the contractor embedded inside the meter. The

breaker can be replaceable or fixed. The breaker shall be able to withstand at

least 5,000 open/close cycles at full load, without degradation of breaker and

meter performance. The power breaker performance shall be in accordance

with IEC 62055-31 Annex C.

3) Firmware for all the relevant modules shall be provided by the Contractor,

Firmware may be separate from meter firewall or shared, embedded within

meter firmware files.

4) Circuit breaker shall be (if needed) disabled permanently either through

mechanical or firmware.

4.2. General Metrology Requirements

4.2.1. Norms & Regulations

1) The proposed meters must conform to the requirements of IEC/EN 62053-21 as a

minimum. The contractor must state those cases in which the proposed meter


28


performance is degraded due to certain simultaneous values of two (or more)

environmental parameters.

2) Meters shall be compliant with the mechanical tests described in IEC/EN 62052-

11 or EN 50470-1.

* Prior to all/any testing the meter must run for two hours at Ith (0.5%*Ib) and

immediately afterwards for two hours at Imax. The meter error values before and

after the test shall be compared. The test load is Un, Imax and PF=1.

4.2.2. Documentation Requirements

In order to prove compliance with the requirements, the Bidder is required to

submit, with the technical proposal, the following documentation. All applicable

documents shall be in English, and shall refer to the specific plant where the

proposed meters are manufactured.

a. A true copy of the Certificate of type (pattern) approval from an

authorized body (institute, laboratory or competent organization),

confirming that the meter type, identical with proposed one, complies

with the requirements of IEC/EN 62052-11 and IEC/EN 62053-21 or EN

50470-1 and EN 50470-3 standards. The authorized body could be: NIST,

OFGEM, PTB, NMI, KEMA, METAS, LNE, NATA or MID assessment

(modules B and D at least) under appropriate identification number. MID

notified body shall be only from list provided at NANDO website.

Inheritance of notified body to outsourced labs outside NANDO list is not

accepted at this tender.

(http://ec.europa.eu/enterprise/newapproach/nando/index.cfm?fuseacti

on=directive.nb&refe_cd=EPOS_43437

http://ec.europa.eu/enterprise/newapproach/nando/index.cfm?fuseaction=directive.nb&refe_cd=EPOS_43437



29


and:

http://ec.europa.eu/enterprise/newapproach/nando/index.cfm?fuseac

tion=directive.nb&refe_cd=EPOS_54808

The provided test certificate must include a full test report, in accordance with

the standards. The bidder shall provide release notes of firmware version since it

was submitted for type test approval, and other changes insert to meter.

b. A copy of a certificate of compliance with ISO 9001 (2008) accredited by

the ISO organization from the both the R&D department and the

manufacturing department of the manufacturer

c. A list of utilities or metering service providers, which have purchased

electricity meters of a similar type and of the same manufacture,

proposed in the bid, during a period of five years, just preceding the last

date for submission of technical proposals. Such list shall include the

dates of delivery, the quantities sold and the name of person to whom

IECo may contact for clarifications at these utilities.

d. RAM Declaration - chapter 7 in this document.

e. Calibration certificates and traceability charts for all relevant test and

calibration equipment.

f. 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.

4.2.3. Additional tests

1. The meter shall withstand the free fall test according to IEC 60068-2-32

(including Amendment 2).




30


2. 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.

4.2.4. Climatic Conditions

The meters shall be finished to keep all specified features when installed indoors as

defined at IEC 62053-21 for indoor meter:

- Long periods of heat and without rain, alternating with high humidity as

experienced in coastal or desert areas.

- Ambient temperature (– 10 °C to 50 °C)

- Heating effects of solar radiation.

- Humidity

4.2.5. Environmental Conditions

The following characteristics shall be as defined at IEC 62053-21 for indoor meter:

Atmospheric and industrial pollution including coal dust, coal ashes, so and

acids.

Dust (suspension and sedimentation)

Sand

Water (other than rain); spraying and jets.

Mechanically active substances.

Chemically active substances

Fungus

Birds and rodents.


31


4.2.6. Electromagnetic Emission

1. The proposed system(s) must conform to the requirements of IEC 62053-21

as a minimum as specified at clause 8.2 table 8, clause 8.2.4, Annex B.

2. The contractor shall specify the levels of electromagnetic emissions of his

proposed system(s) through:

1. Radiation

2. Conduction

4.2.7. Excessive magnetic flux protection

The meter shall be protected against external continuous magnetic flux levels of up

to 1.5kG or detect and log external continuous magnetic flux levels which exceed the

value defined in IEC 62053-21, paragraph 8.2.4, as an influence factor.

4.2.8. Life span and dropout

The contractor shall prove that the meters are designed to operate for 15 years at

least, maintaining their conformance to this tender specification. Conformity to this

requirement shall be proven by the Accelerated Life test and RAM report described

in chapter 7 respectively.

4.2.9. Physical Characteristics

The following parameters are in accordance with standard DIN 43857-2 for 3 phase

meters, and BS 5685-1 for single phase meters.

The maximum dimensions for meters shall be as specified in table 4.2.

Table 4.2 – Maximum dimensions for meters

Item Width (W) Height (H) Depth (D)

Meter 3-ph 180 mm (between bottom mounting holes axes)

320 mm (including terminal cover)

140 mm

Meter 1-ph 90 mm (between bottom 180 mm (including 140 mm


32


mounting holes axes) terminal cover)

Meter CT-connected

180 mm (between bottom mounting holes axes axes)

320 mm (including terminal cover)

140 mm

** The contractor shall specify the dimensions (W x H x D) (mm) including accessibility requirements for operation, maintenance and installation)

4.2.9.1. Sealing

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.

7. The manufacturer shall submit a sample of the proposed seal (metrological

surely and securing if applicable) for IECo's approval after contract signing.

The exact same type of seal shall then be used throughout the period of

supply. Any further change in seal shape or format must be notified to IECo in

advance, and approved.


33


4.2.9.2. Terminal Block

The shape of the terminal block and its cover shall be in accordance with BS

7856:1996 for 1-ph meter and DIN 43857-2 for 3-ph meters on the assumption of

meter features and performance.


34


4.2.9.3. Terminals

1. 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).

2. 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.

3. 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.

4. 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 in their tightened

position must allow steady bottom connection of the meter to "quick springy

connectors" of Test Benches for metrological tests.

5. There shall not be access to internal parts of the meter through the

terminals.

Terminal Screws

For single-phase and poly-phase meters for direct connection the screw

diameter must be at least M6. The screw bottom must be chamfered,

without rough edges. The pinching screws for all meter types must be made

either of Steel 8,8 and be Nickel plated (5 micron min), or made of brass and

be protected against corrosion.

For CT-connected meters the screws heads must be of slot type only.


35


In any case, there shall no galvanic couple be set up between the screws,

terminals and copper conductor – joined alloys potential difference must not

exceed 0.15V (refer ASTM G82 Standard).

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.

Manufacturer is required to state the maximum allowed torque to be applied

to the pinching screws.

Terminal Cover

The terminal cover shall be of 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:

At least 40 mm for single-phase direct and CT connected meters.

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 enable the sealing of the terminal block. The screw shall be

protected against corrosion.

The screws shall be protected from slip out from the cover when not

tightened.


36


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.

4.2.9.4. Mounting Bracket

Mounting brackets to allow easy mounting are required for all meter model

types, with the exception of 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 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 4.1.

Figure 4.1 – Example of mounting bracket


37


Note: If the suspension clip is not of slide-on type it must be supplied to the

purchaser in extended position.


38


4.2.9.5. Mounting Holes

3. 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.

4. 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.

4.2.9.6. Weight

4 For single phase direct meters: up to 1.5 kg.

5 For three phase meters (direct and CT connected): up to 2.5 kg excluding

breaker.

4.2.10. Energy Registers

The meter must measure and register kWh energy irrespective of the

direction of current flow.

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 displayed, and also be readable via the

optical port.

Two additional energy registers must be provided for recording positive

(import) total kWh energy (1.8.x) and negative (export) total kWh energy

(2.8.x), and be accessible via the optical port. Load profile shall be for two

energy types Active import, active export.


39


The meter shall support tariffication. Therefore the following registers shall be

presented as described in table 4.3.

Table 4.3 – 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 following OBIS code

and matching definition.

Table 4.4 – 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:4.8.0*255

Reactive export total over all rates 1-0:4.8.0*255


40


4.2.10.1. Absolute metering:

Absolute value energy metering (OBIS: 15.8.0) is mandatory, and it shall be used only

for display, and not for billing and in accordance to following formula:

, 1 2 3absolute totalE E E E

Where Ei is phases 1, 2, 3 energy metering accumulated totally per all (tariff) rates.

This formula is also in accordance with metering formulas standards IEEE 1459, DIN

40110-1, 3.

1 2 3 4i rate rate rate rateE E E E E

The above formula degenerates to a single energy for single-phase meters. For billing

purposes separate import and export registers should be used. This means that if for

example phase S is PV (export) and phases R, T are import, then at export phase S

shall be registered and at import sum of R, T shall be registered.

4.2.11. Voltage Link

The input voltage connection (link), if any, shall not be available for opening using

conventional means, and shall be protected to prevent opening.

Note: The meters will be supplied to IECo with the link, if any, closed, and checked for

continuity.

4.2.12. Over –Voltage Protection

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.


41


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.

4.2.13. Long-Term Over-Current (Thermal Current) Protection

Additionally to the requirements specified in IEC 62053-21, the meter shall

continuously withstand a current of at least 120% Imax. The meter shall not be

damaged, and continue to operate properly when the over-current condition is

removed. Maximum current is according to clause 7.1. table 2, and clause 7.2.

4.2.14. Over-voltage and thermal current superposition.

The meter shall withstand the "worst case test" scenario is for combined over-voltage

condition (as specified in IEC 62053-21) and over-current condition (as specified in

4.2.13 above) , when superposed during one hour simultaneously. The meter shall

not be damaged, and continue to operate properly when the over- current condition

is removed. Any change of meter metrological features will not come out.

4.2.15. Neutral Connection Lost Operation

Meters shall continue to operate even when the neutral alone or in common with

any one of three phases are removed. The errors in energy measurement shall not

exceed the limits allowed in the standards regarding single phase energizing.

4.2.16. Communication

1) There are 2 types of meters: PLC and Cellular.


42


2) PLC meters shall follow one of the following PLC standards: PRIME or S-FSK (IDIS

only). The required communication protocol standards are SPECIFIED IN TABLE

4.5.

3) Meter must be registered at the websites from the PRIME Alliance or the IDIS

Association.

4) PRIME or IDIS logo must be printed on the meter front panel. Only use of

CENELEC A band (9- 95kHz) is permitted for both PRIME and IDIS S-FSK.

Table 4.5 – Communication protocol standards

# Protocol standards

1 PRIME EN 50065-1, IEEE 1901.2 Standard OFDM

2 IDIS S-FSK

EN 50065-1, IEC 61334 S-FSK IEC 61334-5-1: Distribution automation using distribution line carrier systems – Part 5-1: Lower layer profiles – The spread frequency shift keying (S-FSK) profile IEC 61334-4-511: Distribution automation using distribution line carrier systems – Part 4-511: Data communication protocols – Systems management – CIASE protocol Implemented according to IDIS Pack 1, and chapter 8.3 and 8.4

4.2.17. Meter Display

The meter display shall be LCD with good contrast and wide viewing angle for

easy meter readout. It shall have a wide operating temperature range

(industrial grade) and a life time of at least 15 years.

The display shall have 6 digits for the cumulative energy, with digit height of

at least 8 mm. The cumulative readout will be of whole kWh only, and shall

be the default display at meter power up.


43


General:

Displayed data order for each display item shall be programmable.

Scrolling between displayed data shall be done by push button manually and

auto scrolling (regular usage) as default.

Displayed data time duration shall be programmable.

Displayed data programmable parameters shall be in configuration file.

Configuration design is left to manufacturer's choice.

Current date and time shall be displayed.

Energy Data:

1. Active tariff.

2. Total kWh absolute (15.8.0) to be displayed only for direct meters formula as

specified at relevant energy data section per every meter. Note: Separate

registers, for both direct and CT connected meters, shall register Total Active

import (1.8.x) and Total Active export (2.8.x) for each rate.

3. For CT connected model types only: Total kvarh sum of all phases.

4. Total kWh (for both direct, CT connected) and kvarh (only for CT connected) per

each tariff; tariff name or code. = 11.6.2.2

5. current Maximum demand and cumulative value.

Displayed formats:

1. kWh and kvarh shall have a 6 digits display, 000000 to 999999, passing which, the

displayed value shall start at zero again.

2. maximum demand shall have a 4 digits display, 000.0 to 999.9

3. Cumulative maximum demand shall have a 6 digits display, 00000.0 to 99999.9


44


4. Date & Time: DD/MM/YY 24 h

High resolution display mode

1. High resolution 10wh/varh at least for dial test /accuracy testing

2. Changing to this mode by the meter push buttons or /and software for 60

mins at least. Shall reset to normal at power off.

Status displayed / indicators

1. Operative rate / tariff

2. Phases existence / non existence

3. Phases sequence order

4. Negative consumption flag (the flag shall be extinguished after reading)

5. In case the meter detects reverse energy an indication shall be given during the

reading process.

6. Failure indication and code (if any).

7. Communication status: Cellular/PLC

Instantaneous parameters

o Instantaneous parameters (phases voltage current power pf)

4.2.18. Dial Test Mode (high resolution display test)

The dial test mode shall be activated via either the optical port or a front panel key.

For dial test acceleration of the initial change of normal kWh resolution shall be

done. The dial test mode shall be activated for at least 60 min (necessary software

shall be included in the offer). In this mode, the display shall show 2 or 3 digits after

the decimal point (see 4.2.17). The meter will exit the dial test mode by each of the

following separately:


45


1) A command via the optical port,

2) A front panel key press,

3) Default within a fixed time,

4) After power off.

4.2.19. Optical Test Output

A light emitting diode (LED) indicator must be provided on the meter front panel,

which will flash in direct proportion to the power flow regardless of the current

direction, both for active and reactive, implementing 1 or 2 LEDs. The LED conversion

from emitting light to extinction or back shall denote the test pulse length. The LED

light shall be in the visible spectrum (preferably red), and shall not be modulated.


46


4.2.20. Optical Port (M0)

The meter shall be equipped with an optically isolated connector, physically

conforming to IEC 62056-21 mode E. This port shall be located on the front panel of

the meter, and be fully accessible. The baud rate shall be at least 2400 bit/s after log-

on, and no more than 9600 bit/s. The optical port must be in accordance with

IEC62056-21 pp. 25-29 must withstand:

1. Detachment strength of at least 5 Newton between probe and port, while probe

is touching the port. The optical ports shall be interoperable with Abacus and

Reallin probes.

2. Detachment strength of at least 1.5 Newton between probe and port, while

probe is 2mm away from the port.

3. In addition to IEC 62056-21, successful reading of large load-profile data for at

least 20 minutes, using an optical probe (Abacus and Reallin). Statement of the

conformity with this requirement shall be submitted by the Contractor.

The optical port shall be used for reading the energy consumption registers and other

data, such as the meter serial number and status flags. It shall not be possible to

reset the main (total) energy register, or to change the meter constant and other

metrological parameters via the optical port.

4.2.21. Power Supply

The meter shall operate properly with only one active phase of the mains (+Meter).

4.2.22. Memory

Memory component shall withstand correct performance under maximum

temperature of 60`C.

4.2.23. Meter Casing


47


The meter case shall be made of non-hygroscopic insulating material, self-

extinguishing class V-2 according to IEC60695-11-10, and withstand the tests defined

in IEC 60068. It shall be insulating encased with protective class II according to IEC

62052-11, and sealed against penetration of dust and moisture (IP 51, per IEC 60529).

Its shape shall be in accordance with BS 7856:1996 (for single-phase) and DIN 43857-

2 for 3-phase.

The meter case, as a whole, shall withstand the spring hammer test with energy

equal to 0.35 J.

4.2.24. Marking

4.2.24.1. Meter Serial Number

1. The meter's unique serial number shall be recorded both as printed numbers and

barcode, and also recorded in permanent memory, and available for readout via

the optical port. It must be impossible to change or delete the serial number.

2. The barcode shall consist of 12 digits: the first 4 digits shall present the meter

code with leading zeros if necessary, and the next 8 digits shall present the

unique serial number where the first two digits present the manufacture year.

These 8 digits shall form also the serial number imprint for visual reception, and

of and the internal memory's serial number. The figures of the imprinted serial

number shall be of at least 4 mm height and 2 mm width.

4.2.24.2. Nameplates

Each meter and PLC module shall have a main nameplate, affixed to it firmly.

1. The nameplate could be an intrinsic part of the meter case or cover, , a separate

part mounted under the transparent window, or made by permanent fade-proof

overprint on the front cover surface.


48


2. In addition to the marking required by IEC/EN 62052-11 and IEC/EN 62053-52 the

meter nameplate shall show manufacturing country, the official logo of the IECo

and an encircled code number consisting of 3 or 4 digits.

3. The code number will be given to the Bidder who is awarded the order.

4. The 8 digit serial number shall be marked with digits at least 4 mm high height.

The first two digits shall reflect the year of manufacture.

5. The serial and the code number shall be included in bar-code mark etched on the

plate.

6. 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, adding leading zeros if necessary.

7. The minimum height of the bar-code mark shall be 10mm in medium density.

8. 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%.

9. The meter current range shall be marked in the form:

1. For single phase direct: "10-60 A", for example, where the maximum current is

marked with larger font than the basic current (Figure 4.2)

2. For three-phase direct: The meter current range shall be marked in the form

"3x10-80 A", for example, where the maximum current is marked with larger font

than the basic current (Figure 4.3)

3. For three-phase CT connected: The meter current range shall be marked in the

form "3x 100/5 A". For example (Figure 4.4)

10. The final format of the nameplate is subject to IECo approval. No stickers to carry

or supplement the nameplate marks will be acceptable!)


49


11. The communication mode (e.g. PLC, cellular) should be marked on the

nameplate, with the relevant logo (Prime,IDIS,DLMS/COSEM)

Figure 4.2 – Example of single-phase direct connected meter nameplate

Figure 4.3 – Example of three-phase direct connected meter nameplate

Figure 4.4 – Example of three-phase CT connected meter nameplate


50


4.3. General Technical Features

Table 4.6 – Electric parameters specification

Meter type Connection

type

Reference Voltage

(Un)

Basic Current

(In)

Maximum Current (Imax)

Reference frequency

Accuracy

Static Single phase kWH

Direct connection 2 wire

230 V 10 A or 5 A

>=60 A 50 Hz

Class 1 - IEC 62053-21 Class B - EN 50470-3

Static Poly phase kWh

Direct connection 4 wires

3x230/400 V

3x10A or 3x5A

>=3x80 A 50 Hz

Class 1 - IEC 62053-21 Class B - EN 50470-3

Static Poly-phase Static kWh/kVar with current transformer

CT connected 4 wire. Multiplication factor 100/5 Primary side energy is to be registered and displayed.

3x230/400 V

3x5A >=3x6A 50 Hz

Active: Class 1 - IEC 62053-21 Reactive: Class 1 - IEC62053-24 Class 2 - IEC62053-23 with tightened to 1% calibration


51


tolerances.

Accuracy class of the submitted meter, that is better than the accuracy class required

by this spec , shall be accepted. The same is legitimate for accuracy classes according

to EN 50470-1, 3. The nameplate, however, shall carry the required accuracy class.

4.4. Static single-phase kWh meters for direct connection

4.4.1. Applicable model types

The specification refers to static kWh meters, for direct connection for single-phase

2-wire service. The meters must comply with all requirements of IEC/EN 62052-11

and IEC/EN 62053-21 or EN 50470-1 and EN 50470-3 publications.

This metrology specification covers the following model types – all required at this

tender:

Table 4.7 – Single phase model types according to communication

# Meter type breaker Communication module

(embedded extractable or external)

1 Single phase direct no PLC (either Prime or IDIS S-FSK)

2 Single phase direct no Cellular (generation 3G and above)

Note: If there are contradictions between the requirements of this specification and

those of the standards, the requirements of the specification will prevail.

4.4.2. Specific technical features


52


Following parameters must be sampled each 15 min and logged into the meter's non-

volatile memory:

1. Line-Neutral Voltage deviations of more than 10%

2. Power interruptions. Logging shall start with the event occurrence and stop with

the event cessation

4.4.3. Connection Diagram

Figure 4.5 – Connection Diagram according to BS 7856

Note: The connection terminals of mains and customer service must be marked on

the terminal block as given on the diagram with irremovable figures. The

arrangement of terminals must be according to BS 7856.

4.5. Static Poly-Phase kWh meters for direct connection



53


The specification refers to static active energy meters, for direct connection for

Three-phase four-wire service. The meters must comply with all requirements of

IEC/EN 62052-11 and IEC/EN 62053-21 or EN 50470-1 and EN 50470-3 publications.

Table 4.8 – three phase direct meters model types

# Meter type breaker Communication module

(embedded extractable or external)

3 Three phase direct no PLC (either Prime or IDIS)

4 Three phase direct yes PLC (either Prime or IDIS)

5 Three phase direct no Cellular (generation 3G and above)

Note: If there are contradictions between the requirements of this specification and

those of the standards, the requirements of the specification will prevail.

4.5.2. Specific Technical Features

The meter shall have the following features:

1. Breaker: Remotely operated breaker for disconnecting / connecting neutral conductor

shall be provided as an option. The breaker's operation reasons:

1. Consumption limitation

2. Consumer disconnecting / connecting

3. The breaker shall be able to withstand at least 5,000 open/close cycles at full load,

without degradation of breaker and meter performance. The power breaker

performance shall be in accordance with IEC 62055-31 Annex C.

2. Following parameters must be sampled each 15 min and logged into the meter's non-

volatile memory:

1. Line-Neutral Voltage deviations of more than 10% per each phase

2. Power interruptions in each phase and total power interruptions. Logging shall start with

the event occurrence and stop with the event cessation



54



the terminal block as given on the diagram with irremovable numbers. The dashed

line is optional. Both an implementation with and without simultaneous phase

switching shall be accepted.

Figure 4.6 – Three phase connection diagram

At IECo, the breaker shall be used for remote connect/disconnect of entire consumer

load, therefore phase contacts shall be switched simultaneously, either by software

configuration or by hardware built-in at the breaker. Both a breaker with separate

phase contacts and a breaker with single control per all phase contacts shall be

accepted by IECo

4.6. Poly-Phase Static CT-Connected Electricity Meter


Table 4.9– Three phase CT connected meters model types

# Meter type With/without

breaker

Objective Communication module (embedded extractable or

external)

1 Three phase Indirect CT-

w/o Consumer > 100A PLC (either Prime or IDIS S-FSK) Or RS-485 (both options are


55


connected acceptable)

2 Three phase Indirect CT- connected

w/o Adjacent to DC cellular

The specification refers to Static Watt/Var-hour Meter, with three measuring

elements, connected via Current Transformers. The meters shall comply with all

requirements of IEC/EN 62052-11, IEC/EN 62053-21 and IEC/EN 62053-24 or IEC/EN

62053-23 publications.

4.6.2. Specific Technical Features

The Meter must have the following specific features:

Multiplication factor: 100/5 A. Primary side energy is to be registered and displayed.


Figure 4.7 –Connection diagram of CT connected meter

Breaker is not drawn herein but is a mandatory requirement.


the terminal block as given on the diagram with irremovable numbers.


56


4.7. Diagrams, Sealing

Following are additional diagrams concerning logo, nameplates

4.7.1. Company Symbol

Figure 4.8 - IECo Company Symbol

Symbol Design: The symbol basic design is a positive square. It is important to keep

the proportions of the form in order to get the right performance.

Note: The square dimensions in the drawing are for proportional reference only.

4.7.2. Stranded Steel Wire for Sealing

Figure 4.9 – Sealing still wire schematic


57


Material: 7 s trands made of zinc galvanized steel, or stainless s teel

Diameter: 0.3 mm

Tensile Strength: 180 kg/mm2

4.7.3. Sealing Alternative Shapes

Figure 4.10 – Sealing schematic

Plate thickness: 0.75 mm nominal

Rockwell Hardness: 55-65 T15


58


Coining: One side; IECo logo, other side; the manufacturer sign or logo

Ferrule embossing (while sealing the meter): One side; IECo sign/logo. other side;

the manufacturer mark (to be agreed with IECo)

4.8. Functionalities

4.8.1. Interchangeability

Meters that have the same lower layer communication (cellular, IDIS-SFSK, PRIME)

shall be interchangeable regarding data model and application layer.

(E.g. in case for some reason it is decided to replace single phase meter with 3 phase

meter or direct meter with CT connected meter). In order to enable simple handling

by MDM the meter types and meters from different manufacturers must have

1. Same data elements and datatypes of value attributes.

2. Same list of events codes supported.

3. Same behavior in terms of ‘functionalities’.

All functionalities shall be part of the application layer and be fully documented by

the bidder in the companion specification(s) as refered to in appendix D.

4.8.2. Meter Registration

The meter shall have unique Device ID in accordance with the marking on the

nameplate.

Once installed meter automatically identifies nearest neighbor meter and DC and

automatically registers itself in the parent DC meter list. The parent DC is the one

located at the same distribution transformer.

If the meter communicates over a mobile network, the bidder shall describe how the

meter can be registered to the network and how IP addresses are assigned (how the


59


PDP context is set up). The meters are only accessable after ‘waking up’ by the

MDM. The procedure shall be the same for all meters (manufacturer independent)’.

Connection management of meters shall be managed via objects of the designated

DLMS/COSEM classes (auto-connect, GPRS Setup, IP-Setup).

4.8.3. Meter reading on demand

Meter reading on demand means that the head end system initiates the meter

reading.

Direct meters shall be able to record and store active import and active export

energy registers and have 2 load profiles channels (import and export. CT connected

meters must also be able to read and store the reactive import and reactive export

energy registers and have 4 (Active+, Active-, Reactive+, Reactive-) load profile

programmable channels. Meters shall enable the capture (= integration) period of

the load profile to be configured. Integration periods will by default be set to 15

minutes.

Table 4.10– Required energy parameters for all model types

Meter type (direct/CT)

Registers Load profiles columns and

capture period

Direct Active Energy Import Active energy Export

Profile type 1: Clock Active Energy Import Active energy Export AMR profile status

Default - 45 days, 2 chanels, 15 Minutes

CT

Active Energy Import Active energy Export Reactive energy import Reactive energy export

Profile type 2: Clock Active Energy Import Active energy Export Reactive energy import Reactive energy export AMR profile status


60


Default - 45 days, 4 chanels, 15 Minutes

The list of all required energy parameters that are in accordance with both DLMS

COSEM and IECo requirements shall be part of the Companion Specification, see

appendix D. At appendix D there are columns specifying objects required for load

profiles, billing and other.

Maximum Demand requirements are described below:

1. Maximum demand shall be calculated over 15 minute intervals.

2. The max demand interval shall be terminated and value zeroed, by Meter time

update and loss of power.

3. The max demand of this period is not to be transferred to cumulative max

demand for accumulation.

4. A new (shorter) time interval shall immediately begin after an interval is

terminated due to power down/power in the same integration period in order to

complete 15 round minutes.(Example: if max demand terminate at 10:07, a new

period covering 10:07-10:15 shall be generated. )

5. Maximum demand calculation time intervals shall be synchronized with the

beginning of an hour according to the Meter time base.

6. Max demand periods shall start and terminate at round 15 minutes periods (i.e.:

10:00, 10:15, 10:30,…).

7. Recording of maximum demand time shall be performed at the end of its

respective time interval.


61


8. Maximum demand shall be managed separately for each tariff, Monthly maximum

demand, cumulative maximum demand, date and time of maximum demand

shall be stored for each tariff.

9. Each record shall contain the date and time stamp of the recorded maximum

demand occurrence, this time being the end of the respective time interval.

10. A new maximum demand shall be recorded at the end of the respective time

interval, only if it is bigger than the previous one.

1. The meter shall register the biggest Maximum Demand at the current month, at

the accumulated at the CMD1 of that month.

2. At every end of month Max Demand is reset and shall start measurement from

zero.

11. The beginning of a new calculation time interval due to interference, loss of

power etc. shall zero the momentary maximum demand fields.

12. In case the meter detects reverse energy, no maximum demand shall be recorded

(negative maximum demand is not considered), and an event in the log file will be

recorded.2

13. Once self reading is performed, the monthly maximum demand value shall be

added to the cumulative maximum demand register; monthly maximum demand

value and time registers shall be cleared. Definition: Self-reading is defined as;

when the meter records a snapshot of all energy registers including absolute

total value, rate registers, max demand, and cumulative max demand with their

respective time and date stamps.

1 Cumulative Max Demand 2 Cumulative Max Demand


62


14. After ’end of billing’ is performed, the maximum demand register shall be

zeroed. The value of max demand previous to zeroing is transferred to

cumulative max demand for accumulation.

4.8.4. Meter reading for billing

Meters shall be read daily for billing with the same consumption and load profile

objects as described in meter reading on-demand (4.8.3).

4.8.4.1. Billing Profile

1) The Meter shall be able to store at least 4 entries in the billing profile.

2) It shall be feasibility to perform automatic adding of an entry in the billing

profile (triggered by a scheduler in the meter at the end of the billing period) or

by an external triggersuch as the DC or HES.

3) Selective access per date or range entry shall be allowed.

4) End of Billing shall be performed by the Meter automatically in the following

scenarios:

1) Automatically at the end of a calendar month at 00:00 only by default but

additional entries can be scheduled.

2) Deliberately, by personnel performing maintenance operations using a portable

PC.

3) Deliberately, by MDM.

4) Self-read shall be performed after activation of any new configuration such as new

TOU calendar.

5) The attributes required for billing are marked in appendix D.

4.8.5. Remote Tariff Programming


63


The TOU implementation shall be located in the meter. It shall be remotely

configurable and robust to communication failures.

1. Total energy register of kWh data shall be separately stored for each tariff. By

total it is meant sum of all phases.

2. Only one season and one tariff shall be in operation during any time.

3. A season shall be defined by a month and a day, and shall be in effect starting

at 00:00 hours of the defined day in every year, and shall be superseded when

the next season becomes effective. Holidays and weekdays shall be definable

during a season.

4. Ending of a maximum demand time interval shall be performed before the end

of a season. If necessary, self-reading shall be performed before a new season

becomes effective. At least 4 seasons shall be definable. For each season the

tariff prices are different.

The Manufacturer shall define his proposed meter in strict compliance with the

parameters described here.

4.8.5.1. TOU & Special Days

The general definitions of the TOU structure are according to figure 4.11 - TOU Table

2010. IECo preserves the right and shall test, ability to modify TOU configuration, for

up to four tariffs per day. In any case there is doubt the description herein override

figure 4.11.

1. The Meter shall input and store any TOU that defines:

1. At least 4 seasons per year( the seasons dates are repeating for each year)

2. Within each season, 3 different day profiles shall be available (so: 12 day profiles

in total shall be defined).


64


3. The meter shall support 3 different tariffs.

4. At least 6 Tariff change points per day indicating the beginning of tariff

5. Enough special points for definition of "special days" (holidays& holidays evening

covering at least 1 year (Table 4 - TOU Special Dates Table 2014-2015). IECo

requires 18 special days per year

2. A new TOU shall become effective immediate after uploading to meter

3. TOTAL import and export register of kWh and data shall be separately counted

for each tariff.

4.8.5.2. Seasons

1. The start of a season shall be defined by a month and a day

2. Season starting at 00:00 hours of the defined day in every year

3. Shall be superseded when the next season becomes effective.

4. Holidays and weekdays shall be definable during a season.

5. Only one season and one tariff shall be in operation during any time.

4.8.5.3. Daylight Saving Time

IECo allows either of the following two options:

1. DST for lifetime of the meter. DST start and end dates are stipulated by the new

law is as follows:

1. DST starts at 02:00 on Friday (or Sunday) before the last Sunday in March. The

meter time is moved forward by 1 hour, so the time change is as follows:

02:00 --> 03:00.

2. DST ends at 02:00 on the last Sunday of October . The meter time is moved back

by 1 hour, so the time change is as follows: 02:00 --> 01:00.


65


2. Different Years Date

1. Daylight saving time shall be defined by its beginning date, ending date and time

difference from standard time (one hour or more).

2. DST time shall become effective on the date prescribed for daylight saving time

beginning, at 02:00 to 03:00 hours.

3. Standard time shall become effective on the date prescribed for daylight saving

time ending, at 02:00 to 01:00 hours.

4. In case of missing DST definition command or file dates expired the meter shall

work at standard time.

5. The different DST dates shall be programmable within some uploadable

configuration file or via MDM command.

6. A new definition shall become effective immediate on uploading to meter..

7. If current meter date, is within period of [DST entry date, DST exit date],

provided meter is not already at DST, then entry to DST shall be immediate.

8. If current date is not within [DST entry date, DST exit date], then meter shall wait

until date arrives.

9. Updating meter time with remote MDM system, with real time while DST is valid

shall not damage the meter time.

10. There shall be a flag in the meter and accessible while reading by MDM,

that indicates that the meter is at DST time.

11. Updating meter (Before and after the DST dates are effective) with new

dates shall change the meter time correctly to the updating dates and

time.


66


Note: For both options Meter Bidders are allowed to change the meter firmware and

the relevant software in order to comply with this requirement during the technical

evaluation stage.

4.8.5.4. TOU & special dates & DST dates

Israel currently uses the TOU table show below (figure 4.11) which has not changed

since 2010.

1) The TOU table below shall be programmed through configuration file or via its

communication interface to arriving meters.

2) IECo requires that it shall be possible to re-program TOU table as defined in IECo

requirements.

3) IECo requires 18 special days. Special day table is defined in appendix C.

Figure 4.11 –TOU


67


4.8.6. Remotely Programmable Parameters

The meter shall input and store any TOU table covering at least 4 Seasons per year,

at least 3 tariffs per season, calculation of Maximum demand for each of the 3

tariffs, and 18 points for definition of " special days" and holidays (Israel calendar - in

accordance with 18 special days per year), at least 3 types of days, at least 6 tariff

change points per day (rates: high, medium #1, medium #2, medium #3, medium #4,

low) indicating the beginning of tariff and the beginning and dates of day light saving

time period.

A typical TOU table in use by IECo is presented as in figure 4.11.

4.8.7. Disconnection and Reconnection

IECo requires implementation of the breaker only for 3 phase direct PLC meters. The

breaker shall have the characteristics; 80A, 3P (preferably but not mandatory

including 0). This output shall be operated by remote control from DC.

The breaker shall by be operated by:

1. Load limitation – meaning beyond certain load (measured in current or power).

2. A present demand value for activating the main breaker shall be calculated over

programmable time intervals (5, 15, 30 minute). In addition, these time intervals

shall be terminated by system time update and loss of power. The values

exceeding the preset demand shall be recorded.

3. Remote Consumer disconnecting / connecting

Remote reconnection shall only be enabled via push button if the meter is set by

MDM in ‘Ready for Reconnection’.

4.8.8. Clock Synchronization


68


RTC synchronization is required for load profile period alignment between meters.

Meter RTCs will be synchronized by the parent DC, which will be synchronized by the

MDM. MDM shall be synchronized by an SNTP server. For details on requirement for

load profile in the case of duplicate data field see Appendix E.

4.8.9. Meter Supervision

a) The meter shall store a log containing events of software updates, failures

and their time of occurrence, readings, power failures, communication etc.

For additional information as regards to event log structure and the list of

events that shall be supported see Appendix E.

b) IECo requires that there shall be a flag at events log when magnetic flux value

exceeds the value stated at IEC 62053-21, paragraph 8.2.4. 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.

4.8.10. Firmware Update

a) It shall be possible to remotely update meter's Firmware. In case there is a

separate firmware for the communication and the meter application, then

both parts are required to be remote upgradable.

b) Firmware version identifiers shall be available trough the communication

interface of the meter.

c) Metrological part of the firmware (Legally relevant FU) shall not be

upgradable.

d) Neither (metered) data stored in the meter, nor configuration settings are

impacted by a firmware update.


69


4.8.11. Consumer Information

a) Messages for customers shall be displayed by the meter.

b) Messages can be configured via the communication interface.

4.9. Performance Characteristics

The performance characteristics of the meters shall be specified in this paragraph.

These characteristics shall be expressed as requirements that must be achieved and

shall have upper and lower limits of acceptable operation.

The contractor shall provide the performance characteristics of his proposed meter.

The following data shall be specified and complied with as a minimum.

Table 4.11 – Performance characteristics

# Feature Number of

retries Latency

1 Local meter reading of 2 months of Load Profile data

4 20 mins

2 Local firmware update 2 10 mins

3 Remote cellular meter reading of 2 months of Load Profile data

4 30 mins

4 Remote update of firmware for cellular meters 2 1 hour

5 Remote reading of PLC meter via DC – 2 months of Load Profile data

4 40 mins

6 Remote firmware update of PLC meter via DC 4 1 hour

7 Remote reading of cellular meters Load Profile data for single day

2 5 mins

8 Remote reading of PLC meters via DC – Load Profile data for single day

4 15 mins

4.10. Software Tools


70


Software tools are required for validation of meters functionality until the MDM is

operational. Laboratory software tools shall continue to be used for generation of

configuration files for meters. For details of requirements see Appendix F.

5. INSTRUMENT CURRENT TRANSFORMERS

5.1. Norms & Regulations

1) The proposed CTs must conform to the requirements of IEC/EN 60044-1.

Type test Certificate must be issued by a laboratory that uses a reference CT and a

current measuring bridge traceable to a National Laboratory, according to IEC

publication 60044-1 clause 7 and must consist of:

a) Temperature rise test (IEC 60044-1 clause 7.2).

b) Instrument security factor determination (IEC 60044-1 clause 11.6).

c) Short-time current tests (IEC 60044-1 clause 7.1).

d) Thermal current Ith-1 sec: 60 x In

e) Determination of errors (IEC 60044-1 clause 11.4) at 25% and 100% of the

rated burden.

2) The proposed CTs must conform to the requirements of IEC 61000-4-8, Edition

1.1 2001-03 EMC. Testing and measurement techniques – Power frequency

magnetic field immunity test.

5.2. Documentation


71


In order to prove compliance with the requirements, the Bidder is required to

submit, with the technical proposal, the following documentation. All applicable

documents shall be in English, and shall refer to the specific plant where the

proposed CTs are manufactured.

a. A copy of a certificate of compliance with ISO 9001 (2008) accredited by

the ISO organization from the both the R&D department and the

manufacturing department of the manufacturer

b. A list of utilities, which have purchased CTs of a similar type and of the

same manufacturer, proposed in the bid, during a period of three years,

just preceding the last date for submission of technical proposals. Such

list shall include the dates of delivery, the quantities sold and the name of

person to whom IECo may contact for clarifications at these utilities.

c. Calibration certificates and traceability charts for all relevant test and

calibration equipment.

d. The manufacturer shall attach with the technical offer a complete

description of the CT with all its properties and its detailed relation to

each item of this specification.

e. Type tests certificate and results of proposed CTs, or similar, issued and

performed by a laboratory that uses a reference CT and a current

measuring bridge traceable to a National Laboratory, proving its full

compliance with Standard IEC/EN 60044-1.

Remark: In the context of this paragraph, a "similar type" means a CT which:

Has the same construction (split-core), accuracy class, rated current, rated output (burden) as

defined in Standard IEC 60044-1 and the same dimensions

Is manufactured with the same technology and the same materials

Is designed to operate at the same environmental conditions.


72


f. Calibration certificate of manufacturer test equipment (Bridge, reference

CT and burden), performed by a laboratory accredited according to ISO

17025.

g. Routine tests results as per paragraph 14.2.2.6 of the provided samples of

CTs.

5.3. Design and construction

5.3.1 The CT must have open core around an axis and not split entirely

5.3.2 The CT must have the casing made of thermoplastic material. The

casing must be heat and impact resistant.

5.3.3 The casing must be of self-extinguishing classes HB40 and V-0 according

to IEC 60695-11-10.

5.3.4 The casing should have the uniform surface. Any apertures or cavities

on the surface are not acceptable.

5.3.5 The proposed CT shall be for indoor use.

5.3.6 Dimensions:

Height: 150 mm max; Width: 150 mm max; Depth: 60 mm max

5.3.7 Window Opening:

CT must have an opening with diameter of 80mm min to 100mm max. The CTs is

intended to be "hanged" on the primary conductor. If the accuracy of the CT is

sensitive to cable position in the aperture (centered or not) the centering accessory

shall be provided.

5.3.8 Each terminal shall ensure good contact pressure on exposed tips of

secondary wire of 4mm2. The screws shall withstand the tightening


73


torque of at least 4.0 Nm. The screws shall be made of nickel plated or

passivated brass.

5.3.9 Terminals shall be marked as per Standard IEC 60044-1, clause 10.1.

The polarity markings P1, P2 and terminals markings S1 and S2 shall be

placed on the top surface of CT and be clear and readable.

5.3.10 The rating label shall bear all the data as per Standard IEC 60044-1,

clause 10.2, including serial number and IECo catalog number. It will be

steadily fixed on the surface of CT.

5.3.11 The rating label shall include bar-code mark done in code 128C with 12

digits, the first four digits for the transformer code and 8 digits for the

serial number, adding leading zeros if necessary, and the IECo logo. The

winner of the tender will be informed regarding transformer code.

5.3.12 The rating label shall be protected against environmental impacts.

5.4. Technical Requirements

5.4.1 Highest voltage for equipment 0.72 KV RMS.

5.4.2 Rated power-frequency with-stand voltage: 3 KV RMS.

5.4.3 The thermal class of the insulation should be B, according to IEC 60085.

5.4.4 Rated primary currents (In): 1000 Amps.

5.4.5 Rated secondary current: 5 Amps.

5.4.6 The rated insulation voltage is 800 V.

5.4.7 The rated frequency is 50 Hz.

5.4.8 Accuracy class: 0.5 or better

5.4.9 Rated output: 10VA or less.


74


5.4.10 Extended current ratings: 1.2 In.

5.4.11 Instrument security factor: FS10 or less.


75


6. DATA CONCENTRATOR

The smart meter data concentrator (DC), in our context, relates to the use of PLC

technology for the last-mile. The DC is responsible for the acquisition, processing,

recording and storing of data from smart meters. The DC is typically installed near

the transformer station, on the low voltage side of MV/LV power transformer. It

collects data from meters connected to the same transformation station, and

subsequently delivers processed data to an higher level managing system such as :

HES (Head end System), MDM (Meter Data Management) and MOC ( Meter

Operations Center). Main functionalities typically include: automatic detection of

meters, meter registration, meter synchronization and periodic and on-demand

reads. Additional major functionality is configuration update. IECo wishes to

emphasize that any operation that can be performed locally at the meter, shall

also be able to be performed remotely from the DC.

The DC specification is in two parts: the first part presents an overview of the

communication technology and interfaces. The second part is a table containing

detailed requirements that will form the basis for the evaluation of the tender.

6.1. Communication Technology in DC

DCs shall communicate with smart meters using PLC from meter side (M1-C1) and

3G or above from MDM side (C2). Vendors that reply to this Specification shall follow

one of the following PLC standards: PRIME or S-FSK as defined in IDIS pack 1.

The required standards are:

Table 6.1 Communication Standards

# DC Type Standards

1 Prime EN 50065-1, PRIME

2 IDIS S-FSK EN 50065-1, IEC 61334 S-FSK


76


PLC communication shall be performed through the CENELEC A (9- 95kHz)

band, which is licensed for use by IECo.

Interface between DC and HES/MDM shall be based in open solutions (i.e

webservices with xml format exchange). Vendor shall provide the detailed

specification of this interface to IECo as part of the deliverable.

Communication towards HES shall be done with secured protocols, https,

sftps, etc, for more details see section 13.3.

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.

Defined Required communication reliability #1: DCs shall be able to reach at

least 90% of their meters within 48 hours of DC and meter installation, and

successfully receive entire load profile data, consumption data, and event

logs. Required data with 97% comm. reliability is once a day. A meter is

declared comm. failure if for 5 succesive days it is failing. The first constraint

(90%) applies to cluster statistics, and 2nd constraint (5 days) applies to

individual failing meters.

Defined Required communication reliability #2: Within 30 days after

installation DCs shall be able to reach at least 97% of their meters, and

successfully receive entire load profile data, consumption data, and event

logs. It is integrator's responsibility to take all necessary and required

measures in order to obtain that communication availability level. Installation

and testing shall be performed by IECo with bidder/integrator guidance. This

means that if communication level is below 97%, then if required, that a


77


technical expert shall be sent by contractor to IECo for root cause, and if

required filters/repeaters shall be installed. Filters shall be budget as 0.1% of

entire meters population requirement for repeaters/filters

Filters/amplifier/repeater requirement: Filters shall be required.

Repeaters/amplifiers shall be required if needed to improve the

communication quality to meet the communication requirements of this

specification. Filters shall be either 3 phase, and if there are no 3 phases,

single phase is also accepted, by quantity of 0.1% X 3 phases.

Filters/repeaters/amplifiers shall have a P/N, a serial number and preferably

a barcode. Repeaters – only if implemented not as meters. Barcode may be

stamped. Filter shall withstand 65 Amperes. Filter shall preferably not be

connected to GND.

Antennas: In certain locations the DCs shall be installed underground. For

these cases IECo requires extension communication cables of at least 20m in

one segment, with antenna. Antennas shall be suitable for use with DCs and

CT-connected meters.

6.1.1. DC Interfaces:

6.1.1.1. C0: Local Interface

DCs shall provide local interface for local configuration of the DC through both the

following methods:

RS 232 interface

Ethernet (LAN)

6.1.1.2. C1: Interface between the DC and the meter

Interface between the DC and the meter shall be based on PLC transimission on 3-

phase (Prime or IDIS-SFSK).


78


6.1.1.3. C2: Remote Interface

The DC remote interface shall be based on MODEM or Ethernet (WAN). The MODEM

will be at least 3G and above In the case of MODEM, approval of the Israeli Ministry

of Communications is required. The remote interface shall be used for the following

needs:

For communication with HES/MDM

To enable access directly to the DC for configuration purposes using web access

or by a similar way.

6.2. General Requirements

Table 6.2- List of general DC requirements

ID Requirement

6.2.1 General Requirements

1. IEC 60068-2 regarding mechanical, vibrations, heat and fire resistance tests

2. Insulation test IEC 60060-1

3. Test of immunity to electrostatic discharges IEC 61000-4-2

4. Test of immunity to electromagnetic RF fields IEC 61000-4-3

5. Test of immunity to fast transient bursts IEC 61000-4-4

6. Surge immunity test IEC 61000-4-5

7. Test of immunity conducted disturbances IEC 61000-4-6

8. Conducted and radiated emissions test EN 55022

9. DCs shall conform to the degree of protection of at least IP 51 as given in IEC 60529

10. CT meter can be integrated with DC or connected.

11. Filter/repeater/amplifier shall withstand IP 55.

6.2.2 Operating conditions requirements

1. Relative humidity durability range 5%-95%

2. Temperature range from -10oC to 60oC


79


6.2.3 Electromagnetic Compatibility

1. Dielectric strength: 4 kV, 50 Hz, (IEC 61004-5)

2. Electrostatic discharge: 15 kV (IEC 61004-2)

3. Burst: 4 kV (IEC 61004-4)

4. Impulse voltage 6kV, 1,2/50 μs (IEC 62052-11)

5. High frequency electromagnetic field 10 V/m and 30 V/m (IEC 61004-3)

6.2.4 Nameplate and Housing requirements

1. Each data DC shall be marked legibly and indelibly with the following information:

a. Device description

b. Complete model number

c. Power supply voltage

d. Serial No. and year of manufacture

e. Transceiver Type

f. Maximum Current consumed by DC.

2. Protection fuses on the DC housing; four-pole MCB3 for disconnecting the neutral as well as the 3 phases

3. DC Lifetime. DC shall have a lifetime of 15 years as guaranteed by manufacturer.

6.2.5 Clock Requirements

1. DC device must have a real-time clock (RTC)

2. 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

3. Battery for RTC and calendar that shall be operational for 15 years from which 2 years of storage.

6.2.6 Maintenance

6.2.6.1 The following maintenance manuals shall be provided:

1. Test equipment manuals including testing instruction and test equipment description, theory of operation

2. Storage instructions

3. Software manuals

4. Documentation: DC manufacturer shall provide all documentation

3 MCB – Circuit Breaker


80


that covers entire functionality, and tests results as defined by this spec.

6.2.6.2 Maintenance Tools

1. Good quality test equipment for testing and diagnosis at direct DC reading, and features of remote diagnostics that shall be suitable for proposed PLC protocol and provide at least the following data:

a. Signal-Power-dBm

b. Signal-Noise-Ratio (SNR)

c. Attenuation

d. Power Spectrum; differentiation of noise

2. A local tool/facility for readout of data and log file

3. Facility for local reprogramming of the DC

4. Availability of GUI map/flowchart/diagram which shows the status of all meters connected to the DC

6.2.6.3 Maintenance of communications

1. Facility for checking the communication between the DC and meter and between the DC and MDM

2. Receiving an indication via display or LED, when DC is properly connected to the voltage network DC Indication LEDs: Cellular ON/OFF Cellular quality PLC send / receive Ethernet

6.3. Functionalities

Table 6.3- List of DC Functional Requirements


81


6.3 6.3.1 Time Synchronization

6.3.1.1 DC synchronization

1. DC shall support synchronization of the RTC from the MDM/HES. Time synchronization from other system is not allowed . Time synchronization from HES shall synchronizes DC with local time.

2. Capability to automatically carry out the Israel official DST time change for at least a period of 1 year (according to supplied calendar)

3. The DC shall provide functionality to adjust the maximum deviation that is accepted compared to the actual time from the MDM/HES.

6.3.1.2 Meter synchronization

1. Perform synchronization of all its dependent meters to same time stamp once per day

2. DC shall provide functionality to synchronize the meters using M1-C1 interface . Synchronization command shall be able to be generated unicast and multicast.

3. Capability to execute synchronization cycle manually, via local web client in DC.

6.3.2 Meter Registration

1. DC shall support Automatic Meter Registration (Plug and Play mechanism). DCs shall automatically discover meters on installation in the following sense:

a. If new meter is added, while transmitting to DC it shall be added.

b. If meter is de-installed then after a pre-determined period it shall remove by MDM from DC meters list.

2. In the DC's meter list there will be an option to filter the meter list. For example: According to different meter types or according to meter status (installed, fail to communicate and etc.)

6.3.3 Data receiving/transmission

1. Automatically or Upon request of the MDM/HES, DC shall send data to MDM/HES once a day or according to configurable schedule

a. DC will respond to configurable schedule requests or direct commands from the central system.

b. DC will send only pre-defined and configurable alarms (DC alarms and meter alarms) to the central system, upon request from MDM or automatically

2. Capability to program requests for meter periodic reads. DC shall be configurable for scheduled task that will be periodically executed (i.e. periodic meter reading). At least the following parameters shall be configurable inside the task:

a. Periodicity (in seconds, minutes, hour, day, month and year)

b. Start and end date


82


c. Group of meters to execute the task

d. Priority

e. Information to read

3. On-demand meter reading, manual requests to a specific meter. The following requests, sent by theMDM/HES, shall be forwarded by the concentrator to the specified electricity meter:

a. Periodic meter reads

b. On demand meter reads

c. Power quality information

d. (Dis)connect electricity meter

e. Apply threshold

f. Remote parametrization (i.e TOU)

g. Interval values

h. Firmware Upgrade

i. Retrieve electricity meter state

j. Network monitoring

4. The concentrator shall provide functionality to forward a broadcast or multicast on demand request, which was sent by the MDM/HES, to all metering installations hosted by the concentrator.

5. The DC shall provide functionality to bi-directionally communicate with the Electricity meters hosted by the DC.

6. Dc shall have access at least to the following data in the meters:

a. Total power consumption per {active, Reactive}X {import, export} per each meter

b. Power factor of each connected meter

c. Current/power limiting parameters

d. Load profile

e. Every electric parameter registered in the meter

7. DC shall have the option of collecting alarms from meters and forward them without delays to the central system ( i.e. neutral loss) via push mechanism.

a. It shall be configurable the selection of alarms/events read from the meters that shall be transmitted with push mechanism.

8. Functionality of automatic data transfer to the MDM/HES shall be configurable

6.3.4 Retries in data transmission

1. Automatic management of retries in the data reading/transmitting

2. Capability of programming of number of retries and time between retries for sending data to meters, or accessing meters for data reading

6.3.5 Remote parametrization of the meters


83


1. DC shall be able to write every configurable meter parameter.

2. DC shall be able to configure the following meter parameters (via unicast, multicast or broadcast request):

a. TOU,

b. DST

c. Connect/Disconnect

d. Displays

e. special days

f. general parameters

g. Limit consumption

3. Configuration updates shall be robust to voltage and communication failures. If communication with DC is lost during configuration update, existing configuration shall not be erased (!)

6.3.6 Schedule data transmission

1. The concentrator shall provide functionality to send a broadcast or multicast scheduled request, which was programmed by the MDM/HES, to all metering installations hosted by the concentrator.

2. If the data for a scheduled task cannot be sent, at the next scheduled time for sending data the DC shall automatically try to send both the current data and previous missing data. E.g. for a daily task, if data from yesterday could not be sent, today the DC shall automatically try to send yesterday and today's data.

6.3.7 Monitoring and Network Management

1. Each DC shall be able to be managed by MDM, as a unique device identified by some unique valued parameter

2. The concentrator shall provide functionality to respond to a communication test initiated by MDM/ HES in case the concentrator is the addressee of the test.

3. DC shall be able to automatically detect the network topology, including repeaters following a change in network topology scheme

a. DC shall be able to detect number of communication switching (transmit/receive) with a specific meter

4. Capability of determination of size of transmitted/received data chunks

5. Capability of determination of latency time between DC and meters

6. Total number of readable meters in terms of communication. System will consider a meter as readable when it has been able to read its load profile at least once in the last 24 hours.

7. DC shall provide information about the line quality, at least the following parameters shall be made available:


84


a. Statistics about lost data

8. DC shall store communication statistics between:

a. DC and meter (PLC)

b. DC and HES(cellular)

9. DC shall detect loss of communication to a meter and shall register an event. It means that DC is aware of meters that lost comm. and logs their comm. loss. DC shall be capable to send this event information automatically to the MDM/HES, if configured.

a. Definition of meter in communication failure (loss of communication) shall be agreed between Contractor and IECo based in keep alive/ping mechanism of the PLC protocol.

b. Number of retries or timing in the keep alive/ping mechanism shall be configurable.

6.3.8 Data Storage

1. The DC shall store information on each dependent meter device which shall be kept even in the event of a power failure, including:

a. Physical device meter identifier, preset in the factory (= serial number)

b. Device Meter type or other identifiers (single phase, three phase)

c. Unique identifier of the modem associated with the device

d. Meter/Device communication status: in service, temporal failure or permanent failure

e. Load profiles for at least 4 channels on of energy at 15 minute intervals, for at least 10 days.

f. Daily data for billing purposes

g. Meter firmware version ID

2. Each DC shall be able to store readings (consumption, load profile/event logs) of up to 250 meters for 12 days.

3. DC will have the ability to create output file of the stored information in some standard format (e.g. .csv, .xml, .txt).

a. At least the following reports shall be available:

i. Monthly billing

ii. Load Profile.

b. Output file shall be available for a specific meter or selectable group of meters and for all meters.

4. Once the available memory is full for a particular parameter the oldest data shall be deleted first to be replaced with the most recent data (FIFO)

5. In cases where a meter changes its DC ownership:

a. the DC shall be able to update its meter list, according to MDM.

b. but continue to store data of de-registered meter until authorized otherwise by MDM


85


6.3.9 Event logging and reporting

6.3.9.1 DC events

1. The DC shall store information on internal DC events. Events will be stored using a code and a time stamp. The event code list will be supplied to the Client by the system integrator. IECo shall validate the list of events.

2. DC shall detect the following events:

a. Tamper

b. Reboot.

c. Power failure

d. Communication loss

e. Local/Remote access to the DC

f. Opening/Closing cover

g. Demand response

h. Meter (un)registration

i. Communication events (initialisation/ending cellular communication, initialisation/ending PLC communication, no SIM, error in ethernet connection,etc…)

6.3.9.2 Meter events

1. DC shall be able to retrieve all events log from the meters( through unicast or multicast request). Some example of logs below:

a. Standard event log

b. Tamper detection event log is required for all meters connected to DC and for DC itself.

c. Power quality event log (start/stop)

d. Demand Management event log

e. Firmware event log

f. Disconnect event log

2. DC shall be capable of processing push messages from the meters with event information. It shall be configurable, sending the event information automatically to the MDM/HES.

6.3.10 Firmware upgrade

6.3.10.1 DC firmware upgrade

1. DC shall support remote firmware upgrade. Firmware transmission shall be initiated by the HES/MDM.

2. DC shall support local firmware upgrade, by direct connection to DC RS.

3. Firmware updates for DC shall be robust to voltage and communication failures. If communication with DC is lost during firmware update, existing shall not be erased (!)

6.3.10.2 Meter firmware update

1. DC shall be capable to perform remote firmware upgrade to the meter(s), to


86


6.4. Software Tools

Software tools are required for validation of DC functionality until the MDM is

operational. Laboratory software tools shall continue to be used for generation of

configuration files for meters. For details of requirements see Appendix F.

a single meter or with a multicast or broadcast request.

2. DC shall implement a robust mechanism against communication failure for the meter firmware update. The mechanism shall allow that the procedure is recovered or that in reiterative communication problems the procedure is aborted.

6.3.11 Power-cut handling

1. Data shall not be harmed in even of at sudden power cut situation

2. During shutdown process all unsaved data shall be saved to the flash memory

6.3.12 Security

1. Data/message encryption at store and in transit

2. Password management. Password for DC shall be unique to IECo.

3. Request for information: any other information security capability that D.C. has – shall be mentioned to IECo

4. External encryption/decryption modem can be connected to D.C., as known to D.C. manufacturer

5. External information security module software/hardware can be connected to D.C. successfully proven, as known to manufacturer

6.3.13 Local and remote operations at the DC

1. Every request defined in the previous requirement sections shall be available directly accessing to the DC through web interface

2. DC shall implement a web client.


87


7. METERS AND DCS RAM REQUIREMENTS

7.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-191.

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.


88


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

7.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.

7.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.

total


89


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).

7.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).


90


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.


91


8. METER DATA MANAGEMENT (MDM)

8.1. General

MDM (Meter Data Management) is the central repository system which

communicates with the Head-End on one side and various enterprise applications on

the other side. It renders the complexity of different head-ends and acquisition

technologies transparent to the enterprise applications. It stores all the meter data

collected from different smart meters and processes it as required by the enterprise

applications. It also triggers commands and events required by the business to the

meters through the Head-Ends e.g. requests to connect and disconnect all signals

and special requests coming from or going to the meters in the AMI System like

flags, errors, outage alarms or messages for voltage events, pings.

MDM, in our propose architecture, serves not only as a data repository but as an

umbrella of services that enable additional processing:

Meter Data Collection

Calculations – For billing purposes (and visualization to the customers).

VEE – Validation, Estimation, (meter) Editing

Analytics

Event Management

Holds lean entities of customers, contracts and geographical information.

The head end will hold (and manage) the connection between meters and

concentrators (fathers & sons).

The MDM shall manage different kinds of meters roles

Billing


92


Check / reference – serve to validate readout data in case of CT and CT/VT

meters. Can be utilized for replacing missing / invalid readouts of the main

(billing) meter by means of automatic editing as part of the VEE process.

Communication – a technical entity that is installed at the field to enhance /

rectify communication quality.

Energy balancing

Generation

Bidder Response:


93


8.2. Business processes

Table 8.1 - MDMs process by phases

Details in process number Phase process #

8.2.1 – install meter A Install meter 1

8.2.1 – install meter A Manually install meter 2

8.2.2 - remove meter B Remove meter 3

8.2.2 - remove meter A Manually remove meter 4

8.2.3 – meter replacement B Meter replacement 5

8.2.4 – disconnect / connect meter

C Remotely disconnect meter / load -limiting 6


A Manually disconnect meter / load-limiting 7


B Remotely connect meter 8


A Manually connect meter 9

8.2.5 - Update master data A Update master data 10

8.2.6 - Provide insight to customer

B Provide insight to customer 11

8.2.6 - Provide insight to customer

C Provide insight to customer – near time 12

8.2.7 - Meter data validation

A Meter data validation (VEE) 13

8.2.8 - Meter data acquisition

A Meter data acquisition

14

8.2.9 - Meter to bill B Meter to Bill 15

8.2.9 - Meter to bill B Triggering Bill Correction 16

8.2.9 - Meter to bill B Billing on demand 17

8.2.9 - Meter to bill B Creating a new billing timeslice 18

8.2.10 - on-demand reading

A On-demand reading 19

8.2.10 - on-demand reading

B On –demand reading via SAP ISU/CRM or other

20

8.2.11 - Managing virtual / calculated channels

B Managing virtual / calculated channels 21

8.2.12 - Contractual load B Contractual load shedding - Voluntary load 22


94


Details in process number Phase process #

shedding shedding

8.2.12 - Contractual load shedding

C Contractual load shedding - incentive scheme

23

8.2.13 - Load balancing / Transformer energy balancing

C Transformer metering / load (Energy) Balancing

24

8.2.14 – handle notification C Handling notification 25

8.2.15 – Handling log A Events log handling 26

8.2.16- Manage meter configuration

B Manage meter configuration – tables / firmware

27

8.2.17- System time synchronization

A System time synchronization 28

8.2.18 - Operational reports

A Operational reports 29

8.2.19 – Fault Managment A Fault Managment 30

8.2.20– Data Concentrator Management

A Data concentrators management 31

8.2.1. Install meter

The meter installation sequence begins in SAP, when a request is initiated to install a

meter. After the smart meter has been issued from the inventory the technician

installs the meter in the premise. The technician reports back to SAP that the meter

has been installed. An interface from SAP to the MDM will create the meter in the

MDM with its master data (lean entities).

The contractor will ensure that the necessary attributes, that have not been

delivered from SAP-ISU, or other enterprise systems for reading the meter (be that a

PLC or a cellular read meter) will be stored in the system by means of automated

processes. It shall also be possible to define the relationship between the

transformer meter and all its "children" meters (the meters connected to the

concentrator at that transformer).

If required the contractor will deliver the required tools to accomplish the above.


95


The process ends successfully when the MDM manages to get a read-out from the

meter.

It shall be possible to trigger a "manual installation" in the MDM, in the case that the

interface between SAP and the MDM hasn't been established yet or is

malfunctioning.

The system shall provide the ability to import a file with details of installed meters.

The file is based on data that is extracted from SAP-ISU.

The attributes shall be the as those that are passed in the automated "install meter"

interface from SAP-ISU.

In addition, the system shall provide a GUI screen by which the meter and its

relevant master data can be introduced in the MDM and thereafter in relevant

activities, e.g. triggering a read-out to get the installation reading.

If the MDM fails to read the meter as a result of the meter not being registered

automatically in one or more of the AMI components a ticket will be registered in

the fault management system.

Bidder Response:

8.2.2. Meter Removal

Removal of the meter is typically needed when:

The premise is being demolished.

The device is malfunctioning or too old.

The device needs to be replaced by another device such as a cellular meter.


96


The MDM is required to support meter removal processes.

It shall be possible to trigger a "manual removal" in the MDM, in the case that the

interface between SAP and the MDM hasn't been established yet or is

malfunctioning.

The system shall provide the ability to import a file with details of removed meters.

The file is based on data that is extracted from SAP-ISU.

The attributes shall be the as those that are passed in the automated "meter

removal" interface from SAP-ISU.

In addition, the system shall provide a GUI screen by which the meter and its

relevant master data can be removed in the MDM.

Bidder Response:

8.2.3. Meter replacement

Meter replacement will be accomplished by issuing the meter removal and install

meters processes.

In case the customer hasn't changed as part of the meter replacement there should

be continuity of metering data for this customer at this point of delivery.

Bidder Response:

8.2.4. Disconnect / connect meter / load-limiting


97


In some cases customers may be disconnected. For example:

Customers that don’t pay their bills.

When people move out of the house and there is no immediate new

occupant.

Load limit have been reached ( as part of the load shedding contract)

This can be carried out manually on-site by a technician at the customer premises.

Alternatively, some smart meters allows for remotely turning off/on the main switch

of the premise (remote disconnect/connect) or reducing capacity (load-limiting). The

MDM needs to support remote disconnect/reconnect/load-limit process (updating

the meter status) by a special GUI screen or by means of importing a file with details

of meters. The file is based on data that is extracted from SAP-ISU (phase A) and by

automatic interface from the SAP-ISU (phase C).

Some customers will not be allowed to be disconnected. E.g. people with a blood

dialysis machine at home. These cases will need to be registered in the MDM (non-

interruptible customer), much in the same way as a voluntarily interruptible

customer is registered for the Load Limit Plan. When registering a request for

disconnect/load-limit the MDM will first need to check that it does not concern such

a customer, before sending the disconnect request to the head-end.

Various scenarios may trigger disconnection and reconnection. For example

disconnection and reconnection can be triggered by the CRM in case the customer

has not paid his debt and the dunning process has reached the step of

disconnection. When the customer has paid his debt then the reconnection process

is set in motion. Another scenario can be when a customer asks voluntarily to be

disconnected because of a long planned absence from the premise e.g. a trip abroad.


98


In phase A the MDM will receive a manual request and will register and will send the

disconnect/load-limit command to the smart meter.

It shall be possible to send time frame parameters along with the load-limit

command, i.e. when does the load limit become effective and when does it expire.

A confirmation that the status has changed at the meter level will be fed back

through the communications chain in an expedited manner, to the MDM, where it

can be verified by the back-office user. In phase C there shall be an automated

interface from SAP CRM to the MDM to initiate these actions.

Please refer - DLMS UA 1000-1 Ed. 12: 2014 - COSEM Interface Classes and OBIS

Identification System, the “Blue Book”, chapter 4.5.8 Disconnect Control.

Bidder Response:

8.2.5. Update master data

The MDM will hold master data that will include lean entities of the customer,

contract and geographical information, this data will be based on the relevant data

in the SAP-ISU system.

An updating process shall be triggered by any change in the attributes connected to

a smart meter in the SAP system. This process is expected to be performed

automatically from the beginning of the Project (phase A). However in case that

there will be any problem concerning the automatic interface there shall also be the

possibility to update master data manually through a special GUI screen. The system


99


shall provide the ability to import a file with details of update master data. The file is

based on data that is extracted from SAP-ISU.

This process shall be compatible with the SAP-ISU/CRM relevant process UseCase2:

Change Technical Master Data and all additional needed consumer data.

Bidder Response:

8.2.6. Provide insight to customer

Provision of customer portal and mobile application are out of scope of the Project,

however there is a requirement to enable provision of the relevant data to the

customers via existing IECo Customer Portal and Mobile app.

The goal is to provide the customer with insight regarding his consumption, in order

to create awareness and reduce consumption via the IECo portal or mobile

application. The primary purpose of the portal/mobile application is to provide a

higher level of insight based on analytics, history and tariffs.

It is required that the MDM shall also transfer data to the portal/mobile app. There

shall be daily updates from the backend systems.

The portal shall support and display the following:

Consumption history (through a link with the MDM; aggregated per Time of

Use, but also raw load curves).

The portal may also provide additional insights such as:


100


Send customer messages about load limit events.

Notify customers of time to end of outage (through a link with the outage

management system).

Provide customers with tariff and billing information

Providing insight to customers in near time:

In the scope of the Project we expect to implement a solution that provides near

time consumption data for a sub-group of customers (a few hundred customers).

IHD (In Home Display) solution will not be acceptable. Visualization of the data

needs to be accessible to the customer via a web site or a mobile device.

Bidder Response:

8.2.7. Meter data validation (VEE)

The MDM will compile VEE processes and store validated data for billing. The MDM

will respond to Billing cycle request and aggregate validated interval data based on

TOU and send aggregated or register data to the billing system from where a bill will

be generated and sent to the customer. The basic VEE process will be expected at

phase A and will be developed and enhanced as will be determined in the detailed

design phase.

1) The MDM must perform VEE as part of the Meter to Bill process.

a) Validation – can be divided broadly into two categories:


101


i. Energy registers e.g. sanity (maximal values), daily balance, monthly

balance

ii. Meter configuration – comparing values with reference data, e.g. TOU

table, DST, number of load profile channels, firmware version

b) Estimation – can be applied to register values and load profile interval values

as well. Estimated values should be clearly marked as such. It should be

possible to apply the estimation as soon as the meter readout data is

processed or alternatively, after a configurable amount of time. The bidder

shall detail the various estimations algorithms that can be applied.

c) Editing – the MDM should support manual editing of registers and load

profile periodic values. It should also be possible to automatically edit values

based on the values of a reference meter / check meter. Editing can be based

on imported data from a file that was read at the field by, for example, an

HHU. Edited data should be marked as such.

d) If meter data is changed once by either reason, a new version of meter data

must be created.

e) It should be possible to define precedence rules, e.g. automatic editing from

check / reference meter (if applicable) should precede application of

estimation rules.

2) Validated meter data will be stored in the MDM and be available for use by other

processes, such as aggregations/reporting.

3) It shall possible to define validation rules that relate to virtual and/or calculated

channels.

4) The MDM will aggregate load profile data into Time of Use blocks. TOU formulas

can be different for different customer segments, different tariff choices of the


102


customer, different geographies, and different moments in time (e.g., formula

can change from one month to the next). Changes in TOU formula need to be

“timesliced”. It shall also be possible to provide the billing system with non-

aggregated data. TOU formulas will be imported from SAP-ISU as described in

meter-to-bill business process in the Creating a new billing timeslice sub process.

5) Validations in the SAP-ISU Billing Application will be of a different nature. They

will not look to validate consumption. Rather, these validations will check

parameters such as; if all customer data requested for billing have been

delivered by the MDM, if the MDM calculations have taken into account the

correct tariff timeslices, etc.

6) The VEE processes must be configurable to comply with Israel regulations.

Phase A: validation for meter data including technical data shall be supported.

Phase B: editing for meter data shall be supported.

Phase C: estimation for meter data shall be supported.

Bidder Response:

8.2.8. Meter data acquisition

1) It should be possible to configure the data acquisition frequency per data

category (register, load profile, events). The acquisition frequency shall also be


103


configurable by defined parameters from the master data e.g. meter type,

contract type. Typically, all meter data should be acquired at least once a day.

2) Load profile data acquisition should support the various period intervals that can

be sampled by the meters, e.g. 5,15,30 and 60 minute intervals

3) Register data for billing (e.g. TOU, max demand) will be acquired at least once a

day

4) For details of the required type of data please refer to Meter chapter (chapter 4)

in this Specification document

5) In case of missing information the MDM shall keep track of the missing

information in the previous readings and will issue retry read operation to

downstream modules in order to acquire missing data. In case of new meter

installation, the MDM shall keep track of retrieving the missing information from

the date and time of the physical meter installation

6) If data is received for a meter from two sources, e.g. in case the meter is

registered and read by two concentrators, then an alert shall be triggered to the

NOC system and the multiplicity of the data shall be resolved.

Phase A: the MDM will receive the meter data (LP, register and events). Register

data will be delivered to Shoval for further processing (billing will remain the same as

is currently performed).

Manual read will serve as a fallback in this phase, clarification: readouts will be

gathered on field by HHU.

Phase B: providing aggregated LP data to SAP billing system (Shoval) to support the

new tariff schemes as part of the pilot.

Phase C: support billing requirement for load shedding events.

Bidder Response:


104


8.2.9. Meter to bill

Billing will be done monthly (as this is what a smart metering infrastructure would

typically allow) or bi-monthly (as this is the regulatory regime currently in place in

Israel).

Billing information is provided by the MDM to the Billing System (SAP - Shoval). SAP

will determine the billing cycle; the MDM must deliver aggregated LP data or register

data based upon the billing system policy for billing in response to and in line with

the billing scope defined in the request from the SAP system. The Billing system will

be the “Master” for tariffs and will feed the MDM with this information through an

interface.

Billing can also be applied to calculated / virtual channels. The MDM should support

the ability to send billing data for these kind of channels.

Billing data will be transferred to the SAP system in one of two options, as a reply to

a request sourced in Shoval or will be pushed to Shoval based on billing cycle

requirements that were given from Shoval in advance.

Triggering Bill Correction:

After billing has been done, errors may still be detected in the meter data (or other

data) that was already sent to SAP to be used for billing. Corrective actions shall still

be possible. In this scenario a notification shall automatically be provided to the

Billing / CRM application with information to credit and re-bill the customer. In this


105


case, it is expected that the original data-set that was used for issuing the bill will be

kept intact and a new version will be created for the new updated data set.

Billing on demand (e.g., cases of customer end and start)

This case is assumed to be the same as the monthly/bi-monthly billing described

above, except that the trigger for billing is on a specific day due to an event such as

someone moving out of their house, and the period being billed could be quite short

(even only one day).

A billing process is not assumed to require immediate information; a bill is typically

sent via mail to a customer (in the case above, it could be to a different address).

Daily granularity and speed seems adequate for billing purposes.

The exact way of triggering and transferring data between MDM and SAP, shall be

further elaborated in detailed design.

Creating a new billing timeslice (e.g., changing TOU or tariff formula)

Certain events will impact the aggregations in the MDM, without immediately

triggering a bill as in the case above. This is the case when e.g., the tariff formula or

Time of Use formula would be changed in between two billing runs.

The MDM will need to be able to register the formula change and the date from

which it needs to take effect (i.e., create a “timeslice”).

At the time of billing, assuming the billing system requires aggregated data, the

MDM shall provide 2 sets of aggregated TOU values: the aggregations from periods

data before the formula change date, and the aggregations referring to periods after

the formula change date.

The exact way of triggering and transferring data between MDM and SAP shall be

further elaborated in detailed design.

Bidder Response:


106


8.2.10. On demand reading

Reading on demand can be triggered from SAP as part of a business process e.g.

customer complaint or manually from the MDM or it can be triggered by a technician

at the field requesting to trigger a read for a meter which is about to be replaced /

removed.

Reading on demand can have a parameter of date in order to retrieve historical data

– in case the desired data already exists in the MDM it will be retrieved from there.

It shall be possible to set the target from which the meter data is retrieved, i.e. MDM

(when invoked from SAP), HE, concentrator or directly from the meter.

Phase A – on demand reading shall be supported manually from the MDM or from a

third party system.

Phases B & C – on demand reading can be initiated from SAP.

Bidder Response:

8.2.11. Managing virtual / calculated channels

The MDM shall manage different kinds of meters roles.

Additionally it shall be possible to define relationships between meters e.g.

main/billing and check reference.


107


It shall be possible to define relationships between meter channels e.g. in case of

managing distributed generation (e.g. PV) the solution shall support:

In the case without sub-meter, IECo will have no information regarding how much

energy a customer has generated, rather they’ll know the import from or export to

the grid for every interval of that customer.

There will be separate tariffs for net export and net import; export revenues and

import billing will appear as separate lines on the invoice.

In the case with a sub-meter, IECo will have information regarding how much energy

a customer has generated. This data can be used to reward a customer on all the

energy he has generated

The information of main meter (measures Import “I "and Export “E”) and sub meter

(measures Generation “G”) will have to be combined to calculate the net

consumption (“C”) for which to bill the customer.

At times when a Customer’s Consumption is greater than his own Generation: C=I+G

At times when a Customer’s Generation is greater than his own Consumption:

G=C+E; C=G-E

It shall be possible to define complex validation rules that relate several channels

e.g. in case of DG an additional Validation rule could be applied: Export cannot be

larger than Generation.

It shall be possible to define virtual channels as an arithmetic expression of several

real channels (up to thousands of meters). E.g. creating a virtual channel that sums

up all the channels of a C&I customer with several premises.

Bidder Response:


108


8.2.12. Contractual load shedding

"Contractual load shedding” constitutes a special case in which changing master data

could have an impact on billing. The distribution network must be designed taking

into account the possible concurrent peak use of different connected customers. If

customers agree to limit their peak use, this has a positive effect on reducing

network reinforcement needs.

It shall be possible to enlist customers to this program via various channels in the CIS

system. This data shall be propagated to the MDM.

There can be two approaches to implement this business process:

Voluntary load shedding: the customer chooses to enlist in a plan where the

customer is informed when a load shedding event is announced. The customer

consumption in the period of said event is compared with his average hourly

consumption within a predefined period, e.g. the last ten working days. The MDM

shall provide the necessary data to accomplish this. This option shall be

developed and delivered as part of the scope of phase B.

An incentive scheme (probably linked to tariffs) can be set where customers can

agree to a certain contractual maximum capacity to be drawn from the network.

When a load shedding event will be announced a message will be sent to the

meter which will be capable to set the proper capacity reduction (This

functionality will be available just for the meters with a contactor, if max power is

exceeded then disconnection will take place). This option shall be developed and

delivered as part of the scope of phase C.

Bidder Response:


109


8.2.13. Load balancing / Transformer energy balancing

Energy balancing meters shall be read similarly to the way other smart meters are

read. Their data shall arrive at the MDM and be available for balancing reports with

the data of the meters that are marked as the "children" of the transformer meter.

It shall be possible to import a file with details of linkage between meters and their

energy balancing meter.

The required processes aggregate consumption of meters by transformer association

and compare it to the documented consumption in the transformer meter.

Bidder Response:

8.2.14. Handle notification

Alarm / Event Notification refer to near real time data that will be pushed from the

meters (via cellular communication (Cellular meters) to HES).

The MDM shall be able to receive notification from the HES.

Notification shall include the following type of events and configurable:

Outage

Power quality

Fraud Detection


110


This data will be routed to the relevant system via designated interfaces, e.g. –

outage and power quality notification transfer to "Takalot vehafra'ot" / NIS, fraud

dedication to MOC or ISU modules.

MDM shall store all notification in to relevant database.

Bidder Response:

8.2.15. Handling Log - events / alarms

Log alarm / event refer to data that will be stored in the meter and / or DC and will

be pulled to the MDM as part of the data acquisition process. Log events may

include outage events that are not available in near real time (e.g. via PLC).

Various types of events (referenced in meter requirements chapter) may be

distinguished by the meter, and passed on via the head end to the MDM. The MDM

shall be capable of logging these events (including their type) and make this

information available for other process, e.g. - the VEE process, reports and other

analytics purposes.

Bidder Response:

8.2.16. Manage meter configuration – tables / firmware

The tracking and management e.g. uploading to the meters of parameters (TOU

table, fixed special days table, passwords, etc.) and firmware versions held in each


111


meter will be controlled in some form in the MDM or the MOC. The process relevant

to this data will be considered in the detailed design phase.

It shall be possible to configure the parameters of a specific meters as well as

broadcasting configuration update to multiple meters in a single transaction.

It will be supported as an on-demand (ad-hoc) action as well as a scheduled routine.

It should be clear to the bidder that in IECo meter configuration needs to be

manageable according to IECo business related definitions, e.g. fixed special days.

It shall be possible to track and diagnose whether the update configuration action

completed successfully and highlight the meters that weren't updated, the system

should cater for retry policy for the failed updates.

Bidder Response:

8.2.17. System time synchronization

The MDM shall maintain time synchronization, i.e. all the relevant components shall

periodically engage with an SNTP server to ensure its system time is accurate.

The offered solution shall support validation and monitoring process controlled by

the MDM to insure all components of the system, are correctly synchronize.

Bidder Response:

8.2.18. Operational reports\scripts


112


Basic reporting and analysis must be available on all MDM data , including data

originating from MOC / NOC/ HES/ functionalities in such way that it does not

compromise the performance of operations of normal MDM tasks. This section

describes operational reports that are not based on the DWH.

It should be possible to combine data from different sources to generate more

precise and reliable reports, e.g. invalid meters report should be crossed checked

with the list of valid DCs and meters removals data from SAP-ISU.

Examples are:

Daily data collection report

Missing read reports for meters with confirmed valid communication

grouped by communication method (e.g. cellular meters , PLC meters)

Meter availability and diagnostics

Daily read status report

Zero consumption report

Validation error report

Tamper and fraud detection reports

Reports shall be available in a digital format suitable for further data processing (e. g.

Excel) and digital formats for reporting only (e. g. PDF). The MDM shall support user-

configurable reporting tools so that a user can easily define its own reports. User

shall be able to configure time-consuming reports to run automatically (e.g. at night)

and specify where the reports will be saved. The MDM shall be capable to store the

reports and results of reports persistently. The MDM shall support the usage of

stored results from reports, as the basis for new reports.


113


The MDM shall facilitate invoking relevant process from reports, e.g. triggering

messages, mails to relevant destination, triggering process in interfacing systems

(Shoval).

Generally reports generation and configuration should be user friendly and flexible.

Bidder Response:

8.2.19. Fault management

The system shall perform a daily analysis of faults including communication,

metering, invalid / missing readouts. Following detailed design respective errors will

be logged in this module. The system will allow for forwarding tickets to relevant

enterprise systems and receiving feedback from those systems.

In case there are separate fault management systems for the MOC & NOC it is

expected that there will be a centralized combined view for all the faults.

The solution shall support fault management process including:

Trouble ticketing

Fault analysis

Ticket routing to enterprise systems

PLC meters cross talks

8.2.20. Data Warehouse

The purpose of the data warehouse is to enable production of managerial reports

and enable business intelligence.


114


The data warehouse will reflect the MDM entities and maintain a frequent updating

regime, at least once a day, to allow for up-to-date analysis of the accumulated

meter reading data.

It shall be possible to import external entities into the data warehouse to allow for a

more robust data model.

It shall be possible to access that data in the warehouse via customized interfaces

from other IECo systems.

It shall be possible to utilize standard BI tools on the warehouse data; in IECo we use

SAS and SAP BO as standard BI tools.

It shall be noted that operational reports are to be produced directly from the MDM

database.

Bidder Response:

8.2.21. Data Concentrator Management

The system shall provide capabilities of tracking and management of the DC e.g.

uploading to the DC parameters. It shall be possible to address multiple DC in a

single transaction.

Required Functionalities :

Updating firmware across several DCs

Changing DC processes (e.g. changing LP interval from 15 to 5 minutes)

Viewing topology

Removal of meters from DC's meter list e.g. in case of remove meter


115


Password management

For further requirements re DC management please refer to DC chapter 6

8.3. Functional Requirements – General

Table 8.2 – General MDM Functional Requirements

ID Requirement Phase Remarks

8.3.1

The MDM must allow at least basic viewing, editing and input of all MDM data. Enable access via user interface.

A User interface mast be friendly

8.3.2 The MDM must enable access to all data for other applications via API

A

For example: Information for Customers of private producers

8.3.3

Basic reporting and analysis must be available on all MDMS data in such way that it does not compromise the performance of operations of normal MDM tasks

A

For example: replicate could be to have a separate Data Warehouse for reporting and analytics

8.3.4

The MDM shall support different types of

meters: industrial (CT,CT/VT), residential,

sub-meters (register the relation between a

main meter, and a sub-meter),

check/reference, energy balancing,

communication

A

8.3.5

The MDM must be able to use “time slices” on all its entities and attributes, and apply these time slices in calculations (e.g. ability to change the TOU aggregation scheme as of a certain date, and aggregate all relevant period before the date of change using the old version of the formula, while using the new version of the formula on period data relating to a time after the change)

A

8.3.6 MDM must keep versions of all meter data in case of a change

A


116



System data

8.3.7 Support lean data objects of CIS data in MDM (customer/ premises / contract)

A

8.3.8

Register asset information regarding the meter and its installation (e.g. meter type, meter location, outage detection capability, tamper detection capability, connect/disconnect capability, capacity reduction capability, installation date & time )

A

8.3.9

Support service address for one or multiple meters (sub-meters; apartments and “commons” meters) and logical relation between meters

A

8.3.10

The MDM shall be able to import, process and make available for export the predefined set of attributes as mentioned in meter chapter and DC chapter

A

8.3.11

The MDM shall store and enable display of raw and calculated data (e.g. multiply by transformer factor). It shall be possible to view LP data split by TOU where applicable.

A

Configuration

8.3.12

Provide an ability to configure VEE functions; including rules that determine what level of VEE can happen automatically, and what requires manual intervention

A

8.3.13 Have the ability to define a new formula for validation rules

8.3.14 Have the ability to define a new routine for editing or estimation

8.3.15 Have pre-defined validation rules that can be adjusted using parameters

A

8.3.16 Have the ability to turn on and off the VEE rules

A

8.3.17 Configure estimation routines for a specific group of meters / accounts

A

8.3.18 Have the ability to apply automatic editing based on the values of the check meter.

A


117



8.3.19 Have the ability to prioritize VEE rules A

8.3.20

Configure thresholds or boundaries for estimation on specific accounts by meter/customer, group, tariff/rate, or energy provider

A

8.3.21

Configure customizable summarization and billing rules (e.g., maintain TOU schedules per customer segment, geography, etc.; maintain holidays)

A

8.3.22 Allow change of aggregation specs A

8.4. Functional Requirements – Business Process

Table 8.3 – Business Process Functional Requirements


Update master data

8.4.1

Interface to the CIS system to import all relevant consumer and technical data so all the data in the MDM data will be synchronised in cases that data updating is not part of the natural process

A

Meter data acquisition

8.4.2

Interface with and obtain all meter data from multiple head ends, at least daily acquisition. (LP, TOU & technical)

A

8.4.3

Scheduling can be configurable B

In specific cases it will be needed more often than once a day

8.4.4 Provide interface for manual meter reads and indicate as manual read

A It shall be possible to register the data via GUI and


118



a backend transaction

8.4.5 Be able to interface with specific AMR head ends

C interface with working enterprise AMR e.g. - ITF

Install meter

8.4.6

Support online end-to-end check during new meter device installations

A

8.4.7 Automatically install meter A 8.4.8 Manually install meter A

remove meter

8.4.9

Automatically remove meter The MDM is required to support disassembly cases of a meter

B

8.4.10 Manually remove meter A

Meter replacement B

8.4.11

Implement meter replacement business process by calling meter removal and install meter BP.

B

8.4.12

In case customer has not changed there should be continuity of meter readings for the POD.

B

disconnect / connect meter 8.4.13 Automatically Disconnect meter C

8.4.14 Manually disconnect meter / load limiting

A

8.4.15 capacity reduction (load limit) C 8.4.16 Automatically connect meter C 8.4.17 Manually connect meter A

Provide insight to customer

8.4.18

Provide the ability to interface with a web portal. The interaction will show customer consumption data, historical data and analytical data regarding consumption

B

8.4.19

Consumption Data published on the internet shall not be older than 24 hours

B

8.4.20 Provide insight to customer – near C A few hundreds customers


119



time Near time ~ 1 hr.

Metering – meter data validation (VEE)

8.4.21

Perform VEE as part of the Meter to Bill process & Provide pre-built and configurable VEE functions for meter data usage. Apply different VEE rules for different customer segments.

A

8.4.22

Automatically propose replacement interval data through estimation (e.g., in case of missing data), but with an indication that it is a replacement

A

8.4.23

Make available tampering and outage information in the VEE process Perform VEE on DG sub-meter data. keep log files for later investigation

A

8.4.24

Estimate according to different techniques, including linear interpolation, historical averages, using previous day

A

8.4.25

Support manual user editing of data, including copying, deleting; through user screens, and while keeping an audit trail of changes Support automatic editing by using values of the check meter

A

In any case of manual data editing, the original data will be saved in the system along with the new data (modified) & an indication about the editing action

8.4.26 Store validated meter data in versions

A

8.4.27

The VEE processes must be configurable to comply with Israel regulations.

B

Billing

8.4.28 Summarize and store interval data into billing determinants (e.g., time

A


120



of use buckets) when required to do so by the SAP_ISU system

8.4.29 Generate all necessary output for the billing system

A According to process table X

8.4.30

Allow Tariff schemes to be updated through user screens (if not ready from an automated SAP interface, taking into account start/end dates of TOU schemes (Timeslicing)

A

8.4.31 Triggering Bill Correction B 8.4.32 Billing on demand B 8.4.33 Creating a new billing time slice B

8.4.34 Support billing cycle triggered by SAP Billing system

B

on-demand reading 8.4.35 Manual on-demand reading A

8.4.36

Support on demand punctual meter reading request for meter data (near real time for call centre)

B Time frame- 3 minutes (doing customer call)

Managing virtual / calculated channels

8.4.37 Store master data regarding (type, size, etc)

A

8.4.38

Able to process, import, exportdata of vitrula / calculated channels in all relevant processes, such as VEE and billing preparation aggregation

B

8.4.39 Perform VEE on virtual / calculated channels

A

8.4.40

Define specific VEE rules, e.g., Export cannot be larger than Generation

B Support calcluations between diffrent chanels

8.4.41

Automatically assign relevant (e.g., premise, customer, transformer ) characteristics from main meter to check meter

B

8.4.42 Generate reports and/or provide user screens that show reporting

A


121



results ; frequency can be configurable

Contractual load shedding

8.4.43 Register which premises have been signed up for this program

B

8.4.44 Send messages to customer about load shedding events via CIS

B

Business rule: Customer notifications need to happen at least X hours before the event; X – TBD.

8.4.45

Register general requests for demand reduction “load shedding event”

B

8.4.46 Aggregate load shedding relevant consumption data for billing

B

8.4.47

Allow customers to overrule a request for load shedding, and keep track of such overruling

C

8.4.48

Generate reports about load shedding events, based on i.e., premises signed up , measured consumption

B

Transformer metering / load (Energy) Balancing

8.4.49

Support first level transformer: register father-son link between meter and transformer outputs

B

screen for assigning meters to transformer for PLC and cellular communication meter

8.4.50 Read and treat smart meters and their meter data in transformers

A

8.4.51 Provide Operations metering data aggregation reports

C

8.4.52

Compare the sum of consumptions at Home level (PLC, cellular meters), for one specific transformer, with the metered value at the transformer. Identify deviations that are not justified by technical

C


122



losses alone.

8.4.53 Hold connected transformer data for each meter

C

8.4.54

Provide overview (report) of unjustifiable deviations. The report shall reflect power losses and possible thefts.

C

Handle notification

8.4.55

Receive and store notifications from the smart meters (via the head ends)

C depends on meter functionality

8.4.56

Rule based forwarding / routing of notifications to enterprise systems in near real time.

C E.g. TAKALOT VHAFRA'OT (OMS)

Handling log events / alarms

8.4.57

Register various types of events as detected by the meter and the DC and communicated by the head end

A * Depends on functionality of meters and DC in Project

8.4.58 There shall be a logging of all events in the MDM for analysis/reporting

A

8.4.59 Provide reports and extracts on all events information

A

Manage meter configuration – tables / firmware

B

8.4.60

Track and manage meter configuration tables (e.g. TOU, special days, passwords) and firmware versions held in each meter.

B The process relevant to this data will be considered in the detailed design phase

Operational reports A

8.4.61

Implement at least the operational reports as listed in 3.2.18 - Operational reports

8.4.62 Provide a tool for dynamic reporting

A

8.4.63

Reports production shall not interfere with the system ongoing performance

A


123



8.4.64

Reports shall enable invoking processes based on the query results

A

Data Warehouse

8.4.65

Enable production of managerial reports and enable business intelligence

A

8.4.66

reflect the MDM entities and maintain a frequent updating regime, at least once a day, to allow for up-to-date analysis of the accumulated meter reading data

A

8.4.67 Enable import of external entities B

8.4.68 Provide interfaces to other IECo systems

B

8.4.69 Enable utilization of standard BI tools on the warehouse data

B

System time synchronization A

8.4.70

maintain time synchronization, i.e. all the relevant components shall periodically engage with an SNTP server to ensure its system time is accurate

A

Fault Managment A 8.4.71 Trouble ticketing A 8.4.72 Fault analysis A 8.4.73 Ticket routing to enterprise systems A 8.4.74 PLC meters cross talks A

DC management A 8.2.21

8.4.75 Updating firmware across several DCs

A

8.4.76

Changing DC processes (e.g. changing LP interval from 15 to 5 minutes)

A

8.4.77 Viewing topology A

8.4.78 Removal of meters from DC's meter list e.g. in case of remove meter

A

8.4.79 Password management A


124



125


8.5. Interfaces Requirements

8.5.1. General guidelines for interfaces

IECo integration infrastructure is based on enterprise message bus with hub and

spoke topology that is implemented with the following components: IBM integration

bus, IBM MQ, message broker, IBM Websphere DataPower.

Interfaces have to conform to the following principles:

Use of web-services and / or MQ

The bidder has to provide WSDL files and test data for the WS it publishes

IECo will provide WSDL files and test data for the WS it publishes

Interfaces will utilize a secured protocol (HTTPS) in accordance with IECo

information security guidelines (Chapter 13).

Mutual authentication – every interface that is originating from or its target is

IECo Demilitarized Zone (DMZ) or external vendor server has to go thru

mutual authentication between the server and DataPower server based upon

IECo certificate.

The bidder must detail how the message scheme can be secured with respect to the

following items:

Number of instances

Elements length

Ranges of values

Etc.

Message attachments, e.g. bill image shall be in Base64 format


126


Message attachments will have to conform to IECo clearing system requirements.

Detailed guidelines with respect to message structure will be provided at the HLD

stage

The bidder will cater for development, testing and production environments for the

interfaces

Interface architecture and integration implementation approach will be defined as

part of the high level design process.

The bidder will be responsible to develop the connection to IECo integration

infrastructure.

Interface design will be a coordinated with IECo application subject matter experts.

The development will commence once the design was approved by IECo integration

team.

8.5.2. Interface MDM to SAP

Technical requirement for all interfaces with SAP-ISU and SAP-CRM:

In the IECo the CIS (Customer Information systems) are SAP, naturally the MDM will

require a variety of interfaces to those systems. The SAP standard tool for interface

to enterprise systems is SAP-PI, therefore we expect that all interfaces with it will be

implemented in the appropriate format.

The interfaces shall interface with SAP MDUS module.

Use Case list: (from SAP literature) MDUS

UseCase1: Device Initialization Process

UseCase2: Change Technical Master Data

UseCase3: Discrete Meter Reading Process

UseCase3a: SAP Requests Meter Readings from MDUS


127


UseCase3b: Sending Meter Reading Results from SAP to MDUS

UseCase4: Reading One Customer's Meter – On Demand Read

UseCase5a: Uploading Usage Data (EhP2onwards)

UseCase5b: Uploading Usage Data (EhP6onwards)

UseCase6a: Remotely Disconnecting and Reconnecting a Meter

UseCase6b: Manually Disconnecting and Reconnecting a Smart Meter

UseCase7: External Profile Calculation

UseCase8: Event Management

UseCase9: Text Messaging to AMI Device

8.5.3. MDM Interfaces with other systems in this Project scope

The MDM is expected to be tightly interfaced with the following systems: HES, MOC,

NOC, and Deployment Tool.

This can be achieved either by utilizing IECo enterprise bus or by having these

systems pre-integrated.

8.5.4. MDM to support export and import of files

It is expected that the MDM will be able to support import and export of data via

file, e.g. initial import of migration data, importing readout files from other AMR

systems or HHU.

8.5.5. OMS

Implement interface to propagate outage and power quality events to OMS

8.5.6. Fraud management

Implement interface to propagate fraud events to fraud manage ment system

Bidder Response:


128


Table 8.4 – Interface Requirements


General guidelines A 8.5.1 Use of web-services and / or MQ A

8.5.2 The bidder has to provide WSDL files and test data for the WS it publishes

A

8.5.3 IECo will provide WSDL files and test data for the WS it publishes

A

8.5.4 Interfaces will utilize a secured protocol (HTTPS) in accordance with IECo information security guidelines.

A

8.5.5 Mutual authentication A 8.5.6 The message scheme shall be secured A 8.5.7 Message attachments shall be in Base64 format A

Interface MDM to SAP A 8.5.8 The interfaces shall interface with SAP MDUS module 8.5.9 All interfaces with will be implemented using the SAP-PI 8.5.10 The interfaces shall interface with SAP MDUS module

8.5.11

The following interface shall be implemented: UseCase1: Device Initialization Process UseCase2: Change Technical Master Data UseCase3: Discrete Meter Reading Process UseCase3a: SAP Requests Meter Readings from MDUS UseCase3b: Sending Meter Reading Results from SAP to MDUS UseCase4: Reading One Customer's Meter – On Demand Read UseCase5b: Uploading Usage Data (EhP6onwards) UseCase6a: Remotely Disconnecting and Reconnecting a Meter UseCase6b: Manually Disconnecting and Reconnecting a Smart Meter


129



UseCase7: External Profile Calculation UseCase8: Event Management UseCase9: Text Messaging to AMI Device

MDM Interfaces with other systems in this Project scope

8.5.12

The MDM is expected to be tightly interfaced with the following systems: HES, MOC, NOC, and Deployment Tool. This can be achieved either by utilizing IECo enterprise bus or by having these systems pre-integrated.

MDM to support export and import of files

8.5.13

It is expected that the MDM will be able to support import and export of data via file, e.g. initial import of migration data, importing readout files from other AMR systems or HHU.

OMS

8.5.14 Implement interface to propagate outage and power quality events to OMS

Fraud management

8.5.15 Implement interface to propagate fraud events to fraud management system


130


9. HEAD END SYSTEM

The Head-End shall enable all the functional requirements of the MDM that require

interaction with the meters and DCs.

The Head-End performs the acquisition of meter data from the meters, across the

communication infrastructure. It acts as an interpreter between the meters and the

MDMS. As there is no common standard for communication from the data

concentrator/HES, today smart meter and AMI vendors provide the data in different

ways.

The MDM shall support multiple head-ends for each kind of meter communication

technology (e.g. PLC and cellular).

Head End - functional requirements:

Head ends will be responsible for uniform data output to the MDM (data

received in different standards from the different types / manufacture

concentrators).

The head end will know how to redirect messages including configuration

commands from the MDM in order to reach the desired meter.

The head end shall support alerts and messages transfer from the meters and

concentrators to the MDMs (MDM, MOC, NOC).

the bidder is required to provide an estimation of “meter to head-end” travel

time for each of the profiles

Bidder Response:


131


Table 9.1 – Head End Requirements

ID Requirement Stage Remarks

9.1.1

Perform acquisition of meter data across the communication infrastructure

A

9.1.2

Provide the MDM with unified data regardless of meter type and communication channels

A

The HES shall encapsulate the data when communication with upstream systems (MDM) ensuring that messages have the same format regardless of how the data was transmitted to the HES by the meters and/or DC

9.1.3

HES shall have a GUI to support management and viewing on the status of the system

A

9.1.4 HES shall be scalable A

9.1.5

HES shall support efficient metering infrastructure management

A

Ability to install MDMs at separate application server and database server. MDMs shall enable installation at two separate servers.

9.1.6

Interface between HES and DC should be based upon open solution i.e. web services with XML format exchange

A The Vendor shall provide detailed specification of this interface to IECo


132


10. MONITORING (MOC/NOC)

10.1. General

The NOC and MOC will serve as management & monitoring tools for the

maintenance team at Meter Operations Center in IECo, as an integral system giving a

complete view on all activities and performance related to smart metering.

These components can be either separate modules or an integral part of the MDM

product. In the case that MOC/NOC are separate modules MOC/NOC shall be fully

integrated with the MDM, e.g. operational reports shall be based on combined data

from all functional modules.

10.2. Overlapping / duplicate requirements

Some of the requirements in this chapter have been described already in chapter 8

Meter Data Managemet.

The bidder is required to respond with respect to the solution compliance in both

these chapters.

It should be noted that duplicate requirements will be scored only once.

Bidder Response:

10.3. MOC - Meter Operations Center


133


MOC is an entity that manages and monitors the metrology and other meter

functionality that is not communications related.

The MOC is responsible for monitoring and managing the meter devices and other

end-devices, it will enable the meter operation center team to monitor the smart

meters and other end devices such as the Concentrators, Repeaters, Filters and

Amplifiers as well as to some extent conduct remote management operations from

the MOC.

Bidder Response:

10.3.1. MOC Operational Processes

1) Managing authorization and authentication User name and password

2) Meters diagnostics

3) Meter Firmware (FW) update

4) Meter configuration management e.g. TOU, DST, special days Table

5) Triggering a service request e.g. on-site diagnostics, meter replacement

6) Meter connect/disconnect

7) Managing functional performance meters

8) event log / notifications management capabilities for auditing purposes and

follow-up

9) on demand reading

10) fault management


134


Bidder Response:

10.3.2. General MOC Assumptions

MOC will have the ability to access all meters, selective group of meters (By

Concentrator or not, by meter code or just handpicked) and a single meter

Information Security – the required security protocols, signatures, certificates

are supported throughout the AMI networks.

Bidder Response:


135


10.3.3. MOC Functional Requirements

Table 10.1 – MOC Functional Requirements


10.3.1

The MOC must be able to support meter diagnostics functionality

A

In accordance with relevant diagnostics provided by the meter

10.3.2 The MOC must be able to support meter configuration update functionality

A

10.3.3 The MOC must be able to support meter firmware update functionality

A

10.3.4 The MOC must be able to support meter connect/disconnect functionality

A

10.3.5 The MOC must be able to support Tampering detection

A

10.3.6 The MOC must be able to validate a meter’s availability and functionality within 1 minute

A Preform ping & BIT

10.3.7

must be able to interface to NOC and be able to send and receive messages including: network availability, network performance and other messages

A

10.3.8 must be able to interface to MDM and be able to send and receive messages

A

10.3.9

must be able to interface to other enterprise systems and be able to send and receive messages, e.g. interface to ISU to open a service request for meter replacement

A

10.3.10

must support the relevant security requirements and protocols as mandated by IECo

A Based on detailed security plan to be designed

10.3.11 must be able to log events for auditing and management purposes

A

10.3.12 must be able to generate reports A

10.3.13 Preform analytics on meters performance and failures

A

10.3.14 Have a managerial dashboard A


136


10.4. NOC - Network Operations Center

NOC is responsible for monitoring the communication network for alarms or certain

conditions that may require special attention to avoid impact on the network's

performance. The NOC will monitor and control all network nodes including the

Smart Meters, Concentrators, Head-Ends and possibly other relevant pieces of the

AMI network.

NOC is typically an IT component residing in the back office layer of enterprise

applications. It will be able to monitor any layer of the network and will provide

network managers with a systematic approach to identifying communication

network errors and performance factors.

Bidder Response:


137


10.4.1. NOC Operational Processes

1) Network management (diagnostics, remote booting, blocking access).

2) Fault management (including communication events filtering, correlation, root

cause analysis, detection (Discovery).

3) Performance management.

4) Security management in accordance with the requirements in the security

chapter

5) Managing indication and perform troubleshooting (communication events)

6) Management software (for example - configuration, FW updates).

7) Network testing in all its various layers.

8) Maintaining, managing and processing the Event Log of all media events for the

purpose of monitoring and control.

9) Generating operational and managerial reports.

10) There shall be a system process that compares the system time across the

components of the system and raises an alert in case a discrepancy is found, i.e.

there is a difference in time between hosts in the system.

Bidder Response:

10.4.2. General NOC assumptions


138


NOC will be able to interface with all System layers and send communications

network management related commands and get communications network

monitoring data and responses.

Bidder Response:

10.4.3. NOC Functional Requirements

Table 10.2 – NOC Functional Requirements


10.4.1

Provide Network Management A

e.g. diagnostics, remote reset, access termination, time sync

10.4.2 Support fault management A 10.4.3 Provide performance management A 10.4.4 Support security management A

10.4.5 Provide communication Software management

A

10.4.6 Be able to interface with all network layers

A

10.4.7 log events for auditing and management purposes

A

10.4.8 generate reports A

10.4.9 interface with the MDM system to send and receive messages

A

10.4.10

The NOC must support the relevant security requirements and protocols as mandated by IECo

A

10.4.11

be able to manage and support balancing of the communications network load

A


139


10.4.12 be able to support communications network congestion management

A

10.4.13

NOC shall be able to validate a meter’s availability within 5 seconds – cellular communication

A

10.4.14

NOC shall be able to validate a meter's availability - meter via PLC + concentrator

A

10.4.15

NOC will be able to validate network availability for all AMI network layers components within 5 seconds.

A


140


11. DEPLOYMENT TOOL

11.1. General

The Project will include deployment of about 70,000 – 163,000 smart meters in a

time frame of about a year. For this reason the IECo will need a rollout solution that

will be used to plan, manage and monitor the deployment process. This solution will

need to interface with the relevant enterprise systems (SAP-ISU & SAP-CRM) and be

aligned with the standard deployment routine practiced in IECo.

In the tariff trial specific geographical locations will be chosen to participate

according to climate and socioeconomic parameters. Based on the pre-selection of

these locations the relevant population will be identified via use of BI tools. Other

meters will be installed in new neighborhoods around the country.

The required deployment tool solution will be used for the full national rollout of

smart meters. The solution shall be used by field technicians and may be compatible

with IECo HHU/Mobile Devices, or a different solution may be proposed, The

Contractor shall provide details of any hardware tools necessary for the solution e.g.

tablets etc.

Bidder Response:

11.2. Business processes


141


1) Planning of the population participating in the deployment – define a set of

parameters according to the population is selected. Interface with the IECo

enterprise systems in order to acquire the relevant attributes of the selected

population. The attributes can be (but are not limited to): electrical relation e.g.

(transformer, meter data) geographical address, billing rates, customer segment.

2) Meter grouping as a basis for work packages planning based on the attributes

fetched previously.

3) Set work packages.

4) Trigger process in the SAP - ISU to open replacement (removal + installation)

request for all relevant meters.

5) Automatically indicate participation in the pilot in SAP-ISU & SAP-CRM.

6) Preform scheduling based on work packages.

7) Set work routes, work crews and issuing of work equipment and meters.

8) Handling work performance (set batches of work).

9) Record work done, result.

10) Enable task completion validation by e.g. triggering meter reading or by

refreshing DC meter list.

11) Provide feedback upon task completion (installation, field work) to relevant

systems, e.g (IP, transformer details, GPS coordinates, repeater)

12) Enable interface for sub-contractors work.

13) Producing of reports.

14) Manage information of:

all relevant premises


142


Prepare GIS infrastructure for participant population [optional – TBD]

Build all necessary "lean" entities needed for managing and monitoring

rollout process e.g. customer, address, and contract.

All relevant resources including personnel, vehicles and other equipment.

Bidder Response:

11.3. Functional requirements for rollout solution

The deployment solution could be suggested in a few approaches, e.g. a SAP – ISU

PM embedded implementation, MDM embedded module or a separate system.

Bidder Response:

11.4. Interface Requirements

It is expected the deployment tool will be strongly interfaced with the SAP-ISU and

SAP-CRM. Doing the detailed design the architecture of these interfaces will be

decided. One known requirement is that actions done in the field will be updated in

the back office systems immediately (this could be implemented via the current HHU

system in IECo or via a new tool).


143


Table 11.1 – Deployment solution Functional Requirements


11.4.1 Creating and managing database of all relevant premises for the Project

A

11.4.2 Build all necessary "lean" entities needed for managing and daily inspection of rollout

A Keeping the entities updating with CIS (SAP)

11.4.3 GIS infrastructure for participant population relevant permises

A

11.4.4

Building and managing all relevant resources including HR, vehicles and, and other equipment

A

11.4.5 work standards and validation protocols A

11.4.6 Planning work routes, work crews and issuing of work equipment and meters

A

11.4.7 Creating and managing work orders A Could be done via SAP-ISU

11.4.8 Reporting task status e.g. completion, on hold, etc.

A

11.4.9 Producing reports (daily, weekly etc.) A

11.4.10 Updating progress to the CIS systems routinely

A

11.4.11 Interfaces to other enterprise system according to IECo standards

A

11.4.12

Enable task completion validation by e.g. triggering meter reading or by refreshing DC meter list.

A

11.4.13

Provide feedback upon task completion (installation, field work) to relevant systems, e.g. (IP, transformer details, GPS coordinates, repeater)

A

11.4.14 be strongly interfaced with the SAP-ISU and SAP-CRM / MDM

A


144


12. SOFTWARE SYSTEMS GENERAL REQUIREMENTS

12.1. General

The SW systems in this project would be obligated to confirm with IECo standards

and technical guidelines as detailed in appendix A- IT landscape and appendix B -

applicable standards.

Bidder Response:

12.2. Deployment plan

The plan is to have 50,000 meters deployed per year in the years 2017 thru 2020,

thus eventually at the end of 2020 there will be 200,000 meters installed at the field

and handled by the system.

The bidder shall provide a plan from infrastructure requirements perspective to

accommodate for this deployment plan.

Bidder Response:


145


12.3. High availability

The software systems related to smart metering are defined by the IECo as 24/7 high

availability system (this requirement excludes communication aspects between

meters, DCs and HES.

For phase A – 99%

After phase A -99.5%

The bidder is required to detail how he plans to accomplish the high availability

requirement.

It should cover the following domains –

Redundancy (hardware & software)

Monitoring

KPIs settings e.g. MTBF, MTTR

In service software upgrade

Bidder Response:


146


12.4. Performance Requirements

1) The system should support up to 40 users working concurrently.

2) The system shall comply with this response time:

a) The average response time for processes of simple complexity (e.g. look up

meter values for one POD / one day) should not exceed 1 second for Vendor's

area of responsibility. The Vendor should provide the sizing and prerequisites

that enables this requirement.

b) The average response time for processes of medium sized complexity (e.g.

look up meter values for a group of POD) should not exceed 3 seconds for

Vendor's area of responsibility. The Vendor should provide the sizing and

prerequisites that enables this requirement.

c) The average response time for processes of large complexity (e.g. look up

meter readings for a group of POD / one year) should not exceed 10 seconds

for Vendor's area of responsibility. The Vendor should provide the sizing and

prerequisites that enables this requirement.

Bidder Response:

12.5. Disaster Recovery Requirements

IECo requires a disaster recovery plan that conforms to the following parameters:


147


RPO (Recovery point objective) will be 0 i.e. no data loss in event of system

failure,

RTO (Recovery Time Objective) will be 30 minutes up to two hours i.e.

switching to failure over system in no more than two hours..

The vendor is expected to detail the requirements with respect to hardware,

software, licenses and physical space that are required in order to fulfill the DRP.

Bidder Response:

12.6. Data availability Requirements

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.

Bidder Response:

12.7. Data backup Requirements

Data backup in IECo is done by utilizing IBM - TSM: Tivoli Storage Manager for

System Backup and Recovery. The suggested solution must comply with this method

or provide an alternative method for backup procedure.


148


Bidder Response:

12.8. Scalability requirements

IECo plans to scale up the system to 2.7M meters.

The vendor is expected to provide a scalability plan for the proposed System to

support this volume of meters and corresponding data.

Will the scaling up require introducing new software systems / hardware?

Is the growth in required resources linear, polynomial or worse with respect to

the growth in the number of meters?

It should list the implications on –

Hardware

Software

Licenses

Bidder Response:

12.9. Configuration management requirements

The Bidder is expected to detail the methodology, procedures and tools it plans to

utilize for configuration management and system installation management.

Bidder Response:


149


12.10. Hardware environment specifications

The Bidder shall list the environmental parameters that are required for sustainable

operation of the System, e.g. physical space, ambient conditions (temperature,

humidity), power requirements, etc.

Bidder Response:


150


Table 12.1 – Software system general Requirements


General

12.9.1

The SW systems in this project would be obligated to confirm with IECo standards and technical guidelines as detailed in appendix A- IT landscape and appendix B - applicable standards.

A

12.9.2

The solution will ensure full integration between the different modules of the MDMs system. Data will be accessible across the modules

A

12.9.3 The solution shall include a scheduler module

A

Deployment plan

12.9.4

The plan is to have 50,000 meters deployed per year in the years 2017 thru 2020, thus eventually at the end of 2020 there will be 200,000 meters installed at the field and handled by the system. The bidder shall provide a plan from infrastructure requirements perspective to accommodate for this deployment plan.

High availability software & Reliability

12.9.5

The smart metering systems are define by the IECo as 24/7 high availability system. The bidder is required to detail how he plans to accomplish the high availability requirement. It should cover the following domains – Redundancy (hardware & software) Monitoring KPIs settings e.g. MTBF, MTTR In service software upgrade

A

12.9.6 The system shall be online and available A


151


99.0% of the time in phase A and 99.5% in phase B.

Disaster Recovery

12.9.7 The system will support fail over to back up site

A

12.9.8 RTO = 30 minutes to two hours A 12.9.9 RPO = 0 A

Maintainability

12.9.10

The system must be able to deal with weekly regular maintenance activities in less than 4 hours per week

A

Performance

12.9.11

Support X IEC customer service representatives accessing the system simultaneously

A X=40

12.9.12 Store and manage data of X POD’s ( Point of Delivery ) and Y meters

A X~Y ~ 70,000-163,000

12.9.13 Schedule automated reads per meter every day

A

12.9.14

Import, validate and store all data from meters, including – load profile, billing, events and technical. For ~ 70k-163 k meters at least once a day in X hours 70k-163 k meters * 3 channels (250 data fields)

B X = 2 hours

12.9.15

Provide usage data for creation of X bills/statements per day B

X ~ 2000-5000 Assuming monthly bills are spread over 5 day

12.9.16

Respond to Billing system requests for billing input information within X time (optional working method)

B X = 1 day

12.9.17

Respond to meter reads on-demand request within X time From CRM /MDM / MOC

B

X = 3 minutes from the meter Total response time including AMI shall be no longer than from CRM

12.9.18 receive in MDM and dispatch to OMS an outage notifications within X seconds

C X = shall be near real time

scalability


152


12.9.19

The vendor is expected to provide a scalability plan for the existing systems to support this volume of meters and corresponding data.

Will the scaling up require introducing new software systems / hardware?

Is the growth in required resources linear, polynomial or worse with respect to the growth in the number of meters? It should list the implications on –

Hardware

Software

Licenses

Usability

12.9.20 User screens shall include links to support guides

A

12.9.21 The system shall provide user friendly navigation

A

12.9.22 The system shall provide automatic refresh of screens

A

12.9.23 Single user sign on A

12.9.24

Hebrew language support – for predefine fields, Database and screens display and input

A Hebrew GUI is not required

Security

12.9.25

The solution must comply with IEC Information Security Policies and with Israeli legislation and regulations

A

obligated to confirm with IECo security requirements as detailed in chapter 13

12.9.26

The solution must comply with IEC and Israeli data protection legislation and regulation

A

Audit trail

12.9.27 Logging of all modifications to MDM data, who did it, and when

A

12.9.28 Authorizations A

12.9.29 Provide administrator screens to assigns user profiles to users: viewing, entering,

A


153


changing.

12.9.30 All users must log in to the system using a user name and password.

A

Configuration management

12.9.31

The vendor is expected to detail the methodology, procedures and tolls it plans to utilize for configuration management and system installation management.

A

Hardware environment specifications

12.9.32

The vendor shall list the environmental parameters that are required for reliable operation of the System, e.g. physical space, ambient conditions (temperature, humidity), power requirements, etc.

A

Interfaces requirements

12.9.33 Provide a platform to create new interfaces

A

12.9.34

Support multiple standards for outbound interface (i.e., not locked into a predefined set of outbound interfaces, but rather have configurability)

A

13. INFORMATION SECURITY (IS) REQUIREMENTS

A relatively a high level of Information Security (IS) is required as defined in this

Chapter. All requirements listed in this chapter are mandatory unless stated

otherwise.

The bidder must provide a schematic of entire IS system embedded within

the proposed solution. The bidder must specify the various "IS" functions,


154


within each component: meters, DCs, HES, MDMs, other communication

software, as defined in each sub-chapter.

The bidder must specify if existing, mechanisms capable of identifying cyber

attempts, by hostile agents unauthorized to access system, and the measures

taken to handle the threats.

13.1. IS requirements for meters and data concentrators

The meter and DC shall have security features to preclude any access of non-

authorized persons to their data and parameters and to their hardware. The meter

shall also have security means restricting purchaser's personnel from performing

activities which are not within their authorization.

General requirements

1. The need for preventing illegal access to the system(s) and for ensuring

information privacy must involve the implementation of the AES 256 or AES

128 Encryption Standard for network traffic and sensitive data.

2. Meters and DC IS requirements follow DLMS/cosem standards although there

is no explicit requirement for DLMS/cosem at DCs

3. Different passwords are used for access to meters and DC with at least 3

privilege access levels:

a. User: meter reads.

b. Super user: writes and configuration update.

c. Admin: firmware update.

4. Usage of public and private key mechanism for defending transmission of

symmetric encryption keys. In case of DLMS/COSEM implementation, key

transfer is done by AES Key wrap (AES-128 or 256)


155


5. Requirements regarding authentication of client/server should not conflict

with commonly used DLMS/COSEM authentication, preferred solution based

on HLS5.

6. Requirements regarding message encryption and message authentication

should not conflict with the security tools that are available in Security suite 0

according to DLMS COSEM.

7. Additional IS features are welcome and shall be scored accordingly.

IECo considers the (cellular) WAN and the meter side of the DC-s vulnerable

and welcomes vendors to present their solution.

Examples of additional (non-mandatory) IS features:

a. Using Fire Wall for defending DC

b. Using PLC traffic monitoring for cyber attack detection

c. An off-the-shelf solution for intrusion detection between DC and HES

d. An off-the-shelf solution for intrusion detection between meter and DC

e. A system for monitoring external protocol meter↔ DC-s, or DC-s↔

HES/MDM and exposing threats and blocking them.

13.2. Password management system

Tender bidder shall provide a password management capability, either embedded

within the MDM or an off-the-shelf product. That system shall have following

capabilities:

1. Support different passwords for different privilege access levels.

2. Password complicity enforcement measures.


156


3. Enable mandatory replacement of passwords for the entire meter

population within the MDM. This replacement can be periodic or on-demand.

4. Connected meters and DC-s shall support the change of password and store

passwords in a secure way.

13.3. Information security between DCs and HES

1. Data transferred between DCs and HES shall be secured.

a. Data encryption/decryption must be embedded.

b. Secure network traffic between Head End and DCs shall be implemented,

such as https, sftp and ssh mandatory

13.4. Information security between HES and MDMs

1. HES and MDM shall be installed on two separate physical servers

2. Data transfer between HES and MDM shall be based on json or xml.

a. Contractor shall deliver full documentation with details of the data format.

b. Data transfer between HES and MDM will be done via a data power device

provided by IECo. IECo will provide needed information for the integration

purpose.


157


13.5. IECo IS methodology

The following methods shall be implemented and assumed:

Table 13.1 - IECo SI methodology

# Feature 13.5.1 Firewall existence.

The MDMs shall assume existence and implementation by IECo of a firewall at the De-Militarized-Zone frontier. A firewall prevents/monitors data exchange between MDMs and DC-s.

13.5.2 Authentication routine of DC-s and meters at MDMs. Authentication shall be based on one or several unique DC, meter ID-s, at every start of communication. ID shall be unique to DC or meter, and hard to imitate by hostile IS agent. Examples:

MAC address

IP address

serial number

passwords 13.5.3 IECo has a SIEM system (SIEM = Security Information and Event

Management). DCs, HES and MDM shall have capabilities to send relevant information to the SIEM. Contractor shall provide parser or integration in the SIEM. IECo will provide required data to develop such interface.

13.5.4 Limitation of human operators of MDMs, DC communication system, HES, lab software – for objective of remote communication to meters/DC-s, by the following measures. Software shall be immune and robust to these limitation: 1. only limited number of operators, defined separately by application admin, and by servers admin 2. User is allowed to operate only from a specific IP address 3. User is authenticated by username & password.

13.5.5 IECo reserves the right to test IS of all the System by IECo. , and has capabilities to do so. IECo reserves the right to simulate "cyber-attacks" in order to test System IS immunity.


158


14. QUALITY ASSURANCE AND TESTING

14.1. General

This chapter provides an overview of the QA and Testing approach for the project

including; unit-testing program required for meters and DCs and associated

components, and details of the requirements for the Inspection and Test Plan for

software systems and end-to-end processes.

All items to be supplied and all work performed under the Contract shall be

inspected/tested by the contractor.

Should any inspection or test conducted after the contract is signed, indicate that

specific hardware, software, or documentation, does not meet the specified

requirements, or the integrated system does not conform to the specifications, the

appropriate items shall be repaired, replaced, upgraded, or added by the Contractor

as necessary to correct the noted variances. After correction of a variance, all tests

necessary to verify the effectiveness of the corrective action shall be repeated.

Deliverables shall not be delivered until all required inspections and tests have been

completed, all variances have been corrected to IECo's satisfaction, and the

hardware and software have been approved for delivery by IECo.

Upon prior notice, IECo's representatives shall be allowed access to the Contractor's

and subcontractors facilities during System design development, manufacturing and

testing and to other facilities where hardware or software is being produced /

developed. Office facilities, equipment and documentation necessary to complete all

inspections and to verify that the System is being designed developed, manufactured

and tested and delivered in accordance with the Contract shall be provided to IECo's

representatives by the Contractor.


159


IECo uses HP Quality Center software for requirements management, I&T

management and variances management. Therefore from the stage of requirements

definition to Operational Acceptance Test, the contractor is required to utilize HP

Quality Center software as the management tool and the repository for those issues.

The Contractor is required to provide IECo with full access rights to the Quality

Center software for progress monitoring and test documentation.

Successful completion of acceptance tests shall be prerequisite to acceptance, which

shall be constituted by written approval from IECo.

14.2. QA and testing for Meters, DCs and CTs

14.2.1. Testing of samples by IEC as part of the tender evaluation

The technical evaluation stage, will take 3 months following the proposal submittal.

During this stage samples of meters, DCs and CTs provided by bidders (see submittal

table Annexure B1) will be tested by IECo for conformity with the Specification and

standards including; metrology testing, documentation verification, partial

functionality/communication testing. The emphasis is on conformity to the

preliminary requirements.

Samples

The bidder shall provide samples in the amounts and types specified in the Submittal

Table, Annexure B1, together with the technical offer for inspection by the IECo. The

samples must be of the same manufacturer and from the same plant that will supply

the meters in case the bidder is awarded the tender.

If the sample varies from the proposed type, the bidder shall clearly state the

deviations, which shall be corrected in meters/DCs/CTs that will be supplied.

Corrections of such deviations would require only trivial changes to the

meter/DC/CTs, without the need for new type (pattern) approval.


160


The samples shall be submitted with a proper nameplate (including bar-code) for

checking of nameplate data format.

The samples must be accompanied by the necessary software to enable the

communication with the meter through the optical port including necessary

passwords. The IECo may perform tests on the samples according to its judgment.

Note: The IECo reserves the right, at its sole discretion, to allow a bidder, who has not

submitted one or more of the above listed documents or samples, along with its

technical proposal, to accomplish its proposal and to submit the missing documents

within such extra time as allowed by IECo.

Accelerated Life Test (Aging)

The meters should undergo accelerated life tests (powered, at extended

temperatures – above and beyond the operating temperature range) in order to

demonstrate its reliability and long service life. The test shall be carried out per

IEC62059-41 methodology, and its evidences shall be provided with the technical

offer.

14.2.2. Verification of requirements

After signing the contract, a preliminary series of meters, DCs and CTs and all

associated software tools and firmware versions will be tested by IECo for full

conformity to technical specifications.

14.2.2.1. Preliminary series delivery

The awarded bidder must send to the company the meters, DCs, CT's and all

accessories as preliminary series by quantity of 5 meters for each type of meter, 2

DCs and 5 CT's for a Conformity of Compliance. The meters and CT's, must be in

their final version, manufactured or assembled in the same plant where the

remaining meters will be produced, tested with the same equipment that will be


161


used in the course of manufacturing, and packed in the same form that the future

meters and CT's will be supplied.

14.2.2.2. Meter, CT DC related documents for Preliminary series

approval

Contractor shall submit for Purchaser’s approval, before the first delivery, the

documents indicated below:

Up to date calibration certificate of test equipment, on which calibration and final

test of the meters are performed, in accordance with IEC 60736, including

traceability chain – Meters and CTs.

Factory routine tests report – Meters and CTs

Up to date PRIME/IDIS certificates – Meters and DCs.

Up to date release notes for firmware version – Meters and DCs.

Up to date list of qualified suppliers of the most important parts and components

(microprocessor, metering IC, shunts, non- volatile memory, LCD, etc.) – Meters

and DCs.

Up to date identified non conformities and corrective actions if applicable –

Meters, CTs and DCs.

14.2.2.3. Additional Documentation

The contractor shall submit:

Up-to-date QA manual

Up-to-date Installation manuals

14.2.2.4. Preliminary Series Verification


162


The contractor shall submit with the preliminary series, an Integration test report

between Meter and Data Concentrator.

14.2.2.5. Quality Assurance on the manufacturing process and inspection

during manufacturing

The meters, DCs and CTs and all associated software tools must be manufactured

under ISO 9001(2008) over a whole contract period. Valid ISO 9001(2008) 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. The IECo, 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.

IECo, experts may ask to visit the manufacturer's plant at the technical evaluation

stage or later: i.e. 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.

The contractor shall submit with his proposal a preliminary Factory Inspection and

Test (I&T) Plan from the relevant manufacturers. A mutually agreed inspection point

plan, including witnesses and points, shall be agreed between IECo and the

contractor during the Design Review after signing the contract (15.2.4). Any

subsequent alteration to this program shall require IECo’s agreement, prior to start

of any work affected by these alternations.

Test and Inspection reports and certificates as required in the specification and the

applicable standards, shall be submitted immediately following their generation. The

reports and certificates shall be original, signed by the manufacturer, and contain

actual measured values.


163


The generation of reports and certificates, including those generated by

subcontractors and sub-suppliers shall bear no extra cost to the IECo.

Any equipment non-conformance to drawings, specifications or any other purchase

order requirements which are considered by the manufacturer as “acceptable as it is”

or “for repair”, shall be submitted to the IECo. for approval, with their recommended

dispositions. All such non-conformances shall be approved by the IECo, shall be

documented, and a copy of the approval shall accompany each shipment.

All materials used in manufacturing the equipment shall conform to specifications,

approved drawings, and accepted Standards.

14.2.2.6. Requirements on insulation test and calibration

Contractor must send to the Meter Test Station Department of the IECo in electronic

form an AC insulation and accuracy test report for each manufactured meter and DC

(for each model) before each delivery. Contractor must submit test scheme and test

procedure to IECo.

IECo should be notified if communication ports are not immune to insulation tests,

then manufacturer must instruct IECo not to connect them to test GND but rather

seal them.

Each ready-made to supply meter must be tested for AC insulation and be calibrated

directly against working kWh/kVarh standard. For test, adjustment and initial

calibration of the meters to be supplied, the manufacturer shall use appropriate test

equipment whose accuracy and reliability shall be periodically checked for

compliance with IEC 60736.

The manufacturer must state in the AC insulation and accuracy test report whether

accuracy test is performed on the meters with closed or open voltage links (for direct

connected meters). If the meters are calibrated with open voltage links, quality


164


control routine must be implemented to insure correct meters functionality after

their sealing (closed links). Results of this QC routine shall be reflected in the

provided report.

A test report of the test equipment, including traceability data of calibration

procedure, shall be presented with the technical offer.

IECo reserves the right to perform additional insulation tests.

CT's Routine Tests:

Each CT shall be routine tested by the manufacturer prior to shipment as follows:

Verification of terminal and rating plate marking (IEC 60044-1, clause 8.1 and

11.7)

Determination of errors according to IEC 60044-1, clause 11.4 at 25% and 100%

of the rated burden

Inter-turn over-voltage test (IEC 60044-1, clause 8.4)

Power frequency withstand test (IEC 60044-1, clause 8.3) on the primary winding

and on the secondary winding

The results of these tests shall be submitted to IECo for each shipment.


165


14.2.3. Acceptance tests for mass production meter, CT batches

The meters shall be manufactured and calibrated in homogeneous production series

and supplied in piles. The piles 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.

Acceptance lot-by-lot inspection by attributes will be performed at the Meter Test

Station according to IEC62058-11, ISO2859-1 and IEC62058-31. Lot for the

acceptance inspection will be defined as cumulative quantity of piles 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, AQL4=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.

IECo will perform acceptance tests, based on routine tests, for inspecting if CT’s are

complying with the requirements, according to its own decision either by sampling

inspection or 100 % inspection.

In any method, a CT will be considered defected if it has one of the following defects:

a. A result of the routine tests, which has a tolerance that will be notified to the

awarded Manufacturer, exceeds the permissible limits defined in IEC60044-1.

4 AQL – Acceptance Quality Limit.


166


b. CT construction is not conforming to the specification.

Regarding nonconforming meters/CT's 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/facsimile/e-mail.

Rejection of five 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/CT within a lot in quantities, which are still within

acceptance criteria, will be subject to replacement if claimed by the Purchaser.

Note: 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 three or more meters or CTs delivered according to the same order will be 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. IECo preserves itself the

right to conduct, according to its decision.

14.2.4. Quality Assurance on change management

14.2.4.1. Modification of the Meter, DC and CT Design and Technology

Any change in technology processes – including its replacement, modification of the

meter and/or CT and/or DC form, structure of parts or materials from which the parts

are made of – after IECo has approved the meter and/or CT and/or DC, shall be done


167


only after written agreement with the IECo, has been settled. For obtaining this

agreement the manufacturer shall present the company with the following:

The engineering drawings describing the modification.

Samples to be tested in the IECo, according to its judgment.

Proof that the proposed modification does not decrease the quality or

performance of the meter.

Note: In case the main manufacturing line is replaced by another, an IECo

representative will inspect and approve the new premises before manufacturing will

commence there.

If the said modifications result in degradation of meter/CTs/DCs performance or

quality, IECo reserves the right to demand that the meters/CTs/DCs be returned to

their original form. IECo reserves the right to cancel the order if the manufacturer will

refuse to do so.

If it has been agreed between the manufacturer and the IECo to carry out the

modification, the manufacturer shall inform the company in writing about the serial

number of the first modified meter/CT/DC, and the shipment identification detail.

14.2.4.2. Testing new firmware, software tool versions

Each new tool version, must be accompanied by version release test program and

test report approved by IECo. Testing should focus on modifications and regression.

IECo as a policy shall not accept tool versions without a report, and shall initiate a

version release procedure. Contractor shall submit "release notes" specifying shortly

and clearly changes list. Contractor and IECo shall agree on severity of changes:

minor, medium, major revision. Testing requirements will be in accordance with

severity of changes. A version is not officially accepted for use in IECo. until an

official notice from IECo defines it as official.


168


14.2.5. Quality Assurance on the software development process

All software developed for the meters, the DC shall be developed in a well-controlled

and well-documented way. A documented software development process shall be in

place.


169


14.2.6. Test Equipment and Tools

The contractor shall specify all test equipment and tools, software and accessories

required to perform the following activities:

Preventive/periodic maintenance and meter reading

Installation

Field troubleshooting

Laboratory level repairs.

Maintenance, debug and evaluation of software (see relvent chapter).

The test equipment and tools shall be specified according to the following

categories:

- Special test equipment and tools

- Special jigs, fixtures, accessories and software

- Standard test equipment, test tools and accessories

Test equipment for PLC for field troubleshooting and determination whether filters

and repeaters are required, suitable for the specific PLC method proposed by the

meter manufacturer (PRIME, IDIS) should be budgeted at a separate part number.

14.2.6.1. Portable PC for Laboratory for meters/DC configuration:

Portable PC for Laboratory for meters/DC configuration: Control station for the test

equipment run meter software-s shall be supplied by Contractor.

Number of required laptops specified in Annexure C1.

1) Portable PC – with modern/recent CPU, (i.e. Intel core i7 or later model).

2) Minimum Screen size 15.6".

3) 8 GB RAM or more


170


4) 1 TB HD or more.

5) Operating System: Windows 7 or Windows 10 64 bits Enterprise Edition.

6) USB PORT: at least USB2.0 X 2 and USB 3.0 X 1.

7) Warranty period: 3 years by a lab located in at Israel.

8) Graphic Card – Exists and of type: either Intel or NVidia GeForce.

9) Ruggedized model. (Example: Dell latitude, HP Probook etc.)

10) The portable PC shall include installed software tools as defined at Appendix F .

11) SW license – all software licenses (bidder and third-part Company) should be for

unlimited time duration.

12) Integrated high quality sound card.


171


14.2.7. Adjustments, alignment, calibration and tuning

Define all adjustments, alignments, calibration and tuning which are required for the

proper operation of meters and DCs and associated components without any

performance degradation. The following shall be specified:

Definition of adjustments, alignment, calibration/ tuning activity.

Recommended time duration for performing each activity.

Recommended maintenance level for performing same.

14.3. QA and testing for software systems and end-to-end

14.3.1. Test Plan

All tests shall be conducted in accordance with approved test that shall be prepared

by the Contractor and approved by IECo. Each scenario in the test plan shall include

the following items:

5. The name of the part/system under test;

6. The name of the function to be tested;

7. Step-by-step descriptions of each test segment, including the inputs and user

actions for each test step and associated operating conditions;

8. The expected results for each test, including pass/fail criteria;

The Contractor shall submit all documentation of the Test plan to IECo for approval

prior to the scheduled date for the commencement of the tests. The number of prior

days will be decided by the Contractor and IECo during High Level Design process.

14.3.2. Test Initiation Procedure


172


The following conditions must be satisfied before starting each acceptance test:

a. All relevant test plans are approved by IECo.

b. All test procedures, databases, hardware setup and procedures for the test

shall be approved by the IECo.

c. All hardware and software updates shall be incorporated into the system

under test.

d. All relevant documentation, including drawings, lists of deliverables, software

functional and design documents and user manuals, shall be approved by

IECo

e. The tested hardware is defined completely, configured and functional.

f. All hardware and software engineering design change orders shall be

incorporated into the system under test.

g. A complete build / regeneration (depending on type of test) of the software

under test for which source code is being supplied shall be performed

immediately prior to the start of testing. All operating system parameters,

files and configuration information shall be saved to archive media so the

System's operating environment can be recreated starting with an

uninitialized system. The existence and completeness of these data shall be

demonstrated to IECo.

h. All database, display, report definitions and source code libraries shall be

saved to archive media so that the system databases, displays and reports

can be recreated / rebuilt if necessary.

i. IECo personnel participating in the test have been properly trained and are

prepared for running the tests.


173


j. Complete internal acceptance test (such as Pre-FAT) using the approved test

plans, shall be conducted by the Contractor. Written certification that the

internal test has been duly completed shall be provided to IECo prior to the

start of a test.


174


14.3.3. Test Completion Procedure

An acceptance test shall be deemed to be successfully completed only when:

a) The acceptance test has been fully performed.

b) All variances have been resolved to the satisfaction of IECo.

c) All test records have been submitted to IECo.

d) Update documentation.

e) IEC acknowledges, in writing, successful completion of the acceptance test.

14.3.4. Test Suspension Procedure

If the IECo representatives believe, at any time, that the number or severity of

system variances warrants suspension of any or all testing, the test shall be halted,

remedial work shall be performed, and the complete test shall be repeated. The

repeat of the test shall be scheduled for a date and time agreed upon by both the

Contractor and IECo.

14.3.5. Reporting of Variances

A variance report shall be prepared by either IECo or Contractor personnel each time

a deviation from the requirements of the specification is detected. The report shall

include a complete description of the variance, including:

a. A sequential identifying number assigned to the variance;

b. The date and time the variance was detected;

c. Appropriate references to the test procedures and the specification;

d. A description of the test conditions at the time the variance was detected;

e. Identification of Contractor and IECo witnesses;


175


Variance will be categorized according to severity as detailed in Table 15.9 - Problem

Severity Levels

Each variance shall be assigned to one of three classes defining the action to be

taken to resolve the variance:

Critical – A schedule for the correction of critical priority variances shall be

informed within one (1) hour and it shall be fixed within eight (8) hours after IECo

request. Basic MDM functionality must be restored after 30 minutes. After the

six hours period the Contractor shall assign dedicated resources until the

problem is fixed or a workaround implemented.

High – A schedule for the correction of high priority variances shall be informed

within eight (8) hours and it shall be fixed within twenty-four (24) hours after

IECo request. After this period the Contractor shall assign dedicated resources

until the problem is fixed or a workaround implemented.

Medium – A schedule for the correction of medium priority variances shall be

informed within twenty-four (24) hours and it shall be fixed or a schedule for

correction presented to IECo for approval within five (5) working days.

Low – The schedule for correction of all low variances shall be replied within two

working days and it shall be fixed or a schedule for correction presented to IECo

for approval.

The variance class shall be assigned by the person who reports the variance with

IECo approval.

Variance reports shall be available to IECo at all times and shall be submitted by the

Contractor to IECo. The Contractor shall maintain and periodically distribute a


176


variance summary that lists for each variance the report number, a brief description

of the variance, its class and its current status (open or resolved).

14.3.6. Resolution of Variances

All actions taken to correct variances shall be documented on the Variance Report by

the Contractor. Sufficient information shall be provided to enable an IECo

representative to determine the need for and extent of re-testing, the need for

testing any previously tested hardware or software, and the need of updating

appropriate documentation. A variance shall be deemed resolved only when all re-

testing has been performed to the satisfaction of the IECo and after the Contractor

and IECo representatives acknowledge correction of the variance in the Variance

Report. A description of the corrective actions taken shall be provided to IECo.


177


14.3.7. Test Types

Each test described below shall be considered as a separate test. The requirements

for test plans and procedures, test records, test initiation, test satisfaction and

unstructured testing shall apply separately to each test.

14.3.7.1. Software Installation Test

This test will check that the installation process is concluded successfully in each

applicable environment. This test will be performed for every software version

installation.

14.3.7.2. Unit Testing

Unit tests will check that each module performs as expected, according to its

specification. This test is a pre-requisite for any integration test.

14.3.7.3. Functional and Performance Tests

The Functional and Performance Tests shall completely verify all features and

performance of the System's hardware and software as specified in this

Specification. As a minimum, the following items shall be included in the Functional

and Performance Tests:

Inspection of all equipment for conformance to specifications and drawings

and for satisfactory construction and appearance.

Testing of the proper functioning of the System, including test cases with

normal and exceptional field and user-entered inputs.

A basic dead-or-alive (DOA) test suite to run first to detect basic failures

Bug detection tests: tests which resulted in detecting bugs in the past will be

added to the regression library and run regularly.


178


Simulation of field inputs which allow sample inputs to be varied over the

entire input range via individual setters.

Simulation of field input transient error and failure conditions.

Simulation of control outputs to suitable indicators.

Verification of communications between all types and models of equipment

at all levels of the System

Simulation of equipment errors, communication errors and channel failures,

including incorrect check codes and random channel noise bursts.

Simulation of data exchange with IECo systems

Testing of security and authorization processes.

Testing of all user interface functions including random tests to verify correct

database linkages.

Simulation of hardware failures and input power failures to verify the

reaction of the System to processor and device failure and to verify the

backup and redundancy policy performance.

Testing of all features of the database, display, report generators and all

other software maintenance features.

Testing of all software utilities.

Simulation of attempts to violate data protection or forbidden access.

Verification that the System meets or exceeds its performance requirements.

Simulation of the complete communication network.

The Contractor shall inform IECo about any part of the communication

infrastructure that is only tested by simulation.


179


The Contractor shall describe in the test plan how the data links will be simulated

during the normal, high and peak loading conditions tests. The Contractor shall

describe the auxiliary equipment and software on site for performance evaluation.

The Contractor shall provide all required hardware and software to perform the

simulation.

Each time a new version is delivered the Contractor shall provide regression test

suite, which shall be added to the regression library.


180


14.3.7.4. System Hardware Integration Test

The System Hardware Integration Test shall confirm that the System's tested

hardware configuration conforms to the Specification and the Contractor-supplied

hardware documentation. The System Hardware Integration Test shall be performed

once the tested hardware configuration has been installed. The operation of each

item shall be verified in both a stand-alone mode and as an integral part of the

System. It will be verified that each hardware component is completely operational

and assembled into a configuration capable of supporting software integration and

factory testing of the System. Equipment expansion capability shall also be verified

during the System Hardware Integration Test. The System Hardware Integration Test

shall include the inspection of all equipment for conformance to specifications and

drawings and for satisfactory construction and appearance.

14.3.7.5. Integrated System Test

The Integrated System Test shall verify the stability of System's hardware and

software after the Functional and Performance Tests have been successfully

completed. During the Integrated System Test, all System's functions shall run

concurrently and all Contractor supplied equipment (including subcontractor's

equipment) and any IECo provided equipment shall operate for a continuous 96-

hour period. The test configuration shall be identical to that which was tested in the

framework of the test.

The test procedure shall include periodic repetitions of the normal high loading and

peak loading scenarios as will be defined as well as random activities introduced by

the IECo test team.

The Integrated System Test shall assure IECo that the System is free of improper

interactions between software and hardware while the System is operating as an

integrated whole. IECo will not consider that the test is passed if more than two


181


accidental functional restarts or processor or device failures have occurred. The test

will be extended by 24-hour increments until this requirement is satisfied.

14.3.7.6. Interfaces to IECo's Systems Tests

The Contractor shall test the "End-to-End" functionality of the System including

interfaces to IECo's systems (SAP, NIS etc.), ensuring thereby that the data is

successfully transferred from one sub-system, whether provided by Contractor or by

IECo, to another such sub-system without loss of data or without breakdown or

interruption – all in accordance with the requirements of this specification.

14.3.7.7. Unstructured Testing

Periods of Unstructured Testing shall be allocated to allow IECo representatives to

verify proper operation of the System under conditions not specifically included in

the approved test procedures. Unstructured Testing shall be conducted in

compliance with the following conditions:

1. The Contractor's test representative shall be present and the Contractor's

other technical staff members shall be available for consultation with IECo

personnel during unstructured test periods.

2. All simulation software, test cases and other test facilities used during the

structured portions of the factory tests shall be made available for IECo's use

during unstructured testing.

3. Unstructured Testing shall not begin prior to the start of the Functional and

Performance Tests.

4. Unstructured Testing shall be allowed at IECo's discretion both at the end of a

structured test segment and after completion of the Functional and

Performance Tests.


182


14.3.8. Testing Phases

The testing shall comprise the following phases:

14.3.8.1. Factory Acceptance Tests (FAT)

The purpose of FAT tests is to completely test the systems at Contractor's site before

delivering to the IECo. The Contractor shall be responsible to establish the proper

environment for the test. All testing will be done at the Contractor’s location or at a

manufacturing facility contracted by the Contractor. Testing shall be done under the

supervision and control of authorized employees of the Contractor.

FAT shall include in the test setup all the components of the Sytem. Amount of

meters shall be agreed between Contractor and IECo. In order to test performance

of the system contractor shall provide meter simulator.

14.3.8.2. Site Acceptance Tests (SAT)

The SAT shall take place after complete installation and final configuration and shall

repeat FAT or an acceptable subset to verify no damage has occurred during

shipment and installation.

The responsibility for conducting the Site Acceptance Test shall rest with the

Contractor. However, IECo will witness all tests and will perform the hands-on

actions of the test procedures to the maximum extent possible. Knowledgeable

Contractor representatives shall be present at IECo during all over the test.


183


It is IECo's responsibility to provide the Contractor with all necessary information

regarding IECo production / operational environment and network.

14.3.8.3. User Acceptance Test (UAT)

The UAT shall take place after SAT and shall verify that the solution works for the

user. The UAT will be conducted by IECo. Knowledgeable Contractor representatives

shall be available at all times. In order to conduct UAT the contractor will provide the

following to IECo:

1. Description of test results which were determinted by simulation, calculation

or extrapolation and not actually performed

2. The Contractor's maintenance records identifying all hardware and software

modified repaired or replaced the completion of FAT and the start of UAT.


184


14.3.8.4. Operational Acceptance test (OAT)

The OAT will be conducted once the whole System has gone live. An estimated 2,000

hours Operational Acceptance Test (OAT) shall be conducted to verify the System

ability to meet their specified availability requirements.

OAT Requirements

System availability of at least 99.5% shall be demonstrated. Device availability shall

also be demonstrated in accordance with criteria specified in this Specification

document.

Communication availability level of 97% for meters installed during the scope of the

Project as specified in Chapter 6.1 of this Specification.

The exact OAT program, i.e. method, quantities, parameters, time table, etc. will be

discussed, and agreed upon between Contractor, and IECo representatives.

OAT Responsibilities

The Contractor shall be responsible for the OAT which will be conducted by IECo. The

Contractor shall ensure that the test is performed in accordance with the approved

procedures and that maintenance and troubleshooting are performed exactly as

prescribed by the Contractor in the relevant System Maintenance Manuals and other

System Documentation.

The Contractor’s active involvement in the OAT processes includes participation in

the Failure Review Board (FRB), headed by IECo’s representative. This board is the

only body in the project, which is entitled to decide about the relevancy of each one

of the failures as countable or non-countable for the purpose of the demonstrations.


185


IECo will operate and maintain the System according to procedures prescribed in the

approved Contractor documentation using the tools supplied by the Contractor,

relying on the training provided.

During the demonstration, a computerized logbook shall be maintained in which

occurrences in general and failure descriptions in particular shall be recorded.

Software and hardware down times, as well as System down times, shall be

recorded, as applicable. All records shall be maintained by IECo in accordance with

Contractor's written instructions and under his supervision.

Where applicable, all spare parts pertaining to the system and used during the OAT

shall be drawn from IECo's inventory. All spare parts supplied from IECo's inventory

and used to replace failed equipment during the demonstration shall be restocked

by the Contractor. If a part is required which is not in IECo's inventory of purchased

spares, due to the failure of the Contractor to recommend appropriate spare parts,

the system shall be considered down until the part is obtained. The failed part shall

be repaired or replaced and an additional unit shall be placed into IECo's inventory at

no cost to IECo concurrently, the recommended spare parts list shall be updated.

During the OAT period, IECo reserves the right to modify the system databases,

displays, reports and application software. Such modifications will be described to

the Contractor at least 48 hours in advance of implementation to allow assessment

of impact on the OAT.

OAT Definitions

The OAT Procedure shall incorporate, as a minimum, the following definitions:

Availability

Availability in this case is the proportion of time the System/subsystem is operating

satisfactorily, and is calculated according to the following formula:


186


A =

UP Time

UP Time + Down Time

Subsystem

A subsystem is any group of devices (or a device) performing a specific function or

functions of the System.

Up Time

Up Time is the time when the System/subsystem operates satisfactorily.

Down Time

Down Time occurs whenever the criteria for successful operation are not satisfied as

specified in the specification. Down Time consists of repair time and delay time:

Down Time = Repair Time + Delay Time

Repair Time

Repair Time (RT) is the total actual accumulated time spent by technicians/engineers

to correct failures, i.e.:

RT = Tp + Tfi + Td + Ti + Tr + Tco + Tst

Where:

Tp - Preparation Time (starts right after detection of a failure).

Tfi - Failure Isolation Time.

Td - Disassembly Time of the surrounding area of the failed item.

Ti - Interchange Time of the failed item.

Tr - Re-assembly Time of the surrounding area of the failed item.

Tco - Checkout Time.

Tst - Start up Time.

RT shall be applicable to Software as well.

Delay Time


187


Delay Time is the accumulated time connected with restoring failures, excluding

Repair Time, and consists of:

Delay Time = Logistic Time + Administrative Time + Hold Time

Logistic Time

Logistic Time is the accumulated time spent for bringing technicians/engineers,

documentation, spare parts or test equipment for the purpose of repairing failures.

Administrative Time

Administrative Time is the accumulated delay time due to management decisions.

Hold Time

During the OAT, certain contingencies may occur that are beyond the control of

either party. The contingencies may prevent successful operation of the system, but

are not valid for the purpose of measuring system availability. Such periods of

unsuccessful operation may be declared "Hold Time" by mutual agreement of IECo

and the Contractor. Specific instances of Hold Time contingencies are:

Scheduled Shutdown: During scheduled shutdowns, or if an equipment failure occurs

while its backup device is scheduled out-of-service, the resulting system outage shall be

Hold Time, provided that service can be restored according to Contractor-specified

procedures within 30 minutes.

Power Interruption and Environmental Excursion: Loss of power or manual shutdown in

the event of loss of environmental control, shall be considered "Hold Time". If the

system are operated during periods of power or environmental conditions beyond those

specified, any resultant Down Time shall be considered Hold Time.

Failure of IECo Software: Time during which the System is down due to failure of

software written and independently produced by IECo shall be considered "Hold Time."

If a failure in such software cannot be corrected by Contractor-defined procedures,

execution of the failed program will be suspended. Programs developed by IECo

personnel under Contractor supervision are specifically excluded from this provision.

Service Response time: a maximum of 24 hours of Hold Time will be allowed for the

Contractor to respond to each call for maintenance support. The time between


188


detection of a failure and the start of diagnostic procedures shall also be considered

Hold Time when performed by IECo’s personnel.

Corrected Design Error: Hold Time may be declared by mutual agreement to ensure

against similar future occurrences if a failure occurs due to an error in system design, for

which the Contractor defines and implements corrective measures. In such a case, "Hold

Time" shall be allowed in increments of 120 hours to allow verification of the corrective

action.

Failures caused by misuse of the System or its Test Equipment. Misuse, in this sense,

shall mean acts performed by IECo personnel, in contradiction to written instructions

provided by the Contractor as part of Project's Documentation.

Intermittent Failure: Periods during which an intermittent recurring software or

hardware failure is experienced will be considered Hold Time provided that the

Contractor is engaged in remedial action as mutually agreed and normal functions can

be restored by the Contractor - defined procedures whenever the failure occurs. Instead

of accounting for the actual intermittent Down Time, one hour of Down Time shall be

counted for each 120 hours of otherwise successful operation while the problem

persists.

Failure: A failure occurs each time the System does not meet its specification.

OAT Satisfaction

After the elapse of 2,000 hours of cumulative OAT time, the availability will be

calculated using the formula described in this chapter. The Administrative Time and

the Hold Time shall, as mutually agreed upon by IECo and the Contractor, not be

included in the availability calculations.

The calculated availability figure shall then be compared with the specified decision

rule value. If OAT objectives have not been met, the test shall continue until the

specified availability is achieved based on one of the following time periods:

Total elapsed test time

Consecutive 2,000-hour period of test time, exclusive of hold time and administrative

time

To establish that all failures have been satisfactorily repaired prior to the end of the

OAT, no Down Time or no more than one uncommanded failover should occur


189


within 240 hours (In addition to the initial 2,000 hours) of the OAT’s conclusion. The

OAT shall be extended, if necessary, to satisfy these requirements.

After the satisfactory conclusion of the availability test, the availability of each

Subsystem shall be measured against the Subsystem availability criteria based on

records kept during the availability test. If one or more Subsystem devices do not

meet the defined criteria, then completion of the test shall be delayed until IECo and

the Contractor mutually agree that the corrective action has been completed for

those Subsystems. Corrective action shall include all necessary procedures to test

and verify proper operation to IECo's satisfaction.

Reliability Field Demonstration

Some of the equipment (such as meters) that will be supplied by the Contractor to

IECo shall be participating in a “Reliability Field Demonstration” (RFD). This

Demonstration shall be performed after their installation at IECo sites, and

completion of their Acceptance Test. The exact Demonstration program, i.e. method,

quantities, parameters, time table, etc. will be discussed, and agreed upon between

Contractor, and IECo representatives.

In case of a systematic failure or a design error the Reliability Field Demonstration

will be stopped, the Contractor will perform a corrective action, and the

Demonstration will start again from the beginning.

No more than two (2) systematic failures and/or design errors are allowed. After the

third systematic failure and/or design error has occurred, the Demonstration will be

stopped, and IECo shall have the right to reject the entire System, or part of it.


190


15. PROJECT MANAGEMENT AND GOVERNANCE

The purpose of this chapter is to provide tools as well as key requirements describing

how the project is to be managed, as well as describe who are the responsible

parties, and describe key project management approach and processes.

15.1. Contractor Responsibility

The Contractor shall be responsible for the delivery of the System. The Contractor

shall design, procure, adapt, develop, assemble, test, preserve, ship, integrate,

supervise, support and maintain the startup and commissioning of the System

provide associated equipment and documentation and provide services in

accordance with the Contract. In order that, IECo, at the end of the commissioning

process be able to independently operate and maintain the System. The Contractor

shall be responsible for the satisfactory operation of the System.

15.2. Project Management

The project management will comprise of two primary roles, the project manager

and the program manager, the roles will be further described in the following sub-

sections.

In addition to the primary project management roles by the Contractor the following

shall be defined:

The Contractor shall identify key personnel in accordance with the requirements

provided in the CV Section 17.2.1 – Key Personnel Resumes, The Contractor will

nominate technical experts who will work vis-à-vis their counterparts in IECo The

technical experts will have the authority to take decisions and reach agreements


191


in issues having merely technical nature. Decisions / agreements having schedule

/ cost / change of requirement impact, will require Contractor's / IECo's Project

Manager's approval.

The assignment and reassignment of key personnel to the Project by the

Contractor shall be reported and subject to approval by IECo.

The Contractor project management team will be the single point of contact and

responsible for the project management of the overall project scope including

sub-Contractors management.

15.2.1. Project Manager

The Contractor shall appoint a Project Manager who will be a single point of contact

for IECo.

The Project Manager will have the end-to-end project responsibility and will be

tasked with managing the project on a daily basis, responsible for meeting deadlines

and payment milestones as defined in this document. The project manager will work

with IECo’s assigned project manager to coordinate efforts and will also be

responsible for all sub-Contractors deliverables and project tasks.

The Project shall be staffed with personnel who have previous experience in a similar

position in other project similar in scope to the IECo Project. Project Manager will be

expected to be frequently on-site in Israel during the project implementation period,

at least once every 2 weeks, as required. Contractor shall have a project coordinator

or representative located in Israel throughout the Project implementation period.

It is expected by IECo that Project Manager shall attend steering committees.

Following, the Contractor is required to provide information on how it intends on

defining the project manager roles, responsibilities and skills such that it will provide

an end-to-end project management capability in accordance with the above.


192


Table 15.1 - Project Manager Roles & Responsibilities Description

Item Description

Key Project Manager Roles

Key Project Manager Responsibilities

Describe how Project Manager will provide an end-to end project management capability

15.2.2. Program Manager

The Contractors’ Program Manager will be the primary stakeholder on behalf of the

Contractor; it will be the sponsoring authority and will have overall responsibility for

the success of the project and meeting deadlines and payment milestones. Program

Manager will have the authority to commit company's resources in order to perform

this program in accordance with the Contract.

Following, the Contractor is required to provide information on how it intends on

defining the program manager roles, responsibilities and skills such that it will

provide an end-to-end program manager capability in accordance with the above.

Table 15.2- Program Manager Roles & Responsibilities Description

Item Description

Key Program Manager Roles:

Key Program Manager Responsibilities

Describe how Program Manager will provide an end-to end project management capability


193


15.2.3. Program Review (PR) and Progress Report

The Contractor shall define under this paragraph of the Proposal, those PR’s that

shall be used to obtain the following objectives:

Solving Program management problems.

Presentation of Program status by the Contractor.

The PR’s shall be convened at least every month. The Contractor shall define his

proposed procedures for conducting PR’s, including detailed descriptions of PR

agenda and summary under this paragraph.

Where applicable, PR’s shall be scheduled in alignment with the quarterly (every 3

months) Steering committee meetings and will take place prior to the steering

committee.

The reviews shall be held at IECo's offices. It is the obligation of the Contractor to

assure adequate participation by his technical and management representatives, as

required by the issues to be discussed. The PR's discussions will be based on the

Contractor's Monthly Progress Report, defined below.

The Contractor shall define in his proposal, the structure and submission procedures

of his Progress Reports in accordance with the requirements in Annexure A – Terms

and Conditions.

The Progress Report shall include the following items:

a) An updated Project schedule with explanation of any deviations from the

planned schedule. The explanation shall include the anticipated impact of any

delays and a plan for returning to the target schedule. All delays shall be factored

into the Project schedule as soon as they are known to the Project Manager. All

changes to the schedule since the last progress reporting period shall be

identified.


194


b) A summary of activities performed by the Contractor, Sub-Contractors and IECo

during the reporting period.

c) An updated list of all correspondence transmitted and received.

d) An updated list of Contractor and IECo action items with status and required

resolution dates.

e) A summary of pending and upcoming Contractor and IECo activities during the

next two reporting periods along with the required completion dates.

f) The status of unresolved Contract questions and change requests.

g) A description of current and anticipated Project problem areas and the steps that

have to be taken in order to resolve each problem.

h) QA report which summarizes all quality activities during the reporting period,

according to the Inspection and Test Plan.

i) Review risk management updates, discuss risk mitigation plans and follow up

identified risk issues.


195


15.2.4. Design Review (DR)

Following are IECo's requirements for conducting Design Reviews. The Contractor

shall describe in the Proposal his DR procedures, based on these requirements.

The Contractor shall conduct DR’s with IECo personnel. The main objectives of the

DR’s are:

To clarify and eliminate all misunderstandings, differences, errors and omissions

based on the preliminary documentation, drawings and procedures.

To ensure the adequacy of technical solutions proposed for IECo's requirements.

To discuss issues connected with the System Functional Specifications, the

Acceptance Tests Plan, etc.

Design Reviews shall include

1) PDR – Preliminary Design Review, in which the Contractor shall present his

building blocks to implement the System’s functionality, as described in the

Requirement Documents. This will serve as a basis for scheduling the review and

approval of the design, tests procedures etc. The Contractor shall state clearly all

the deviations, if any, from the Requirements. PDR shall be conducted after

contract signing. The PDR will be conducted as part of the High Level Design

stage.

2) CDR – Critical Design Review, will be held once the detailed design, test

procedures, etc. are approved. The Contractor shall present the full coverage of

the system functionality by his solution. Approval of the CDR shall be a

prerequisite for the implementation phase.


196


The DR’s shall be based on the preliminary documentation which shall be submitted

in accordance with the work plan provided by the Contractor in work plan.

The Contractor shall list and schedule all his proposed DR’s and recommend their

respective lengths. The Contractor shall describe in detail the subjects as well as

specify the documentation to be reviewed. The agenda for each DR shall be

forwarded to IECo at least two weeks prior to the DR scheduled date. Location and

time of the meeting shall be included in the agenda. The IECo shall have the right to

add issues to the agenda. The complete list of the proposed DR’s, (with the

specification of the issues to be discussed) is to be detailed here. The Contractor

shall ensure that all Subsystems / Requirements / Test procedures / Integration /

Architecture / cyber security will be covered.

DR’s shall be conducted at IECo site, as and when requested by IECo.

All DR’s shall be summarized by the Contractor. The summary shall include action

items to be implemented by the Contractor as well as by IECo and shall be approved

of by the IECo IECo's approval of the DR’s and subsequent approval of preliminary

documentation shall be subject to the provisions of Annexure A – Terms and

Conditions.

A DR shall be completed and approved by the IECo only when all the subjects and

documentation scheduled for review as well as concerns brought up during the

course of the DR are completed by the Contractor and approved by the IECo.


197


15.2.5. Steering Committees

The Steering Committee’s role is to steer the project towards its goal, the steering

committee will monitor, provide guidance, act as the highest point for escalation and

decision making for the project. The steering committee will convene on a frequent

basis and will include materials for discussion such as the content of the general

work plan, items at hand, schedules, risks, execution vs. planning, decisions follow-

ups and budgetary items

• In order to coordinate and to direct the general development of the program the

Steering Committee’s main functions can be summarized in the following points:

o Making key decisions about the future of the project.

o To control the progress of the project and decide accordingly.

o Highest point of escalation to solve possible conflicts and open issues. For

example: discrepancies between different areas, resources availability,

conflicts of priorities, etc.

• Steering Committee composition could change along the project, depending on

the project phase.

• The Steering Committee will meet on a quarterly basis (every 3 months) and will

be aligned with the Program Review.

• Steering Committee will be composed by Project Manager and Program Manager

from Contractor and Project Manager of IECo and a representative of IECo’s

Manager Board.

• The steering committee will be able to convene in case additional special

sessions are required by either project managers, these steering committees

could utilize conference calls and other types of communications in order to

provide on time response to project needs.


198


• The steering committee will publish formal steering committee protocols noting

the decisions that were agreed upon, the responsibilities assignment to execute

the decisions and schedule for execution.

15.2.6. Subcontractors Management

The Contractor shall identify at the time of proposal submission, under this

paragraph, all subcontractors (with work volumes exceeding $50.000 US) who will be

actively involved in the Project, according to Annexure A – Terms and Conditions.

The Contractor is required to provide the following information per subcontractor:

• Subcontractor’s name.

• Subcontractor’s key roles in the projects.

• Subcontractor’s key contributions.

• Type of Agreement – what type of agreement is currently available between

Contractor and subcontractor.

• Nature of collaboration and previous experience – does the Contractor have

previous experience in collaborating on a project with the specific subcontractor,

what is the level of cooperation currently available between the companies.

• Collaboration policy - what is the collaboration policy between the companies for

the proposed project (weekly calls, co-design teams, what level of management

is involved in the collaboration).

• It is required from the Contractor to provide all information relevant to assess

the level collaboration between the companies.


199


• Subcontractors governance – i.e. what are the means, policies, procedure the

Contractor intends to employ in order to comply with its responsibilities relating

to work being done with its subcontractors.

It is required that the Contractor will be actively managing the work with the

subcontractors and to assume full responsibility over the subcontractors deliverables

as well as making sure subcontractors are meeting the deadlines and perform in

accordance to the quality assurance and standards defined in this document.

Contractor is responsible for providing all warranties for meters, DCs and

associated hardware including filters, repeaters, and testing equipment, software

tool version, and firmware versions including for products provided by

subcontractors.

Table 15.3 - List of Subcontractors

# 1 2 …

Subcontract Name

Key roles in the Project

Key Contribution to the Project

Type of Agreement

Nature of Collaboration / Previous Experience

Collaboration Policy

Subcontractors Governance

15.2.7. Data Management


200


The Contractor shall appoint a Data Manager who will be responsible for managing

all data, documents, specifications etc. pertaining to this Project. This paragraph of

the Proposal shall detail the description of his/her activities, as well as the Data

Management procedures and tools.

Table 15.4 - Data Management Key Activities

# Key Activities Description

1

2

3

…


201


Table 15.5 - Data Management Procedures

# Data Management

Procedures Description

1

2

3

…

Table 15.6 - Data Management Tools

# Data Management Tools Description

1

2

3

…

15.2.8. Configuration Management

The Contractor shall conduct a computerized Configuration Management (CM)

Program which it shall define in detail under this paragraph of the proposal. The CM

Program shall support development, manufacturing, testing and commissioning of all

hardware, software, firmware and documentation delivered under this Contract

including updates and retrofits to assure effective logistic support.

The Contractor is expected to enable a flexible form of digital configuration

management files such that it could be then integrated to systems at IECo.

15.2.8.1. Software Configuration Management

All software development performed by the Contractor shall be under a formal

documented software configuration management procedure. In lieu of a software

configuration management scheme developed by the Contractor, IEEE Std. 828-1990

Standard for Software Configuration Management Plans, or a similarly common

standard will be acceptable for the Project.


202


The procedure shall encompass the following aspects:

• Inventory control.

• Version control.

• Change control.

• Build management.

• Configuration files for meters and DCs

• Release notes

In addition to managing source, object and binary code, the software configuration

management scheme shall maintain coordination with all relevant documentation,

including functional design and user documents.

The software configuration management scheme shall be properly managed

beginning at the time code is initially installed on the proposed system. Changes to

the proposed system’s software shall be implemented so as to ensure that the

source library is properly maintained and is kept up to date throughout its life cycle.

15.2.8.2. Hardware Configuration Management

The Contractor shall conduct a hardware configuration management program for all

hardware provided under the Contract.

Configuration management procedures shall support the hardware throughout its

life cycle from definition, through development, purchasing, testing, installation,

final acceptance, warranty and post warranty stages, assuring effective logistic

support.

For additional details for meters and DCs refer to chapters 4 & 6.

15.2.8.3. Document Configuration Management


203


The Contractor shall conduct a document configuration management program for all

documents provided under the Contract. Configuration management procedures

shall support the documents supplied under the framework of the Contract

throughout the system life cycle.

15.2.9. Changes

Under this paragraph of the Proposal, the Contractor is required to state the detailed

change procedures in compliance with the requirements of Annexure A – Terms and

Conditions.

In general, every change to the project plan after approval of IECo must undergo a

process of evaluation and approvals, only after the implications are assessed and

changes are approved by IECo, it will be possible to adjust the project work plan and

publish as a new official version.

Each change request will have to be evaluated and analyzed according to the

following:

• Cause for the specific change request

• Implications and risks analysis

• Technological implications analysis

• Impact analysis on project plan, key milestones, budget and resources

15.2.10. Risk Management

As part of the overall project management, the Contractor is expected to identify,

analyze, concentrate, handle and monitor risks associated with the project plan.

Risks should firstly be identified, categorized and devised with proposed alternative

responses; Contractor is also required to list Level of Impact (Low/Medium/High)

and the specific impact in terms of project stage as well as suggest a mitigation plan

to prevent risks and follow-up on identified risks throughout the project lifespan.


204


The Contractor is required to fill in the following table listing all risks that will be

managed by the Contractor during the project.


205


Table 15.7 - Risk Management Table

# Category Description of Risk Level of Impact

Area of Impact

Alternative Responses

1

2

…

15.3. Environments Policy

The Contractor, as an integral part of the Build/Integrate, Test and Production

phases of the project will specify the number of environments it is expected to

provide, assuming a minimum of 3 environments: Development, Testing and

Production. The Contractor shall also specify in detail each of the environments to be

setup for the project, its hardware, software, characteristics, and the procedures for

phasing from one environment to the next and additional information.

Table 15.8 - Table of Environments

# Environment

Name Hardware Software

Key Characteristics

Phasing Procedures

1

2

3

…


206


15.4. Delivery of Meters, DCs, CTs and associated

components

15.4.1. Workmanship

The contractor shall state his workmanship standards, specifications and procedures,

directed at achieving accepted workmanship quality.

15.4.2. Safety issues

The contractor shall state the means and the specification he uses to preclude

hazard to personnel, equipment or both. Hazards to human life or health as well as

to equipment, property and/or to the environment shall be addressed.

15.4.3. Human performance/engineering

The contractor shall state the standards and specifications on which human

performance/functions are based. The following topics shall be addressed:

a) Functions allocated to personnel vs. functions performed automatically.

b) Man-machine interface (or personnel/equipment interaction). (Note that all

displays and test programs shall be in the English language or in Hebrew where

applicable).

15.4.4. Logistics

The contractor shall specify in this paragraph all logistic related requirements,

principles and characteristics which assure that:

a) The proposed system(s) performance shall conform to the specification without

degradation throughout its lifetime.

b) The operations required to obtain the objective of (a) above are effective and

efficient.


207


c) Delivery of all the components will be done to IECo warehouses in Tel-Aviv area.

15.4.5. Packaging

15.4.5.1. Meters and DCs Packaging

Each poly-phase meter must be packed, together with its terminal cover, in a

separate cardboard box, which can be opened and re-closed without needing

adhesives. Up to 10 single-phase meters must be packed together with their

terminal covers in a group cardboard box, which can be opened and re-closed

without needing adhesives. For three phase meters 4 to 8 meters per group card-

box.

The box shall prevent, as much as possible, penetration of dust during long storage

periods. The box must be designed for multiple use and be robust, with wall

thickness of at least 4 mm.

The packaging will protect the meters against shock and vibration, preventing

damage due to the road conditions during transport and distribution in the

countryside. The electrical and mechanical properties shall not be affected by these

disturbances.

The group box shall be marked – both on the front (wide side) and the top – with the

manufacturer name, meter type, meter code, IECo catalog number, production serial

number/s and bar-code/s, manufacturing year, the sign “FRAGILE” and the IECo logo.

For shipping the boxed meters will be close packed by stockpiles of suitable

quantities on pallets. The meters numbers sequence (without partition) shall be kept

in each pallet. A pallet 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 IECo

logo, the manufacturer's name, meter type, meter code, IECo catalog number,


208


production serial numbers' borders, serial number bar-codes borders, manufacturing

year, the IECo order number, the sign “FRAGILE”. 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 ("Shock-Watch") 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 general form, overall and access dimensions of the pile are as given in figure

15.1.

Each pallet should contain between 70 and 300 meters. The actual number of meters

on each pallet will be agreed with the IECo when the manufacturer is awarded an

order.

Figure 15.1 – Packaging Instructions

10

50

-1

00

250 ±20100 -10

800 -40

11

0 +

10

15

0 -

10

150 -10

1200 -200

KMKM

Cardboard Hood Polyethylene Hood


209


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 open at the bottom, per

drawing;

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.

15.4.5.2. CTs Packaging

The CTs will be supplied in shipping boxes, properly packed and lagged to prevent

the CTs from possible damage during shipment and storage.

a) Each shipping box shall have packing list and, in addition, shall be marked with

the following information:

• Contractor name and address

• Descriptive name of the CT

• IECo order number

• Gross weight of the box

• Package volume of the box

• Complete destination marking

• IECo catalog number


210


• Range of serial number in the box.

b) Each CT will be packed in one carton box.

c) The Manufacturer shall attach one set of the Bill of materials to the shipment.

d) Unless specially designated, all Equipment and other items shall be packaged in

shipping boxes for outdoor storage. Where required by the nature of the

equipment, it shall be protected from sand, rain, hail and dust. Equipment shall

be adequately sealed and protected during shipment to prevent corrosion and

entrance of foreign matter.

e) The Manufacturer shall submit detailed storage instructions for any Equipment if

necessary for storage. Such information shall be available to the Purchaser in

ample time to prepare the required facilities.

f) 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.

g) The certificates shall include the signature and name of the entity performing the

tests and shall subject to the review and acceptance of the purchaser.


211


15.5. Warranties

15.5.1. Warranty For Meters, DCs, CT's and associated components

The contractor shall provide a warranty for meters, DCs, CT's and associated

hardware including filters, repeaters, and testing equipment, software tool versions,

and firmware versions, against any defects, which may develop due to faulty

hardware, calibration, software defects, transportation or workmanship. The

contractor shall be responsible for repairing or replacing each faulty component

during the warranty period at no cost. Contractor shall be responsible of the

shipping costs of the materials.

In the case that a faulty component is replaced by a working component in a one-

for-one way, this shall be done within 2 weeks, from the date the faulty components

have been returned to the manufacturer in the case of hardware components.

In the case of a non-systemic failure (defined as annual occurrence in <<0.1% of total

installed components), contractor shall acknowledge reporting of failure within 1

working day. Failure shall be investigated and resolved within 4 weeks and working

component shall be delivered within 8 weeks from date failure was reported.

In the case of a systemic failure (defined as annual occurrence in >0.1% of total

installed components) contractor shall acknowledge reporting of failure within 1

working day. Failure shall be investigated and resolved within 6 weeks. First pallet of

working components shall be delivered within 10 weeks from date failure was

reported.

If the annual failure rate of components exceeds 0.5% of the total installed

components is considered a series failure. If there is series failure that requires mass

de-installation contractor shall bear all the associated costs covering from the de-

installation up to the re-installation (included too).


212


Date of a failure shall be determined either as the date when the fault was

discovered, or as the date that the faulty component was removed from service. Any

component will be regarded as faulty if it does not meet one or more of the

requirements in this Specification, as well as requirements for safety, reliability,

physical integrity, etc.

Warranty by the Contractor for DCs shall also cover communication reliability

requirements as described in Chapter 6.1. i.e. 97% of its meters shall be reacheable

within 30 days, and there shall be reliable daily transfer of consumption data, load

profile data and event-log data, reaching 97% success rate within five reading

attempts.

The contractor will be informed of the nature of the found failures in order to

perform corrective actions. The contractor will coordinate, with the relevant

manufacturer in the case that the component manufacturer is a subcontractor, an

investigation to determine the reasons for the found faults, as well as implement

corrective measures. These shall be coordinated with IECo technical experts involved

in preventive measures implementation, diagnostics and failure statistics.

Warranty period shall be for mandatory 3 years from delivery of respective

components, plus an option to extend the warranty by 1+1+1 years with payment if

decided by IECo within 90 days after the 3-year warranty period, and after each of

the extended period.

15.5.2. Warranty for software systems and associated Hardware

The contractor shall provide a warranty for all software systems and all associated

hardware. The warranty period for the software systems will begin at the end of the

Operational Acceptance Test for phase C, when approved and will be for a period of

1 year. The warranty period for associated hardware will be 3 years from delivery.


213


For details of support requirements during the warranty periods refer to Chapter

15.6.2.

The contractor shall also provide a proposal for maintenance after the end of the

warranty period for software systems for a period of three years which should

include the support program components described in this chapter. Maintenance of

associated hardware after the respective warranty period will be covered by existing

IECo services support agreement.


214


15.6. Support and Maintenance

15.6.1. Maintenance for Meters, CTs and DCs and associated components

Maintenance Responsibilities

The Contractor shall be responsible for providing maintenance for all meters, CTs

and DCs and associated SW and HW components provided under the contract

through the end of the relevant Warranty period. For details of warranty

requirements see Chapter 14.5.2.

a) Preventive/periodic maintenance - The contractor shall specify policy and attach

comprehensive procedures for periodic maintenance, required to maintain the

proposed system(s) in operational non-degraded state and prevent it from

developing long term damages

b) Troubleshooting - The contractor shall state policy and attach comprehensive

procedures for field troubleshooting detailing, in step by step description, fault

detection and localization using built-in, standard and special test equipment and

software; fault repair and system(s) operability verification tests.

c) Laboratory level repairs - The contractor shall state policy and attach

comprehensive the contractor shall state policy and attach comprehensive

procedures for laboratory level repair policy.

d) Maintenance times - The contractor shall specify mean times required to

perform the three types of maintenance activities mentioned in a, b and c above.

e) Accessibility - The contractor shall specify accessibility requirements for

performing the necessary maintenance and troubleshooting activities.

f) Provisioning - The contractor shall specify policy and procedures for provisioning,

required for proper operation and maintenance of the modules, subassemblies,

cards, components, mechanical parts, cables, wires and consumables.


215


g) Infrastructure - The contractor shall specify, in quantitative terms, the

infrastructure required for maintenance and operation of the meters, DCs and

associated components.

h) Spare Parts - The Manufacturer shall be committed to supply spare parts to IECo

as required to maintain and repair the quantity of the purchased meters and

DCs, if asked for.

The parts shall be supplied as long as the meters and DCs are purchased and shall

continue to be available at least 5 years after the manufacturer has stopped

supplying the purchased meter/DC type.

After this time, before the termination of the spare parts supply, the

manufacturer shall provide IECo with all the necessary information to produce

the spare parts, or inform IECo of alternative sources.

15.6.2. Maintenance and support for Software Systems and associated

Hardware

The Contractor shall be responsible for providing support for all software systems

and associated hardware provided under the contract during the whole period of the

project, including phase A, phase B and phase C (pre-warranty period) and through

the end of the Warranty period. Support Program

The Contractor shall have the following basic support program components:

Problem Reporting

a) Help Desk Support to submit system problems. IECo shall be able to submit

problems by contacting them in any agreed way.


216


b) IECo shall be able to submit, review, and track the Contractor’s progress of all

problems that are associated with the IECo’s system, with HP – Quality Center

tool.

c) The Contractor’s help desk support team shall be staffed with experienced and

trained personnel. The staff shall possess adequate technical competencies so

that any aspect of a system failure can be investigated and corrected.

d) The help desk support team will offer support services in English or Hebrew.

e) IECo representative shall state the severity level for any problem that he/she

submits for correction.

f) Problems will be categorized according to severity. The definition of each

severity level is described in the Table 15.9 below.

Table 15.9 - Problem Severity Levels

Category Definition

Severity 1 – Critical Critical Functions or equipment non-operational or unusable. Critical or material impact to the normal operations.

Severity 2 – High Critical Functions operational but without redundancy, and there are no possible circumventing actions.

Severity 3 – Medium Functions are operational but with limited functionality. There are no possible circumventing actions to prevent impacts to normal operation.

Severity 4 – Low Functions are operational but there are some identified problems that need correction. There are no impacts on normal operation.

Problem Handling

Problem Determination and Resolution Process - The Contractor will work with IECo

to understand, isolate, and resolve the reported problem. During the problem

evaluation, the Contractor will work with the IECo’s support staff to identify any

additional support that may be required to resolve the problem.


217


Debugging - If a fault occurs, which reduces the use of the system products

considerably; the vendor will start debugging immediately after the error message

was sent. The response time is 3 hours during the normal working hours.

The obligation for debugging corresponds to the latest version of the system

software which is installed at and used by IECo and released by the vendor.

All remaining faults will be collected and then corrected. Thereafter, the vendor will

forward a corrected version of the respective software products to the IECo from

time to time.

The vendor will inform the IECo in advance in writing about the changes.

The corrected and further developed versions are delivered according to the

preferences of the IECo on appropriate data carriers or via remote data transmission.

Problem Escalation

The Contractor’s Maintenance and Support Program shall include a problem

escalation that can be triggered automatically (e.g., “X” amount of time has elapsed

for a high severity problem, etc.) as well as manually by IECo.

a) Problem escalation in non-emergency cases (Medium and Low Severity) IECo

may elect to escalate a support request for the following reasons:

• Contractor’s proposed action plan or solution to a problem is

unsatisfactory.

• The reported severity of a problem has changed.

• Contractor has not provided a response within the stated response time.

b) Problem escalation in emergency cases (Critical and High Severity)


218


A severity of Critical or High, as described in 15.6.2.1, Table 15.9, shall be

considered an emergency. If the problem is not resolved according to the

times specified in Table 15.10, the Contractor shall immediately begin to

make arrangement for on-site assistance. On-site support shall be maintained

until the problem is resolved. The Contractor shall continue to work on the

problem remotely while the on-site support person(s) are in transit.

Response time

The Contractor shall be required to respond to support requests for each category of

severity within a defined time frame. The Bidder shall fill table 15.10 – Response

Time. Where:

• The Maximum Response Time - This time includes the initial notification of

the problem, assignment of the problem to a qualified technician, and

initiation of problem resolution efforts by the technician.

• The Maximum Solution Time – this is the maximum time for the problem to

be corrected or at a minimum an acceptable workaround implemented.

The Contractor shall respond to a request for service within 30 minutes during

normal business hours (8:00 AM to 5:00 pm local time at IECo).

Table 15.10 – Response Time

Variance Category

Level

Maximum Response

time

Maximum Solution

time Guidelines


219


Variance Category

Level

Maximum Response

time

Maximum Solution

time Guidelines

Critical

A schedule for the correction of critical priority variances shall be informed within one (1) hour and it shall be fixed within eight (8) hours after IECo request. Basic MDM functionality must be restored after 30 minutes. After the six hours period the Contractor shall assign dedicated resources until the problem is fixed or a workaround implemented.

High

A schedule for the correction of high priority variances shall be informed within eight (8) hours and it shall be fixed within twenty-four (24) hours after IECo request. After this period the Contractor shall assign dedicated resources until the problem is fixed or a workaround implemented.

Medium

A schedule for the correction of medium priority variances shall be informed within twenty-four (24) hours and it shall be fixed or a schedule for correction presented to IECo for approval within five (5) working days.

Low

The schedule for correction of all low variances shall be replied within two working days and it shall be fixed or a schedule for correction presented to IECo for approval.


220


15.6.2.1. Maintenance - General

The vendor commits to continuously optimize the operability, the system

performance and the system administration in case of new experiences regarding

the use and new technologies for hardware and software, continuously.

The use of new system components requires a mutual consent.

If the manufacturer changes something in the meters in the field of firmware (within

already existing functions) then the vendor will realize the necessary adjustments for

free.

a) Obligation to adjust the system in case legal requirements are modified - The

vendor commits to execute adjustments when new legal conditions become

valid. The costs will be regulated between the vendor and the IECo by mutual

agreement.

b) Program updates - Updates include the debugging as well as the optimization of

the program for ordered programs and program parts for which a valid

maintenance agreement is existing. Purchased test systems are a part of the total

functionality and will be included in the updates.

Updates for the Systems' standard programs are free within the scope of the

maintenance agreement. In advance, the vendor will inform the IECo in writing

about all changes in the affected program parts.

Improved of optimized programs or program parts are delivered according to the

preferences of IECo on appropriate data carriers or via remote data transmission.

c) System extensions - The vendor commits to further develop the system

according to the market requirements and to inform IECo in writing about the

essential changes or about new system components, and, if necessary, to offer

the corresponding trainings for the innovations.


221


d) Changes in operating systems - The vendor commits to support the latest

operating systems. Adjustments at the IT systems delivered by the vendor which

become necessary are self-financing and covered by the maintenance costs

during the duration of the maintenance agreement.

The released patches of the operating systems can be imported by IECo.

e) Special services on request of IECo - Consulting and individual adjustments of

the software to standard programs are liable to costs. The vendor will prepare a

cost estimate for IECo before the realization.


222


16. TRAINING

The Contractor shall provide a comprehensive training program including a training

program for meters and DCs, and a separate training program for software systems

such as MDM, that prepares IECo's personnel for on-site installation, operation, and

maintenance of the System.

Training may be conducted by the Contractor, the Contractor's subcontractors, third

party software suppliers, and/or original equipment manufacturers (OEMs). The

training requirements of this Contract shall apply to courses taught by

subcontractors, third parties, and OEMs, as well as to courses taught by the

Contractor. The training courses shall be planned and prepared in accordance with

the Specifications and the training timeline will be established according to the

project timeline and the needs for required knowledge of the trainees in order for

them to successfully execute their roles.

Training language shall be Hebrew or English.

16.1. Training Principles

The Proposal shall define training principles such that IECo's personnel shall become

proficient in commissioning, operation and maintenance practices of the System

(both hardware and software). The Proposal shall fully describe the training program

that includes the courses described below. Syllabus of standard courses shall be

attached with the Proposal. "Hands-on" training shall be emphasized.

In addition the contractor shall provide a specific course and material for a “train the

trainer” training.

The Contractor shall prepare training manuals for trainees and for instructors,

training aids and equipment, utilize all of them during training courses and deliver


223


them to IECo prior to the training. The Contractor shall also provide all other

necessary equipment for the adequate conduct of the training courses.

Under this paragraph of his Proposal, the Contractor shall submit his Training Plan

which shall detail all courses, timetables, locations, equipment, etc., and

administrative procedures.

The Contractor shall define in the Training Plan the contents and duration of each

proposed training course.

16.2. General Training Requirements

The Contractor shall provide all facilities, equipment and accessories required for the

proper conduct of the courses:

1) Class Size: The Proposal shall state the Contractor’s recommendation for the

number of participants in each course (except for the seminars). For meters and

DCs training maximum class size shall be 15 trainees.

2) Training Location and Classrooms: The Proposal shall state the Contractor’s

recommendation for the location of each training course (except for the

seminars, database, display, and report training that shall be conducted at IECo's

facilities). IECo's preference is to locate as many courses as possible in Israel

without reducing the quality of the training

3) Training Environment:

a) Training will be conducted in a frozen environment, which shall be a true

reflection of the System and System architecture, and shall use real data. The

training environment will include all the components of the System

b) Training will be both theoretical and hands-on


224


4) Instructors:

a) The principal instructors provided by the Contractor, by the subcontractors,

by third party software suppliers, or by OEMs shall have had previous formal

classroom instructor training, relevant experience with the System hardware

and software, and shall demonstrate a thorough knowledge of the material

covered in the courses.

b) When prerecorded lectures are part of a training course, the lecturer or a

qualified substitute shall supplement the recorded material. All IECo-specific

material shall be presented in person by a qualified instructor.

5) Manuals:

a) The Contractor, subcontractors, third party software suppliers or the OEMs

shall prepare training manuals and submit them to IECo prior to start of

classroom instruction.

b) The training manuals shall be prepared specifically for use as training aids;

Reference manuals, maintenance manuals and user's manuals may be used

as supplementary training material. Principal documents used for training

shall be tailored to reflect all IECo hardware, software and user requirements.

c) Each course participant shall receive individual copies of training manuals and

other pertinent material.

d) Upon completion of each course, instructor's manuals, training manuals and

training aids shall become the property of IECo. The Contractor shall supply

IECo with all the changes and revisions in the training manuals and other

training documentation as part of the delivered system documentation and

the final documentation.

e) Training Manuals may be provided either in Hebrew or in English.


225


f) IECo reserves the right to copy all training manuals and aids for use in IECo-

conducted training courses.

6) Training Tools: The Contractor shall furnish for use during training courses all

special tools, software, training aids, and any other materials required to

adequately train the number of course participants.

7) Training Schedule: The Contractor shall provide training in a timely manner that

is appropriate to the overall project schedule.

8) Supplemental Training: The Contractor shall provide extended, duplicate, or

additional training for the System as deemed necessary by IECo because of:

a. Where there are pre-requisites for participation in training courses (e.g.

knowledge of SQL) contractor shall provide the additional relevant

training prior to commencing core training courses.

b. major modifications to either System hardware or System software,

made after completion of the scheduled training courses, that were

necessary to meet the requirements of this Specification

9) Trainees:

Trainees shall include:

a) Field engineers/technicians, laboratory support engineers/technicians

b) System end-users such as, but not limited to, MDM-operations, HES-

operations, NOC/MOC operations, Smart Meters operations, call center

agents.

c) System development teams such as, but not limited to, developers and

testers


226


d) ICT infrastructure teams such as, but not limited to, communication

technical staff, system administrators, database administrators,

enterprise bus middleware staff and security assurance staff.

e) Internal IECo helpdesk staff.

10) Course Accreditation:

Certificates shall be provided to trainees that have completed/participated in

training courses.

In the case of courses for System operators, there shall be a final examination.

Trainees that pass the final examination shall receive a qualification certificate to this

effect.

16.3. Training for meters and DCs and associated

components

At least 20 days training are required, that shall be provided in two blocks of 10

working days. The first block of 10 working days of training shall occur after

equipment is delivered. The second block of 10 days shall occur at least 3 weeks

after the end of the first block of 10 training days and before installation begins.

Training shall provide at least the following content:

Functional Product Training:

Introduction and basic operation of all Products, Features

Meter/DC Hardware block diagrams and electronics scheme, meters and DC

wiring

Design Reviews


227


Operational training:

Operation of software systems for meters and DCs

Operation of tools for testing PLC communication between meters and DCs in

the field

Training for field technicians in installation of DCs and meters

Hands-on practice sessions for technical laboratory and engineering trainees

16.4. Training for Software systems

Training program shall include courses related to project scope such as in the

following areas:

Management Seminar

End Users and Operators Training

Installation Training: Hardware; Software; Meters; IT personnel

The Contractor shall provide IECo with On the Job Training (OJT) for :

o Handling of NOC/MOC

o Handling of MDM

o Handling of HES

o Handling of deployment tool

16.5. Additional Training and Knowledge Transfer

Training topics include but not limited to:

1) System architecture and flows of data between all the components of the

System.


228


2) Flows of business processes and how they are supported by the System

functionality including screens, reports and interfaces.

3) Flow of system administration and maintenance processes and how they are

supported by the System functionality.

4) System configuration and customization know-how.


229


17. ORGANIZATION AND EXPERIENCE

17.1. Organization

In the following section the Contractor is required to provide proposed organization

chart, provide resumes for key personnel in accordance with the organization chart

such that all key roles are mapped and resumes are provided per each of the roles.

17.1.1. Organization Chart

The Contractor is requested to provide a proposed organization chart describing the

project management team including all potential subcontractors associated with the

implementation of the project. The organization chart should clearly show roles and

names of proposed team and should include team members for all project elements

including the MDM development, communications, Smart Meters, integration

architecture, technology, security and other relevant key-roles.

Figure 17.1 - Contractor's Proposed Project Organization Chart


230


17.1.2. Key Personnel Resumes

In the following sub-section, the Contractor is expected to provide the key personnel

resumes, based on the following table of key project positions. The Contractor is

expected to provide a maximum of 2 possible resumes for each position describing

the following:

Company name

Name

Title

Professional relevant expertise

Relevant previous experience in similar projects throughout the years and time

spent on each assignment

Education

Additional relevant information

Following is a non-exhaustive list of Potential Roles to be included, it is required that

the Contractor provides key roles for all key project functions whether employed by

Contractor or any of the subcontractors as specified in 15.2.26 15.2.6 -

Subcontractors Management including but not limited to: System Integrator, MDM,

AMI Communications, Smart Meters, integration architecture, technology, security

and other primary functional as described in the Organization Chart above.


231


Table 16.1 - List of Potential Roles to be Included

Role Title Key Role Description/Responsibilities

Program Manager

As described in Section 15.2.2 – Program manager

Project Manager As defined in Section 15.2.1 – Project Manager

Solution Architect

Develop the application and technical solution plan, including solution, scope, estimates, contingency, costs, schedule, delivery model, resource/sourcing plan, assumptions, and risks

Software Team Lead

Assist in determining the project approach, staffing, responsibilities, and schedule. Assist in developing and/or reviewing estimates and estimating assumptions for the SW systems 's schedule, effort, and cost using established estimating models, best practices, and benchmarks. The resulting estimates account for all activities in the project scope, including project management and application development tasks, software quality assurance reviews, and vendor and contract management activities.

Meters and DCs Team Lead

Assist in determining the project approach, staffing, responsibilities, and schedule. Assist in developing and/or reviewing estimates and estimating assumptions for the project's schedule, effort, and cost using established estimating models, best practices, and benchmarks. The resulting estimates account for all activities in the project scope.

Software Designer

Assist in defining and reviewing the technical requirements for the application, including security, integration, performance, quality, and operations requirements. Design individual technology components of the application development, execution, or operations architecture. Work with other designers and the technical architect to make sure that the architecture components interact to fulfill the requirements and meet performance goals.

Test Lead Determine all testing environment requirements and tools. Review the development process to ensure that defect tracking Manage testers’ work throughout test plan development and test execution to ensure that testing is on time and within budget.

The list of potential roles to be included is non-exhaustive; the Contractor may

choose to add more role descriptions.


232


17.2. Experience

17.2.1. Contractor Related Credentials

In this section, the Contractor is required to provide credentials of projects with

similar or greater scale and functionality and scope. The credential should be up to 2

pages long and include details on the number of meters installed, the

communication network, the meter data management system, the cyber-security,

the architecture, the integration to enterprise IT and OT systems and timelines. The

credentials should explain if and how the Contractor has implemented:

Remote reading of smart meters (at least 50,000)

Outage management via MDM

Load shedding

Metering of distribution generation devices (e.g. Private photovoltaic generation)

Fraud detections

Consumption analytics

Integration with SAP-ISU

Each credential should be signed by the client of the project described in the

credential and include a client statement of satisfaction. The Contractor should

include for each credential a contact name on the client’s behalf that IECo can

contact for further inquiries. The contact person should be able to communicate in

English or Hebrew.

Each credential should also include the following information:

Country.

Project Start and End date.


233


Project Scope.

Contractors’ Key Role: a description of what are the key activities under the

Contractor/subcontractor responsibilities.

What systems were designed, implemented and tested as part of the

Contractors’ project scope

Overall outcome.

17.2.2. Value Added Initiatives

In this section, the Contractor and all of the subcontractors specified in 15.2.6 -

Subcontractors Management are required to provide information regarding possible

value added initiatives that further enhance the Contractors’ positioning as a leader

in the smart metering vendor or service provider. Such value added initiatives may

include: subject specific labs, R&D centers, innovation centers, strategic alliance with

tier-1 vendors and service providers, knowledge and consultation in matters such as

customers' response to various tariffs and providing data related to lessons learned

all of which are obviously well within Contractor's expertise and experience.

The Contractor shall provide a list of key initiatives in free text, describing the type of

initiative, scope, year started, size of initiative and other relevant information.

17.2.3. Proven Methodology

In this section, the Contractor is required to provide information about

methodology, such that IECo will be capable to evaluate its strengths and alignment

with the proposed project.

The Contractor shall describe the key methodology with which it operates on such

projects, whether it’s a proprietary methodology, number of projects executed

according to this methodology, key aspects, is this methodology being constantly


234


maintained and developed and by what means. Is this methodology specific to a

certain market or industry and in what way?

The contractor may provide additional information regarding its methodologies and

processes as relevant according to this section.

17.2.4. Geographic Alignment

In this section, the Contractor is required to provide information about its

organization and its alignment in order to successfully carry through the proposed

project to completion.

The Contractor is required to provide the following information:

Overall headcount and breakdown according to types of services provided (i.e.

Consulting, Integration Services, Developers, Testing)

Number of employees working exclusively for customers the utility industry and

smart metering specific project

Location of global Headquarters

Regional headquarters location

Breakdown of regions according to which the Contractor operates

Detailed information about the specific region covering the proposed project, its

size of operations, number of employees working within the specific region,

number of employees covering the utilities industry, types of services provided

Number of utility clients serviced globally and in the specific region

The Contractor may provide additional information relating to geographic alignment.


235


18. SOLUTION IMPLEMENTATION PLAN

18.1. General

The following chapter will provide information and requirements for each work package

describing the project based on the timetable and phased approach described in Chapter 1

(Introduction) of the Specification document, as well the functional and technical

requirements of the Specification.

The aim of the work plan is to get a structured baseline for project plan with high level

details from the Contractor in order to better understand the Contractor’s proposed

approach for the IECo project.

In the following chapter, the Contractor is required to provide a work plan based on the

prescribed work packages items and to describe in general each work package contents, key

tasks to be carried out in the specific work package and key deliverables and flag

deliverables that constitute a Payment Milestone


236


18.2. How to Fill the Work Packages Template

The work packages description will include all of the Contractors’ key tasks for each

work packages, the Contractor will specify also tasks to be carried out by potential

sub-contractors such that the work packages will provide a complete overview of the

project plan.

The following comprises the work package template:

Responsibility –

The Contractor shall specify in this field its level of responsibility for the specific work

package, the Contractor should indicate per work package whether it is: Responsible,

Accountable, Consulted or Informed (less likely). In the description field, the

Contractor may further elaborate on its responsibility.

Total Estimated Time Effort –

The Contractor is required to provide high level estimation of the time effort it

expects this work package to undertake.

Brief Description –

A general description of the approach for the specific work package that will include:

Primary purpose of this work package as viewed by the Contractor

Description of inputs to be used

A general description of the work package objective and proposed approach as

the Contractor views it

Description of expected results

The general description shouldn’t be longer than a few paragraphs long.


237


List of Tasks –

The Contractor shall provide a list of key tasks to be carried through in this work

package, the tasks should be definable, quantifiable and concise in order to be able

understand the way in which the Contractor intends to carry through the specific

work package and the project as a whole.

For each task, the Contractor is requested to provide the following information:

1) Task Name –

2) Task Description – Description of content and structure as well as additional

information as the Contractor sees fit.

3) Contractor Expected Effort – a high level description of effort required by the

Contractor (or any of its sub-Contractors) to carry through the specific task. The

effort can be described in number of people and their expertise, i.e. – System

Architect, SW developer, System Analyst and Network specialist for a period of 5

months. Please note, that the purpose of this is to get a better understanding of

the overall project planning and not regarding pricing, thus, it should reflect on

the effort estimated for the specific task

4) IECo Expected Effort – high level description of what effort is required from IECo

by the Contractor to carry through the specific task, i.e. Billing Team 2 week’s

workshop / Detailed Design with communications team. The effort should not

include only time requirements but also tasks as interfaces and other related

collaboration items.

List of Deliverables –

The Contractor shall provide a list of up to 10 key deliverables (not mandatory to fill

all 10) to be achieved within the specific work package, the deliverables should be

concise, exact and descriptive to the specific deliverable.


238


For each deliverable, the Contractor is requested to provide the following

information:

1) Deliverable Name: Deliverable Description – a short and inclusive description of

the deliverable

2) Related Tasks/Deliverables – name the key tasks and deliverables associated with

this deliverable. To further clarify, only tasks/deliverables to be mentioned are

such that contribute or conclude with the deliverable.

3) Notes – 2 types of deliverables should be identified as follows:

a. Key Deliverable (KD) – this will be a key deliverable that marks the end of the

of the specific work package, there could be more than one deliverable

marked as Key Deliverables.

b. Payment Milestone (PM) – there should not be more Payment Milestones

then specified in Annexure C1 – List of Payment Milestones, it is possible that

there are more than one KD in each work package. There should not be more

than one Payment Milestone per single work package.


239


Table 18.1 - work package template

Work Package # – Operate, Maintain & Support

Work Package

WP-# Total Estimated Contractor Time Effort (man months)

Total Estimated IECo Time Effort (man months)

Name: ### - -

Brief Description:

List of Tasks

# Task Name Task Description Contractor Expected Effort

IECo Expected Effort

Task 7.1

Task 7.2

Task 7.3

Task 7.4

Task 7.5

Task 7.6

Task 7.7

Task 7.8

Task 7.9

Task 7.10

List of Deliverables:

# Deliverable Name

Deliverable Description Related Tasks/Deliverables

Notes*

Del. 7.1

Del. 7.2

Del. 7.3

Del. 7.4

Del. 7.5

Del. 7.6

Del. 7.7

Del. 7.8

Del. 7.9

Del. 7.10


240


18.3. Work Packages Description

18.3.1. Project Management

The project management work package shall provide a management plan for all

phases of the project. The description provided by the Contractor shall include all

items related to project management from project initiation, mobilization, planning,

and execution to completion. Examples of aspects expected to be addressed by the

contractor for this work package are:

Planning and mobilization program - Establish project governance to provide

leadership and decision making support for the project, Confirm project scope,

estimate, resources, Develop project work plan, Roll-on resources to teams.

Confirm roles and responsibilities.

Execution planning and management including: governance, scope and

requirements, releases, Project Reviews, work plan and time, performance and

reporting, issues, risks, quality, and stakeholders expectations management

Asset Management – including sub-Contractors, resources, configuration and

work environment management

Value Management – including contract, financials and business case

management

Sign-off and Close project- ensuring all project activities have been completed,

finalize documentation and transfer responsibility to responsible parties,

evaluate overall results and review.

Establish the approach, technique, and tools to enable and support the

requirements traceability throughout the project life cycle.


241


Strategy on how to execute development, transition project deliverables,

conduct testing, etc.

18.3.2. High Level Design

The high level design work package will be done in phase A. The deliverables of this

work package will elicit, document, verify, analyze, prioritize, validate, and baseline

the projects requirements to provide the foundation for installation, design, build,

and test. The PDR (Preliminary Design Review) will be conducted at this stage.

Contractor shall include in the work package description, a detailed list of the items/

processes to be included. Examples of items expected in this stage are:

High level architecture of the System

High level processes to be implemented within the project scope, these will be

based on the information scope and requirements discussed in the requirements

documents of this Specification, the level of details will be as such that it will

enable based on it to develop the detailed technical design.

Design and analysis of users roles and authorizations

Analysis of potential process gaps

Creation of test plan that leverage the requirements to start developing test

conditions

Analysis and definition of project’s metrics

18.3.3. Detailed Design

The detailed design work package deliverables will include all processes and tasks to

transform the functional specifications into applications, technical specifications and


242


well defined architecture to become the blueprint for the build work package. All

detailed design will be performed by contractor together with IECo representatives.

In phase A, Contractor shall provide detailed design for meters, DC, communication

network and phase A SW systems.

In phase B and C, Contractor shall provide detailed design for the SW systems for

each of phase B and C.

Contractor shall include a complete description of task/process to be performed in

this work package. Some examples are:

Design documents for applications such as the MDM, head-ends, MOC, NOC,

deployment tool and other system components

Design workflows

Creation of the technical architecture design to meet quality requirements,

technical constraints, and performance requirements

Detailed hardware specification for MDM, HES, deployment tool and list of 3rd

party licenses

Detailed architecture design for software for DCs/communication components

The Contractor should address the following guidelines for the detailed design work

package:

Design is required to be optimized to meet the performance requirements

Design is required to be flexible to meet all requirements

Design is required to have addressed quality attributes: have the resulting

solution be reusable, efficient, and reliable

Design is required to consider economic factors: can the solution be

implemented on time and within budget based on the current design


243


Design is required to validate proper designs are in place to ensure the

application’s integrity, availability, confidentiality and privacy

The CDR will be conducted at this stage.


244


18.3.4. Implementation

The implementation work package deliverables will include all processes and tasks to

build the proposed solution based on the detailed design documentations and

architecture.

The implementation stages are described in Chapter 1 of this Specification

(Introduction).

Contractor shall include a complete description of task/processes to be performed in

this work package. Some examples are:

Identify and define the builds for each phase

Code and integrate components

Build databases

Install and build all environments

Integrate applications

18.3.5. Testing- Meters, DCs and associated components

The deliverables for the testing meters, DCs and associated components work

package will include all processes, tasks and documentation as specified in the

Chapter 14 and will be carried out during Phase A.

18.3.6. Testing – Software systems and End-to-End Testing

The Testing SW and E2E work package will include all tasks and deliverables as

specified in Chapter14. This detailed work package will be based on test phases:

Factory Acceptance Tests - FAT

Site Acceptance Tests - SAT

User Acceptance Test - UAT


245


Operational Acceptance test - OAT

For each phase the contractor will detail which test types will be performed and in

what methods.

18.3.7. Training and knowledge transfer

The training work package deliverables will include all tasks related to training and

knowledge transfer as specified in Chapter 16. Some examples of tasks to include

are:

Course plan for each component of the System

On-the-job training

Course materials


246


19. SCHEDULE

The Contractor shall provide under this chapter of the Proposal a high level schedule.

Schedule data shall be provided in the form of PERT diagrams and their derivative

GANTT charts.

The GANTT and PERT diagrams shall include high-level steps, critical path that may

influence the final date, period of times for each step and make distinction of

the responsibility for execution of each step.

The Project schedule shall emphasize Program Reviews (PR’s) and Design Reviews

(DR’s). The schedule shall be an integrated schedule comprising Contractor's, sub-

Contractors and IECo's activities, major Project events, payment milestones and

Project phases. The Project schedule shall be representative of the progress and

planned activities throughout the Project. The Contractor shall manage the

integrated project schedule throughout the life of the IECo project.

The Contractor shall maintain the schedule using Microsoft Project. The schedule will

be continuously accessible to IECo's Project Team at all times.

The Contractor shall base his lower tier schedule on inputs received and

coordination performed from / with IECo's Project Team.

The Contractor shall provide for each of the schedule items:

Provide further details for each item;

Assign an appropriate SEQ. No. to each item added as above;

Provide all the required data in all the other table columns for each item

State obligations for delivery dates, if different IECo's schedule or not determined by

IECo, as long as the time schedule for Provisional & Final Acceptance is unchanged.


247


APPENDICES

Appendix A – IT landscape

1. IT Landscape Hardware:

1.1. Application Servers + OS

Windows + >=Win2008 & Win2012

Windows + >=ESX 5.5 (VMware)

Linux + ReadHat

AIX

1.2. Oracle 11+ Data Base Servers

Linux

1.3. MS-SQL 2008/2012 Data Base Server

Windows

1.4. DB2 10.5 Data Base Server

2. Central Storage:

The central storage infrastructure is based on NAS and SAN technologies

The SAN infrastructure is based on high-end EMC(vmax) & Infinibox machine

The NAS infrastructure is based on EMC Isilon & Netapp

3. The end user equipment:

3.1. PC

OS – Win7

3.2. Terminal

Terminal based on Wyse

Terminal connected to Vdi farm


248


3.3. VDI

VDI farm based on Xendesktop Product

3.4. Printer

All printers are PCL3 protocol based

4. Electronic Mail :

Windows Server - Exchange 2010

Client PC – Outlook 2010

Unix Server - SendMail

5. Firewall :

Miscellaneous Checkpoint models

6. Ldap :

MS – Active Directory

7. Proxy:

Websense

8. Web Servers:

Apache

IIS

9. Application Servers:

IBM WebSphere

Windows IIS

10. Development Tools:

10.1. Distributed Environment

Java

Visual Studio/.Net - Version 10/12

11. Standard Environments:

Production


249


Test

Teaching

Development

12. Operational Tools:

12.1. Control

Windows platform - Scom

Non Windows platform - HP-OpenView, centerity , BMC (partial)

12.2. Print Services

Windows Printer Server

12.3. Document Management

Composedoc

12.4. Backup Services

Open System Environment backup system are based on TSM server (IBM)

Windows servers backed up using TSM

Unix servers backed up using TSM

Oracle databases backed up using OBSI Module 2.4 + SQLBACKTRACK 3.3,

Oracle/ rman

MSSQL databases backed up using Litespeed >=v5.2 (quest)

DB2 – Data base backup by using TDP for DB2 (IBM)

Exchange databases backed up using TDP for Exchange (IBM)

13. Report Generation tools:

SAP - Business Objects

SAS/Sigma

MSSQL Reporter

14. Scheduler Tools:

Control-M


250


15. ERP:

SAP –ISU (ECC6 Ehp-7 ) – define as critical system (24/7)

SAP-CRM (4 Ehp-7)

SAP BW 7.4 based on SAP HANA DB

SAP Moduls - , ISU , SAP-CRM, FI,CO,HR,MM,PS,PM,QM,SD,MR,EDM

SAP – DMS (Document Management System, contact server)

SAP Interface - SAP-PI (7.1, 7.4)

The SAP systems operate in segregated / isolated LAN network in 1 G and 10

G band widths.

16. Application Integration:

16.1. Today the integration in IEC is based on IBM Websphere products that

include:

IBM WebSphere MQSeries Family

IBM WebSphere MQSeries 7.5

Message Broker V7 MQSeries

IBM WebSphere DataPower XI52.6.0.1.3

16.2. The architecture used for integration is an EAI approach, established

with HUB & Spoke topology

16.3. The WBI is the central HUB, that is responsible for:

Message Data Transformation (syntax and semantic)

Message Routing

16.4. Each of the corporate systems connects to the ESB messaging bus

through:

Application Adapter (preferred method)

Technical Adapter (using MQ API)

16.5. There are 2 types of interfaces:


251


Request/Reply (used for queries)

Datagram (Fire and Forget used for transactional updates)

16.6. Each message sent by the system is XML based (excluding the MF

applications)

16.7. Each message contains the IEC_HEADER with the following metadata:

<IECHeader>

<IECHeaderVer></IECHeaderVer>

<AppName></AppName>

<ModuleName></ModuleName>

<ServiceName></ServiceName>

<ReturnCode></ReturnCode>

<ErrorMsg></ErrorMsg>

<User></User>

<Password></Password>

<MesgID></MesgID>

</IECHeader>

16.8. The IEC_HEADER meta data is used for the following purposes:

Routing

Authentication

Authorization

Auditing

16.9. The Integration Competence Center Team (ICC) is responsible for:

Integration Architecture design and implementation

Interface design and implementation at central WBI

First level support for developer's

Second level support for operation

Mentoring the interface life cycle in the developers department

17. Data Integration:

DataStage


252


18. Network:

18.1. LAN

The IEC lan based on TCP/IP protocol

The campus network equipment based on star topology and connected

using cables based on 8w (cat6-cat5e) and 4w stp standard

18.2. WAN

The IEC wan based on MESH topology

The IEC campuses connected with optical fiber with 1GBPS throughput

18.3. Routing protocol

OSPF V2

Figure A.1 – General IECo integration guideline


253


Appendix B – Applicable standards

Followed is a list of applicable documents for MDMs, DC, CT and meters.

Table B.1 – Applicable Documents

Document Title / Purpose Document Name #

Electricity metering equipment (a.c.) - General requirements, tests and test conditions - Part 11: Metering equipment

IEC/EN 62052-11 (2003) 1.

Electricity metering equiment (a.c) – Particular requirments – part 21: Static meters for active energy (classes 1 and 2)

IEC/EN 62053-21 2.

Electricity metering equipment (a.c.) - Particular requirements - Part 21: Static meters for active energy (classes 0.2S and 0.5S)

IEC/EN 62053-22 (2003) 3.

Electricity metering equipment (a.c.) – Acceptance inspection - Part 11: General acceptance inspection methods

IEC 62058-11 (2008) 4.

-Electricity metering equipment (a.c.) – Acceptance inspection - Part 31: Particular requirements for static meters for active energy (classes 0,2 S, 0,5 S, 1 and 2).

IEC 62058-31 (2008) 5.

Electricity metering – Data exchange for meter reading, tariff and load control - Part 21: Direct local data exchange

IEC 62056-21 (2002) 6.

Equipment Reliability Testing - Compliance test plans for failure rate and mean time between failures assuming constant failure rate

IEC 60605 (1994) 7.

Dependability management - Part 3: Application guide - Section 2: Collection of dependability data from the field

IEC 60300-3-2 (1993) 8.

Electricity metering equipment - Dependability - Part 21: Collection of meter dependability data from the field

IEC 62059-21 (2002) 9.

Environmental testing IEC 60068 (1988) 10.

Degree of protection provided by enclosures (IP Code) IEC 60695-11-10 (2013)

11.

Electricity metering equipment (a.c.). General requirements, tests and test conditions. Metering equipment (class indexes A, B and C).

EN 50470-1 (2006) 12.

Electricity metering equipment (a.c.). Particular requirements. Static meters for active energy (class indexes A, B and C).

EN 50470-3 (2006) 13.


254


Document Title / Purpose Document Name #

Electromagnetic compatibility (EMC) – Testing and measurement techniques – Power qualitymeasurement methods. That requirement is only RFI and not mandatory

IEC 61000-4-30 14.

Electricity metering equipment (a.c.) – Particular requirements – Power consumption and voltage requirements

IEC 62053-61 15.

Voltage characteristics of electricity supplied by public distribution networks.

CSN EN 50160 ed. 2 16.

Quality Systems-Model for Quality Assurance in Design, Development, Production, Installation and Servicing.

ISO 9001-(2008) 17.

Standard for Software Configuration Management Plans IEEE Std. 828, 1990 18.

Allow application software to exchange information about the configuration and status of an electrical network

IEC 61970 - CIM 19.

Interface Standard for Meter Reading & Control IEC 61968-9 20.

International EDI standard ISO 9735 - EDIFACT 21.


255


Appendix C – TOU special dates & DST dates tables

TOU Table data for the next four years are specified below:

Table C.1 – IECo special days of year 2016


# Holiday Name Day Type Date

1 Pesach

Holiday evening 10/04/2017

2 Holiday 11/04/2017

3 Pesach2


4 Holiday 17/04/2017

5 Atzmaout


6 Holiday 02/05/2017

7 Shavuot


8 Holiday 31/05/2017

9

Rosh-Hashana


10 Holiday 21/09/2017

11 Holiday 22/09/2017

12 Yom-Kippur


13 Holiday 30/09/2017


1 Pesach

Holiday Evening 22/04/2016

2 Holiday 23/04/2016

3 Pesach 2


4 Holiday 29/04/2016

5 Atzmaout


6 Holiday 12/05/2016

7 Shavuot


8 Holiday 12/06/2016

9

Rosh-Hashana


10 Holiday 03/10/2016

11 Holiday 04/10/2016

12 Yom-Kippur


13 Holiday 12/10/2016

14 Sukkoth


15 Holiday 17/10/2016

16 Simchat Torah


17 Holiday 24/10/2016


256


14 Sukkoth


15 Holiday 05/10/2017

16 Simchat Torah


17 Holiday 12/10/2017




1 Pesach


2 Holiday 20/04/2019

3 Pesach2


4 Holiday 26/04/2019

5 Atzmaout


6 Holi0day 09/05/2019

7 Shavuot


8 Holiday 09/06/2019

9

Rosh-Hashana


10 Holiday 30/09/2019

11 Holiday 01/10/2019


1 Pesach


2 Holiday 31/03/2018

3 Pesach2


4 Holiday 06/04/2018

5 Atzmaout


6 Holiday 19/04/2018

7 Shavuot


8 Holiday 20/05/2018

9

Rosh-Hashana


10 Holiday 10/09/2018

11 Holiday 11/09/2018

12 Yom-Kippur


13 Holiday 19/09/2018

14 Sukkoth


15 Holiday 24/09/2018

16 Simchat Torah


17 Holiday 01/10/2018


257


12 Yom-Kippur


13 Holiday 09/10/2019

14 Sukkoth


15 Holiday 14/10/2019

16 Simchat Torah


17 Holiday 21/10/2019

Table C.5 – Day light saving time dates

Year Start Date Start Time End Date End Time

2015 27/03/2015 02:00 25/10/2015 02:00

2016 25/03/2016 02:00 30/10/2016 02:00

2017 24/03/2017 02:00 29/10/2017 02:00

2018 23/03/2018 02:00 28/10/2018 02:00

2019 29/3/2019 02:00 27/10/2019 02:00


258


Appendix D – Requirements regarding the DLMS application layer

and COSEM data model

The Contractor shall create a project specific DLMS COSEM based Companion

Specification for cellular meters and a Companion Specification for PRIME or IDIS-

SFSK based meters, which will specify the communication between meter and Data

Concentrator

• The Companion Specification shall be delivered to IECo. Level of detail to be

delivered similar to the COSEM profile used in T5 specification, IDIS specification

or DSMR P3 for example. At least the following topics shall be covered:

- List of mandatory COSEM Objects and their OBIS Codes and Interface Class.

- Data types of all attributes of the COSEM Objects.

- Access Rights to attributes for the defined clients.

- Selected communication profile.

- Set of selected DLMS Messages and their options.

- Selected Access Security Mechanism (HLS – n)

- Selected Transport security (Security Suite, Encryption and/or

Authentication)

- Load Profile structure and all details (capture objects, capture times)

- Event Log structure and list of event codes and definition of status words.

• Meters that implement the companion specification shall be interchangeable.


259


• The DLMS implementation shall follow the DLMS guideline and no manufacturer,

utility or consortium specific object shall be used when an object is already

defined in DLMS COSEM standard.

• The Contractor shall implement in the meters according to the companion

specification.

• The Companion Specification shall cover all the functionalities requested in this

technical specification.

• The selected OBIS Codes shall be compliant to the Blue Book (DLMS UA 1000-1

Ed. 12.0) as issued by the DLMS UA. Exceptions are allowed only if the contractor

can clearly indicate why an non-compliant OBIS code is included in the

Companion Specification.Additionally for cellular meters the Contractor shall

present DLMS certificate of the conformity of the firmware version delivered in

the sample. Certificate from different firmware versions will not be accepted.

• Additionally for contractors offering an IDIS meters, IDIS certification for IDIS

pack 1 (1D) shall be requested. The M and L as specified in IDIS Pack 1 functional

options are allowed but not requested.

• IECo will have the right to reject the proposed Companion Specification if it does

not follow the above mentioned requirement. IECo may also test the sample

meters to verify that the defined data model is implemented in the meter as

described in the technical specification.

Listed herein all the energy variables required by IECo for implementation of drivers

between meter and IECo applications: (1) between DC and MDM, (2) for portable PC,

(3) between MDM and SAP.


260


The integrator of the system must provide these fields as DLMS/cosem objects or

variables. The preferable format for data transfer is XML. These variables are being

used to implement IECo: report file, load profile file, and event log file.

Table D.1- List of Attributes Required

# IECo Current

Attribute Name

Usage DB Table Name DB Attribute Name

Bill LP Other

1 Meter Name MNM_TECHNICAL METER_NAME

2 Meter serial ALL METER_SERIAL

3 Meter Code ALL METER_CODE

4 Date and time of reading

ALL READING_DATE

5 Current reading date

MNM_BILLING METER_DATE

6 Import total KWH

MNM_BILLING IMP_TOT_KWH

7 Export total KWH

MNM_BILLING EXP_TOT_KWH

8 Import total KvarH

MNM_BILLING IMP_TOT_KVARH

9 Export total KvarH

MNM_BILLING EXP_TOT_KVARH

10 Import total KWH in Rate 1

MNM_BILLING IMP_TOT_KWH_RATE_1

11 Max demand in KWH within a given period in time of Rate 1

MNM_BILLING IMP_KWH_RATE_1_MAX_DMND

12 Cumulative max demand in KWH in time of Rate 1

MNM_BILLING IMP_KWH_RATE_1_CUM_MAX_DMND


261


13 Date and time of Max demand in KWH in time of Rate 1

MNM_BILLING IMP_KWH_RATE_1_MAX_DMND_TS

14 Import total KvarH in Rate 1

MNM_BILLING IMP_TOT_KVARH_RATE_1

15 Max demand in KvarH in a givenperiod in time of Rate 1

MNM_BILLING IMP_KVARH_RATE_1_MAX_DMND

16 Cumulative max demand in KvarH in time of Rate 1

MNM_BILLING IMP_KVARH_RATE_1_CUM_MAX_DMND

17 Date and time of Max demand in KvarH in time of Rate 1

MNM_BILLING IMP_KVARH_RATE_1_MAX_DMND_TS

18 Export total KWH in Rate 1

MNM_BILLING EXP_TOT_KWH_RATE_1

19 Max export of KWH in a given period in time of Rate 1

MNM_BILLING EXP_KWH_RATE_1_MAX_DMND

20 Cumulative max export in KWH in time of Rate 1

MNM_BILLING EXP_KWH_RATE_1_CUM_MAX_DMND

21 Date and time of Max export in KWH in time of Rate 1

MNM_BILLING EXP_KWH_RATE_1_MAX_DMND_TS


262


22 Export total KvarH in Rate 1

MNM_BILLING EXP_TOT_KVARH_RATE_1

23 Max export in KvarH in a given period in time of Rate 1

MNM_BILLING EXP_KVARH_RATE_1_MAX_DMND


MNM_BILLING EXP_KVARH_RATE_1_CUM_MAX_DMND

25 Date and time of Max export in KvarH in time of Rate 1

MNM_BILLING EXP_KVARH_RATE_1_MAX_DMND_TS











31 Max demand in



263


KvarH in a given period in time of Rate 2

















40 Cumulative max demand in KvarH in



264


time of Rate 2













47 Max demand in KvarH in a given period in time of Rate 3




49 Date and time of Max



265


demand in KvarH in time of Rate 3




















266










63 Max demand in KvarH in a given period in time of Rate 4








67 Max export of KWH in a given period in time of



267


Rate 4













74 Historical data for 4 month that includes - same data attributes as for the current reading

MNM_BILLING

75 Current tariff name

MNM_TECHNICAL CURRENT_TARIFF_NAME

76 Current tariff

MNM_TECHNICAL CURRENT_TARIFF_ACTIVATION_DATE


268


activation date

77 Latent tariff name and activation date

MNM_TECHNICAL LATENT_TARIFF_NAME

78 Latent tariff activation date

MNM_TECHNICAL LATENT_TARIFF_ACTIVATION_DATE

79 DST MNM_TECHNICAL DST_CODE

80 Reverse detect

MNM_TECHNICAL REVERSE_DETECT

81 Battery hours

MNM_TECHNICAL BATTERY_USAGE_POWER_FAILURES

82 System flag MNM_BILLING S_FLAG

83 Relays types A, C

MNM_TECHNICAL RELAY_TYPE_A

MNM_TECHNICAL RELAY_TYPE_B

84 Relays types B, D

MNM_TECHNICAL RELAY_TYPE_C

MNM_TECHNICAL RELAY_TYPE_D

85 Pulse weight relay A, C

MNM_TECHNICAL PULSE_WEIGHT_RELAY_A

MNM_TECHNICAL PULSE_WEIGHT_RELAY_B

86 Pulse weight relay B, D

MNM_TECHNICAL PULSE_WEIGHT_RELAY_C

MNM_TECHNICAL PULSE_WEIGHT_RELAY_D

87 Load Profile Flag

MNM_TECHNICAL LOAD_PROFILE_FLAG

88 Period Time MNM_TECHNICAL PERIOD_TIME

89 number of LP channels

MNM_TECHNICAL NUMBER_LP_CHANNELS

90 Number of days held by the meter

MNM_TECHNICAL NUMBER_LP_DAYS_ACCUMULATED

91 Load Profile channel type

MNM_TECHNICAL LP_CHANNEL_1_TYPE




92 Power fail events,

including date, time and Phase should be

repeated up

MNM_EVENTS METER_CODE

MNM_EVENTS METER_SERIAL

MNM_EVENTS EVENT_ID

MNM_EVENTS MAIN_CODE

MNM_EVENTS SUB_CODE

MNM_EVENTS EVENT_DESCRIPTION

MNM_EVENTS LOGGED_TIME


269


to the maximum number of

events that can be stored in the

meter. (currently 20

events)

MNM_EVENTS STORED_TIME

93 Standard or Day Time Saving time

MNM_TECHNICAL DST_INDICATOR

94 I/O Table MNM_TECHNICAL IO_TABLE

95 Gen Table name

MNM_TECHNICAL GEN_TABLE

96 Meter software version

MNM_TECHNICAL SW_VERSION

97 Meter BIOS version

MNM_TECHNICAL BIOS_VERSION

98 Time since battery activated (Hours)

MNM_TECHNICAL BATTERY_TOT_USAGE

99 Auxiliary check meter total kWh

MNM_BILLING AUX_TOT_KWH

100 (Auxiliary check) meter total kWh - phase 1

MNM_BILLING TOT_KWH_PHASE_1





103 Meter number

MNM_LP_HEADER METER_SERIAL

104 Meter code MNM_LP_HEADER METER_CODE

105 Reading date MNM_LP_HEADER READING_DATE

106 Pulse MNM_LP_HEADER PULSE_MULTIPLIER


270


Multiplier

107 Pulse Divider MNM_LP_HEADER PULSE_DIVIDER

108 Recording start date & time

MNM_LP_HEADER REC_START_DATE

109 Recording end date & time

MNM_LP_HEADER REC_END_DATE

110 Number of periods per Hour

MNM_LP_HEADER NUMBER_PERIODS_HOUR

111 Number of Channels

MNM_LP_HEADER NUMBER_CHANNELS

112 Channel number

MNM_LP_HEADER CHANNEL_NUMBER

113 Energy type (channel type)

MNM_LP_DETAILS ENERGY_TYPE

114 number of pulses within measured period

MNM_LP_DETAILS NUMBER_OF_PULSES

115 supply failure within the period

MNM_LP_DETAILS SUPPLY_FAILURE_IN_PERIOD

116 Long supply failure

MNM_LP_DETAILS LONG_SUPPLY_FAILURE

117 Indication for invalid data

MNM_LP_DETAILS INVALID_DATA_INDICATION

118 Date change forward

MNM_LP_DETAILS DATE_CHANGE_FORWARD

119 Date change backward

MNM_LP_DETAILS DATE_CHANGE_BACKWARD

120 Time changed forward

MNM_LP_DETAILS TIME_CHANGED_FORWARD

121 Time changed backwards

MNM_LP_DETAILS TIME_CHANGED_BACKWARDS

122 Phase 1 failure (any

MNM_LP_DETAILS PHASE_1_FAILURE


271


length)

123 Phase 2 failure (any length)


124 Phase 3 failure (any length)


125 Power present

MNM_LP_DETAILS POWER_PRESENT

126 Time or date programmed

MNM_LP_DETAILS TIME_OR_DATE_PROGRAMMED

127 Reverse detect

MNM_LP_DETAILS REVERSE_ENERGY_DETECTED

128 a = EDAM event flag

MNM_LP_DETAILS EDAM_EVENT_1

129 b = EDAM event flag


130 c = EDAM event flag


131 d = EDAM event flag


132 e = clock sync failure

MNM_LP_DETAILS CLOCK_SYNC_FAILURE

133 f = maximum demand

MNM_LP_DETAILS MAXIMUM_DEMAND

134 g = low battery voltage

MNM_LP_DETAILS LOW_BATTERY_VOLTAGE_IND

135 n = level 4 access

MNM_LP_DETAILS LEVEL_4_ACCESS

136 o = level 2 access


137 p = level 1 access



272


Appendix E – Load Profile and Event Log structure

1. Duplicate Data Fields

The load profile buffer shall normally contain no more than one record for each date

and time stamp. Meter shall aggregate several records (energy, status) if exist of

same time stamp to a single reported record. This occurs if for example time change

backward command occurs.

Table E.1 - Load profile Duplicate Data Fields

Reason for duplication Action to be taken

Data collection resumed after an interruption, data sets overlapping

Eliminate duplicate days

Time change (other than a small adjustment)

For each channel, combine days having the same date

If first period is valid and second is invalid (meaning hasn't been stepped over) then

invalid Load Profile period status shall be marked.

In the event of a change in scaling, a new set of data is started (including header

info).

2. DST Offset

In the meter, Load profile is always maintained using base time.

3. Events – log file / events file book

1. The meter shall have a log file / book that cover this topics /events:

a) At least 40 power failures- all phases or separate phase failure (partial)

Note: (Sag / swell events if available shall not recorded in this list).

b) At least 20 communication events such as:

o Meter read


273


o Clock Synchronization.

o Update of meter configuration (e.g. TOU).

2. At least 15 meter HW / SW problems such as:

1) B.I.T failures.

2) Watch – dog event

3) SW crash

4) Magnetic flux (see requirement in 4.7.8)

5) At least 20 measuring events -such as:

a. Reverse phase

b. Reverse current

c. Low power factor

d. Reverse energy flow.

3. Each event shall accompanied with date and time start &stop time stamp

Note: The same event shall be reported once at start stop time /date and

shall not dump the event data memory.

4. Events shall be logged in dedicated event logs.

5. An event code shall be triggered by only one event.

6. Event codes shall have the same meaning (= referring to the same event) in

all System components.


274


Appendix F – Software tools

Contractor shall supply SW application for the purpose of configuring and testing the

meters and DC.

1) The applications shall be available in two format:

a) Local installation in PCs

b) Installation in Server, with remote access from the PCs/Tablets in field.

2) Applications shall run on Windows 7, 64 bits, Entreprise Edition or Server edition

where applicable.

3) The application shall be configured for the following different uses:

a) Laboratory

b) On field in portable PC (local installation in the PCs)

c) On field tablets (remote access)

d) DC configuration (local and remotely)

4) The functionalities available in each profile shall be at least as described in the

table above.


275


Table F.1 - Software operations and required types

# Performed by Activities Author of SW

1

Laboratory Engineer

Desktop or PortablePC

software

a. Generate meter CONFIG files, Perform maintenance, and test TOU/DST validity. Downloading of software, initialization of counters, update data, parameters and passwords etc. b. Meter reading, manual meter time updating. downloading and uploading of data. (For example: day light saving time, new TOU etc.). c. Diagnostics (Local & Remote), self-reads (billing), etc. Determination if Meter is operational or defective

Meter /DC Manufacturer

2

Local version Technician (meter

installer/maintainer With portable PC

a. Meter reading, manual meter time updating. downloading and uploading of data. (For example: day light saving time, new TOU etc.). b. Diagnostics (Local), self-reads (billing), etc. Determination if Meter is operational or defective

Meter/DC Manufacturer

3

Remote metering Communication

One for PLC meters and one for Cellular

a. All the activities of level 2 b. Remote metering and maintenance

Meter/DC Manufacturer

4 Software for

communication to DC

Capable of all features defined for DC


276


Table F.2 - Software to be supplied by manufacturer

SW Name & Description

Applications OS Integrated With IECo

SW

Com port

Computing platform

Optical port

Meters configuration &management

Laboratory software

Create files Needed to CONFIG& OPERATE the meter

Win7

Stand alone

Com 1-4 USB

USB to com / RS-232/ RS-

485

Desk top PC

Portable PC

IECo 1107&port Abacus 1107

portable PC (local = non-remote version of remote

tool) For PLC and cellular

meters

Meter reading & maintenance

Win7

Embedded at IECo applications (MSF –IECo interface SW)[2]

Com USB

Portable pc IECo 1107&port1 Abacus 1107

Remote metering Communication for

cellular meters

Meter reading &maintenance

c2s .s2c

Win 7 for

server

IECo A.M.R

Com232 USB & virtual

Com

PC Server (HES

or else)

-

Software for communicating to DC

Meter/DC reading &maintenance

Win 7 server

- -

PC

portable or desktop

-

[2]Portable PC software is embedded at following IECo applications: (i) meter testing personal Magic software, (ii) TOU (local) IECo test tool, (iii) comparison to master configuration files.


277


Table F.3 - F3 – PC / PC / Lab PC / Server applications

# Function Lab pc Portable Pc – local version

portable pc remote version

software to communicate to dc

1 Read meter billing data(current + billing/ parametric choice)

√ √ √ √

3 Configure meter general definitions √ √ √

√ Including DC

V

4 Configure meter tariff(rate information& special days)

√ √ √ √

5 Configure meter DST dates

√ √ √ √

Including DC

6 Configure meter displays

√ √ √ √

Including DC

7 Change meter passwords

√ √ √ √

Including DC

8 Configure meter interval recording (characteristics/open/close)

√ √ √ √

9 Read profiles (interval recording)

√ √ √ √

10 Read log book& technical data & mains power diagnostics

√ √ √ √

Including DC

11 Read meter configuration files (gen/ TOU / DST /display…)

√ √ √ √

12 Read reverse energy flag status

√ √ √ √

13 Clear reverse flag √ √ √ √

14 Perform billing reset √ √ √ √

15 Read instantaneous (volts ,currents etc.)

√ √ √ √

16 Configure energy LED to kWh or kVAh

√ √ √


278


# Function Lab pc Portable Pc – local version

portable pc remote version

software to communicate to dc

17 Reset battery registers √ √ √

18 Adjust meter to hi res /dial test mode

√ √ √

19 Read High resolution registers

√ √ √

20 Read the active TOU status (1 or 2 or 3, etc.)

√ √ √

21 Generate configure / TOU / DST / IO / displays files

√

22 Remote/local firmware update

V V V V

Including DC

23 Remote/local configuration and time update

V V V V

Including DC


279


Appendix G – 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;


280


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.


281


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:____________________