Annexure B - IECo - Smart - Meter - Project - Specification - 210316 Final PDF

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
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
Israel Electric Corporation 2

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

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

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

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

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

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

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

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.

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)

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

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

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

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 Abbreviation Meaning
Table#
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

Table 2.1 –
Abbreviations Abbreviation Meaning
Table#
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
Machine to Machine – Meters with cellular
26 M2M
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
The CIS – implemented with SAP CRM and SAP-
32 Shoval
ISU
33 OSS Operational Support Systems
34 MF Main Frame
35 "taklot vhafraot" Legacy system for outage management
36 HHU Hand Held Device
System for managing meters operations in the
37 "Paamon"
field
38 "Nakal" System for managing requests for meter reading
OSS Operations support systems
39

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

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


Figure 3.1 – Expected high level architecture
Figure 3.2 – Interface Diagram

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

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

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

 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

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
Communication module
Breaker
# Meter type (embedded extractable or
(Disconnector)
external)
1 Single phase direct with No PLC (either Prime or IDIS S-FSK)
BS 7856:1996 connection
scheme.
2 Single phase direct No Cellular (generation 3G and above)
With BS 7856:1996
connection scheme.
3 Three phase direct No PLC (either Prime or IDIS S-FSK)
With DIN 43857-2
connection scheme.
4 Three phase direct Yes PLC (either Prime or IDIS S-FSK)
With DIN 43857-2
connection scheme.
5 Three phase direct with No Cellular (generation 3G and above)
DIN 43857-2 connection
scheme.
6 Three phase No PLC (either Prime or IDIS S-FSK)
Indirect CT- connected Or cellular (both options are
With DIN 43857-2 acceptable)
connection scheme.

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

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

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

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.

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)

180 mm (between bottom 320 mm (including
Meter 3-ph 140 mm
mounting holes axes) terminal cover)
Meter 1-ph 90 mm (between bottom 180 mm (including 140 mm

mounting holes axes) terminal cover)

Meter CT- 180 mm (between bottom 320 mm (including
140 mm
connected mounting holes axes axes) terminal cover)
** 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.

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.

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.

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

 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

Note: If the suspension clip is not of slide-on type it must be supplied to the
purchaser in extended position.

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.

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

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:
Eabsolute ,total  E1  E2  E3
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.
Ei  Erate1  Erate 2  Erate 3  Erate 4

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.

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.

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
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
2 IDIS S-FSK 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.

 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

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:

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.

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

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.

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!)

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

4.3. General Technical Features
Table 4.6 – Electric parameters specification
Reference Basic Maximum

Connection Reference
Meter type Voltage Current Current Accuracy
type frequency
(Un) (In) (Imax)
Class 1 - IEC
Direct
Static Single 10 A or 62053-21
connection 230 V >=60 A 50 Hz
phase kWH 5A Class B - EN
2 wire
50470-3
Class 1 - IEC
Direct
Static Poly 3x230/400 3x10A 62053-21
connection >=3x80 A 50 Hz
phase kWh V or 3x5A Class B - EN
4 wires
50470-3
CT connected Active: Class 1
4 wire. - IEC 62053-21
Multiplicatio Reactive: Class
Static Poly-
n factor 1 - IEC62053-
phase Static
100/5 3x230/400 24
kWh/kVar 3x5A >=3x6A 50 Hz
Primary side V Class 2 -
with current
energy is to IEC62053-23
transformer
be registered with tightened
and to 1%
displayed. calibration

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
(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

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

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
(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

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
Objective Communication module

With/without
# Meter type (embedded extractable or
breaker
external)
1 Three phase w/o Consumer > 100A PLC (either Prime or IDIS S-FSK)
Indirect CT- Or RS-485 (both options are

connected acceptable)
2 Three phase w/o Adjacent to DC cellular
Indirect CT-
connected
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.

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

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

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

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 Load profiles columns and

Registers
(direct/CT) capture period
Profile type 1:
Clock
Active Energy Import Active Energy Import
Direct Active energy Export Active energy Export
AMR profile status
Default - 45 days, 2 chanels,
15 Minutes
Profile type 2:
Clock
Active Energy Import
Active Energy Import
Active energy Export
CT Active energy Export
Reactive energy import
Reactive energy import
Reactive energy export
Reactive energy export
AMR profile status

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.

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

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

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.

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.

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

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

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.

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
Number of
# Feature Latency
retries
1 Local meter reading of 2 months of Load Profile 4 20 mins
data
2 Local firmware update 2 10 mins
3 Remote cellular meter reading of 2 months of 4 30 mins
Load Profile data
4 Remote update of firmware for cellular meters 2 1 hour
5 Remote reading of PLC meter via DC – 2 4 40 mins
months of Load Profile data
6 Remote firmware update of PLC meter via DC 4 1 hour
7 Remote reading of cellular meters Load Profile 2 5 mins
data for single day
8 Remote reading of PLC meters via DC – Load 4 15 mins
Profile data for single day
4.10. Software Tools

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

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.

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

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.

5.4.10 Extended current ratings: 1.2 In.
5.4.11 Instrument security factor: FS10 or less.

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

 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

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

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

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

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

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:

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

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

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

total and these components values as predicted and verified
(tested) will be reflected at MTTF state.

4) The historical RAM field data of proposed meters/DC, for all installed meters/DC
(identical to the ones proposed), at all sites, supplied during the last 5 years. The
RAM report should include specific model type, and years of the collected data.
5) Reliability prediction report according to IEC 62059-41.
6) Information about RAM activities and optimization in the manufacturing plants

concerning the proposed meters/DC including:
a) Criticality (long supply time, high price, short life length, high failure rate,
single supply source, sensitive or vulnerable materials, etc.
b) Latent failure rate (  ), and induced failure rate (caused by human).
c) Turn Around Time (door to door).
d) Quantity in service.
e) Recommended “probability of no shortage” (spares availability) on shelf.
f) Cost
The Bidder shall state the rationales for his above-mentioned declarations
(usage/tests/analysis/estimation).
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).

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.

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

 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:

8.2. Business processes
Table 8.1 - MDMs process by phases
# process Phase Details in process number

1 Install meter A 8.2.1 – install meter
2 Manually install meter A 8.2.1 – install meter
3 Remove meter B 8.2.2 - remove meter
4 Manually remove meter A 8.2.2 - remove meter
5 Meter replacement B 8.2.3 – meter replacement
8.2.4 – disconnect / connect
6 Remotely disconnect meter / load -limiting C
meter
7 Manually disconnect meter / load-limiting A
meter
8 Remotely connect meter B
meter
9 Manually connect meter A
meter
10 Update master data A 8.2.5 - Update master data
8.2.6 - Provide insight to
11 Provide insight to customer B
customer
8.2.6 - Provide insight to
12 Provide insight to customer – near time C
customer
8.2.7 - Meter data
13 Meter data validation (VEE) A
validation
Meter data acquisition 8.2.8 - Meter data
14 A
acquisition
15 Meter to Bill B 8.2.9 - Meter to bill
16 Triggering Bill Correction B 8.2.9 - Meter to bill
17 Billing on demand B 8.2.9 - Meter to bill
18 Creating a new billing timeslice B 8.2.9 - Meter to bill
8.2.10 - on-demand
19 On-demand reading A
reading
On –demand reading via SAP ISU/CRM or 8.2.10 - on-demand
20 B
other reading
8.2.11 - Managing virtual /
21 Managing virtual / calculated channels B
calculated channels
22 Contractual load shedding - Voluntary load B 8.2.12 - Contractual load

# process Phase Details in process number

shedding shedding
Contractual load shedding - incentive 8.2.12 - Contractual load
23 C
scheme shedding
8.2.13 - Load balancing /
Transformer metering / load (Energy)
24 C Transformer energy
Balancing
balancing
25 Handling notification C 8.2.14 – handle notification
26 Events log handling A 8.2.15 – Handling log
Manage meter configuration – tables / 8.2.16- Manage meter
27 B
firmware configuration
8.2.17- System time
28 System time synchronization A
synchronization
8.2.18 - Operational
29 Operational reports A
reports
30 Fault Managment A 8.2.19 – Fault Managment
8.2.20– Data Concentrator
31 Data concentrators management A
Management
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.

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.

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

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.

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

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:

 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:

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

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

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:
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

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

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:

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:

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

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

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

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.

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

The MDM must allow at least basic viewing,
User interface
8.3.1 editing and input of all MDM data. Enable A
mast be friendly
access via user interface.
For example:
The MDM must enable access to all data for Information for
8.3.2 A
other applications via API Customers of
private producers
For example:
Basic reporting and analysis must be available replicate could be
on all MDMS data in such way that it does not to have a separate
8.3.3 A
compromise the performance of operations Data Warehouse
of normal MDM tasks for reporting and
analytics
The MDM shall support different types of
meters: industrial (CT,CT/VT), residential,
sub-meters (register the relation between a
8.3.4 A
main meter, and a sub-meter),
check/reference, energy balancing,
communication
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
8.3.5 certain date, and aggregate all relevant A
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)
MDM must keep versions of all meter data in
8.3.6 A
case of a change


System data
Support lean data objects of CIS data in MDM
8.3.7 A
(customer/ premises / contract)
Register asset information regarding the
meter and its installation (e.g. meter type,
meter location, outage detection capability,
8.3.8 A
tamper detection capability,
connect/disconnect capability, capacity
reduction capability, installation date & time )
Support service address for one or multiple
meters (sub-meters; apartments and
8.3.9 A
“commons” meters) and logical relation
between meters
The MDM shall be able to import, process
and make available for export the predefined
8.3.10 A
set of attributes as mentioned in meter
chapter and DC chapter
The MDM shall store and enable display of
raw and calculated data (e.g. multiply by
8.3.11 A
transformer factor). It shall be possible to
view LP data split by TOU where applicable.
Configuration
Provide an ability to configure VEE functions;
including rules that determine what level of
8.3.12 A
VEE can happen automatically, and what
requires manual intervention
Have the ability to define a new formula for
8.3.13
validation rules
Have the ability to define a new routine for
8.3.14
editing or estimation
Have pre-defined validation rules that can be
8.3.15 A
adjusted using parameters
Have the ability to turn on and off the VEE
8.3.16 A
rules
Configure estimation routines for a specific
8.3.17 A
group of meters / accounts
Have the ability to apply automatic editing
8.3.18 A
based on the values of the check meter.


8.3.19 Have the ability to prioritize VEE rules A
Configure thresholds or boundaries for
estimation on specific accounts by
8.3.20 A
meter/customer, group, tariff/rate, or energy
provider
Configure customizable summarization and
billing rules (e.g., maintain TOU schedules per
8.3.21 A
customer segment, geography, etc.; maintain
holidays)
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
Interface to the CIS system to
import all relevant consumer and
technical data so all the data in the
8.4.1 A
MDM data will be synchronised in
cases that data updating is not part
of the natural process
Meter data acquisition
Interface with and obtain all meter
data from multiple head ends, at
8.4.2 A
least daily acquisition. (LP, TOU &
technical)
Scheduling can be configurable In specific cases it will be
8.4.3 B needed more often than
once a day
Provide interface for manual meter It shall be possible to
8.4.4 A
reads and indicate as manual read register the data via GUI and


a backend transaction
Be able to interface with specific interface with working
8.4.5 C
AMR head ends enterprise AMR e.g. - ITF
Install meter
Support online end-to-end check
8.4.6 during new meter device A
installations
8.4.7 Automatically install meter A
8.4.8 Manually install meter A
remove meter
Automatically remove meter
8.4.9 The MDM is required to support B
disassembly cases of a meter
8.4.10 Manually remove meter A
Meter replacement B
Implement meter replacement
8.4.11 business process by calling meter B
removal and install meter BP.
In case customer has not changed
8.4.12 there should be continuity of meter B
readings for the POD.
disconnect / connect meter
8.4.13 Automatically Disconnect meter C
Manually disconnect meter / load
8.4.14 A
limiting
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
Provide the ability to interface with
a web portal. The interaction will
8.4.18 show customer consumption data, B
historical data and analytical data
regarding consumption
Consumption Data published on the
8.4.19 internet shall not be older than 24 B
hours
8.4.20 Provide insight to customer – near C A few hundreds customers


time Near time ~ 1 hr.
Metering – meter data validation
(VEE)
Perform VEE as part of the Meter to
Bill process & Provide pre-built and
configurable VEE functions for
8.4.21 meter data usage. Apply different A
VEE rules for different customer
segments.
Automatically propose replacement

interval data through estimation
8.4.22 (e.g., in case of missing data), but A
with an indication that it is a
replacement
Make available tampering and
outage information in the VEE
8.4.23 process A
Perform VEE on DG sub-meter data.
keep log files for later investigation
Estimate according to different
techniques, including linear
8.4.24 A
interpolation, historical averages,
using previous day
Support manual user editing of In any case of manual data
data, including copying, deleting; editing, the original data will
through user screens, and while be saved in the system
8.4.25 A
keeping an audit trail of changes along with the new data
Support automatic editing by using (modified) & an indication
values of the check meter about the editing action
Store validated meter data in
8.4.26 A
versions
The VEE processes must be
8.4.27 configurable to comply with Israel B
regulations.
Billing
Summarize and store interval data
8.4.28 A
into billing determinants (e.g., time


of use buckets) when required to do
so by the SAP_ISU system
Generate all necessary output for According to process table
8.4.29 A
the billing system X
Allow Tariff schemes to be updated
through user screens (if not ready
8.4.30 from an automated SAP interface, A
taking into account start/end dates
of TOU schemes (Timeslicing)
8.4.31 Triggering Bill Correction B
8.4.32 Billing on demand B
8.4.33 Creating a new billing time slice B
Support billing cycle triggered by
8.4.34 B
SAP Billing system
on-demand reading
8.4.35 Manual on-demand reading A
Support on demand punctual
Time frame- 3 minutes
8.4.36 meter reading request for meter B
(doing customer call)
data (near real time for call centre)
Managing virtual / calculated
channels
Store master data regarding (type,
8.4.37 A
size, etc)
Able to process, import, exportdata
of vitrula / calculated channels in all
8.4.38 B
relevant processes, such as VEE and
billing preparation aggregation
Perform VEE on virtual / calculated
8.4.39 A
channels
Define specific VEE rules, e.g.,
Support calcluations
8.4.40 Export cannot be larger than B
between diffrent chanels
Generation
Automatically assign relevant (e.g.,
premise, customer, transformer )
8.4.41 B
characteristics from main meter to
check meter
Generate reports and/or provide
8.4.42 A
user screens that show reporting


results ; frequency can be
configurable
Contractual load shedding
Register which premises have been
8.4.43 B
signed up for this program
Business rule: Customer
notifications need to
Send messages to customer about
8.4.44 B happen at least X hours
load shedding events via CIS
before the event; X – TBD.
Register general requests for

8.4.45 demand reduction “load shedding B
event”
Aggregate load shedding relevant
8.4.46 B
consumption data for billing
Allow customers to overrule a
8.4.47 request for load shedding, and keep C
track of such overruling
Generate reports about load
shedding events, based on i.e.,
8.4.48 B
premises signed up , measured
consumption
Transformer metering / load
(Energy) Balancing
Support first level transformer: screen for assigning meters
register father-son link between to transformer for PLC and
8.4.49 B
meter and transformer outputs cellular communication
meter
Read and treat smart meters and
8.4.50 A
their meter data in transformers
Provide Operations metering data
8.4.51 C
aggregation reports
Compare the sum of consumptions
at Home level (PLC, cellular meters),
for one specific transformer, with
8.4.52 C
the metered value at the
transformer. Identify deviations
that are not justified by technical


losses alone.
Hold connected transformer data
8.4.53 C
for each meter
Provide overview (report) of
unjustifiable deviations. The report
8.4.54 C
shall reflect power losses and
possible thefts.
Handle notification
Receive and store notifications from
depends on meter
8.4.55 the smart meters (via the head C
functionality
ends)
Rule based forwarding / routing of
E.g. TAKALOT VHAFRA'OT
8.4.56 notifications to enterprise systems C
(OMS)
in near real time.
Handling log events / alarms
Register various types of events as
* Depends on functionality
8.4.57 detected by the meter and the DC A
of meters and DC in Project
and communicated by the head end
There shall be a logging of all events
8.4.58 A
in the MDM for analysis/reporting
Provide reports and extracts on all
8.4.59 A
events information
Manage meter configuration –
B
tables / firmware
Track and manage meter
configuration tables (e.g. TOU, The process relevant to this
8.4.60 special days, passwords) and B data will be considered in
firmware versions held in each the detailed design phase
meter.
Operational reports A
Implement at least the operational
8.4.61 reports as listed in 3.2.18 -
Operational reports
Provide a tool for dynamic
8.4.62 A
reporting
Reports production shall not
8.4.63 interfere with the system ongoing A
performance


Reports shall enable invoking
8.4.64 processes based on the query A
results
Data Warehouse
Enable production of managerial
8.4.65 reports and enable business A
intelligence
reflect the MDM entities and
maintain a frequent updating
8.4.66 regime, at least once a day, to allow A
for up-to-date analysis of the
accumulated meter reading data
8.4.67 Enable import of external entities B
Provide interfaces to other IECo
8.4.68 B
systems
Enable utilization of standard BI
8.4.69 B
tools on the warehouse data
System time synchronization A
maintain time synchronization, i.e.
all the relevant components shall
8.4.70 periodically engage with an SNTP A
server to ensure its system time is
accurate
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
Updating firmware across several
8.4.75 A
DCs
Changing DC processes (e.g.
8.4.76 changing LP interval from 15 to 5 A
minutes)
8.4.77 Viewing topology A
Removal of meters from DC's meter
8.4.78 A
list e.g. in case of remove meter
8.4.79 Password management A


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

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

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:
Table 8.4 – Interface Requirements
General guidelines A
8.5.1 Use of web-services and / or MQ A
The bidder has to provide WSDL files and test data for
8.5.2 A
the WS it publishes
IECo will provide WSDL files and test data for the WS it
8.5.3 A
publishes
Interfaces will utilize a secured protocol (HTTPS) in
8.5.4 A
accordance with IECo information security guidelines.
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
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
8.5.11
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

UseCase7: External Profile Calculation

UseCase8: Event Management
UseCase9: Text Messaging to AMI Device
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
8.5.12 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
It is expected that the MDM will be able to support
import and export of data via file, e.g. initial import of
8.5.13
migration data, importing readout files from other AMR
systems or HHU.
OMS
Implement interface to propagate outage and power
8.5.14
quality events to OMS
Fraud management
Implement interface to propagate fraud events to fraud
8.5.15
management system

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:

Table 9.1 – Head End Requirements
ID Requirement Stage Remarks

Perform acquisition of meter
9.1.1 data across the A
communication infrastructure
The HES shall encapsulate the
data when communication with
upstream systems (MDM)
Provide the MDM with unified
ensuring that messages have
9.1.2 data regardless of meter type A
the same format regardless of
and communication channels
how the data was transmitted
to the HES by the meters and/or
DC
HES shall have a GUI to
support management and
9.1.3 A
viewing on the status of the
system
9.1.4 HES shall be scalable A
Ability to install MDMs at
HES shall support efficient separate application server and
9.1.5 metering infrastructure A database server. MDMs shall
management enable installation at two
separate servers.
Interface between HES and DC
The Vendor shall provide
should be based upon open
9.1.6 A detailed specification of this
solution i.e. web services with
interface to IECo
XML format exchange

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

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

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:

10.3.3. MOC Functional Requirements
Table 10.1 – MOC Functional Requirements

The MOC must be able to support meter In accordance with
diagnostics functionality relevant diagnostics
10.3.1 A
provided by the
meter
The MOC must be able to support meter
10.3.2 A
configuration update functionality
10.3.3 A
firmware update functionality
10.3.4 A
connect/disconnect functionality
The MOC must be able to support
10.3.5 A
Tampering detection
The MOC must be able to validate a meter’s Preform ping & BIT
10.3.6 A
availability and functionality within 1 minute
must be able to interface to NOC and be
able to send and receive messages
10.3.7 A
including: network availability, network
performance and other messages
must be able to interface to MDM and be
10.3.8 A
able to send and receive messages
must be able to interface to other enterprise
systems and be able to send and receive
10.3.9 A
messages, e.g. interface to ISU to open a
service request for meter replacement
must support the relevant security Based on detailed
10.3.10 requirements and protocols as mandated by A security plan to be
IECo designed
must be able to log events for auditing and
10.3.11 A
management purposes
10.3.12 must be able to generate reports A
Preform analytics on meters performance
10.3.13 A
and failures
10.3.14 Have a managerial dashboard A

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:

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

 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

Provide Network Management e.g. diagnostics, remote
10.4.1 A 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
Provide communication Software
10.4.5 A
management
Be able to interface with all network
10.4.6 A
layers
log events for auditing and
10.4.7 A
management purposes
10.4.8 generate reports A
interface with the MDM system to
10.4.9 A
send and receive messages
The NOC must support the relevant
10.4.10 security requirements and protocols A
as mandated by IECo
be able to manage and support
10.4.11 balancing of the communications A
network load

be able to support communications

10.4.12 A
network congestion management
NOC shall be able to validate a
10.4.13 meter’s availability within 5 seconds A
– cellular communication
NOC shall be able to validate a
10.4.14 meter's availability - meter via PLC + A
concentrator
NOC will be able to validate network
10.4.15 availability for all AMI network layers A
components within 5 seconds.

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

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

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

Table 11.1 – Deployment solution Functional Requirements

Creating and managing database of all
11.4.1 A
relevant premises for the Project
Keeping the
Build all necessary "lean" entities needed
11.4.2 A entities updating
for managing and daily inspection of rollout
with CIS (SAP)
GIS infrastructure for participant population
11.4.3 A
relevant permises
Building and managing all relevant
11.4.4 resources including HR, vehicles and, and A
other equipment
11.4.5 work standards and validation protocols A
Planning work routes, work crews and
11.4.6 A
issuing of work equipment and meters
Could be done via
11.4.7 Creating and managing work orders A
SAP-ISU
Reporting task status e.g. completion, on
11.4.8 A
hold, etc.
11.4.9 Producing reports (daily, weekly etc.) A
Updating progress to the CIS systems
11.4.10 A
routinely
Interfaces to other enterprise system
11.4.11 A
according to IECo standards
Enable task completion validation by e.g.
11.4.12 triggering meter reading or by refreshing A
DC meter list.
Provide feedback upon task completion
(installation, field work) to relevant
11.4.13 A
systems, e.g. (IP, transformer details, GPS
coordinates, repeater)
be strongly interfaced with the SAP-ISU and
11.4.14 A
SAP-CRM / MDM

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:

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:

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:

 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.
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:
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:

Table 12.1 – Software system general Requirements

General
The SW systems in this project would be
obligated to confirm with IECo standards
12.9.1 and technical guidelines as detailed in A
appendix A- IT landscape and appendix
B - applicable standards.
The solution will ensure full integration
between the different modules of the
12.9.2 A
MDMs system. Data will be accessible
across the modules
The solution shall include a scheduler
12.9.3 A
module
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
12.9.4 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
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
12.9.5 requirement. A
It should cover the following domains –
Redundancy (hardware & software)
Monitoring
KPIs settings e.g. MTBF, MTTR
In service software upgrade
12.9.6 The system shall be online and available A

99.0% of the time in phase A and 99.5%

in phase B.
Disaster Recovery
The system will support fail over to back
12.9.7 A
up site
12.9.8 RTO = 30 minutes to two hours A
12.9.9 RPO = 0 A
Maintainability
The system must be able to deal with
12.9.10 weekly regular maintenance activities in A
less than 4 hours per week
Performance
Support X IEC customer service
12.9.11 representatives accessing the system A X=40
simultaneously
Store and manage data of X POD’s (
12.9.12 A X~Y ~ 70,000-163,000
Point of Delivery ) and Y meters
Schedule automated reads per meter
12.9.13 A
every day
Import, validate and store all data from
meters, including – load profile, billing,
events and technical. For ~ 70k-163 k X = 2 hours
12.9.14 B
meters at least once a day in X hours
70k-163 k meters * 3 channels (250 data
fields)
Provide usage data for creation of X X ~ 2000-5000
12.9.15 bills/statements per day B Assuming monthly bills
are spread over 5 day
Respond to Billing system requests for
X = 1 day
12.9.16 billing input information within X time B
(optional working method)
Respond to meter reads on-demand X = 3 minutes from the
request within X time meter
From CRM /MDM / MOC Total response time
12.9.17 B
including AMI shall be
no longer than from
CRM
receive in MDM and dispatch to OMS X = shall be near real
12.9.18 C
an outage notifications within X seconds time
scalability

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?
12.9.19  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
User screens shall include links to
12.9.20 A
support guides
The system shall provide user friendly
12.9.21 A
navigation
The system shall provide automatic
12.9.22 A
refresh of screens
12.9.23 Single user sign on A
Hebrew language support – for
Hebrew GUI is not
12.9.24 predefine fields, Database and screens A
required
display and input
Security
The solution must comply with IEC obligated to confirm
Information Security Policies and with with IECo security
12.9.25 A
Israeli legislation and regulations requirements as
detailed in chapter 13
The solution must comply with IEC and
12.9.26 Israeli data protection legislation and A
regulation
Audit trail
Logging of all modifications to MDM
12.9.27 A
data, who did it, and when
12.9.28 Authorizations A
Provide administrator screens to assigns
12.9.29 A
user profiles to users: viewing, entering,

changing.
All users must log in to the system using
12.9.30 A
a user name and password.
Configuration management
The vendor is expected to detail the
methodology, procedures and tolls it
12.9.31 plans to utilize for configuration A
management and system installation
management.
Hardware environment specifications
The vendor shall list the environmental
parameters that are required for reliable
operation of the System, e.g. physical
12.9.32 A
space, ambient conditions
(temperature, humidity), power
requirements, etc.
Interfaces requirements
Provide a platform to create new
12.9.33 A
interfaces
Support multiple standards for
outbound interface (i.e., not locked into
12.9.34 A
a predefined set of outbound interfaces,
but rather have configurability)
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,

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

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.

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.

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.

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.

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

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

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.

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

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.

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

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.

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.

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

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

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.

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.

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;

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

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.

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.

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

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.

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

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.

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.

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.

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.

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:

UP Time
A =
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

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

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

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.

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

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.

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

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.

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.

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.

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.

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.

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

• 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

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
…

Table 15.5 - Data Management Procedures
Data Management
# Description
Procedures
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.

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

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.
The Contractor is required to fill in the following table listing all risks that will be
managed by the Contractor during the project.

Table 15.7 - Risk Management Table
Level of Area of Alternative

# Category Description of Risk
Impact Impact 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 Key Phasing

# Hardware Software
Name Characteristics Procedures
1
2
3
…

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.

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,
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
Cardboard Hood Polyethylene Hood

1050 -100
KM KM
150 -10
110 +10
100 -10 250 ±20 150 -10

800 -40 1200 -200

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

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

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

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.

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.

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

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
Critical Functions or equipment non-operational or unusable.
Severity 1 – Critical
Critical or material impact to the normal operations.
Critical Functions operational but without redundancy, and
Severity 2 – High
there are no possible circumventing actions.
Functions are operational but with limited functionality. There
Severity 3 – Medium are no possible circumventing actions to prevent impacts to
normal operation.
Functions are operational but there are some identified
Severity 4 – Low 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.

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)

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 Maximum Maximum

Category Response Solution Guidelines
Level time time

Variance Maximum Maximum

Category Response Solution Guidelines
Level time time
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.
Critical 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.
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.
High
After this period the Contractor shall assign dedicated
resources until the problem is fixed or a workaround
implemented.
A schedule for the correction of medium priority
variances shall be informed within twenty-four (24)
Medium hours and it shall be fixed or a schedule for correction
presented to IECo for approval within five (5) working
days.
The schedule for correction of all low variances shall be
replied within two working days and it shall be fixed or
Low
a schedule for correction presented to IECo for
approval.

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.

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.

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

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

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.

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

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

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.

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.

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

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.

Table 16.1 - List of Potential Roles to be Included
Role Title Key Role Description/Responsibilities

Program As described in Section 15.2.2 – Program manager
Manager
Project ManagerAs defined in Section 15.2.1 – Project Manager
Solution Develop the application and technical solution plan, including
Architect solution, scope, estimates, contingency, costs, schedule,
delivery model, resource/sourcing plan, assumptions, and risks
Software Team Assist in determining the project approach, staffing,
Lead 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 Assist in determining the project approach, staffing,
Team Lead 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 Assist in defining and reviewing the technical requirements for
Designer 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.
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.

 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

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.

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

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.

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.

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.

Table 18.1 - work package template
Work Package # – Operate, Maintain & Support

Work Total Estimated Contractor Total Estimated IECo Time
WP-#
Package Time Effort (man months) Effort (man months)
Name: ### - -
Brief Description:
List of Tasks
Contractor IECo
# Task Name Task Description Expected Expected
Effort 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:
Related
Deliverable
# Deliverable Description Tasks/Deliver Notes*
Name
ables
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

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.

 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

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

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

 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

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.

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

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

 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

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:

 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

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

Appendix B – Applicable standards
Followed is a list of applicable documents for MDMs, DC, CT and meters.
Table B.1 – Applicable Documents
# Document Name Document Title / Purpose

Electricity metering equipment (a.c.) - General
1. IEC/EN 62052-11 (2003) requirements, tests and test conditions - Part 11: Metering
equipment
Electricity metering equiment (a.c) – Particular
2. IEC/EN 62053-21 requirments – part 21: Static meters for active energy
(classes 1 and 2)
Electricity metering equipment (a.c.) - Particular
3. IEC/EN 62053-22 (2003) requirements - Part 21: Static meters for active energy
(classes 0.2S and 0.5S)
Electricity metering equipment (a.c.) – Acceptance
4. IEC 62058-11 (2008) inspection - Part 11: General acceptance inspection
methods
-Electricity metering equipment (a.c.) – Acceptance
5. IEC 62058-31 (2008) inspection - Part 31: Particular requirements for static
meters for active energy (classes 0,2 S, 0,5 S, 1 and 2).
Electricity metering – Data exchange for meter reading,
6. IEC 62056-21 (2002)
tariff and load control - Part 21: Direct local data exchange
Equipment Reliability Testing - Compliance test plans for
7. IEC 60605 (1994) failure rate and mean time between failures assuming
constant failure rate
Dependability management - Part 3: Application guide -
8. IEC 60300-3-2 (1993)
Section 2: Collection of dependability data from the field
Electricity metering equipment - Dependability - Part 21:
9. IEC 62059-21 (2002)
Collection of meter dependability data from the field
10. IEC 60068 (1988) Environmental testing
11. Degree of protection provided by enclosures (IP Code)

IEC 60695-11-10 (2013)
Electricity metering equipment (a.c.). General
12. EN 50470-1 (2006) requirements, tests and test conditions. Metering
equipment (class indexes A, B and C).
Electricity metering equipment (a.c.). Particular
13. EN 50470-3 (2006) requirements. Static meters for active energy (class
indexes A, B and C).

# Document Name Document Title / Purpose

Electromagnetic compatibility (EMC) – Testing and
14. IEC 61000-4-30 measurement techniques – Power qualitymeasurement
methods. That requirement is only RFI and not mandatory
Electricity metering equipment (a.c.) – Particular
15. IEC 62053-61 requirements – Power consumption and voltage
requirements
Voltage characteristics of electricity supplied by public
16. CSN EN 50160 ed. 2
distribution networks.
Quality Systems-Model for Quality Assurance in Design,
17. ISO 9001-(2008)
Development, Production, Installation and Servicing.
18. IEEE Std. 828, 1990 Standard for Software Configuration Management Plans
Allow application software to exchange information about
19. IEC 61970 - CIM
the configuration and status of an electrical network
20. IEC 61968-9 Interface Standard for Meter Reading & Control
21. ISO 9735 - EDIFACT International EDI standard

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 Holiday Evening 22/04/2016
Pesach
2 Holiday 23/04/2016
Pesach 2
4 Holiday 29/04/2016
Atzmaout
6 Holiday 12/05/2016
Shavuot
8 Holiday 12/06/2016
10 Rosh-Hashana Holiday 03/10/2016
11 Holiday 04/10/2016
Yom-Kippur
13 Holiday 12/10/2016
Sukkoth
15 Holiday 17/10/2016
Simchat Torah
17 Holiday 24/10/2016

1 Holiday evening 10/04/2017
Pesach
2 Holiday 11/04/2017
Pesach2
4 Holiday 17/04/2017
Atzmaout
6 Holiday 02/05/2017
Shavuot
8 Holiday 31/05/2017
11 Holiday 22/09/2017
Yom-Kippur
13 Holiday 30/09/2017


Sukkoth
15 Holiday 05/10/2017
Simchat Torah
17 Holiday 12/10/2017

Pesach
2 Holiday 31/03/2018
Pesach2
4 Holiday 06/04/2018
Atzmaout
6 Holiday 19/04/2018
Shavuot
8 Holiday 20/05/2018
11 Holiday 11/09/2018
Yom-Kippur
13 Holiday 19/09/2018
Sukkoth
15 Holiday 24/09/2018
Simchat Torah
17 Holiday 01/10/2018

Pesach
2 Holiday 20/04/2019
Pesach2
4 Holiday 26/04/2019
Atzmaout
6 Holi0day 09/05/2019
Shavuot
8 Holiday 09/06/2019
11 Holiday 01/10/2019


Yom-Kippur
13 Holiday 09/10/2019
Sukkoth
15 Holiday 14/10/2019
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

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.

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

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 Usage

# Attribute DB Table Name DB Attribute Name
Bill LP Other
Name
1 Meter Name    MNM_TECHNICAL METER_NAME
2 Meter serial    ALL METER_SERIAL
3 Meter Code    ALL METER_CODE
4 Date and    ALL READING_DATE
time of
reading
5 Current    MNM_BILLING METER_DATE
reading date
6 Import total    MNM_BILLING IMP_TOT_KWH
KWH
7 Export total    MNM_BILLING EXP_TOT_KWH
KWH
8 Import total    MNM_BILLING IMP_TOT_KVARH
KvarH
9 Export total    MNM_BILLING EXP_TOT_KVARH
KvarH
10 Import total    MNM_BILLING IMP_TOT_KWH_RATE_1
KWH in Rate
1
11 Max    MNM_BILLING IMP_KWH_RATE_1_MAX_DMND
demand in
KWH within
a given
period in
time of Rate
1
12 Cumulative    MNM_BILLING IMP_KWH_RATE_1_CUM_MAX_DMND
max demand
in KWH in
time of Rate
1

13 Date and    MNM_BILLING IMP_KWH_RATE_1_MAX_DMND_TS

time of Max
demand in
KWH in time
of Rate 1
14 Import total    MNM_BILLING IMP_TOT_KVARH_RATE_1
KvarH in
Rate 1
15 Max    MNM_BILLING IMP_KVARH_RATE_1_MAX_DMND
demand in
KvarH in a
givenperiod
in time of
Rate 1
16 Cumulative    MNM_BILLING IMP_KVARH_RATE_1_CUM_MAX_DMND
max demand
in KvarH in
time of Rate
1
17 Date and    MNM_BILLING IMP_KVARH_RATE_1_MAX_DMND_TS
time of Max
demand in
KvarH in
time of Rate
1
18 Export total    MNM_BILLING EXP_TOT_KWH_RATE_1
KWH in Rate
1
19 Max export    MNM_BILLING EXP_KWH_RATE_1_MAX_DMND
of KWH in a
given period
in time of
Rate 1
20 Cumulative    MNM_BILLING EXP_KWH_RATE_1_CUM_MAX_DMND
max export
in KWH in
time of Rate
1
21 Date and    MNM_BILLING EXP_KWH_RATE_1_MAX_DMND_TS
time of Max
export in
KWH in time
of Rate 1

22 Export total    MNM_BILLING EXP_TOT_KVARH_RATE_1

KvarH in
Rate 1
23 Max export    MNM_BILLING EXP_KVARH_RATE_1_MAX_DMND
in KvarH in a
given period
in time of
Rate 1
24 Cumulative    MNM_BILLING EXP_KVARH_RATE_1_CUM_MAX_DMND
max demand
in KvarH in
time of Rate
1
25 Date and    MNM_BILLING EXP_KVARH_RATE_1_MAX_DMND_TS
time of Max
export in
KvarH in
time of Rate
1
KWH in Rate
2
demand in
KWH within
a given
period in
time of Rate
2
max demand
in KWH in
time of Rate
2
time of Max
demand in
KWH in time
of Rate 2
KvarH in
Rate 2
demand in

KvarH in a
given period
in time of
Rate 2
max demand
in KvarH in
time of Rate
2
time of Max
demand in
KvarH in
time of Rate
2
KWH in Rate
2
of KWH in a
given period
in time of
Rate 2
max export
in KWH in
time of Rate
2
time of Max
export in
KWH in time
of Rate 2
KvarH in
Rate 2
in KvarH in a
given period
in time of
Rate 2
max demand
in KvarH in

time of Rate
2
time of Max
export in
KvarH in
time of Rate
2
KWH in Rate
3
demand in
KWH within
a given
period in
time of Rate
3
max demand
in KWH in
time of Rate
3
time of Max
demand in
KWH in time
of Rate 3
KvarH in
Rate 3
demand in
KvarH in a
given period
in time of
Rate 3
max demand
in KvarH in
time of Rate
3
time of Max

demand in
KvarH in
time of Rate
3
KWH in Rate
3
of KWH in a
given period
in time of
Rate 3
max export
in KWH in
time of Rate
3
time of Max
export in
KWH in time
of Rate 3
KvarH in
Rate 3
in KvarH in a
given period
in time of
Rate 3
max demand
in KvarH in
time of Rate
3
time of Max
export in
KvarH in
time of Rate
3
58 Import total    MNM_BILLING IMP_TOT_KWH_RATE_4
KWH in Rate
4

59 Max    MNM_BILLING IMP_KWH_RATE_4_MAX_DMND

demand in
KWH within
a given
period in
time of Rate
4
60 Cumulative    MNM_BILLING IMP_KWH_RATE_4_CUM_MAX_DMND
max demand
in KWH in
time of Rate
4
time of Max
demand in
KWH in time
of Rate 4
KvarH in
Rate 4
demand in
KvarH in a
given period
in time of
Rate 4
max demand
in KvarH in
time of Rate
4
time of Max
demand in
KvarH in
time of Rate
4
66 Export total    MNM_BILLING EXP_TOT_KWH_RATE_4
KWH in Rate
4
of KWH in a
given period
in time of

Rate 4

max export
in KWH in
time of Rate
4
time of Max
export in
KWH in time
of Rate 4
KvarH in
Rate 4
in KvarH in a
given period
in time of
Rate 4
max demand
in KvarH in
time of Rate
4
time of Max
export in
KvarH in
time of Rate
4
74 Historical    MNM_BILLING
data for 4
month that
includes -
same data
attributes as
for the
current
reading
75 Current    MNM_TECHNICAL CURRENT_TARIFF_NAME
tariff name
76 Current    MNM_TECHNICAL CURRENT_TARIFF_ACTIVATION_DATE
tariff

activation
date
77 Latent tariff    MNM_TECHNICAL LATENT_TARIFF_NAME
name and
activation
date
78 Latent tariff    MNM_TECHNICAL LATENT_TARIFF_ACTIVATION_DATE
activation
date
79 DST    MNM_TECHNICAL DST_CODE
80 Reverse    MNM_TECHNICAL REVERSE_DETECT
detect
81 Battery    MNM_TECHNICAL BATTERY_USAGE_POWER_FAILURES
hours
82 System flag    MNM_BILLING S_FLAG
83 Relays types    MNM_TECHNICAL RELAY_TYPE_A
A, C MNM_TECHNICAL RELAY_TYPE_B
84 Relays types    MNM_TECHNICAL RELAY_TYPE_C
B, D MNM_TECHNICAL RELAY_TYPE_D
85 Pulse weight    MNM_TECHNICAL PULSE_WEIGHT_RELAY_A
relay A, C MNM_TECHNICAL PULSE_WEIGHT_RELAY_B
86 Pulse weight    MNM_TECHNICAL PULSE_WEIGHT_RELAY_C
relay B, D MNM_TECHNICAL PULSE_WEIGHT_RELAY_D
87 Load Profile    MNM_TECHNICAL LOAD_PROFILE_FLAG
Flag
88 Period Time    MNM_TECHNICAL PERIOD_TIME
89 number of    MNM_TECHNICAL NUMBER_LP_CHANNELS
LP channels
90 Number of    MNM_TECHNICAL NUMBER_LP_DAYS_ACCUMULATED
days held by
the meter
91 Load Profile    MNM_TECHNICAL LP_CHANNEL_1_TYPE
channel type MNM_TECHNICAL LP_CHANNEL_2_TYPE
MNM_TECHNICAL LP_CHANNEL_3_TYPE
MNM_TECHNICAL LP_CHANNEL_4_TYPE
92 Power fail    MNM_EVENTS METER_CODE
events, MNM_EVENTS METER_SERIAL
including MNM_EVENTS EVENT_ID
date, time MNM_EVENTS MAIN_CODE
and Phase MNM_EVENTS SUB_CODE
should be MNM_EVENTS EVENT_DESCRIPTION
repeated up MNM_EVENTS LOGGED_TIME

to the MNM_EVENTS STORED_TIME

maximum
number of
events
that can be
stored in the
meter.
(currently 20
events)
93 Standard or    MNM_TECHNICAL DST_INDICATOR
Day Time
Saving time
94 I/O Table    MNM_TECHNICAL IO_TABLE
95 Gen Table    MNM_TECHNICAL GEN_TABLE
name
96 Meter    MNM_TECHNICAL SW_VERSION
software
version
97 Meter BIOS    MNM_TECHNICAL BIOS_VERSION
version
98 Time since    MNM_TECHNICAL BATTERY_TOT_USAGE
battery
activated
(Hours)
99 Auxiliary    MNM_BILLING AUX_TOT_KWH
check meter
total kWh
100 (Auxiliary    MNM_BILLING TOT_KWH_PHASE_1
check) meter
total kWh -
phase 1
check) meter
total kWh -
phase 2
check) meter
total kWh -
phase 3
103 Meter    MNM_LP_HEADER METER_SERIAL
number
104 Meter code    MNM_LP_HEADER METER_CODE
105 Reading date    MNM_LP_HEADER READING_DATE
106 Pulse    MNM_LP_HEADER PULSE_MULTIPLIER

Multiplier
107 Pulse Divider    MNM_LP_HEADER PULSE_DIVIDER
108 Recording    MNM_LP_HEADER REC_START_DATE
start date &
time
109 Recording    MNM_LP_HEADER REC_END_DATE
end date &
time
110 Number of    MNM_LP_HEADER NUMBER_PERIODS_HOUR
periods per
Hour
111 Number of    MNM_LP_HEADER NUMBER_CHANNELS
Channels
112 Channel    MNM_LP_HEADER CHANNEL_NUMBER
number
113 Energy type    MNM_LP_DETAILS ENERGY_TYPE
(channel
type)
114 number of    MNM_LP_DETAILS NUMBER_OF_PULSES
pulses
within
measured
period
115 supply    MNM_LP_DETAILS SUPPLY_FAILURE_IN_PERIOD
failure
within the
period
116 Long supply    MNM_LP_DETAILS LONG_SUPPLY_FAILURE
failure
117 Indication    MNM_LP_DETAILS INVALID_DATA_INDICATION
for invalid
data
118 Date change    MNM_LP_DETAILS DATE_CHANGE_FORWARD
forward
119 Date change    MNM_LP_DETAILS DATE_CHANGE_BACKWARD
backward
120 Time    MNM_LP_DETAILS TIME_CHANGED_FORWARD
changed
forward
121 Time    MNM_LP_DETAILS TIME_CHANGED_BACKWARDS
changed
backwards
122 Phase 1    MNM_LP_DETAILS PHASE_1_FAILURE
failure (any

length)
failure (any
length)
failure (any
length)
125 Power    MNM_LP_DETAILS POWER_PRESENT
present
126 Time or date    MNM_LP_DETAILS TIME_OR_DATE_PROGRAMMED
programmed
127 Reverse    MNM_LP_DETAILS REVERSE_ENERGY_DETECTED
detect
128 a = EDAM    MNM_LP_DETAILS EDAM_EVENT_1
event flag
129 b = EDAM    MNM_LP_DETAILS EDAM_EVENT_2
event flag
130 c = EDAM    MNM_LP_DETAILS EDAM_EVENT_3
event flag
131 d = EDAM    MNM_LP_DETAILS EDAM_EVENT_4
event flag
132 e = clock    MNM_LP_DETAILS CLOCK_SYNC_FAILURE
sync failure
133 f = maximum    MNM_LP_DETAILS MAXIMUM_DEMAND
demand
134 g = low    MNM_LP_DETAILS LOW_BATTERY_VOLTAGE_IND
battery
voltage
135 n = level 4    MNM_LP_DETAILS LEVEL_4_ACCESS
access
136 o = level 2    MNM_LP_DETAILS LEVEL_2_ACCESS
access
137 p = level 1    MNM_LP_DETAILS LEVEL_1_ACCESS
access

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 Eliminate duplicate days
an interruption, data sets
overlapping
Time change (other than a For each channel, combine
small adjustment) 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

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.

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.

Table F.1 - Software operations and required types
# Performed by Activities Author of SW

a. Generate meter CONFIG files, Meter /DC
Perform maintenance, and test Manufacturer
TOU/DST validity. Downloading of
software, initialization of counters,
Laboratory update data, parameters and passwords
Engineer etc.
1 Desktop or b. Meter reading, manual meter
PortablePC time updating. downloading and
software 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
a. Meter reading, manual meter Meter/DC
Local version time updating. downloading and Manufacturer
Technician (meter uploading of data. (For example: day
installer/maintainer light saving time, new TOU etc.).
2
With portable PC b. Diagnostics (Local), self-reads
(billing), etc. Determination if Meter is
operational or defective
Remote metering a. All the activities of level 2 Meter/DC

Communication b. Remote metering and Manufacturer
3
One for PLC meters maintenance
and one for Cellular
Software for Capable of all features defined for DC
4 communication to
DC

Table F.2 - Software to be supplied by manufacturer
Integrated
SW Name & Com Computing
Applications OS With IECo Optical port
Description port platform
SW
Create files Com 1-4
Meters configuration Needed to USB Desk
IECo 1107&port
&management CONFIG& Win7 USB to com top PC
Stand alone Abacus 1107
Laboratory software OPERATE / RS-232/ RS- Portable PC
the meter 485
portable PC Embedded
(local = non-remote at IECo
version of remote Meter reading applications Com IECo 1107&port1
Win7 Portable pc
tool) & maintenance (MSF –IECo USB Abacus 1107
For PLC and cellular interface
meters SW)[2]
PC
Remote metering Meter reading Win 7 Com232
IECo Server (HES
Communication for &maintenance for USB & virtual -
A.M.R or else)
cellular meters c2s .s2c server Com
PC
Software for Meter/DC reading Win 7
- - portable or -
communicating to DC &maintenance server
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.
Table F.3 - F3 – PC / PC / Lab PC / Server applications
Portable portable pc
software to
# Function Lab pc Pc – local remote
communicate to dc
version version
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/cl
ose)
9 Read profiles (interval
√ √ √ √
recording)
10 Read log book&
√
technical data & mains √ √ √
Including DC
power diagnostics
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
Portable portable pc
software to
# Function Lab pc Pc – local remote
communicate to dc
version version
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 V
V V V
update Including DC
23 Remote/local
V
configuration and time V V V
Including DC
update

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;

6. Our Proposal shall be binding upon us in accordance with the terms and
conditions set out in the Tender Documents.
7. The Meter (and SW ) that is proposed in this tender is Off the Shelf Products and
complying with the requirements defined below:
7.1. Is completely defined (design, construction and performance) by a formal

technical specification.
7.2. Is manufactured in accordance with formal production drawings, processes

and procedures which govern all stages and aspects of the manufacturing
process.
7.3. Have successfully passed all qualification tests and the environmental tests
in particular.
7.4. Is manufactured with strict adherence to the prescribed quality assurance

procedures, which have to include in-process inspection procedures.
7.5. "Similar" meter type in accordance with IEC 62052-11, section 3.1.8.2, is
currently manufactured with at least 400 units installed/at electrical power
utilities at the last two years and the accumulated operational data proves
high reliability indicating the Product is mature.
7.6. Is regularly checked for reliability by field data collection, collation and
corrective action taken when needed.
7.7. Is accompanied by a complete set of manufacturing drawings and

procedures, reliability prediction, user manuals and maintenance manuals.

Bidder's Information
Bidder’s Full Name:
Bidder’s Address
Street:
City State / Province Zip/Postal Code
Country
Bidder's Contact Information
Telephones:
Fax:
e-mail:
Signature ____________________ Date:____________________

Annexure B - IECo - Smart - Meter - Project - Specification - 210316 Final PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Annexure B - IECo - Smart - Meter - Project - Specification - 210316 Final PDF

Uploaded by

Copyright:

Available Formats

ISRAEL ELECTRIC CORPORATION (IECo)

Status: Final Draft edition

2. Definitions and Abbreviations ________________________________________ 15

Israel Electric Corporation 2

4.9. Performance Characteristics ______________________________ 69

5. Instrument Current Transformers ____________________________________ 70

6. Data Concentrator ________________________________________________ 75

7. Meters and DCs RAM requirements ___________________________________ 87

8. Meter Data management (MDM) ____________________________________ 91

9. Head End System ________________________________________________ 130

Israel Electric Corporation 3

10.4. NOC - Network Operations Center ________________________ 136

11. Deployment Tool ________________________________________________ 140

12. Software systems general Requirements _____________________________ 144

13. Information security (IS) requirements _______________________________ 153

14. Quality Assurance and Testing _____________________________________ 158

15. Project Management and Governance _______________________________ 190

Israel Electric Corporation 4

15.2. Project Management ________________________________________ 190

16. Training _____________________________________________________ 222

17. Organization and Experience _______________________________________ 229

18. Solution Implementation Plan ______________________________________ 235

19. Schedule _____________________________________________________ 246

Israel Electric Corporation 5

Israel Electric Corporation 6

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

Israel Electric Corporation 7

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

Israel Electric Corporation 8

1.1. Smart Metering In IECo

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

1.2. Tariff Trial

1.3. Structure of the document

1.4. How to reply to this document

1.4.1. General instructions

1) The proposal will be submitted in English.

Israel Electric Corporation 10

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

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

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

Israel Electric Corporation 11

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.

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

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

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

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

Israel Electric Corporation 12

6) Bidder Response – Bidder clarification where applicable.

1.5. Phases of Project

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

Israel Electric Corporation 13

Figure 1.1 – Project time line

Israel Electric Corporation 14

Figure 1.2 – Implementation phases of Project

1.6. Meters and DCs installation

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

2. DEFINITIONS AND ABBREVIATIONS