Rec Power Development and Consultancy Limited (Recpdcl)

INVITATION OF EXPRESSION OF INTEREST (EoI) FOR EMPANELMENT OF
METER DATA MANAGEMENT SYSTEM (MDMS) PROVIDER and SYSTEM

INTEGRATION SERVICES FOR ADVANCE METERING INFRASTRUCTURE (AMI)
PREPAID SOLUTION
REC POWER DEVELOPMENT AND CONSULTANCY LIMITED (RECPDCL)
EOI NO: RECPDCL/SM/2024-25/004
DATED: 04 June 2024
Tentative Dates
Sr. No. Particular Date
1 Issuance of EOI 04.06.2024
2 Pre-Bid Meeting 07.06.2024
3 Receipt of Clarification from Bidders to RECPDCL 10.06.2024
4 Reply to Clarification by RECPDCL 12.06.2024
5 Last Date of Bid Submission 18.06.2024
1|Page
DISCLAIMER
This EOI Document is issued by the REC Power Development & Consultancy Ltd. (Company), for general
information purposes only, without regard to specific suitability, financial situations and needs of any particular
person and does not constitute any recommendation and should not be construed as an offer to sell or
solicitationof an offer to buy, purchase or subscribe to any securities and engagement of business activities but is
merely an invitation of offer from interested parties for the purpose of undertaking Smart Metering Projects.
Neither, this EOI Document nor anything contained herein shall form the basis of or be relied upon in
connection with any contract orcommitment whatsoever from the Company.
This EOI Document constitutes no form of commitment on the part of the Company or any of their group
companies. Furthermore, this EOI Document confers neither the right nor expectation on any interested parties
to be selected to participate in the Bid Process and nothing in this EOI Document or subsequent submission of
EOI Document by a Bidder constitutes a contract between the Company or any other entityand the interested
parties.
The Company reserve the right to accept or reject any EOI. The Company also reserve the right to suspendand/
or cancel the Bid process and/ or amend and/ or supplement the Bid Process or modify the dates or other terms
and conditions relating thereto, without assigning any reason and without any liability whatsoever. Bidders
should regularly visit Company’s website to keep themselves updated regarding clarifications/ amendments/
time-extensions, if any. No financial obligation will accrue to the Company in such an event. The Court of Law
at New Delhi shall have jurisdiction over this EOI.
The Company shall not be responsible for non-receipt of correspondence sent by any Bidder through any mode.
The Company shall in no circumstances, be responsible to bear or reimburse any expenditure or costs incurred
by any Bidder in respect of the submission of the EOI. This EOI Document and information contained herein
or any part of it does not constitute or purport to constitute investment advice in publiclyaccessible media and
should not be printed, reproduced, transmitted, sold, distributed, or published by therecipient without the prior
written approval from the Company.
Distributing/taking/sending/dispatching/transmitting this EOI Document in certain foreign jurisdictions
other than Republic of India may be restricted by law, and persons into whose possession this EOI Document
comes should inform themselves about, and observe, any such restrictions. Neither the Company or their
affiliates, nor their directors, employees, agents or representatives shall be liable for any damages whether direct
or indirect, incidental, special or consequential including lost revenue or lost profits that may arise from or in
connection with the use of this EOI Document. Further, no representation or warranty, expressed or implied,
is made or given by or on behalf of the Company or its affiliates, nor any person who controls it or any
director, officer, employee, advisor or agent of it, or affiliate of any such person or such persons as to the
accuracy, authenticity, completeness or fairness of the information contained in this EOI Document and
Company or their affiliates or such persons do not accept any responsibility or liability for any such information
and therefore, any liability or responsibility is expressly disclaimed.
2|Page
CONTENTS
1. INTRODUCTION .......................................................................................... 4
2. BRIEF ABOUT EOI......................................................................................... 5
3. DEFINITIONS ................................................................................................. 5
4. QUALIFICATION REQUIREMENT .............................................................. 5
5. SCOPE OF WORK .......................................................................................... 8
1. Overview of the MDM Provider and System Integrator Scope of Work: ................ 8
1.1 Introduction: ............................................................................................ 8
1.2 Brief Scope of Work:................................................................................. 9
2. Supply, installation, integration, testing and commissioning of: ............................. 9
2.1 Meter Data Management (MDM) System ............................................... 10
2.2 Utility Interface and Consumer Portal and App: ...................................... 25
2.3 Network Operation & Monitoring Centre ................................................ 28
2.4 System Software Requirements ............................................................... 32
3. AMI System Integrations ........................................................................ 50
4. Consumer Indexing and Meter Installation Application ........................... 51
5. Analytics and Reports ............................................................................. 55
6. Operation and Maintenance .................................................................................. 60
6.1 Scope and Period .................................................................................... 60
6.2 Empaneled Agency Responsibilities under Operation & Maintenance
Services: 61
6.3 Maintenance Practices: ........................................................................... 61
6.4 Monitoring ............................................................................................. 62
7. Training Requirements ......................................................................................... 63
7.1 Training Categories ................................................................................ 63
7.2 Training modules.................................................................................... 63
7.3 Training Schedules ................................................................................. 64
7.4 General Requirements ............................................................................ 65
8. Test, Inspections and Management of the Quality Assurance / Quality Control Program
65
8.1 Responsibility of Tests and Inspection ..................................................... 65
8.2 Field Installation and Integration Test (FIIT)........................................... 66
8.3 Tests on receipt of complaint by consumer .............................................. 67
8.4 Site Acceptance Test (SAT)..................................................................... 67
8.5 System Availability Test ......................................................................... 70
3|Page
8.6 Operational Go Live of the AMI System: ................................................ 71
8.6.1 Conditions to be Met for Operational Go Live for the AMI system (based on
MDM and System Integrator’s deliverable in the project) ........................................ 71
9. Manpower Requirements (Per 10 Lakhs of the Project Size.).................................... 72
9.1 During Implementation Phase (till the period of Installation milestone of the
AMI project at hand): ................................................................................................ 72
9.2 During O&M Phase (till the period of O&M of the AMI project at hand): 73
6. TERMS OF CONTRACT ............................................................................. 75
Annexure A – Covering Letter .............................................................................. 77
Annexure B – Draft Format for Request for Quotation ....................................... 81
Annexure C – Record of Similar Work Done .......................................................... 82
Annexure D – Consortium Agreement .................................................................... 83
Annexure E – SLA penalties .................................................................................... 87
Annexure F - Conditions/protocols for auto-disconnections ....................................... 93
Annexure G - System Sizing Requirement.................................................................. 94
Annexure H - Future Demand Response Program Use Cases for Reference ................ 95
Form 22: Manufacturer Authorization Form (MAF) .............................................. 98
Form 23: Format of Agreement to be entered by sub-contractors with the sole bidder
/ lead member of a Bidding Consortium ................................................................100
1. INTRODUCTION
REC Power Development and Consultancy Limited (RECPDCL), is a wholly owned
subsidiary of REC Limited, a "Maharatna" Enterprise under the Ministry of Power,
Government of India. The existing services offered by RECPDCL include coordination of bid
processes for Inter-State and Intra-State transmission projects, coordination of bid processes
for flexibility in generation schemes, engagement as Project Implementation Agency (PIA)
for Smart Metering projects, PIA services for Distribution Infrastructure projects, Project
Management Consultancy (PMC) for various Government of India Schemes such as RDSS,
DDUGJY, IPDS, and Saubhagya.
4|Page
2. BRIEF ABOUT EOI
RECPDCL aims to expand its service offering in the Smart Meter implementation works as
an Advanced Metering Infrastructure Service Provider (AMISP). In this regard, RECPDCL
intends to empanel reputed Service Providers for supply and services of Meter Data
Management System (MDMS) Provider and System Integration.
3. DEFINITIONS
• Bidder: A Meter Data Management System Service Provider and System Integrator provider
who shall offer its supply and services in response to this EOI.
• Due Date: shall have the meaning Last date of Bid submission.
• AMI: Advance Metering Infrastructure
• Utility/DISCOM: Shall mean the Distribution company in whose license area the Smart
Meters are being installed.
• Empaneled Agencies (EA)– Bidders who have successfully demonstrated integration
of their MDM with HES systems offered by RECPDCL under this EOI.
• The AMI Project Area: The AMI project area shall be defined by RECPDCL on case-to-case
basis for tender/project at hand
4. QUALIFICATION REQUIREMENT
1. The Bid can be submitted by a Sole Bidder as an individual entity or a Consortium of
firms/companies (specific requirements for Consortium are given under Clause 4 below)
who is eligible to participate in tenders for public procurement in India in accordance with
Applicable Laws including the guidelines issued in Order No. F/No.6/18/2019-PPD by
Ministry of Finance, Department of Expenditure, Public Procurement Division dated 23
July 2020, Order No No.9/16/2016-Trans-Part (2) dated 18 November 2020, latest
Government of India Guidelines for Make in India, Domestically manufactured products,
Atmanirbhar Bharat and circulars DIPP Office Memorandum No. P-45021/2/2017-PP
(BE-II) date: 16th Sept. 2020, MeitY Circular No.1(10)/2017-CLES dated 06.12.2019 and
Order No. 11/05/2018-Coord. by the Ministry of Power dated 17 September 2020
including any amendments or modifications to the same from time to time.
2. If at any stage of the empanelment, any order/ ruling is found to have been passed in the
last 1 (one) year preceding the Bid submission deadline by a competent Court of Law or
any appropriate Commission or any Arbitral Tribunal against the Sole Bidder for breach
of any Contract awarded by any Government agency/department, then Bids from such
Bidders shall be liable to be rejected. All Bidders shall confirm in accordance to Form 7
given in Section 4 that no such order(s)/ ruling(s) have been passed by a competent Court
of Law or an appropriate Commission against it or its Affiliates. In case of any such order/
ruling, it is the duty of the Bidder to inform Utility for the same during the Bid submission.
3. Technically qualified Bidders shall continue to maintain compliance with the Eligibility
and Qualification Requirements specified herein during the term of empanelment. Failure
to comply with the aforesaid requirements shall make the Bid from such Bidders liable for
rejection at any stage of the empanelment process or after empanelment.
4. Eligibility Requirements for Consortium
5|Page
4.1 Members of the Consortium shall enter into a binding Consortium Agreement, in the form
specified at Annexure-D (the “Consortium Agreement”) of EOI Document, for the
purpose of submitting Bid. The Consortium Agreement, to be submitted along with the
Bid, shall, inter alia:
(a) convey the intent to comply with the terms and conditions of the Empanelled
Agencies Contract in the event selected to undertake the Project; and
(b) Clearly outline the proposed roles and responsibilities, if any, of each member.
4.2 The Lead Bidder / Sole Bidder shall have a registered office (under the Companies Act
1956/ 2013 with Registrar of Companies) in India at the time of submission of the Bid. In
case of Award of Contract, other Consortium Members shall be required to have a
registered office (under the Companies Act 1956/ 2013 with Registrar of Companies) in
India.
4.3 Every Consortium Member shall provide consent to the Lead Consortium Member and
make itself aware of all the proceedings of the bidding process and Project implementation
through legally enforceable Consortium Agreement as per Annexure D, power of
attorneys, legal undertakings, etc. (if applicable) entered amongst all members of that
Bidding Consortium including but not limited to those as prescribed in Form 8, Form 9
and Form 11 given in Section 4 of SBD v4 issued by REC Ltd. In the absence of duly
executed formats, the Bid shall not be considered for evaluation and shall be rejected.
4.4 The Lead Consortium Member shall be liable for the execution of the entire obligation in
the Empanelled Agency Contract in accordance with the terms and conditions thereof.
Only the Lead Consortium Member shall have the authority to conduct all businesses for
and on behalf of the Consortium during the empanelment process.
5. The Bidder, participating in the bid as a Sole Bidder or as a Consortium Member or as
Lead Consortium Member of Consortium and its Sub-Contractor(s) should not be
blacklisted /debarred/banned/suspended as on date of bid submission:
a. due to conviction of an offence
i. Under the Prevention of Corruption Act, 1988; or,
ii. the Indian Panel Code or any other law for the time being in force, for
causing any loss of life or property or causing threat to public health as
part of execution of a public procurement contract
b. through any order /list issued by Department of Expenditure (DoE), Ministry of
Finance (MoF)
c. due to breach of code of integrity as per rule 17 of GFRs 2017 in any government
organisation or regulatory agencies or Govt. undertaking.
d. By any Ministry/Department/Organisation under Govt. of India
This clause shall be interpreted in-line with Rule 151 of GFRs, 2017 along with any
guidelines/amendment issued by DoE, MoF
Bidder should submit a self-undertaking signed by its authorized signatories for the same as
per the format prescribed in Annexure-A
6. The Empanelled Bidder(s) will be required to continue to maintain compliance with the
Qualification Requirements throughout the empanelment process and during the
empanelment period till execution of the Contract. Failure to comply with the aforesaid
provisions shall make the Bid liable for rejection at any stage.
6|Page
7. The technical and financial requirements of qualification are as follows:
S. No. Requirements Supporting Documents
Financial Requirements
The Bidder shall have positive net

worth for each of the last three
financial years.
[Net Worth means sum total of the Audited Annual financial statements, Balance
paid up capital and free reserves Sheet and P&L Account for the respective
1. Financial Years as per the format prescribed in
(excluding reserves created out of
Form 12 given in Section 4 of the SBD v4 issued
revaluation) reduced by aggregate by REC Ltd.
value of accumulated losses (including
debit balance in profit and loss account
for current year) and intangible assets.]
Technical Requirements
The proposed MDM solution a) References along with requisite contract/

should have been successfully Purchase Order (PO)/ Work Order (WO).
integrated with at least 2 (two) Thereferences should indicate client name,
nos. of different HES solutions in scope of work, Project start date (as per the
2. Indian/ Global Utility(ies) format prescribed in Annexure-C);
(power/ water/ natural gas/
In case Non-Disclosure agreement (NDA) is
telecom) in last 7 (seven) years
signed withthe client, Bidder shall provide an
which are in operation for at least
undertaking for the NDA andshall also provide
1(one) year.
a client certification as proof of experience
along with Client Name/ Email Address/
Contact no./ designation etc.
b) Documentary evidence of completion of
the Project orcompletion of Go-live status
(i.e., Go-live certificate, UAT testing
The proposed MDM solution certificate etc.) of the respective project as
should have been successfully per the definition of Go-Live/ UAT
integrated with at least 2 (two) specified therein or other documentary
nos. of different Billing Systems in evidence indicating completion (e.g., proof
Indian/ Global Utility(ies) of payment received/ proof of asset
3. (power/ water/ natural gas/ capitalized in books of accounts (as
telecom) or with Billing/ Other IT applicable) and client certificate for supply
systems of 2 (two) different of material or similar proofs) along with
Indian/ Global Utility(ies) in last contact details of the client
7 (seven) years which are in
c) Certificate / report issued byClient / HES
operation for at least 1(one) year.
OEM/ solutionprovider. In case the MDMS
solution provider, has integrated with their own
HES, then a self- certification shall be provided.
b) Any other documentation for
implementation performance/operation.
7|Page
S. No. Requirements Supporting Documents
Should have CMMi (Capability

MaturityModel Integration) Level
3 or IEC/ISO 27001 Certification
4. Copy of valid certificate
(Software Development &
Customization), as the
requirement may be
Should have experience of

integration of HES/MDMS etc.
with at least 2 (two) billing /other
utility IT systems in Indian/
Certificate / report issued by Client / Billing
6. Global Utility(ies) (power/ water/
system solution provider.
natural gas/ telecom) in last 7
(seven) years, in which the meters
are in operation for at least 1(one)
year.
Should have valid ISO

9001:2015 certification should
7. have IEC/ ISO 27001 Copy of valid certificate
certificationor CMMi Level 3 (or
above) certifications
8. Annexure A As per prescribed format
9. Annexure D, if required As per prescribed format
The above bids and related documents including queries to be submitted for evaluation to
pcm@recpdcl.in
The Prebid meeting shall be conducted on 07.06.2024, 4:00 PM through VC whose link is:
https://meet.google.com/cgx-yqce-zgu
5. SCOPE OF WORK
RECPDCL intends to empanel agencies for supply and service of Meter Data Management
systems and System Integration of AMI systems in AMI projects in the country. This EOI intends
to empanel System Integrator and MDMS system provider for AMI projects being executed by
RECPDCL. The expected deliverables from the empaneled agencies shall include but not
restricted to:
1. Overview of the MDM Provider and System Integrator Scope of Work:
1.1 Introduction:
The Integration of the AMI system should be designed such that all the required hardware,
software, and firmware with upgrades satisfy the AMI system requirements and service
level agreements as specified in this Contract while considering technical obsolescence
over the operating life of the system and suitability for future scale up. EA shall be free to
8|Page
decide upon the best solution out of all the available options. However, the responsibility
of fully functional AMI system pertaining to efficient system integration and seamless
transfer f Data to and from form HES and other IT/OT systems of Utility shall rest with
the EA in order to meet the performance levels as given in the Contract. The EA shall
ensure that the Solution complies with the Applicable Law, technical specifications and
other provisions of the Contract.
1.2 Brief Scope of Work:
The Scope of work of the empanelled agency shall include survey, planning, designing,
financing, engineering, manufacturing, supply, transportation & insurance, delivery at site,
unloading, handling, storage, installation, integration, testing, commissioning,
demonstration for acceptance, training, maintenance, operation and documentation of
components given below:
A. Supply, installation, integration, testing and commissioning of:

a. Meter Data Management system (MDM) with prepaid functionality (as a part of
MDM or through a separate pre-payment application) and deployment on cloud
as per Clause 2.1 “Meter Data Management System” of this Section;
b. Consumer portal and mobile application as per Clause 2.2 “Utility Interface and
Consumer Portal/App” of this Section;
c. Network Operation cum Monitoring Centre (NOMC) with suitable backend
communication infrastructure, hardware and power supply as per Clause 2.3
“Network Operation & Monitoring Centre" of this Section;
d. All other necessary software along with valid licenses relevant to the Project (as
per Clause 2.4 “System Software Requirements” of this Section);
B. AMI System integration as per Clause 3 of this Section;
C. Consumer indexing and Meter Installation Application on de-novo basis for

contiguous electrical locations in the selected AMI Project Area along with its regular
updates during contract period as per Clause 4 of this Section;
D. WFM application as per details in clause 4.5 of this Section and Ticket Management
System.
E. Energy accounting and Auditing for the AMI project; Generation of automated energy
audit reports (DT level/ Feeder level / Sub-division level/ Division level/ Circle) in
contiguous electrical locations and other reports as per Clause 5 of this Section;
F. Operation, maintenance, and support services after the successful completion of the
Operational Go-Live of the system as per Clause 6 of this Section;
G. Training of Utility personnel, as required for efficient, viable and fully functional
system as per Clause 7 of this Section;
2. Supply, installation, integration, testing and commissioning of:
9|Page
2.1 Meter Data Management (MDM) System
The Meter Data Management system (MDM) shall support storage, archiving, retrieval & analysis
of meter data and various other MIS along with validation & verification algorithms. The MDM
shall be a scalable and COTS product. It shall act as a central data repository with interactive
dashboard. MDM shall have capability to import raw or validated data in defined formats and
export the processed and validated data to various other systems sources and services in the agreed
format. It shall provide validated data for upstream systems such as billing, analytics, reporting,
etc.
MDM should support the future requirement of utility by way integration with other smart grid as
and when implemented by Utility. In this effort, the methodology as outlined in the approach
paper shall be followed.
The key use cases to be enabled by MDM system provider are provided below. Please note that
these are illustrative list of use cases only and is not an exhaustive list. Further please note that all
IS Standards shall be applicable.
Sr.
Use Case activity description Source Destination Info Exchanged
No.
1. Collection of Daily Meter Profile
At scheduled frequency HESshould Meter Number, reading date

pull the Daily Meter Data from & time, kW, kVA, kWh,
HES Meter
1.1 Smart Meter overcommunication kVAh, PF, Non- critical
Channel Event Code / Date
Meter should send the data toHES.
Provision for retrial should be there if
Meter data is not collected within Meter Number, reading date
1.2 time. Consumption details including & time, kW, kVA, kWh,
Meter HES
non-critical events will be in 15 kVAh, PF, Non- critical
min/30 min block data, and data Event Code / Date
could beincremental to what was sent
by meter in preceding instance.
Meter Number, reading date
1.3 HES should send the data toMDM HES MDM & time, kW, kVA, kWh,
kVAh, PF
MDM should send the required Meter Number, reading date

parameter to Prepaid system for daily & time, kW, kVA, kWh,
MDM Prepaid Engine
charge calculation at leastonce on kVAh, PF, Non- critical
1.4
daily basis Event Code / Date
2. Monthly Billing profile collection

Command from Billing system
Billing & time, kW, kVA, kWh,
triggered and send toMDM / HES MDM / HES
2.1 System kVAh, PF, Non- critical
for collection ofMonthly billing Data
Event Code / Date
10 | P a g e
Sr.
No.
At scheduled frequency HES should Meter Number, reading date

pull the monthly meter data from & time, kW, kVA, kWh,
HES Meter
2.2 Smart Meter over kVAh, PF, Non-
the communication channel critical Event Code / Date
Meter should send the data to HES. Meter Number, reading date
Provision for retrial should be there if & time, kW, kVA, kWh,
Meter HES
2.3 Meter data is not collected within kVAh, PF, Non- critical
time. Event Code / Date

HES should decrypt and validate the & time, kW, kVA, kWh,
HES MDM
2.4 data collected and send to MDM kVAh, PF, Non- critical
Event Code / Date

MDM should send the required
& time, kW, kVA, kWh,
parameter to Billing system for MDM Billing Engine
2.5 kVAh, PF, Non- critical
Monthly Bill calculation
Event Code / Date
3. Remote Meter disconnection
Prepaid
Meter Number, group of
Meter disconnects operationcommand Engine/
MDM meters, instruction to close
3.1 after wallet balance calculation Billing
switch
system

Disconnection alert sent toconsumer MDM Billing System meters, instruction to
3.2
close switch
Meter disconnection operator Meter number, action

3.3 MDM HES
command (disconnect)
Meter Number, switch

3.4 Consumer meterdisconnection HES Meter
status

3.5 Disconnection Status Update Meter HES
status

3.6 Disconnection Status Update HES MDM
status
4. Remote Meter Reconnection
Billing
Meter reconnect operationcommand system/
MDM meters, instruction to close
4.1 after wallet recharge Billing Prepaid
switch
Engine
11 | P a g e
Sr.
No.
Meter reconnect operationcommand MDM HES meters, instruction to
4.2
close switch
Meter number, action

4.3 Consumer meterreconnection HES Meter
(reconnect)

4.4 Reconnection StatusUpdate Meter HES
(reconnect)

4.5 Reconnection Status Update HES MDM
(reconnect)
5. Utility detects tampering at consumer site
High priority events capturedby Meter Meter Number, event date &
sent to HES as and Meter HES time, event Code
5.1
when occurred /Description
Meter Number, event date &

High priority events reachMDM for
HES MDM time, event Code
5.2 further action.
/Description
Consumer number, Meter

Share with WFM to Notifyutility
MDM WFM Number, Tamper code,
5.3 personnel for site inspection
address
On analysis and detection of valid Consumer number, meter

tamper event or malfunction, the number, action to be triggered
Meter HES/ MDM
tamper eventmust be sent / pushed by (disconnect), action date &
5.4
the meter to the HES /MDM time
HES sends disconnectcommand to Meter Number, action

5.5 HES Meter
meter (disconnect)
Tamper event shared with Meter Number, event date &

CIS/CRM. Billing determinants are MDM CIS / CRM time, event Code
5.6
updated fortamper invoicing /Description
Meter re-connection order once Meter number, action (re-

5.7 MDM HES
tamper issue is resolved connect)
HES sends re-connectcommand to Meter Number, action (re-

5.8 HES Meter
meter connect)
6. Missed interval readings
12 | P a g e
Sr.
No.
On identifying missed interval, HES Meter Number, from date &

will re-acquiredata for the missing HES Meter time, to date & time (for
6.1
period from meter which data ismissing)
On receiving data requestcommand, Meter Number, reading date

meter will send Meter HES & time, kW, kVA,
6.2
data to HES kWh, kVAh
Missed Interval and ReadsData Meter Number, readings

6.3 HES MDM
acquired by MDM with date & time
7. Consumer connection outage/restoration event
Outage/restore event recorded by Meter Number, Outage /

meter is sent toHES as and when Meter HES restoration Date / Time,
7.1
event occurs Power On or Off count
Meter Number, Outage /

Outage / RestorationNotification HES MDM restoration Date / Time,
7.2
Power On or Off count
Meter Number, Outage /

Sharing Outage / Restoration
MDM OMS/CIS-CRM restoration Date / Time,
7.3 Notification
Power On or Off count
Meter read request from OMS to

identify service OMS MDM → HES
7.4 Meter Number,
outage / restoration
Meter responds to event poll from Meter number, Status

7.5 Meter HES
HES (live/dead)
8. Remote firmware upgrades/ meter configuration changes
8.1 Remote firmware upgrade HES Meter Firmware
Configuration Commands: Change Meter number, tariff

tariff parameters, parameters, registers
HES Meter
8.2 Synchronize clock, Registers reset status, event type and
(status, max, tampering) priority
Status update of Firmware /

8.3 Meter HES
Configuration
9. Load monitoring at demand side
When there is a load violation event

Meter Number, max
recorded in the meter, the information
Meter HES → MDM demand, date & time of
9.1 is
load violation
sent to the CC
13 | P a g e
Sr.
No.
10. Time synchronization
Synchronizing RTCs ofmeters /
10.1 HES DCU/Meter Time Setting
DCUs/ACP
11. Metering network changes
Change / new installation inMeter / Network identification info

Meter /DCU HES
11.1 DCU Network Hierarchy including DCUs
Change / new installation inMeter / Network dentification info

HES MDM
11.2 DCU Network Hierarchy including DCU
12. New consumer connection
Receive verified pre & post-paid new CIS-CRM/ Consumer name, address.
12.1 MDM
consumer requests Billing Connection request etc.
12.2 Generate meter installationorder MDM WFM Consumer ID & details
Meter number, DT no,Feeder

12.3 Receive meter installationreport WFM MDM
& reading
Meter Number, Readingdate

Requesting instant, & time, reading params
MDM HES → Meter
12.4 interval & events data frommeters (kWh, kVAh, kW
etc.)
Acquire instant, interval /events data Meter Number, Readingdate

12.5 from meter by HES which then HES MDM & time, reading params
reaches MDM system. (kWh, kVAh, kW etc.)
Once new meter remote read

Consumer ID, Consumer
verification is over, confirm new
Billing / CIS- address, Meter Number,
12.6 connection with other MDM
CRM initial reading etc.
applications
13. Migrate post-paid consumer to prepaid mode
Migration request for post-paid

CIS-CRM/
consumer with
13.1 Receive migration request Billing MDM
profile
Setup prepaid consumer profile in

prepaid engine. Ifno change in meter MDM Prepaid Engine
13.2 Prepaid consumer profile
is required, skip next two steps
14 | P a g e
Sr.
No.
Generate prepaid meter installation

13.3 MDM WFM Consumer ID & details
order if required
Meter number, DT no,Feeder

13.4 Receive meter installationreport WFM MDM
& reading
Prepaid
13.5 Enable prepaid mode inmeter HES → Meter Engineering token
engine
13.6 Receive activationconfirmation HES MDM Activation status
Meter Number, readingdate &

Request instant, interval &events data
MDM HES → Meter time, reading params (kWh,
13.7 from meter
kVAh, kW etc.)
Acquire instant, interval /events data Meter Number, readingdate &

from meter byHES which then HES MDM time, reading params (kWh,
13.8
reaches MDM system. kVAh, kWetc.)
Once meter remote read verification is

Billing / CIS-
over, share migration request MDM
13.9 CRM Prepaid consumer profile
completion detail with other modules
14. Migrate prepaid consumer to post-paid mode
Migration request for prepaid

CIS-CRM MDM consumer with
14.1 Receive migration request
profile
14.2 Request meter data MDM HES → Meter Meter Number, ConsumerID
Meter Number, Reading date

Acquire instant, interval /events data
& time, reading params (kWh,
from meter byHES which then HES MDM
14.3 kVAh, kW etc.) with balance
reaches MDM system.
credit
14.4 Send meter disconnect command MDM HES → Meter
14.5 Receive connection status HES MDM Disconnect status
14.6 Enable post-paid mode in meter MDM HES → Meter Engineering token
15 | P a g e
Sr.
No.
14.7 Receive activation of post- paid mode HES MDM Activation Status
Request instant, interval & events

MDM HES → Meter Meter Number, Consumer ID
14.8 data from meter
Acquire instant, interval / events data Meter Number, Reading date

from meter by HES which then HES MDM & time, reading params (kWh,
14.9
reaches MDM system. kVAh, kW etc.)
Once meter remote read verification is Billing / CIS- Post-paid consumer profile and
MDM
over, share migration request CRM meter data along with credit
14.10
completion detail with other modules balance
15. Consumer Registration in Consumer Portal/ App
Consumer clicks on new useron

consumer portal/ App, provides Portal/ App CIS/CRM Request for registration with
15.1
RMN or email ID and submits data RMN/email ID
Utility receives request for registration

Email/ Message
and sends OTP CIS/CRM
15.2 gateway OTP
after verification
15.3 Consumer submits OTP Portal/ App CIS/CRM
15.4 Consumer receivesregistration detail CIS/CRM Email Gateway Login ID and defaultpassword
15.5 Consumer submits first loginrequest Portal/ App CIS/CRM
15.6 System seeks passwordchange CIS/CRM Portal/ App
15.7 Consumer changes defaultpassword Portal/ App CIS/CRM
16. Consumer Access to Consumption, Billing & Profile Data
Portal/
16.1 Consumer logs in to Portal/App MDM
App
MDM Name, Account, Address,

16.2 Consumer Profile for Portal/App CIS-CRM
→Portal/App Service Points, K Number
16 | P a g e
Sr.
No.
Portal/ App
16.3 Consumption Data MDM Consumption profile
→UI
Post-paid Billing history/

Billing (post-paid) / Credit Balance Billing →
Portal/ App Current Bill, Prepaid
16.4 (prepaid) MDM
Recharge history
17. Prepaid Consumer Recharge
Consumer logs into Portal /Mobile Mob App /

17.1 UI Login
App Portal
Consumer fills-in requireddetail in UI UI→ Prepaid Payment Consumer ID, Recharge

17.2 and requests recharge App Gateway amount
Net banking
Payment
Consumer selects paymentmethod /Credit Card /
17.3 Gateway
Wallet etc.
Prepaid
Consumer receives payment Payment
App→Portal→
17.4 acknowledgement Gateway
UI
Calculate credit balance forprepaid

Consumer credit balance
consumer & update Prepaid App HES→Meter
17.5 (virtual token)
prepaid meter
Email/SMS
17.6 Notify credit balance toconsumer Prepaid App Credit Balance
Gateway
18. Post-Paid Consumer Bill Payment
Consumer logs into Portal /Mobile Mob App /

18.1 UI Login
App Portal
Consumer is presented withBilling Billing → Portal/

18.2 history and current outstanding Bill MDM App→UI Outstanding Bill
Consumer requests bill payment. UI→Billin Payment

18.3 Option to download bill g Gateway
Net banking
Payment
Consumer selects paymentmethod /Credit Card /
18.4 Gateway
Wallet etc.
17 | P a g e
Sr.
No.
Billing→
Consumer receives payment Payment
Portal/
18.5 acknowledgement Gateway
App→UI
Payment acknowledgementthrough Email/SMS

18.6 Billing Payment acknowledgement
email/SMS Gateway
19. Consumer Service Request
19.1 Consumer logs in to Portal/App Portal/ App CIS/CRM
19.2 Consumer requests forservice UI CIS/CRM Service request
Portal/
System assigns SRN & sends App→UI,
19.3 CIS/CRM
acknowledgement Email/SMS
Gateway
Portal/
System resolves request & updates
CIS/CRM App→UI,
19.4 consumer records
CIS/CRM
Email/SMS
19.5 System closes SRN CIS/CRM
Gateway
20. Consumer Complaints
20.1 Consumer logs into Portal/App Portal/ App CIS/CRM
20.2 Consumer registerscomplaint UI CIS/CRM Specific complaint
Portal/
App→UI,
System assigns CRN & sends
20.3 CIS/CRM Email/SMS
acknowledgement
Gateway
System assigns resolution based on CIS / OMS /

20.4 CIS/CRM
nature of complaint WFM
Target system reports completion of OMS /

20.5 CIS/CRM
complaint WFM
CIS,
System updates records andcloses
20.6 CIS/CRM Email/SMS
CRN
Gateway
21. Demand read of meters from consumer premises
18 | P a g e
Sr.
No.

Requesting instantaneous,interval,
time, reading params (kWh,
21.1 load profile & events data from meters MDM HES→Meter
kVAh, kWetc.)
Acquire instant, interval, loadprofile

& events data from meters by HES
Meter→ time, reading params (kWh,
21.2 which then MDM
HES kVAh, kW etc.)
reaches MDM system.
22. Staff User Access to Utility Portal
Login with appropriate

22.1 User logs in to Portal Portal MDM
credentials
22.2 User selects availablefunctions MDM Portal → UI

22.3 User logs out Portal →UI MDM
The Empaneled Agency shall specify and deliver an initial system that supports the collection and
storage of data for meeting the performance level for [X no of consumers/ Smart Meters] with
facility of future expansion.
The MDM shall have the ability to selectively choose which data to be maintained and which to
be purged or archived [as per requirement of Utility (user selectable)]
2.1.1 Asset Management
a) The MDM shall maintain information and relationships between the current installed
meter location (apartment, shop, industry/ address etc.), Consumer information (Name
etc.), Consumer account no, Meter ID, Type of Meter (type of consumer, 1 phase/
3phase, with or without relay, etc.), Meter configuration (Demand integration period,
Load profile capture period etc.), GIS supplied information (longitude, latitude,
connection with feeder/ transformer/ pole etc.) etc.
b) The software should support tracking the status of meters and communication
equipment from the date when they are installed in the field. The history of in-service
asset location is maintained throughout the device life with start and end dates
associated with each in-service location reference.
c) Ability to report and log any damage / deterioration in the meter attributable to
consumer /utility.
2.1.2 AMI Installation Support
a) The MDM shall also support device lifecycle management from device registration,
installation, provisioning, operations and maintenance to decommissioning etc. The
MDM shall generate exceptions for meter or modules not delivering the correct meter
data after installation.
b) The MDM shall provide a reconciliation report that identifies the meters that have been
installed but not communicating for a designated (configurable) period. MDM shall
19 | P a g e
generate reports on the number of meters installed in comparison to the number of
meters successfully communicating.
2.1.3 Meter Data
a) The MDM shall accept input, process, store, and analyse Meter data from HES and
meter data collected through handheld meter reading instruments and manual meter
reads. In case of manual reads, provision should be there to insert associated notes such
as assessed energy, etc.
b) The MDM should accept input, process, store, and analyse non-billing meter data such
voltage and power quality data (such as under/over voltage, out of band frequency,
etc.) as they are available from HES. The MDM should also support schedule and on-
demand meter reads and pinging of meter energized states by authorized users and by
other utility systems.
c) The MDM shall provide storage and retrieval of all collected Meter Data, events and
alarm. It shall have capacity of storing [10] years data (as required by the utility based
on regulatory provisions) via archiving.
d) The archiving of data should be done at a frequency of [24] hours and all data older
than [3] years should be archived. MDMS solution should describe the process of
archiving and restoration from the archive.
e) Correctly track & resolve energy usage across meter changes with no loss of individual
meter data.
f) Provide complete history and audit trail for all data collected from meters including
commands sent to meters and other devices for 30 days. (Configurable period).
g) Execute on-demand read processes.
h) Handle special metering configurations such as net metering/pre-paid
metering/multiple meters at same premises.
i) The MDM shall have the ability to manage at a minimum 5-minute interval data.
j) The MDMS solution provider shall ensure data integrity checks on all metered data
received from data collection systems.
2.1.4 Data Validation, Estimation, and Editing (VEE)
a) The validation and estimation of metered data shall be based on standard estimation
methods (such as max/avg. of past three days, max/avg. of past X number of similar
weekdays, max/avg. of similar blocks of past X numbers of similar weekdays, etc.). The
MDM should also support and maintain following data-
i. Registered Read Data including register reads, daily billing cycle, as well as
derived billing determinants such as TOU
ii. Interval Data channels with variable intervals and variable units of measure
iii. Calculated Data that is derived or computed such as billing determinants and
aggregated loads.
iv. Event data storage of all collected event and alarm data from meters, network
equipment, and MDM itself
b) MDM shall flag, alarm and trigger an estimating process including but not limited to
when the following anomalies occur in the cumulative (“CUM”) register reads
i. CUM decrements within a billing cycle (except net-metering)
ii. CUM reads increments more than configurable threshold
20 | P a g e
iii. Future or old read dates
iv. Number of digits exceeds number of meter dials
c) MDM shall detect, flag, alarm and trigger an estimating process including but not
limited to when the following anomalies occur in Time of Use (TOU) register reads
i. Register decrements (except net-metering)
ii. Resets (to zero) (except net-metering)
iii. CUM reads increments more than configurable threshold
iv. Future or old read dates
v. Erratic compared to CUM read (sum of TOU reads minus CUM read)
d) MDM shall detect, flag, alarm and trigger an estimating process including but not
limited to when the following anomalies occur in Demand register reads
i. Do not reset on cycle
ii. Do not reset coincident with consumer move-out or move-in
iii. Reset off cycle inappropriately
iv. Too high
e) All data shall be transferred to billing system after meter data validation and estimation
including transformer / feeder station wise energy audit.
f) MDM shall estimate usage for non-metered service points such as streetlights, farm
lights, traffic signals, etc.
g) The MDM shall maintain both the original received raw data in a non- manipulated
state, in addition to VEE data.
h) Notwithstanding the latency of data collection via the AMI system, once the MDM
receives meter read data, the VEE process occurs in real-time and the post-VEE data is
then immediately available to user or external systems.
i) The MDM shall be able to automatically flag data changes from manual edits, VEE
(Validating, Editing and Estimating) rules and data source corrections and
electronically generate audit trail with timestamps and user-ids.
2.1.5 Billing Determinants Calculations
The MDM-
a) Shall allow configuring multiple TOU options (e.g., the number and duration of TOU
rate periods) by consumer type, tariffs and day type (weekend, weekdays, and holidays)
and by season.
b) Shall support the processing of interval data into billing determinants to include the
following at a minimum:
i. Total Consumption
ii. Consumption in different time blocks for ToU billing
iii. Maximum Demand (in kW and kVA)
iv. Number of tamper counts
v. Average power factor
vi. Net-Metering data
21 | P a g e
c) Shall process interval data and frame it into the appropriate TOU periods for
consumption and demand; for example, roll up 15 min for system metering and 30-
minute for consumer metering data intervals into hourly data.
d) Shall have the ability to properly account for special metering situations such as check
metering, sub metering, prepaid metering and net metering when calculating billing
determinants and sending them to billing and other systems.
e) Shall have the ability to properly account for special situations including, but not
limited to, curtailment requests, demand response scenarios (based on use cases
provided in Annexure-H) when calculating billing determinants and sending them to
billing software.
f) Shall have the ability to facilitate implementation of automatic compensation
payments by Utility to consumers for sustained outages when requested.
Compensation calculations would require cross checking with billing and consumer
balance information to ensure that disconnection is not construed as a no supply event.
2.1.6 Prepaid functionality
The MDM with the help of the corresponding HES, should be able to switch the Smart
Meter between prepaid and post-paid modes by a simple change in configuration of the
Smart Meter firmware remotely. The following prepaid functionality shall apply
a) MDM shall use consumer attributes from Consumer Care System (CCS) and/or
Utility Billing system to,
i. enrol and setup new prepaid/ post-paid consumers
ii. migrate existing post-paid consumers to prepaid mode and vice versa
b) An appropriate pre-payment application engine shall support the pre-payment
metering capability through the delivered system.
c) The prepayment system shall ensure that payment and connection parameters are
stored centrally, and the details are updated to CIS-CRM/MDM through consumer
portal/ app as per Clause 2.0 of this Section “Scope of Work”. Information required
by consumer’s Mobile App and web portal are shared in near real time.
d) Prepaid consumers shall be provided facility to recharge their account by logging on
to the consumer portal/app as per Clause 2.0 of this Section “Scope of Work”.
i. The user interface shall be integrated with the present online payment gateway
of the utility. Additional payment gateways shall be implemented if required
ii. The payment gateways shall facilitate payments through on-line banking, credit
cards and payment wallets
e) A prepaid mobile application functionality shall be provided as a recharge option for
android OS and iOS. The consumer portal/ app, shall enable consumers to recharge
as well as view recharge history, existing balance, daily usage etc.
f) In addition to billing determinants, the MDM shall share, consumer recharge and
credit updates with the utility Billing system. Any re-conciliation shall be carried out
in the Billing System and the same shall be shared with the MDM for use by the
prepayment application.
g) The system shall periodically monitor the energy consumption of prepaid consumer
and decrease the available credit based on consumption. For this purpose, the MDM
22 | P a g e
shall fetch billing data (kWh/kVAh consumption and MD) at configured intervals1
from the prepaid meter. The raw billing data shall be subjected to standard VEE rules
before being used to update recharge balance with the help of applicable tariff slabs.
The credit balance is updated into meter at re-charge time.
h) The prepayment application shall use determinants such as minimum fixed charges,
TOU tariffs, slab rates, duties & surcharge while calculating consumer credit/balance.
Fixed charge shall be deducted on daily basis irrespective of the consumption, even
after disconnection of supply and adjusted in the next transaction.
i) The prepayment application should be able to automatically apply different TOU
tariffs for future date lines, while calculating consumer credits.
j) The system should send connect/disconnect command based on available credit as
per notified rules & regulations.
k) The system should send low-credit notifications to the consumer when their balance
approaches a pre-configured threshold. Alerts shall initiate on every recharge, low
credit and load connection/disconnection. The alerts shall be posted on the consumer
web Portal/ App in real time and sent through SMS and email. Consumer should
also be alerted through other mechanisms such as one-time alarm / beep from the
meter, LED blinking, message, etc.
l) It shall be possible to configure an “emergency” credit limit in INR as well as day
terms. This emergency credit shall be used as reserved amount that is consumed when
consumer credit is exhausted. The credit amount shall be adjusted in next recharge
transaction.
m) It shall be possible to configure certain prepaid consumers where auto-disconnections
shall not happen due to negative credit. The conditions/protocols for auto-
disconnections are detailed in Annexure-F of this EOI.
n) The pre-payment function as part of MDM shall also have a facility to configure
arrear recovery mechanism to recover arrears from a consumer. Some of the
indicative mechanism to recover the same can be recovery of [X]% from every
recharge amount while the rest goes as charging amount till all the arrears are
recovered. Alternately, the arrears may be settled in next [X] instalments as decided
by utility such that not more than 50% of any instalment shall be adjusted towards
arrear.
2.1.7 Net Metering
MDM shall flag, alarm and trigger an estimating process including but not limited to when
the following events occur:
a) CUM decrements of forward energy within a billing cycle
b) Register decrements for Time of Use (ToU) of forward energy
c) Power generated(exported) by any net-metering consumer more than the installed
capacity of solar PV rooftop system
d) Energy exported in any given day by any net-metering consumer more than the
programmable threshold value
Like billing for post-paid meters, the billing for net-meters shall take place in the utility
Billing server.
1
The frequency of pre-configured intervals shall be at least every hour in addition to that at re-charge time
23 | P a g e
2.1.8 Exception Management
a) Ability to capture and log data exceptions, problems and failures and to generate
management reports, provide trend analysis, automate generation of service requests
and track corrective actions.
b) Ability to group, prioritize, filter and send system generated alarms and events to
predetermined email addresses, cellular text messages to phone
numbers/SMS/consumer care etc. Alternatively, these alarms/alerts may be routed
to utility’s WFMS.
c) Exception Generation - MDM shall generate exceptions based on configurable
business rules including but not limited to the following:
i. Meter tamper alerts
ii. Communication module health alerts for meter/DCU
iii. If the consumption is less/more than pre-defined average consumption
iv. Negative Consumption (not for net-metering)
v. Power outage indications received from the Smart Meter
2.1.9 Service Orders
a) The MDM shall generate service orders based on configurable rules for various events
and alarms such as stop meter, tampers, problem in communication networks, etc.
b) MDM shall send service orders via SMS, email, etc. with the email addresses / phone
numbers being configurable. MDM shall receive feedback on action taken on the
service order and track the status of service orders until resolution.
c) Service order tickets could be generated by MDM but processed and closed under
jurisdiction of the HES-NMS combine. If the utility already has a separate Workforce
Management System (WFM), then the service order tickets can be routed from the
MDM and the NMS to the WFM for completion of the tasks and reporting.
2.1.10 Revenue Protection Support
a) Ability to analyse meter tampering flags, power outages, usage trends and usage profiles
to identify potential energy diversion situations, and produce daily reports, monthly
reports and service order requests for investigation.
b) The business rules for revenue protection alerts shall be configurable via a user-friendly
interface.
c) The MDM shall filter out revenue protection alerts that may be caused by field activities
if the field activity information is provided to the MDM.
d) The MDM shall support the analytics/investigation (i.e., view current and historical
usage patterns) to validate suspected revenue protection issues.
24 | P a g e
2.2 Utility Interface and Consumer Portal and App:
EA has to develop and provide Consumer Portal and Mobile app on available platforms iOS
and Google etc. Further the Utility specific customization shall be done by the EA on project
specific basis. The App and Web interface shall be integrated with the provided IT/OT systems
of the Utility like Billing System, Outage Management System etc. for performance of desired
functions like recharge, viewing of usage, registration of grievances, outage alerts etc. by the
EA.
2.2.1 Utility User Interface
User interface for utility shall have ability for at least the following functionality:
a) Compare total energy costs on one rate schedule vs. one or many alternative rates.
b) Enable the user to see how different options within a rate affect costs.
c) Enable the user to see how adjusting load or consumption levels or shifting them to
different time periods influences costs.
d) Display meter data at a user defined configurable cycle that allows authorized users to
view energy usage patterns and the data behind them for selected consumers.
e) Allow authorized users to view metered data, initiate and view reports, modify
configurations, and initiate and update service requests.
f) Display the energy usage profile for a single meter or group of meters. The load profile
shall illustrate energy consumption and peak demand in user defined intervals for a user-
specified time period.
g) Display the energy usage profile for a single meter or group of meters according to Time
of Use (ToU) tariff.
h) The UI shall support a configurable utility dashboard for Operations and Utility
Management
i) Access to a minimum of three (3) years of historical energy usage and meter reads through
the UI.
j) Clearly and visually distinguish between metered, estimated, allocated and substituted
data.
k) User management with roles and access rights
l) GUI to provide role-based access based on user identity and user role. Shall have
following types of users (approximately 500 MDM users):
i. Administrator
ii. Operator
iii. Field staff
iv. Viewer/Guest
m) Configure the look, feel, and functionality of the MDM in accordance with business
needs, business processes, and business conventions. (E.g., GUI, content, look and feel
of screens, validation rules, exception handling, etc.).
n) Ability to set up alarm and event notifications that can be directed to a combination of
configurable email addresses, cellular text messages.
25 | P a g e
o) UI shall enable viewing of the credit amount updated in MDM for prepaid consumers.
p) Option to send marketing messages and notification to select consumers or selected
category of consumers
q) Facility to enable or disable existing functionalities/sections of App/Portal for consumers
use.
r) Consumer views to be available to Utility consumer Service Executive also except
payment card/bank information.
s) Authorised representative to be enabled for consumer engagement analytics. The
analytics to be configurable/ generated with minimal database skill and nil programming
requirements.
t) Representative to be able to generate various reports at different intervals the various
reports as per Clause 6 of this Section. It shall be also possible to export the report data
in multiple formats such as XLS, XLSX, CSV format, etc.
u) Provide consumer interactions history to enable efficient consumer complaints and
queries resolution with consumer information in single screen.
2.2.2 Consumer Portal and App
Consumer portal and mobile application shall cover all consumer categories and category
specific features as applicable prior to operational Go-Live. These apps shall have provision
to enable features required to facilitate consumer participation in Demand Response programs
which the utility may choose to roll out in future. The consumer web portal and the mobile
application (for smartphone and tablet devices using latest and commonly available browsers
and operating systems and platforms) shall provide consumers, ready access to features
extended by MDM. The Solution shall integrate via a user-friendly graphical interface. It shall
facilitate self service capabilities such as usage management, billing, service requests,
participation in energy efficiency programs etc. It shall be noted that the Consumer Portal /
App acts as the bridge between the consumers touch point and the existing utility Customer
Care and Billing Systems. It does not replace these legacy systems in place. Following features
shall be supported by Portal / Mobile app:
a) The mobile app and web portal shall support all device form factors such as mobile, tablet,
desktop etc. by recognising the device details automatically.
b) It shall be OS agnostic to operating system and devices (iOS, Android, etc.)
c) It shall work on all standard browsers such as Microsoft Edge, Chrome, Safari, Firefox
etc.
d) The application should be modular and scalable a COTS product.
e) The application should be native for better user experience.
f) It shall support multiple languages viz. Hindi, English and local language(s) (Gujarati).
Also, notifications should be sent to consumers in local languages.
g) The user experience of the citizen on the Portal and App shall be similar in terms of look
and feel, navigation, menu and access to preferences and other data.
h) Menu should have navigation options, not limited to, Home, Settings, Recharge,
notification preferences, usage rates, change password, terms and conditions, privacy
policy, sign out.
26 | P a g e
i) It shall have search functionality across all the pages.
Software patches, updates, and version upgrades, when they become available for general
release, should be part of ongoing support and maintenance services.
2.2.2.1 Functional Requirements of Consumer Portal/ App
Web portal and Mobile app for consumers should have minimum following functionalities:
a) The consumer portal/app shall have a landing home page. This page shall provide a
brief description about the Utility, any promotional features or advertisement for special
programs can be placed in this page. Login Component is provided, and registered users
may login using their username and password. New Users can also register by clicking
on the First Time Users Register link. The Forgot Password link helps the user to retrieve
their password. New users can register by providing their personal information and
setting up of security answers. Forgot passwords can be retrieved or reset using OTP
through registered mobile number or through email address. The registered users can
change their password and account information as well as registered mobile number
through OTP feature.
b) The consumer portal/app shall provide consumers with access to consumer ID, meter
ID, meter type and name plate details, besides other account information such as
account name, address, balance, due, status etc. Any status message pertaining to the
account/s viz. alerts/actions shall be displayed here. It shall also provide current and
historical consumption in graphical formats for at least 12 months. A more detailed
analysis can be provided in a tabular format listing meter reading date, reading,
consumption, charges, selected period etc. Consumers shall be able to view interval data,
outage flags, voltage, power quality indications, existing tariffs and incentives for
selected period. Information about different consumer engagement programs shall also
be displayed here.
c) The portal/app shall have the ability to provide option for registering in online/paper
billing to the consumer. There shall be a bill summary page that shall display bill
information in summary and also option for detailed view and download in pdf format
if required by consumer. The use shall be able to pay bill for single and multiple accounts.
d) The portal/app shall be integrated with existing helpdesk of the utility and have the
ability to provide option for recording service requests/complaints lodged by the
consumer as new connection, disconnection, load change, category change, meter
shifting etc. The user can view the service request status. The user can register complaints
viz. power failure, faulty meter, streetlight outage etc. There shall be option to track
status of service requests.
e) Mobile App and Web Portal shall facilitate Chat-bot functionality of the utility’s Help
Desk. The portal/ App shall support configuration of notification types via email/ SMS/
message/ automated call (through utility IVRS), of configured alarms & events.
f) The information on consumer identification no., meter ID, name plate details, make,
type i.e., 1 Phase or 3 Phase, etc. (as per requirement of Utility) shall be updated in HES,
MDM, and the consumer portal/app.
g) The consumer Portal/ App shall have the ability to provide the consumer near real time
online views of both usage and cost differentiating high energy usage periods, helping
consumers to understand electricity usage and cost information, alerts and notifications
and energy savings tips with different levels of detail. The Portal/ App shall support the
view for past electricity usage, last week’s, yesterday’s, current days or other period etc.
27 | P a g e
as per selection as well as voltage and power quality indications. The portal/ app shall
provide user friendly access to consumer for their data via graphs and charts and can
download the data into a spreadsheet.
h) The portal/app shall provide option to the consumer to view/download online bill.
There shall be a bill summary page that shall display bill information in summary and
option for detailed view and download in pdf format. The user shall be able to pay bill
for single and multiple accounts.
i) The portal/app shall also provide platform for implementation of peak load
management functionality by providing existing tariff & incentives rates, participation
options etc. The portal/app shall also provide consumers with interval data, flags,
voltage, power quality indications etc. Show outage information in map view.
j) There should be different UI and landing pages for different type of consumers as per
the need of utility.
k) User interface to consumer Portal/ App to access consumer’s data from MDM for all
authorized consumers shall have ability for at least the following functionality:
i. View metered data, monthly average usage, current monthly consumption,
maximum demand and other reports
ii. View data according to Time of Use (ToU), day, week, month, year and season
etc.
iii. Update profile information such as mobile number/email etc.
iv. Guest user account/multi-user account access facility for consumer convenience
v. Initiate request for connection/disconnection
vi. Initiate request to switch between pre-paid and post-paid mode
vii. Initiate service requests for maximum demand updating, meter checking etc.
viii. Initiate complaints such as Meter not working, supply off etc.
ix. In case on net-metering consumers, user can view data for both import & export
data
x. Can view recharge history, present balance, next possible recharge date and
amount etc.
xi. Historical energy consumption and energy charges during the desired time period
xii. Facility to recharge their account through the payment gateway facilitated by the
utility.
2.3 Network Operation & Monitoring Centre
The Network Operations and Monitoring Centre shall cater to the needs of the,
• Project Management Team and the
• AMI network operations team
The Network operation and monitoring centre shall be created in the utility premises by the
empaneled agency, for which suitable built-up space shall be provided by the utility. The built-
up space to be arranged by the utility, shall be properly air conditioned, illuminated, and
adequate for at least five operator workstations and one cabin for a supervisor.
28 | P a g e
The empaneled agency is required to suggest a suitable architecture for the Network Operation
& Monitoring Centre, taking care of the security requirements as described in this document.
empaneled agency shall establish connectivity between the workstations located at the NOMC
with that of the cloud-based MDM-HES system. In addition, the empaneled agency shall
establish connectivity between the cloud-based MDM system with utility’s existing Billing
system. This will necessitate creation of a VPN tunnel between the two unless it is decided to
migrate the Billing system to the same cloud data centre.
The empaneled agency must submit the details of the supplied hardware along with the Bid.
The empaneled agency shall assess the adequacy of hardware specified in the List of Material
and Services & if any additional hardware or higher end hardware configurations are required
to meet all the requirements of the Technical Specifications, the same shall be included in the
offer.
2.3.1 General Requirements for NOMC Hardware
All hardware shall be manufactured, fabricated, assembled and finished with workmanship of
the highest production quality and shall conform to all applicable quality control standards of
the original manufacturer and the empaneled agency. All hardware components shall be new
and suitable for the purposes specified.
All workstations and network equipment (routers, firewall etc.) shall be compatible for remote
monitoring using secure Simple Network Management Protocol (SNMP) Ver. 3.0. All
hardware shall support IPv6 simultaneously.
The empaneled agency shall ensure that at the time of final approval of hardware configuration
and List of Material and Services, all the hardware is as per the current industry standard
models and that the equipment manufacturer has not established a date for termination of its
production. Any hardware changes, except version upgrade in same series, proposed after
contract agreement shall be subject to the following:
a) Such changes/updates shall be proposed, and approval obtained from the Utility
along with the approval of Drawings/documents.
b) The proposed equipment shall be equivalent or with better features than the
equipment included in the Contract.
c) Complete justification along with a comparative statement showing the original and
the proposed hardware features/parameters including brochures shall be submitted
to the Utility for review and approval.
d) Changes/updates proposed will be at no additional cost to the Utility.
e) The porting of software shall be at no additional cost in case of replacement of
hardware during the contract period.
2.3.2 Minimum Technical Requirements for NOMC Hardware
The network operation and monitoring centre shall be equipped with the following minimum
hardware components:
a) Six numbers 27” Operator workstations including one for Supervisor
b) A dual redundant 1 Gbps local area network
c) Internet router with at least 48 no’s 1 Gbps LAN ports and redundant at least 2 Gbps
internet ports supporting IPsec, and SSLVPN capability
d) Firewall and intrusion protection system
29 | P a g e
e) One video display system of at least 75-inch diagonal with laser light source HD cube
(DLP technology) supported by,
i. Dual power supply
ii. IP based control options and
iii. Display Port, DVI, HDMI and Analog D-Sub signal interfaces
f) One A3/A4 size laser jet B/W printer with LAN interface
g) One A4 size ink jet colour printer with LAN interface
h) One dual redundant online UPS to support the load of the above-mentioned
equipment with minimum 2 hours backup
i) 2 Gbps internet connectivity
The minimum technical specification and requirement to be followed for hardware equipment is as
per the table below. < Hardware Requirements and minimum specification to be defined as per utility
requirement>.
Hardware Item Minimum Specification Quantity

Firewall [X]
WAN Router [X]
Workstation Console [X]
Printers [X]
*[x] <As per utility requirements>
Minimum Requirements for Firewall not limited to

The proposed solution must be based on ASIC or Multicore Parallel Processing Architecture
Proposed solution should support inbuilt HDD 250GB for storage or external device for Logs and
Reports.
The proposed solution should have minimum 8 x Copper GbE ports & Expandable to 24 x Copper GbE
ports for Future Expansion
There should be provision to load Fibre modules (1G & 10G) for future Enhancements
The proposed solution should have minimum 2 USB ports
SPECIFICATIONS Minimum Requirements for Printers not limited to

Type Laser
Function Copier-Printer-Scanner
Minimum1200 x 1200 (2400 dpi type or higher), Image Resolution
Resolution color
Enhancement technology
General-5-8ppm
Speed (color)
Scanner-Color : 10 ipm @ 200 dpi via RADF
Memory 128 MB or Higher, expandable to 256 MB
Processor 600 MHz or better
Media size A3 / A4 / A5 / B4 / B5 /Ledger / Legal / Officio / Folio
30 | P a g e
Letter / Executive / Statement/ 8K / 16K / Post Card
Minimum Requirements for Desktop not limited to

i) Type Desktop PC
Vertical Tower Type or Ultra-Small /Small
Form Factor Desktop Type with Mechanical
A) Architecture ii) Orientation
Locking Arrangement for the CPU
Cover/casing
iii) Bus type /
PCI
architecture
i) CPU CHIP Intel Core i7 or higher (11th Generation)
ii) Processor internal
3.80 GHz or higher
clock speed
B) Processor
iii) Planer clock
1066 MHz or higher
speed / FSB
iv) L2 Cache 8 MB or higher
i) Memory (RAM) 4 GB (2 nos. of 2 GB DIMMs)
ii) Memory (RAM)
16/32 GB (in-built) or higher
max expandability
iii) RAM speed 1600 Mhz or higher
C) Memory
4 or more (in Dual Channel; 2DIMMS
iv) RAM slots total
/channel or more)
v) RAM type Non-ECC DDR3
vi) Packaging DIMM
OEM Mother Board with OEM logo
Mother Board embossed on
D) Board the Motherboard
Management agent should show the revision
Revision Level
level
2 TB@ 7200RPM or better SSD, Sync
i) Size & make
Transfer Rate 3 GBPS or higher
ii) Hard disk
E) HDD Integrated SERIAL ATA II or higher
controller
iii) HDD Exp
Option to add 2nd Serial ATA HDD-Required
Option
built-in on the chipset,
i) Type
Intel HD Graphics 6000 integrated or higher
ii) Video RAM Separate
F) Graphics subsystem
iii) Resolution 1920x1200 or better
iv) Graphics bus
Integrated Graphics Media accelerator
interface
27" or higher HD LED, Min. Resolution 1024
G) Monitor (Asset Controlled) Monitor
x 768
H) Keyboard Type USB Std Keyboard
31 | P a g e
Minimum Requirements for Desktop not limited to
Mouse with Mouse
I) Pointing device 2 button OPTICAL scroll Mouse, OEM
Pad
i) Speed 48X or higher
DVD read and write; SATA Implemented
ii) Make OEM make or equivalent (any other make
J) DVD Drive offered to be specified)
At least 8 out of which 2 on front. USB Ports
iii) USB Ver 2.0 or
must be apart enough so that all three can be
higher
used simultaneously
2.4 System Software Requirements

This section describes the standards and characteristics of system software such as operating
system, database and support software (compilers, DBMS, display development, network
utilities, report generation, diagnostics and backup utilities) provided by Empaneled Agencies
and the original software manufacturer as necessary to support the functioning of AMI
Applications systems. All the system software to be used for the present scope of work shall
have valid license(s).
2.4.1 Software Standards
All software provided by the Empaneled Agencies under this EOI, including the operating
system, database and support software, shall comply with the industry-accepted software
standards. In areas where these organizations have not yet set standards, the software
shall comply with those widely accepted de-facto open standards put forth by industry
consortiums, such as Open Software Foundation (OSF) and X/Open. The Empaneled
Agencies shall commit to meet the "open systems" objective promoted by industry
standards groups.
2.4.1.1 Design and Coding Standards for AMI Applications and Utilities
These provisions are applicable for both software applications and operating systems and
would address program features that must be contained in software for the product to meet
the standards.
a) When software is designed to run on a system that has a keyboard, product
functions shall be executable from a keyboard where the function itself or the result
of performing a function can be distinguished textually.
b) A well-defined on-screen indication of the present focus shall be provided that
moves among interactive interface elements as the input focus changes.
c) Applications shall not override user selected contrast and colour selections and
other individual display attributes.
When animation is displayed, the information shall be displayable in at least one non-
animated presentation mode at the option of the user
2.4.1.2 Applications
All components of AMI application system shall be maintainable by owner using the
supplied software utilities and documentation. The software design and coding standards
of the system shall address the followings:
32 | P a g e
a) Expansion: Software shall be dimensioned to accommodate the size of AMI
application system as given in List of Material and Services (as shall be informed
later) and Annexure-G of this EOI.
b) Modularity: Software shall be modular i.e. functionally partitioned into discrete,
scalable, reusable modules consisting of isolated self-contained functional elements
and designed for ease of change. The system shall make maximum use of common
industry standards for interfaces.
c) User-Directed Termination: Functions taking long execution times shall recognize
and process user requests to abort the processing.
d) Portability & Interoperability: The system shall be designed for hardware
independence and operation in a network environment that facilitates
interoperability and integration of third-party applications. AMI applications
should support multiple Relational Database Management Systems (RDBMS)
including Oracle, Microsoft SQL Server and MySQL.
e) Programming Languages: The software shall be written using high level ISO or
ANSI standard programming languages.
All applications shall be designed with sufficient background logs which capture
various level of errors encountered (warning, fatal, informational) while executing, so
that the same can be reviewed and attended to.
2.4.1.3 Operating System
The operating system of all the equipment of AMI application system including network
equipment shall be latest version released up to six months prior to FAT. The operating
system shall be hardened to provide robust security. The operating system and data file
shall be placed in different disk partitions.
In order to facilitate cyber security requirements including patch management, common
operating system is preferable to be used by all server nodes within the AMI application
including MDM/HES servers. This is also to minimize the maintenance. All licenses for
Operating System and other application software shall be supplied by the Empanelled
Agencies and shall be valid throughout the contract period.
2.4.1.4 Time and Calendar Feature
The AMI application & other servers shall maintain time and calendar for use by various
software applications. The internal clocks of all servers and workstation consoles shall be
automatically synchronized on Network Time Protocol (NTP) protocol. The calendar
shall be customizable for working hours, holidays, weekends etc. The holidays, including
type of days, shall be entered for each year at the beginning of the year and shall be
recognized by all applications.
2.4.1.5 Remote Diagnostic
Remote Diagnostic facility with necessary hardware as required shall be provided for
communication between the AMI application system at the cloud data centre and the
NOMC for the diagnosis of hardware & software problems. The login shall be protected
by a username & password entry. An automatic logging and intimation shall be provided
to inform authorized person from Empanelled Agencies /utility on such events of remote
access and diagnosis.
33 | P a g e
2.4.1.6 Development System as a Test Bench
A Development system independent of the production environment shall be defined at the
cloud data centre which shall provide testing facility for integration of
changes/modifications of the AMI application and new field devices before putting it
online with Real-time system. This Development system shall be on a VLAN separated
from the production VLAN and shall be self-sufficient to carryout testing of changes/
modifications.
2.4.2 Network Communication
The network communications software shall use a standard network protocol such as
TCP/IP, UDP etc. and shall support IPv6. The software shall link dissimilar hardware nodes
such as local and remote workstations and peripheral devices into a common data
communication network allowing communications among these devices. The network
communication software shall include network security, security management, patch
management and network services of the AMI system. Network communication software
shall have scalability feature as envisaged.
2.4.3 Cloud Service Providers (CSP)
This section mentions key requirements from the Cloud Service Provider (CSP). Empaneled
Agencies shall be responsible to provide the services of CSP.
2.4.3.1 General Conditions
The cloud data centre shall have to comply with requirements of tier III category which
applies to a concurrently maintainable site infrastructure with redundant capacity
components and multiple independent distribution paths serving the critical environment.
All IT equipment shall be dual powered. The following general conditions will apply:
a) Only GI (MeghRaj) cloud services or Meity empanelled Cloud services should be used.
b) One of the most critical issues in the Cloud Service implementation is the security of
the data. It is the responsibility of the Empanelled Agencies to define the security
services that need to be implemented for their workloads depending on the nature of
the applications / data hosted on the cloud.
c) Empanelled Agencies need to ensure that the CSPs facilities/services are compliant to
various security standards (as mentioned in Clause 5.3.3.4 of this EoI) and should be
verified by third party auditors.
d) CSP should suitably address all the potential risks and issues in cloud implementation
including data security and privacy, increased complexity in integration with existing
environments, vendor lock-in, application portability between different platforms, exit
management / Transition-Out Services etc.
e) The Empanelled Agencies shall be responsible for providing the cloud data centre
services. It shall be up to the Empanelled Agencies, to identify the critical service
agreements with the concerned cloud data centre provider in order that the Empanelled
Agencies can meet and sustain the SLA for the AMI project as per Clause 7.7 of AMISP
SBD v4 OR SLAs attached as Annexure-E of this EoI.
f) All Services including data should be hosted in India
g) Exit Management / Transition-Out Services -The responsibilities of the CSP during the
Exit Management Period need to be agreed upon with the Utility and they should assist
the Utility in migrating the data etc.
34 | P a g e
h) The responsibilities of CSP include migration of the data, content and any other assets
to the new environment or on alternate cloud service provider’s offerings and ensuring
successful deployment and running of the Utility’s Solution on the new infrastructure
i) The ownership of the data generated upon usage of the system, at any point of time
during the contract or expiry or termination of the contract, shall rest absolutely with
the Utility.
The Empanelled Agencies may also choose to procure the following Managed Services
(O&M – Cloud Services) from a Managed Service Provider (MSP) in addition to the
cloud services to handhold the department in managing the operations on the cloud.
The scope of MSP may include:
a) Migration of Existing Applications to Cloud / Deploying of new applications;
b) Operations & Maintenance Services on Cloud (e.g., Resource Management, User
Administration, Security Administration & Monitoring of Security Incidents,
Monitoring Performance & Service Levels, Backup, Usage Reporting and Billing
Management)
c) Exit Management & Transition-out Services, etc.
2.4.3.2 MeitY’s Guidelines
While the security, storage, data and compliance tools are provided by the CSP, it is the
Empaneled Agency’s responsibility to ensure that the CSPs facilities/services are certified to
be compliant to standards.
In the MeitY’s guidelines to Government Departments on Adoption / Procurement of Cloud
Services, the following are included as essential certification by CSP. Empaneled Agencies
also needs to ensure that the CSPs facilities/services are certified to be compliant to the
following standards (indicative list provided below):
a) ISO 27001 - Data Center and the cloud services should be certified for the latest version
of the standards towards information security management system
b) ISO/IEC 27017:2015-Code of practice for information security controls based on
ISO/IEC 27002 for cloud services and Information technology
c) ISO 27018 - Code of practice for protection of personally identifiable information (PII)
in public clouds.
d) ISO 20000-1 – Information Technology service management system requirements
e) The CSP’s Data Center should conform to at least Tier III standard (preferably certified
under TIA 942 or Uptime Institute certifications by a 3rd party) and implement tool-
based processes based on ITIL standards.
f) Payment Card Industry (PCI) DSS - compliant technology infrastructure for storing,
processing, and transmitting credit card information in the cloud
2.4.3.3 Functional Requirements of the CSP
2.4.3.3.1 Operational Management
a) CSP should provide access of cloud virtual machines either by SSH in case of
Linux and RDP in case of Windows servers.
b) CSP should enable Utility to get console access of cloud virtual machine from
portal and perform operations. There should be facility to view resource type-
35 | P a g e
wise (VM, database, storage etc.) quota usage. It should be possible to configure
automated alerts when the threshold of estimated quota is reached.
c) CSP should upgrade its hardware time to time to recent configuration to delivery
expected performance for this Project.
d) Investigate outages, perform appropriate corrective action to restore the
hardware, operating system, and related tools.
e) CSP should manage their cloud infrastructure as per standard ITIL framework
in order to delivery right services to Project.
f) The CSP should allow different users with different level of access on CSP portal.
For example, billing user should not be able to provision resources or delete any
resources
g) The CSP should allow quota management for each department/ISV/Group.
The resources to specific department/group/ISV should be as per allocated
quota only. If there is any request for more than quota request, then it should be
sent as request to admin.
2.4.3.3.2 Compatibility Requirements
a) CSP should provide capability to import a Virtual Machine (VM) as an image
and support standard formats such as OVA, VMDK, VHD, and raw.
b) CSP should give provision to import cloud VM template from other cloud
providers.
c) CSP should ensure connectivity to and from cloud resources used for this project
is allowed to/ from other cloud service providers if required.
2.4.3.3.3 Cloud Network Requirement
a) CSP must ensure that the non-production and the production environments are
in separate VLANs in the cloud so that users of the two environments are
separated.
b) CSP must ensure that cloud VM are having private IP network assigned.
c) CSP must ensure that all the cloud VMs are in same network segment (VLAN)
even if they are spread across multi data centres of CSP.
d) CSP should ensure that cloud VMs are having Internet and Service Network
(internal) vNIC cards.
e) CSP should ensure that Internet vNIC card is having minimum 1 Gbps network
connectivity and service NIC card is on 10 Gbps for better internal
communication.
f) In case of scalability like horizontal scalability, the CSP should ensure that
additional require network is provisioned automatically of same network
segment.
g) CSP must ensure that public IP address of cloud VMs remains same even if cloud
VM gets migrated to another data centre due to any incident.
h) CSP must ensure that public IP address of cloud VMs remains same even if cloud
VM network is being served from multiple CSP data centres.
36 | P a g e
i) CSP must ensure that the public network provisioned for cloud VMs is
redundant at every point.
j) CSP must ensure that cloud VMs are accessible from Utility private network if
private links P2P/MPLS is used by Utility
k) CSP must ensure that there is access to cloud VMs if Utility requires to access it
using IPSEC/SSL or any other type of VPN.
l) CSP should ensure that cloud VM network is IPV6 compatible.
m) CSP should ensure use of appropriate load balancers for network request
distribution across multiple cloud VMs.
2.4.3.3.4 Cloud data centre specifications
a) All the physical servers, storage and other IT hardware from where cloud
resources are provisioned for this project must be within Indian data centres only.
b) Selection of DC-DR site architecture shall be in accordance with applicable laws
including but not limited to the “Disaster Recovery Best Practices” guidelines
issued by the Ministry of Electronics & Information Technology (MEITy) and as
amended from time to time”.
c) The CSP data centres should have adequate physical security in place.
d) The Data Centre should conform to at least Tier III standard (preferably certified
under TIA 942 or Uptime Institute certifications by a 3rd party) and implement
tool-based processes based on ITIL standards.
2.4.3.3.5 Cloud Storage Service Requirements
a) CSP should provide scalable, dynamic and redundant storage.
b) CSP should offer provision from self-provisioning portal to add more storage as
and when require by respective Utilities.
c) CSP should clearly differentiate its storage offering based on IOPS. There should
be standards IOPS offering per GB and high-performance disk offering for OLTP
kind of workload.
d) CSP should have block disk offering as well as file/object disk offering to address
different kind of Project needs.
e) The CSP should retain AMI data for years defined based on regulatory provisions.
2.4.3.3.6 Cloud Security Requirements
a) CSP should ensure there is multi-tenant environment and cloud virtual resources
of this project are logically separated from others.
b) CSP should ensure that any OS provisioned as part of cloud virtual machine
should be patched with latest security patch.
c) In case, the CSP provides some of the System Software as a Service for the project,
CSP is responsible for securing, monitoring, and maintaining the System and any
supporting software.
d) CSP should implement industry standard storage strategies and controls for
securing data in the Storage Area Network so that clients are restricted to their
allocated storage
37 | P a g e
e) CSP should deploy public facing services in a zone (DMZ) different from the
application services. The Database nodes (RDBMS) should be in a separate zone
with higher security layer.
f) CSP should give ability to create non-production environments and segregate (in
a different VLAN) non-production environments from the production
environment such that the users of the environments are in separate networks.
g) CSP should have built-in user-level controls and administrator logs for
transparency and audit control.
h) CSP cloud platform should be protected by fully managed Intrusion detection
system using signature, protocol, and anomaly-based inspection thus providing
network intrusion detection monitoring.
2.4.3.3.7 Data Management
a) CSP should clearly define policies to handle data in transit and at rest.
b) CSP should not delete any data at the end of agreement without consent from
Utility.
c) In case of scalability like horizontal scalability, the CSP should ensure that
additional generated data is modify/deleted with proper consent from Utility.
2.4.3.3.8 Managed Services
a) Network and Security Management:
i. Monitoring & management of network link proposed as part of this Solution.
Bandwidth utilization, latency, packet loss etc.
ii. Call logging and co-ordination with vendors for restoration of links, if need
arises.
iii. Addressing the ongoing needs of security management including, but not
limited to, monitoring of various devices / tools such as firewall, intrusion
protection, content filtering and blocking, virus protection, and vulnerability
protection through implementation of proper patches and rules.
iv. Ensuring that patches / workarounds for identified vulnerabilities are patched
/ blocked immediately
v. Ensure a well-designed access management process, ensuring security of
physical and digital assets, data and network security, backup and recovery
etc.
vi. Adding/ Changing network address translation rules of existing security
policies on the firewall
vii. Diagnosis and resolving problems related to firewall, IDS/IPS.
viii. Managing configuration and security of Demilitarized Zone (DMZ) Alert /
advise Utility(s) about any possible attack / hacking of services, unauthorized
access / attempt by internal or external persons etc.
b) Server Administration and Management:
i. Administrative support for user registration, User ID creation, maintaining
user profiles, granting user access, authorization, user password support, and
administrative support for print, file, and directory services.
38 | P a g e
ii. Installation/ re-installation of the server operating systems and operating
system utilities
iii. OS Administration including troubleshooting, hardening, patch/ upgrades
deployment, BIOS & firmware upgrade as and when required/ necessary for
Windows, Linux or any other O.S proposed as part of this solution whether
mentioned in the EOI or any new deployment in future.
iv. Ensure proper configuration of server parameters, operating systems
administration, hardening and tuning
v. Regular backup of servers as per the backup & restoration
vi. Managing uptime of servers as per SLAs.
vii. Preparation/ update of the new and existing Standard Operating Procedure
(SOP) documents on servers & applications deployment and hardening.
2.4.3.3.9 Business Continuity Plan & Backup Services

As part of a business continuity plan, the Utility has made a business impact analysis
in the event of loss of AMI applications running in the cloud and consequent loss of
data to come up with a management plan for the associated risk to business operations.
Central to this risk management strategy, the Utility has defined the following target
objectives:
a) Recovery Time Objective (RTO): Duration of time and a service level within which
a business process must be restored after a disruption in order to avoid unacceptable
consequences associated with a break in continuity of service. The RTO of [X hours]
“<X> hours defined in tender by Utility” shall be met by infrastructure redundancy and
failover.
b) Recovery Point Objective (RPO): Interval of time that may pass during a disruption
before the quantity of lost data during that period exceeds the business continuity
plan’s maximum allowable threshold. The RPO of [X hours] “<X> hours defined in
tender by Utility” shall be met by a suitable backup and replication strategy of
operational data / application. The RPO shall define how fast the replicated data /
application can be made available to the target system after a disruption strikes.
With these two objectives, the CSP shall provide the following:
a) CSP must provide backup of cloud resources. The backup tool should be
accessible
b) To perform backup and restore management as per policy & procedures for
backup and restore, including performance of daily, weekly, monthly, quarterly
and annual backup functions (full volume and incremental) for data and
software maintained on the servers and storage systems using Enterprise Backup
Solution.
c) Backup and restoration of Operating System, application, databases and file
system etc. in accordance with defined process / procedure / policy. Monitoring
and enhancement of the performance of scheduled backups, schedule regular
testing of backups and ensure adherence to related retention policies
39 | P a g e
d) Ensuring prompt execution of on-demand backups & restoration of volumes,
files and database applications whenever required.
e) Real-time monitoring, log maintenance and reporting of backup status on a
regular basis. Prompt problem resolution in case of failures in the backup
processes.
f) Media management including, but not limited to, tagging, cross-referencing,
storing (both on-site and off-site), logging, testing, and vaulting in fireproof
cabinets if applicable.
g) Generating and sharing backup reports periodically
h) Coordinating to retrieve off-site media in the event of any disaster recovery
i) Periodic Restoration Testing of the Backup
j) Maintenance log of backup/ restoration
k) CSP should provide network information of cloud virtual resources.
l) CSP must offer provision to monitor network uptime of each cloud VM.
2.4.3.3.10 Web Application Firewall (WAF) as Service

a) Cloud platform should provide Web Application Filter for OWASP Top 10
protection
b) CSP WAF should be able to support multiple website security.
c) CSP WAF should be able to perform packet inspection on every request covering
the 7th layers.
d) CSP WAF should be able to block invalidated requests.
e) CSP WAF should be able to block attacks before it is posted to website.
f) CSP WAF should have manual control over IP/Subnet. i.e., Allow or Deny
IP/Subnet from accessing website.
g) The attackers should receive custom response once they are blocked.
h) CSP must offer provision to customize response of vulnerable requests.
i) CSP WAF should be able to monitor attack incidents and simultaneously control
the attacker IP.
j) CSP WAF should be able to Grey list or Backlist IP/Subnet.
k) CSP WAF should be able to set a limit to maximum number of simultaneous
requests to the web server & should drop requests if the number of requests exceed
the threshold limit.
l) The WAF should be able to set a limit to maximum number of simultaneous
connections per IP. And should BAN the IP if the threshold is violated.
m) CSP WAF should be able to set a limit to maximum length of path to URL.
n) CSP WAF should be able to limit maximum size of request to Kilobytes.
o) CSP WAF should be able to limit maximum time in seconds for a client to send
its HTTP request.
40 | P a g e
p) CSP WAF should be able to BAN an IP for a customizable specified amount of
time if the HTTP request is too large.
q) CSP WAF should be able to limit maximum size of PUT request entity in MB
r) The WAF should be able to close all the sessions of an IP if it is ban.
s) CSP WAF should be able to ban IP on every sort of attack detected and the time
span for ban should be customizable. There should be a custom response for Ban
IP.
t) The Dashboard should show a graphical representation of
i. Top 5 Attacked Websites.
ii. Top 5 Attacking IP.
iii. Top 5 Attack types.
iv. Top 5 Attacked URLs.
u) For analysis purpose the Dashboard should contain following information:
i. Number of requests to web server.
ii. Number of attacks.
iii. Number of Attackers.
iv. Types of error messages and on. Of error messages sent to the users.
v. Total Bytes sent during transaction
2.4.3.3.11 Database support service
a) Installation, configuration, maintenance of the database (Cluster & Standalone).
b) Regular health check-up of databases.
c) Regular monitoring of CPU & Memory utilization of database server, Alert log
monitoring & configuration of the alerts for errors.
d) Space monitoring for database table space, Index fragmentation monitoring and
rebuilding.
e) Performance tuning of Databases.
f) Partition creation & management of database objects, Archiving of database
objects on need basis.
g) Patching, upgrade & backup activity and restoring the database backup as per
defined interval.
h) Schedule/review the various backup and alert jobs.
i) Configuration, installation and maintenance of Automatic Storage Management
(ASM), capacity planning/sizing estimation of the Database setup have to be
provided and taken care by the Empanelled Agencies.
j) Setup, maintain and monitor the ‘Database replication’ / Physical standby and
Assess IT infrastructure up-gradation on need basis pertaining to databases.
41 | P a g e
2.4.3.3.12 Factory acceptance testing:
a) The functional performance test shall verify all features specified in respective
technical specifications of equipment/ systems along with cloud services &
software using selected communication paths.
b) The data exchange between central systems shall also be simulated in the factory
test environment. Contractor shall submit the documents for tests and test
procedures for approval of Utility.
2.4.3.4 Security
Further, commercial CSPs offer cloud services to multiple consumers. In such an
environment, the security controls and compliance to various standards (Including ISO
27001, ISO 27017, and ISO 27018) should be verified by third party auditors. Third-party
certifications and evaluations provide assurance that effective physical and logical security
controls are in place.
Although, the Cloud Service Providers (CSPs) offer assurances of effective physical and
logical security controls through the third-party certifications such as ISO 27001, ISO 27017,
ISO 27018, etc. and also may provide a host of security services such as encryption, web
application firewall, etc., it is the responsibility of the Empanelled Agencies to define the
security services that need to be implemented for their workloads depending on the nature
of the applications / data hosted on the cloud.
Now a days, CSPs offer tools and features to help consumers to meet their security objectives
concerning visibility, auditability, controllability, and agility. These tools and features
provide basic but important security measures such as Distributed Denial of Service (DDoS)
protection and password brute-force detection on CSP’s accounts.
However, the following basic security features should be ensured by any CSP-
a) Strong encryption capabilities for data in transit or at rest
b) Firewalls – instance and subnet levels
c) Identity and Access Management (IAM): Control users' access to cloud services. Create
and manage users and groups, and grant or deny access
d) Managed Threat Detection: Managed threat detection service that provides you with a
more accurate and easy way to continuously monitor and protect your cloud accounts
and workloads
e) Managed DDoS Protection: Managed Distributed Denial of Service (DDoS) protection
service that safeguards web applications running on cloud.
f) Web Application Firewall: Helps protect your web applications from common web
exploits that could affect application availability, compromise security, or consume
excessive resources.
g) Key Management Service (KMS): Managed service that makes it easy for you to create
and control the encryption keys used to encrypt your data
h) Certificate Manager: Easily provision, manage, and deploy Secure Sockets
Layer/Transport Layer Security (SSL/TLS) certificates.
i) Cloud HSM: Meet regulatory compliance requirements for data security by using
dedicated Hardware Security Module (HSM) appliances within the Cloud.
42 | P a g e
j) Inspector: Automated security assessment service that helps improve the security and
compliance of applications deployed on cloud
k) Organizations: Policy-based management for multiple consumer accounts. With
Organizations, you can create groups of accounts and then apply policies to those
groups.
CSPs also offers access to additional third-party security tools (e.g., IDS / IPS, SIEM) to
complement and enhance the consumers’ operations in the Cloud. The third-party security
tools complement existing Cloud services to enable consumers to deploy a comprehensive
security architecture. These security tools on cloud are equivalent and identical to the
existing controls in an on-premises environment.
The Empanelled Agencies needs to review and validate the security configurations, review
the notifications and patches released by the CSP and validate that the same is being taken
into consideration during operations, confirm that the audit trails (e.g., who is accessing the
services, changes to the configurations, etc.) are captured for supporting any downstream
audits of the projects by the finance or audit organization such as STQC.
2.4.3.5 Reporting
Further, the Empanelled Agencies should insist on the following regular reporting by CSP
during the contract:
a) Availability of the cloud services being used
b) Summary of alerts that are automatically triggered by changes in the health of those
services.
c) Summary of event-based alerts, providing proactive notifications of scheduled
activities, such as any changes to the infrastructure powering the cloud resources
d) Reports providing system-wide visibility into resource utilization, application
performance, and operational health through proactive monitoring (collect and track
metrics, collect and monitor log files, and set alarms) of the cloud resources
e) Auto-scaling rules and limits
f) In case of any un-authorized access, the Agency should provide logs of all user activity
within an account, with details including the identity of the API caller, the time of the
API call, the source IP address of the API caller, the request parameters, and the
response elements returned by the cloud service. This is required to enable security
analysis, resource change tracking, and compliance auditing
g) Report of all the provisioned resources and view the configuration of each.
h) Summary of notifications, triggered each time a configuration changes
i) Incident Analysis in case of any un-authorized configuration changes.
j) Summary of alerts with respect to security configuration gaps such as overly permissive
access to certain compute instance ports and storage buckets, minimal use of role
segregation using Identity and Access Management (IAM), and weak password policies
k) Summary of security assessment report that identifies the possible improvements
(prioritized by the severity) to the security and compliance of applications deployed on
cloud
43 | P a g e
l) Report on upcoming planned changes to provisioning, either possible optimizations, if
any, indicating how the underutilized services can be reduced to optimize the overall
spend, or required enhancements (e.g., upgrade to additional storage) to meet the
service levels defined in the EOI.
2.4.4 Database
2.4.4.1 Initial Database Generation
Development Tools
The Empanelled Agencies shall provide all necessary software tools for the development and
maintenance of the databases required for AMI application.
This tool shall be capable of managing the entire system database. The database
development software tool delivered with the system shall be used to generate, integrate and
test the database. The system must support export of data into XML format.
The database development tool shall facilitate exchange of both incremental and full data in
standard exchange format. The product should have facility to export and import databases
from different vendors applications.
2.4.4.2 Management
The database manager shall locate order, retrieve, update, insert, and delete data; ensure
database integrity; and provide backup and recovery of database files. The database manager
shall generate and modify all AMI application data by interfacing with all database structures.
In systems with a distributed database, the database manager shall have access to all portions
of the database wherever stored.
Execution of the database manager in any server of the system shall not interfere with the on-
line functions of AMI applications including the normal updating of each server's real-time
database. In a primary server, database editing shall be limited to viewing functions, database
documentation functions and functions that change the contents but not the structure of the
database. Editing the on-line database shall not affect the operation of the primary/backup
configuration.
The database manager shall include the mechanisms, in both interactive and batch processing
modes, to perform the following functions:
a) Add, modify and delete database items and data sources such as data links, and local
I/O.
b) Add, modify and delete application program data
c) Create a new database attribute or new database object
d) Resize the entire database or a subset of the database
e) Redefine the structure of any portion of the database.
The Empanelled Agencies shall be required to provide whether they require or impose any
particular hardware and database management techniques to achieve above functionality.
2.4.4.3 Tracking Changes
The database manager utility shall maintain Audit trail files for all changes made by all users
(both online/off-line). The audit trails shall identify each change including date and time
stamp for each change and identify the user making the change. Audit trail of past [1] year
edit operations shall be maintained.
44 | P a g e
2.4.4.4 Integration
The System should support exchange of data from utility’s computerized billing &
collection, consumer indexing and asset mapping systems residing at different servers.
2.4.5 Display Generation, Management and Integration (Display Management and Reporting)
The Empaneled Agency shall provide necessary software tools preferably browser based for the
generation, management and Integration of AMI application displays.
The displays shall be generated and edited interactively using this display generation software
delivered with the system. All displays, symbols, segments, and user interaction fields shall be
maintained in libraries. The size of any library and the number of libraries shall not be
constrained by software. The display generator shall support the creation, editing, and deletion
of libraries, including copying of elements within a library and copying of similar elements
across libraries. Execution of the display generator functions shall not interfere with the on-line
AMI application functions.
Displays shall be generated in an interactive mode. The user shall be able to interactively:
a) Develop display elements
b) Link display elements to the database via symbolic point names
c) Establish display element dynamics via database linkages
d) Define linkages to other displays and programs
e) Combine elements and linkages into display layers
f) Combine display layers into single displays.
All workstation features and all user interface features defined in this specification shall be
supported by the display generator software.
The display generator shall support the addition, deletion and modification of segments,
including the merging of one segment with another to create a new segment.
Displays shall not be limited by the size of the viewable area of the screen.
The displays shall be constructed from the display elements library. The display definition shall
allow displays to be sized to meet the requirements of the AMI application for which they are
used. The display generation software shall allow unbroken viewing of the display image being
built as the user extends the size of the display beyond the screen size limits.
The display generator shall support the integration of new and edited displays into the active
display library. During an edit session, the display generation software shall allow the user to
store and recall a partial display. To protect against loss of display work when a server fails, the
current work shall be automatically saved every five minutes (user adjustable) to an auxiliary
memory file.
The display generator shall verify that the display is complete and error-free before integrating
the display into the active display library. It shall not be necessary to regenerate any display
following a complete or partial system or database generation unless the database points linked
to the display have been modified or deleted.
The system shall generate reports for all the modules in user-defined formats. The system will
have a graphical user interface with a capability for generating customized reports, apart from
the regular ones mentioned above, as per the requirement of management and operations staff.
Display of statistical data shall be presented additionally in graphical formats such as bar-
45 | P a g e
graph/pie diagram etc. for convenience of analysis.
2.4.6 Software Utilities
Empaneled Agency shall supply all software utilities used to develop and maintain this software,
whether or not specifically described by this Specification. The software utilities shall operate
on-line (in background mode) without jeopardizing other application functions running
concurrently. Utility software shall be accessible from workstations, processor terminals and
servers.
2.4.6.1 Auxiliary Memory Backup Utility
Software utility, to take back-up of auxiliary memory files of server and workstation onto a
user- selected archival device such as SAN, shall be installed. Backup shall be maintained for
the entire duration of contract period. The backup utility shall allow for user selection of the
files to be saved based on:
a) Server and workstation
b) File names (including directory and wildcard designations)
c) File creation or modification date and time
d) Whether or not the file was modified since the last backup.
Further a utility for taking image backup of auxiliary memory files of the Servers and
workstations shall be provided. The utility shall allow restoration of the servers/workstation
from this image backup without requiring any other software. An image backup of the as
built system of each of the Servers and workstations shall be provided on a user-selected
archival device such as SAN, which shall be used to restore the system. Automatic full or
incremental back up capability of selected systems at user defined intervals shall be provided.
It should be possible to restore or recover any software/system at a selected time from
backup.
2.4.6.2 On-Line Monitoring Diagnostics Utility
On-Line monitoring diagnostic programs shall be provided for verifying the availability of
the backup equipment and for limited testing of devices without interfering with on-line
operations of AMI application system or the failover capability of the devices.
Redundant communication line interface equipment shall be tested by periodically retrieving
data over these lines and checking for the ability to communicate with the redundant channel
for any errors.
Designated backup server(s) and associated auxiliary memories shall be automatically tested
for proper operation to ensure they are ready if needed for a failure over contingency. Any
failure to perform diagnostic functions correctly shall cause an alarm to be issued.
2.4.6.3 Data Exchange Utilities
Facility of data export and import between this system and external systems shall be
provided through web services.
2.4.6.4 Other Utility Services
AMI Application management shall include the following utility services:
a) Loading and storage of information from labelled portable media storage units as
dictated by the requirements of this specification.
46 | P a g e
b) Preparation of .pdf output for the displays/reports available in the AMI Application
system. It should also be possible to export all the reports to any MS-Office format.
c) Displays and Reports for Web server -The Empanelled Agencies shall provide utilities
for preparing displays and reports suitable for Web publishing. These utilities shall be
used to generate, all required displays and reports from the system displays and reports,
automatically (without requiring rebuilding).
d) Online access to user and system manuals for all software products (e.g., Operating
System and Relational Database Software) and AMI applications shall be provided with
computer system
e) Antivirus Software - All computers and firewalls shall be provided with the latest
antivirus software as on date of supply. The antivirus software shall have the capability
of having its virus definitions updated from time to time. The Empanelled Agencies shall
be responsible for the maintenance & update of the antivirus software during the contract
period.
f) Software Upgrade-The Empanelled Agencies shall be responsible for the maintenance
& update of the patches and signatures of operating system, applications (AMI
Applications) system and Web based System up to the contract period.
g) Automated patch management and anti-virus tools shall be provided to expedite the
distributions of patches and virus definitions to the system using an orchestration facility.
These tools should consider the possibility to use standardized configurations for IT
resources.
2.4.7 Cyber Security – General Guidance
Cyber security governance problems are unique as well as evolving therefore, they cannot be
dealt with a traditional approach. For establishing secure and resilient Smart Meter systems, a
standardized cybersecurity framework should be adopted by the Empanelled Agencies in
consultation with the Utility and relevant stakeholders. The key elements of the cyber security
framework must include:
a) Differentiation of stakeholders into broad categories to aid in proper distribution of
responsibilities among stakeholders and avoid overlapping
b) Defined set of responsibilities for each stakeholder group. As a result, the decision-
making process is streamlined, and proper management hierarchy is established for
handling the reported cyber-attacks. The roles and responsibilities are divided into two
groups:
i. Cyber – strategy and governance: The responsibilities under this group relates to
the policy and decision-making aspects of cyber security framework
ii. Cyber security – risk, operations and compliance: This group comprises of
responsibilities relating to the operational parts of implementing cyber security
policies
c) Standardization of security practices and abundant guidance from knowledge bodies
while implementing security controls and processes. There are multiple global security
standards and Indian standards that are relevant in context of underlying technologies
used in smart meters:
i. National Institute of Standards and Technology (NIST) has developed a
framework for Cyber Physical Systems (CPS). The Framework provides a
47 | P a g e
taxonomy and organization of analysis that allow the complex process of
studying, designing, and evolving CPS to be orderly and sufficiently
encompassing.
ii. Department of Electronics and Information Technology (DeitY), Government of
India has developed a National Cyber Security Policy. It aims at protecting the
public and private infrastructure from cyber- attacks. The policy also intends to
safeguard "information, such as personal information (of web users), financial
and banking information and sovereign data”.
d) Cyber security incident management: The ISO/IEC Standard 27035 outlines a five-step
process for security incident management, including:
i. Prepare for handling incidents.
ii. Identify potential security incidents through monitoring and report all incidents.
iii. Assess identified incidents to determine the appropriate next steps for mitigating
the risk.
iv. Respond to the incident by containing, investigating, and resolving it
v. Learn and document key takeaways from every incident
Notwithstanding the measures suggested above, the following guidelines/strategies shall be
taken care of by the Empanelled Agencies for making the entire AMI system including the
NOMC immune to Cyber Attacks.
a) All the Hardware, OS and application software shall be hardened.
b) Application, scanning and hardware scanning tools shall be provided to identify
vulnerability & security threats.
c) Data shall be encrypted at system/device/technology level.
d) Network Zoning shall be implemented as per the proposed architecture. However, the
Empaneled Agencies may suggest other methods of network architecture without
compromising the security of the System.
e) Internal user shall be allowed to access all adjacent zones. However, they will not have
access to remote network zone.
f) While procuring cyber security items testing must be done and the system must be secure
by design.
g) Residual information risk shall be calculated by Empaneled Agencies and same shall be
submitted to the Utility for approval.
h) All default user id & passwords shall be changed.
i) All log in/out and cable plugs in/ out shall also be logged in Central Syslog server.
j) Penetration & Vulnerability assessment test from CERT-IN certified auditors during
SAT & Operations and Maintenance period.
k) Auditing by third party during SAT and annually during operations and maintenance
period shall be in the scope of Empaneled Agency.
l) As the computer system in NOMC has access to external environment the Empaneled
Agencies shall document and implement Cyber Security Policy/Plan in association with
the Utility to secure the system.
48 | P a g e
m) Latest Cyber Security Guidelines issued by CERT-In specified at http://www.cert-
in.org.in/, Ministry of Power (including “Testing of all equipment, components, and
parts imported for use in the power Supply System and Network in the country to check
for any kind of embedded malware /trojans/ cyber threat and for adherence to Indian
Standards – Regarding” vide Order No. No.9/16/2016-Trans-Part(2) published by
Ministry of Power, Government of India dated 18 November 2020 and amended from
time to time) or any other competent authority shall be followed.
n) Empaneled Agencies shall adhere with the appropriate security algorithm for encryption
and decryption as per established cyber security guidelines. For smooth functioning of
the entire system, it is essential that the Empaneled Agencies shall provide in the form of
a document enough details of such algorithm including the mechanism of security key
generation to the Utility. In case of proprietary or secret mechanism, the same shall be
kept in a secured escrow account.
2.4.8 Data Privacy
Empaneled Agencies should describe ensure that the system is compliant with the applicable
provisions of the “Reasonable security practices and procedures and sensitive personal data or
information Rules, 2011 (IT Act)” as well as shall be committed to work with Utility for
compliance to Personal Data Protection requirements. In this regard, the general elements of
the data privacy framework may include:
a) The Utility shall be the sole custodian of the Smart Meter data. The Empaneled Agencies
and its contracted vendors will have limited need basis access to the data. In case of pre-
mature termination or at the end of contract, the Empaneled Agencies and the contracted
vendors should relinquish all access to the data and transfer the same to the Utility.
b) Empaneled Agencies is required to prepare and submit a “Privacy by Design” document
to the Utility which details out all the policies, practices, processes and technologies
employed to manage, and process the Smart Meter data in a secure manner. This should
also include the details on methods of anonymization applied to the personal Smart Meter
data based on data types defined below:
i. Aggregated Data: No identification individually and at neighborhood level unless
explicitly required to report
ii. Anonymized Data: A data set which has individual Smart Meter data but without
any personally identifiable information like consumer name, account number,
address etc.
iii. Personal Data: A data set with Smart Meter data tagged with personally identifiable
information.
c) AMI system should enable the Utility to get the consumer consent on sharing and
processing of Smart Meter data based on following criteria
i. Consumer consent not required
1) If any type of Smart Meter data is processed by the Utility or a third party on
behalf of Utility for the purpose of generating bills, identifying theft, network
planning, load forecasting or any related activities that can enable the Utility
to fulfil its duty as a licensee.
2) If any type of Smart Meter data is requested by the law enforcement agencies.
49 | P a g e
3) If aggregated or anonymized data is shared with not-for-profit academics,
policy research, civil society entities for research that can benefit the sector in
general.
ii. Opt-out consumer consent
1) If any type of smart meter data is shared with or processed by any third-party
commercial entity to provide services other than as enabled by regulation. In
this case, the AMI system should enable the Utility to conduct the following
consumer consent process
• Consumer should be notified and given a time to opt-out
• Consumer should have the right to change his/her option through the
app/web account/direct communication to Utility.
d) AMI system should enable following Data sharing protocol
i. Data should be shared by providing finite and secure access to the system. The
access can be modified or terminated as need be.
ii. Sharing of part/full database shall be subject to review and consent of Utility.
e) All data sharing shall be recorded and periodically submitted to utility for review /
regulatory requirement
f) Empaneled Agencies should have a data breach response plan and should communicate
to the utility and consumers in case of any data breach from AMI system
g) Empaneled Agencies is responsible to conduct 3rd party data privacy audit at least once
every year based on evaluation criteria pre-identified by the Utility in consultation with
data experts. The audit report should be made available to Utility. Empaneled Agencies
to take necessary actions on audit observations in consultation with the utility.
3. AMI System Integrations

3.1 MDM Integrations with Utility IT/OT Systems
The MDM will act as the bridge to integrate the AMI system with other utility IT/OT systems.
These IT/OT systems may be already existing or those which the Utility have planned. The
IT/OT systems may include but not be limited to the following:
a) Billing, CIS, IVRS, CRM systems
b) Legacy Data Collection Systems
c) HHU/CMRI or manual reading system etc.
d) Consumer Portal/ App
e) GIS
f) SCADA, OMS
g) PLM, DRMS
h) Asset Management System
i) Work Force Management System
j) DT Monitoring System
50 | P a g e
k) EVSE
l) Feeder metering data for various analytical reporting through collecting/pulling data
from utility/ party designated by utility.
The details of the existing integration infrastructure, including specificity in implementation,
interface and services available for each of the existing enterprise applications which the
MDMS has to integrate with the AMI system, shall be provided on case-to-case basis.
For those IT/OT systems which the Utility have planned in future, the MDMS solution
provider shall publish document on available standard interfaces to enable their integration.
It will be necessary to integrate the MDM with the utility IT/OT systems following robust
industry standard mechanisms.
MDM shall interface with these IT/OT systems on standard interfaces. The data exchange
models and interfaces shall comply with CIM-XML-IEC 61968-9 / IEC 61968-100 / Web
Services / MultiSpeak v3.0. MDM solution shall be ESB-SOA enabled.
The aim of the above interface standards is to ensure generic two-way interfacing of the MDM
with other applications. This effort shall be guided by the methodology whose details are
outlined in the approach paper set out in Project Implementation Plan.
3.2 Integration with national level reporting platform
The AMI system put in place should provide a seamless exchange of data with a national level
data portal without any manual interface including NFMS. In this regard, the MDM shall
have an out-bound interface to facilitate data transfer through API-based model/ service bus
to a central platform as and when made available. An indicative data list will be provided by
the Utility for sharing with the national level reporting platform during contract period. The
technical interface (such as web services, published APIs, DB table schemas etc.) for enabling
this integration, will be defined accordingly. However, the MDMS solution provider needs to
ensure the following:
a) Any reports / analytics / graphics from system would provide opportunity to
anonymize/ remove traceability to individual consumers to maintain privacy
b) Reports/data made available in the public domain for public consumption should be
always sufficiently aggregated/ anonymized so as to protect consumer privacy.
4. Consumer Indexing and Meter Installation Application

Consumer Indexing & Meter Installation should be carried out through a robust CI/MI
Application for better tracking and record of field activities. The Mobile based Application for
Consumer Indexing and Meter Installations along with the RECPDCL and Utility specific
customization and development shall be in the scope of the Empaneled Agency. Further the CI
and MI apps so developed and provided shall be well integrated with WFM system provided in
the project along with web interfaces for monitoring of progress of MI and CI and their multiple
validation, MIS, reporting, exception report generation etc. activities. The Empaneled Agency
shall also provide training to Manpower involved in Meter Installation and Consumer Indexing
pertaining to usage of Mobile Application. The schedules and count of trainees shall be mutually
decided at the time of Metering and indexing activity.
4.1 Consumer Indexing (CI)
Site Survey of electrical device and conduct door to door survey to obtain consumer details
51 | P a g e
by consumer indexing (CI), we can find Division/sub division wise location of the consumer
through which feeder, or transformer, or circuit number and or pole consumer is being
supplied. Mobile App should have functionality of capturing the asset condition, Meter
Condition, Meter Height, Meter Location (Inside/outside), Cable Type (un-armoured
/armored) , Consumer Connection Status ( Active /IDF /TD /PD), Others ( Consumer
Denial /Door Locked) and other required information through automated tool or manual
screens, most important Longitude & Latitude (auto-populated) of location using Google
map.
4.2 Meter Installation (MI)
Smart meter installation on the premises as per order received from organization. Meter
installation is the process where Implementing Agency needs to install smart meter
physically on the consumer premises based on the order finalized. There may be different
scenarios i.e. New Service connection, old meter change, smart meter to smart meter change,
Net meter, IDF, Load Enhancement etc. The provision to capture the details against each
case as mentioned above to be provided in the application for paperless activity and the
consumer/ old meter information/new information data should be seamlessly updated to
the AMI/Utility System.
4.3 Inventory Management
Inventory Management is to have readily availability of stock. All inventory of Meters
devices and its accessories are maintained in warehouse and system will provide the actual
inventory status of all devices. This system would be real-time or offline integrated with meter
installation system or other system. Selection of Meter or Asset from Inventory for
installation, meter or device will be automatically deduct the balance of asset from the
inventory. In case of Smart Meter to Smart Meter replacement, inventory will be added as
defective and as well as deducted from the inventory management with meter status (in case
of faulty) with a maker and checker concept. Maintain the inventory of all the meters in
designated warehouse, maintenance and security including full responsibility for protection
from theft and fire. Meter Inventory Management and Warehousing to be maintained by
AMI Implementing Partner on real-time basis.
4.4 Mobile application for Consumer Information, Meter Installation & Meter Advising
(MC)
During consumer indexing and meter installation implementation agency will use
android/iOS based mobile application. Consequently, following are the major scope of work
for installation in the field.
• Consumer Indexing team (for capturing consumer’s information)
• Documentation and Approval of prescribed format for Consumer indexing & Smart
Meter installation and sealing information.
• Resource deployment and Responsibility allocation
• Quality and Safety Assurance during field work
4.5 Work Force Management (WFM)
The Empaneled Agency shall also have to provide a Workforce Management Application.
The application shall have to be integrated with ERP system of the DISCOM as well as
MDM system amongst other application.
Implementing a Workforce Management (WFM) solution in an Advanced Metering
52 | P a g e
Infrastructure (AMI) implementation will require implementation of below functions to
ensure efficiency, accuracy, and seamless operation. The EA shall be required to provide
project specific customization and additional requirements in WFM as per Utility and
RECPDCL requirements.
4.5.1 Resource Allocation and Scheduling
• Assign Task: Assign tasks to field workers based on availability, skills, and proximity.
4.5.2 Work Order Management
• Creation and Assignment: Create, assign, and track work orders related to meter
installations, maintenance, and inspections.
• Status Tracking: Real-time tracking of work order status from creation to
completion.
• Mobile Access: Field workers can access work orders via mobile devices, update
status, and input data on-site.
4.5.3 Field Data Collection

• Integration with AMI Systems: Seamless integration with AMI systems to upload
data and sync with central databases.
• Data Capture: Capture meter readings, installation parameters, and other relevant
data directly from the field (if required).
4.5.4 Route Optimization

• Efficient Routing: Optimize routes for field workers to minimize travel time and
increase the number of tasks completed.
• GPS Integration: Integrate with GPS for real-time navigation and route adjustments.
4.5.5 Communication and Collaboration

• Real-Time Communication: Enable real-time communication between field workers
and central office through messaging or call functionalities.
• Issue Reporting: Field workers can report issues or anomalies encountered during
their tasks and get instant support.
4.5.6 Performance Monitoring and Reporting

• KPI Tracking: Track key performance indicators (KPIs) such as task completion rate,
average time per task, and worker efficiency.
• Reporting Tools: Generate detailed reports on workforce performance, task status,
and overall project progress.
53 | P a g e
4.5.7 Inventory Management (with ERP)
• Material Tracking: Track usage of materials and tools in the field to ensure adequate
supply and prompt restocking.
• Inventory Levels: Monitor inventory levels in real-time and trigger alerts for low stock.
4.5.8 Compliance and Safety

• Regulatory Compliance: Ensure all tasks comply with industry regulations and safety
standards.
• Safety Checklists: Implement safety checklists and protocols that workers must follow
before and during tasks.
4.5.9 Training and Certification Management

• Skill Management: Track the skills and certifications of field workers to ensure they are
qualified for assigned tasks.
• Training Programs: Schedule and manage training programs to keep workforce skills
up to date.
4.5.10 Customer Interaction and Feedback

• Appointment Scheduling: Allow customers to schedule appointments for installations
and maintenance.
• Feedback Collection: Collect customer feedback on service quality and field worker
performance.
4.5.11 Integration with Other Systems

• Billing and CRM Systems: Integrate with billing and customer relationship
management (CRM) systems to ensure consistent data flow.
• AMI Data Integration: Ensure seamless data exchange between the WFM solution and
the AMI system for accurate and up-to-date information.
• ERP System: Integrate with ERP system of the utility/EA for effective control over
inventory.
An effective solution can include business process modeling, automated staking, dispatch,
geographic information system (GIS), and automatic vehicle locating (AVL) systems, as well as
IT system integration to other systems and the supporting communication networks. Because it
works with wireless data systems, a successful implementation involves a number of system
integrations and technologies working together in both normal and emergency response
situations.
It is expected that the WFM application shall Optimize work management processes & include:
• Elimination of in-office and field order duplication
54 | P a g e
• Web-based information with up-to-date order status information available to management
and customer service representatives
• Dramatic reduction in back-office support activities and increased employee productivity
and customer service support
• Dramatic improvement in information management with up-to-date order status information
available to management and customer service representatives
5. Analytics and Reports
5.1 Analytics including Energy Audit
The MDM shall have analysis capability based on configurable business rules including but
not limited to the following:
a) Energy Audit: Perform DT/Feeder/ Sub-Division/ Division/ Circle wise energy audit for
configurable period. These energy audit reports shall clearly bring out the technical and
commercial losses through detailed analysis of supply side energy data and corresponding
aggregated consumption data of connected consumers. There shall be cases wherein few
consumers like Government and other consumers etc., the DTs and the feeders may fall in
other project area however energy accounting of such consumers is to be done by the EA
selected through present EOI.
For such consumers whose smart meters have already been installed or will be installed by
another other agency/Utility/other AMISP etc. i.e. whose smart meters have been
installed or shall be installed in project other than implemented by RECPDCL with the EA
it shall be the responsibility of the EA selected under present EOI, to perform Energy
Accounting and Auditing for the all Smart meters including those DTs, feeders and
consumers (Including Government Consumer etc.) whose smart meters are installed by
other agency/Utility/other AMISP etc. and to generate energy audit and other relevant
reports w.r.t. Feeder, DT and consumer metering by auto collecting/pulling data from
other agency/Utility/other AMISP etc. / party designated by utility through a standard
technical interfaces (such as web services, published APIs, DB table schemas etc.) for
enabling the required integration in proposed MDM. The necessary level of integration for
this shall be done by EA selected through present EOI as per the RECPDCL/Utility’s
/party designated by Utility’s requirement. In this analysis it must factor in data of energy
export from net-metered consumers. The automated audit should include but not limited
to:
I. A daily automatic feeder loss (Feeder Head reading minus summation of all DT
meters readings)
II. Automatic LT Energy loss (DT meter reading minus summation of readings of all
those consumer meters served by the selected DT) would be reported
III. Billing and collection efficiency
IV. Identify the top best as well as worst performing feeders and DTs as defined by
Utility
b) Display consumption/load profiles by configurable period (15/30 min, hour, day, month,
year etc.) day type (weekday, weekend, holiday, festival wise etc.) and by tariff, consumer
55 | P a g e
type (hospitals, schools, govt. offices, multiplexes, commercial, residential, industrial etc.),
or any user specified collection of meters.
c) Generate peak & off-peak load patterns by aggregating all loads of consumer
group/consumer type/DT/Feeder over configurable period/day type.
d) Perform load analysis for different groups and categories of consumers in different weather
conditions.
e) Ability to provide the data to load forecasting, load research or demand response
applications (based on use cases provided in Annexure H) and perform error management
such as missed reads and intermittent meter reads before sharing data with load forecasting,
load research or demand response
f) Ability to configure the system to effectively visualize consumption trends, identify unusual
patterns, and visualize load analysis to understand which assets are being over utilized.
g) Analysing data to identify new patterns of usage, Setting fraud alert / transformer overload
alerts / demand – supply gap alert etc.
h) Ability to receive and store outage and restoration event data from Smart Meters and
outage systems and to log all such events for analysis and also support calculation of
compensation payments for sustained outages. Five reliability indices shall be calculated,
i. System Average Interruption Duration Index (SAIDI), which is sum of all
consumer interruption durations in a given period over total number of consumers
served.
ii. System Average Interruption Frequency Index (SAIFI), which is the total number
of sustained interruptions in a given period over total number of consumers served.
iii. Consumer Average Interruption Duration Index (CAIDI), which is sum of all
consumer interruption durations in a given period over the total number of
sustained interruptions in that given period
iv. Consumer Average Interruption Frequency Index (CAIFI), which is the total
number of sustained interruptions in a given period over the total number of distinct
consumers interrupted in that given period
v. Momentary Average Interruption Frequency Index (MAIFI), which is the total
number of consumer interruptions less than the defined time (1 or 5 minutes) over
the total number of consumers served
These reliability indices shall be calculated for each month, for individual feeders and
aggregated annually for the whole utility. The source data for outage shall be last gasp /
first breath messages from DT/Feeder level meters or the power outage/restoration events
logged by these meters. These computations shall be independent of similar computations
made by any OMS application.
i) Ability to alerts on DT/ Feeder level overvoltage & back-to normal event and under-voltage
and back-to-normal events. Based on these alerts the system should calculate the duration
56 | P a g e
in which the DT/Feeder remained outside the nominal zone of defined voltage. Similar
calculations should be allowed for power factor and current unbalance.
j) Identify & visualize poor performing assets such as feeder/DT on multiple criteria such as
energy losses, outage duration etc. through appropriate colour coding depending on
severity thresholds.
k) Analyse data of net-metering consumers to identify patterns of energy export to grid on
hourly/weekly/monthly/yearly basis.
5.2 Reporting Function
The Report function shall enable the Utility to deliver reports in standard digital format such
as PDF, Excel, etc. All queries for report generation shall be made through user driven drop
down menu through GUI of Utility user interface (refer to Clause 2.5.1 of this Section for
more details). The empaneled agency shall provide example queries to support internal report
generation needs. The GUI shall have provisions to set up or change report delivery to
configurable email addresses, network file directories, ftp sites or printer systems without
modifying source program code and without any proprietary language skills.
5.2.1 The MDM shall generate following reports (an indicative list only). Utility may request for
additional reports as well during the contract period.
i. Daily data collection report
ii. Usage exceptions
iii. VEE validation failures
iv. Missing interval Read date and times (on hourly, daily, weekly & monthly basis)
and their trends
v. Physical meter events (install, remove, connect, disconnect) & meter reset report
vi. Meter flags
vii. Meter inventory
viii. Defective meters
ix. AMI performance measurements
x. Threshold exception
xi. DT condition monitoring
xii. MIS reports and analytical reports including but not limited to following:
1) Payment collection summary and details in a day/week/month/year or as per
user selectable period and trends
2) Number / list of disconnected consumers due to inadequate prepaid account
balance
3) Prepaid consumers running low on account balance
4) Connected consumers
57 | P a g e
5) Critical notifications sent to consumers
6) Revenue analytics as per consumption pattern of consumers (in terms of
money and energy units). This shall also include automatic compensation
payments by Utility to consumers for sustained outages, if implemented
7) Data-driven Analytics reports by leveraging AI/ML based technologies
5.2.2 Following high level reports for Utility Management shall be generated automatically at
specified frequencies to help management with business decisions. <Below is an example of
reports2 that may be generated. These reports should be defined and agreed by the utility>
Category Report Frequency
Energy Audit Report (DT/ Feeder /

Sub-Division/ Division/ Circle wise) in
contiguous electrical locations:
• A daily automatic feeder loss report
(Feeder Head reading minus
summation of all DT meters
Daily, Monthly and User
readings)
Selectable Time Period with
Energy Audit • Automatic LT Energy loss report configurable near real time
(DT meter reading minus alerts for exceeding defined
summation of readings of all those loss threshold
consumer meters served by the
selected DT) would be reported
• Billing and collection efficiency
• Identify the top [X] best as well as
worst performing feeders and DTs
SAIFI and SAIDI; CAIFI and CAIDI;

MAIFI of the feeder(s) and connected
Reliability Indices consumers would be tracked to measure
Selectable Time Period
the improvement in the same overtime
and establishing reference levels

DT Loading (Categorize DT as
overloaded, optimally loaded, near
configurable near real time
optimal, under loaded)
alerts
Load Management
Load recording (Consumers): Actual Daily, Monthly and User
consumption recorded higher than the Selectable Time Period with
sanctioned load identifying the top [X] configurable near real time
consumers alerts
2
These reports shall be generated provided the corresponding DT/ Feeder data is available as part of the AMI
system being installed.
58 | P a g e
Category Report Frequency
Load Management Report (Identify top Monthly and User Selectable

overloaded DTs) and load rise trend Time Period

Voltage Deviation Index and Frequency Selectable Time Period with
Deviation Index (DT/ Feeder) configurable near real time
alerts

Power quality Low Power Factor (DT/ Feeder)
alerts

Meter Current Unbalance (DT/ Feeder)
alerts
Tamper Alert: as per IS 15959 Part 2
Comparison Consumption (system used Daily, Monthly and User

to detect & track theft suspects) Selectable Time Period with
Loss Analytics
Consumption lower than the expected alerts
pattern (pattern of previous year applied
to the monthly average) or monthly
average
Summary report on top [X] high loss

DTs/ Feeders, top overloaded DTs/
Feeders, Top feeders/ DTs with most
Management
outages (number and duration), Top <Monthly and User
Summary Report
feeders with most power quality issues Selectable Time Period>
(Dashboards)
(over voltage, under voltage, current
unbalance, out of band frequency), DTs
with high failure rate
59 | P a g e
5.2.3 The utility interface should have ability to generate reports on critical and non-critical
information received from the HES to the MDM as per Clause 2.3.3 of Section 6. Project
Requirements of AMI SBD v4 and its subsequent amendments.
5.2.4 The utility interface shall have feature to generate report related to SLAs being mentioned in
Clause 7.7 of Section 6. Project Requirements of AMI SBD v4 and its subsequent
amendments.
5.2.5 Ability to generate various analytics reports as per Clause 6.1 of AMI SBD v4 and its
subsequent amendments.
5.2.6 The Empaneled Agency shall submit a detailed report on data being shared as per Clause
2.7.8 on a yearly basis. empaneled agency shall submit detailed report on any exception in
general data sharing on monthly basis. Further, empaneled agency shall also submit a
detailed report for any other time period as requested by utility.
6. Operation and Maintenance

6.1 Scope and Period
The operation, maintenance, and support services start after the successful completion of the
operational go-live of the system as per Clause 9.6 Section-6 of the AMISP SBD v4 issued by
REC Ltd. Operation, maintenance and support services shall extend up to end of Total Meter-
months from Operational Go-Live. The scope of work under operation and maintenance
services shall include,
a) Comprehensive maintenance of all the software related to MDMS and NOMC (including
licensing, version upgrades if any and annual technical support cost)
b) Comprehensive maintenance of all hardware at the Operation and Monitoring Centre,
provided by the empaneled agency under the project.
c) Comprehensive maintenance of all equipment under leased service like cloud data centre,
MPLS band width etc.
d) Day to day operations of the AMI system under supervision and authority of the Utility.
These shall include among others,
i. Changeover of consumer meters from post-paid to prepaid mode and vice versa
ii. Firmware update of remote devices (Meters and DCUs) as required
iii. Update of tariff slabs
iv. Ensuring completion of recharge cycle of prepaid consumer meters
v. Connecting, disconnecting or reducing consumer’s licensed load under approval
from the Utility
vi. Initiating resolution of consumer trouble tickets raised by utility CCS
vii. Ensuring availability of BP, LP, interval data and event notifications from meters in
time schedules as agreed with the utility
viii. Ensuring scheduled completion of billing determinant calculations
ix. Ensuring daily reports from the AMI system as per agreed list, are made available to
utility
x. Ensuring Consumer Portal is kept updated
xi. Ensuring smooth data traffic between the MDM and utility systems
60 | P a g e
xii. Patch management of AMI applications at cloud data centre
xiii. Provide backup data to support SLA and empaneled agency invoicing
xiv. Carry out performance checks of various functions as per agreed schedule or on
demand
As part of their Operation and Maintenance responsibilities, the empaneled agency shall
develop a compendium of Operation and Maintenance Manuals covering the areas mentioned
in serial number e), Clause 7.1 of the Section-6 AMISP SBD v4 published by REC Ltd. These
manuals shall be kept updated as often as necessary to reflect best practices being employed in
the project.
The empaneled agency is to hand hold the Utility team to take over operation, maintenance
and support services after completion of contract period. The project/ system devices should
allow their functionalities to be upgraded without disruption to the existing functionalities by
downloading new software and configuration information. The Empaneled Agency shall
support the RECPDCL in fulfillment all the above responsibilities.
6.2 Empaneled Agency Responsibilities under Operation & Maintenance Services:
The Empaneled Agency shall make available the following man-power resources at the
utility’s Network Operations cum Monitoring Centre,
a) One resident Project Manager cum Supervisor,
b) Three numbers operations staff
c) One support engineer for each category of hardware supplied and
d) One software specialists for each domain.
The above-mentioned operation and support staff shall be made available as required to meet
the SLA and system availability requirements. Re-distribution of any support
engineer/specialist at the cloud Data Centre shall be at the discretion of the EA.
It shall be the responsibility of the Empaneled Agency to collect meter data through handheld
meter reading instruments for the balance meter data reads not fulfilled by the automated
remote reading process. Similarly, if the remote connect / disconnect facility fails, it shall be
the empaneled agency’s responsibility to manage the function locally.
6.3 Maintenance Practices:
For all third-party equipment (Hardware & Software) empaneled agency shall have back-to-
back support along with supply of spare with appropriate response time from OEM/OEM
Authorized representatives. empaneled agency shall be responsible for coordination with the
OEM for all matter related to equipment.
The maintenance practice followed by empaneled agency shall be in accordance with best
industry practices and must include the following:
a) Scheduled preventive maintenance, performance monitoring, system backup, hardware
& software maintenance and update, field & network devices firmware update,
emergency response and troubleshooting etc.
b) Maintaining adequate spares for maintenance.
61 | P a g e
6.3.1 Preventative Maintenance Activity
The preventive maintenance activities shall be performed by the empanelled agency to keep
the system running at optimum level by diagnosis and rectification of all hardware and
software failures and would broadly include:
a) Repair / replacement of defective equipment
b) Configuration of the replaced hardware and software, periodic routine checking as part
of a preventive maintenance program
c) Monitoring of the performance of the system and doing necessary tuning for optimum
performance to accommodate any changes such as addition of new components
d) Providing all necessary assistance to the Utility for addition and modification of utility
user interface, consumer Portal/ App displays, and Database
e) Ensure Backup of the system at regular interval which is mutually decided during
system design
f) Restoration of the systems upon its failure and to restore the functioning of the various
application / systems at the cloud data centre. Towards this, the RPO and RTO shall
have to be measured no less than once a month.
6.3.2 Integration of Equipment
All future services, protocol emulations and configuration support for integration of Smart
Meters/ nodes, routers, access points, network devices, web services, integration with other
offline applications etc. shall be the responsibility of empanelled agency and shall be part
of the maintenance activities.
6.3.3 Spares inventory
As part of project implementation plan, the empaneled agency shall detail the spares
inventory that shall be maintained for the AMI Project. These spares shall be used as and
when required by the empaneled agency for the project and no separate charges shall be
payable. The empaneled agency shall decide the items and components to be maintained
as spare.
6.4 Monitoring
The operation and performance of the various systems shall be monitored on a continuous
basis. The empaneled agency shall conduct at least the following monitoring:
a) MDM / HES system error history logs or selected day
b) Field & Network device failure – rate and trends
c) Availability of various communication links
d) Missing meter data – rate and trend
e) Reviewing resource information
f) Cyber Security
62 | P a g e
During monitoring if any defect/ abnormality is found, the Empaneled Agency shall
undertake corrective maintenance for the same. The Utility’s UI shall be integrated and be
kept updated with a summary of such monitored data.
6.4.1 System Cyber Security Monitoring

The Empaneled Agency shall also be responsible for monitoring of the system from cyber
security perspective. The logs of the system shall be analyzed for exceptions and the possible
incident of intrusion/trespass shall be informed to the Utility and analyzed to discover root
cause. The monitoring shall encompass all cyber security devices installed at the cloud data
center as well as at the NOMC such as firewalls, all types of Intrusion prevention system,
routers etc.
The Cyber security system shall also be subjected to Annual Security Audit from CERT-In
listed auditors at the cost of the empanelled agency during the contract period. empanelled
agency shall share with Utility such audit reports and implement the
recommendations/remedial actions suggested by the Auditor.
7. Training Requirements
7.1 Training Categories
The Empaneled Agency is required to organize following categories of training for the Utility
personnel:
a) Professional Training - This is the training for the core group of implementation team of
the Utility. This team will comprise of members from all the Business Functions and IT
sections. Each member would be trained in the relevant function/ module. This Training
would be required to be given to approximately [X] personnel. It is the responsibility of
empaneled agency to deliver this training. Standard curriculum designed and agreed by
the Utility for hardware, software and network preferably shall be arranged by the
empaneled agency for each group. The Utility will prefer if a portion of the training is
conducted on-site.
b) End User Training - The Empaneled Agency will provide training to the owner’s team
on a "Train the Trainer" basis. The Utility’s team so trained will then train all of the
Utility’s end users. It is estimated that this training will require around [X] groups, with
each group comprising of around [X] persons. These training sessions will be required to
be conducted at any of the sites. The recommended training material can be in paper /
electronic media with courses on Business Process Automation software fundamentals,
business process overview, job activity training, and delivery options being on-line, CBTs,
instructor led classrooms, etc.
7.2 Training modules
The training modules shall include but not be limited to <Utility to update the list of training
as required>:
a) AMI Administration & Configuration
b) AMI Installation and troubleshooting
c) Application Management and Operations
63 | P a g e
d) Database and Data Analysis Reports
e) Cyber Security
f) Smart Meter and communication technology
An indicative list of training is as provided below.
Duration in weeks Total Man-weeks
Item No. of At At
Description At At
No. Trainees empaneled empaneled
Utility’s Utility’s
agency’s agency’s
facility facility
facility facility
1 Smart Grid components 30 1 1 30 30

Hardware and Software
Course
2 Database, Report and 10 1 1 10 10

Analytic Building Course
3 Application Software 20 1 2 20 40
4 Operator training & 40 1 0 40 0

Maintenance course
5 Smart Meter & 15 1 0 15 0

Communication network
6 Cyber Security Training 5 0 1 0 5

course
Total 120 5 5 115 85
7.3 Training Schedules

As part of the project implementation plan (refer Clause 10.1 of AMISP SBD v4 issued by
REC Ltd.), the Empaneled Agency shall draw up a training schedule in consultation with the
Utility. This will enable the Utility representatives gain knowledge and understanding of the
activities during the following stages of the project implementation, so that they may discharge
effective oversight and witness capabilities.
1. Pre-FAT
2. Pre-Operation Go-Live
3. Operation and Maintenance
4. End of Contract
The training modules as described in Clause 8.2 shall be distributed among these phases of the
training schedule and mutually agreed.
64 | P a g e
7.4 General Requirements
General requirement for training to be imparted is as follows:
a) Training shall be conducted by the Empaneled Agency personnel who are experienced
instructors and speak understandable [language name].
b) The Empaneled Agency shall provide training to various user groups nominated by the
Utility. The empaneled agency shall provide the Training Approach in the response
c) All necessary training material shall be provided by the Empaneled Agency. Each trainee
shall receive individual copies of documents used for training. Training material shall be
organized by functional process that will serve as the training documentation for a
particular functional area.
d) Training materials, including the documents provided to the trainees as well as handouts,
shall become the property of the Utility. The Utility reserves the right to copy such
materials, but for in-house use only.
e) For all trainings the travel expenses of the Utility will be borne by the Utility.
f) The schedule, location, detailed contents, for each course shall be finalized during detail
engineering. The number of participants in the training program may undergo change.
However, all the training courses shall preferably be conducted in single batch. Training
shall be done in batches comprising of Introduction, Basic and Advanced categories.
g) The training will consist of a curriculum of courses to address the issues of system
operation, system troubleshooting, business-wide application, changed business processes
and general use of the new system.
h) Representatives from the empaneled agency, Utility’s project management teams will be
involved throughout in the development of training strategy, training material design and
development, standards and training delivery to ensure that change management issues
are incorporated, and that training strategies and materials are aligned to the requirements
of the project and as business-specific as possible.
i) Two Engineer’s from the Utility shall be stationed at the empaneled agency’s works during
development/customization of solution as per the EOI. The deputed utility engineers shall
be involved with the project till its completion.
8. Test, Inspections and Management of the Quality Assurance / Quality

Control Program
8.1 Responsibility of Tests and Inspection
Test and inspections are in the complete purview of the Empaneled Agency and its sub-
vendors. It shall be ensured that there are no conflicts in roles played between Empaneled
Agency personnel carrying out tests / inspections, and those assigned responsibilities of
quality assurance (QA) and quality control (QC).
The QA/QC organization of the Empanelled Agency shall be an independent administrative and
functional structure reporting via its manager to the Empanelled Agency’s top management. The
QA/QC manager(s) shall have the authority within the delegated areas of responsibility to resolve
all matters pertaining to quality when actual quality deviates from that stated in the Work
Statement. The personnel performing QA/QC functions shall have well-defined responsibility,
65 | P a g e
authority, and organizational freedom to identify and evaluate quality problems and to initiate,
recommend, or provide solutions during all phases of the Contract.
The QA/QC Manager designate for the project shall be the custodian of all inspection and test
records/certificates. QA/QC Manager either directly or through its authorized representative
shall be responsible for all witness testing, approval of test records and in general, management
of the QA/QC program of the project.
The responsibility for inspections and tests is borne by the Inspections and Tests Manager.
This team is responsible for creating the various inspection and test procedures and under the
general supervision of the QA/QC Manager, conducts the tests.
In the event any imports are required for the purposes of this Empaneled Agency Contract,
such imports shall be in accordance with all applicable laws including those issued by Ministry
of Power (Order No. No.9/16/2016-Trans-Part(2) dated 18 November 2020; as amended
and/ or modified from time to time) for testing of imports including those from prior reference
countries.
8.2 Field Installation and Integration Test (FIIT)
Before the start of the FIIT, the following steps have to be completed:
a) Sample Routine & Acceptance Tests for Smart Meters
These tests for Smart Meters as specified in clause 9.2.5.2 may be repeated at the discretion of
the Utility on lots received in the warehouse of the empanelled agency at site.
The sample Routine and Acceptance tests as per IS 13779 and IS 14697 shall be performed
in a third-party accredited laboratory. The Utility shall have the authority of selecting the
samples (in accordance with IS 13779 and IS 14697) for carrying out the Routine and
Acceptance Tests. The empaneled agency shall be obliged to undertake these tests at their
own cost. The conformity requirement shall follow IS 13779 and IS 14697 as the case may
be.
b) All field level hardware which has undergone FAT shall be installed at the site and the
installation report signed off.
c) Before the delivery of the first lot of field devices (meters/DCUs etc.),
a. The production hardware (servers, WS, LAN/Routers, FW, etc.) and software shall
be provisioned at the cloud data centre.
b. The IT hardware shall be installed and made functional at the NOMC with requisite
connectivity to the cloud data centre.
d) The installed field hardware shall be configured and registered in the production
environment of the cloud data centre.
e) It shall be ensured that the smart meter deployment follows a contiguous area coverage
plan. This is to mean for each installation of DT meter, attempt shall be made to prioritize
deployment of all downstream consumer meters and for each installation of feeder meter,
similar effort shall be made to prioritize deployment of all downstream DT/Boundary
meters. However, this requirement of contiguous area coverage plan may exclude
dispersed metering for certain industrial, commercial and government consumers at non-
contiguous electrical locations as per the scope of work
66 | P a g e
It shall be the responsibility of the empaneled agency to devise the FIIT tests regime. The tests
regime so developed shall be shared with the Utility at the time of submittal of the QA Plan.
Any comments received from the Utility shall be addressed within the FIIT. At the minimum
the following tests shall be performed.
a) Proper registration of the incoming population of field devices
b) Checking of user interface linkages with database
c) Remote configuration downloads and reading of profiles
d) If required checking of new meter readings with existing meter readings.
e) Forced event creation and communication of such events
f) Performance tests of device communication links
g) Device communication link failover
h) Integration tests with the MDM in line with a use case table to be drawn up by the
empaneled agency. A use case table is provided in Clause 2.4 of this Section for reference
purpose
Appropriate notice shall be sent to the Utility by the QA/QC Manager before the start of the
FIIT test regimes to enable the Utility to witness the same.
8.3 Tests on receipt of complaint by consumer
During the project period, in case of receipt of complaint by consumer of faulty meter reading
within three months of installation, the empaneled agency would follow the policies of the
utility or corresponding regulations that have been laid out. For this purpose, the Utility may
also install its own check meter. In case of any discrepancy, based on the process followed as
per the prevalent utility policy / regulation, the lot shall be subjected to Routine & Acceptance
Test through Third Party NABL Accredited Lab. If the lot is found faulty, the same shall be
replaced by the empaneled agency at its own cost.
8.4 Site Acceptance Test (SAT)

Once the empaneled agency finalizes the SAT schedule, the QA/QC Manager shall invite the
Utility to witness the tests as per their convenience.
SAT shall be carried out with Smart Meters/DCUs in lots as these are delivered and passes
through the Field Installation and Integration tests. The first lot to be subjected to SAT shall
consist of the complete cloud data centre and its hardware and software components along
with supply, installation & integration of a minimum of [5%] Smart Meters/ DCUs (along
with its related hardware and software equipment). The SAT for remaining meter population
shall be staged on monthly basis based on the monthly supply, installation and integration of
Smart Meters (along with its related hardware and software equipment).
The empaneled agency shall start up and check the performance of the equipment of field
locations. All hardware shall be aligned and adjusted, interfaces to all inputs and outputs
installed, operation verified, and all test readings recorded in accordance with the empaneled
agency’s recommended procedures. The SAT shall exhibit generally all functions of the
equipment and duplicate factory test. All variances must be corrected prior to the start of the
SAT. The list of final tests to be carried out in the field shall be listed in the site-testing
document by the empaneled agency. Among others, the site testing document shall include
the following minimum performance tests:
67 | P a g e
Data Type Performance Requirement
1. Load Profile Data Read3
From 98% of the meters in
One-month block load profile for installed meters
12 hours after the midnight
2. Billing Profile Data Read4
From 98% of the meters in
Billing profile data for installed meters
12 hours after the midnight
3. On-Demand Remote reads of meters
Collection of 7 days of interval energy data and the current total

Within 2 minutes
accumulated energy from a selected individual meter
4. Remote connect / disconnect

Action to response for individual meter Less than 3 mins
5. Updating of data on consumer portal/ app
Action performed for active
Updating of individual consumer data on portal/ app after on portal consumers within 5
receiving the data in MDM minutes after receiving the
data in MDM
6. Ping Response with acknowledgement/ response for selected meters
Action performed at 98% of
For installed meters meters within [5] minute;
and
Action performed within 3
For an individual meter
seconds
7. Meter loss and restoration of supply
Alert to be received within 3
Receiving of alert for all affected AMI meters
minutes for 60% of meters
8. Meter Tamper Alerts
Receiving of alert for an individual meter
minutes
9. Power Quality Alerts
Receiving of alert for an individual meter
minutes
10. Firmware upgrade with acknowledgement/ response for selected meters
meters within [18] hours;
For installed AMI meters (for a batch of at least 20% of installed and
base)
Action performed at 99.9%
of meters within [24] hours
3
This performance test shall be done during SAT, from second lot of meters onwards
4
This performance test shall be done during SAT, from second lot of meters onwards
68 | P a g e
Data Type Performance Requirement
11. Remotely altering settings in meter

For installed AMI meters (for a batch of at least 20% of installed meters within [8] hours; and
base)
of meters within [24] hours
12. Remotely read events logs
meters within [30] minutes;
and
For reading the full event log for installed AMI meter Action performed at 99% of
meters within 1 hour; and
of meters within [6] hours.
13. VEE processing
Action performed in [15]
For all installed meters
mins
14. Computation of Billing Determinants
Action performed in [2]
For all installed meters
hours
15. Prepaid Recharge
Payment success to consumer acknowledgement Within 5 mins
• From 90% of meters
within 30 minutes
Payment success to meter update (From MDM to HES to Meter)
• From 99% of meters
within 1 (one) hour
16. Utility User Interface
Manual data entry of new value appears on screen Less than 6 secs
Acknowledgement of any action request Within 3 secs
Display update rate 2 secs
17. Disaster Recovery Capability (Refer to Clause 2.7.3.3.9 of this Section for details)
Recovery Time Objective (RTO) [4 hours] as agreed
Recovery Point Objective (RPO) [2 hours] as agreed
18. On-Demand Remote reads of meters
Collection of 7 days interval energy data and the current total 95% complete within 2 hrs
accumulated energy from a group of 10% of installed base of 100% complete within 4 hrs
meters (configurable)
Interim inspection reports shall be generated if the SAT is unsuccessful at any stage and all variances
shall have to be corrected and recorded. On successful completion of each lot of SAT a clear SAT
Report shall be issued for the benefit of the Utility. These SAT reports shall be signed by both the
Inspection and Tests Manager and the QA/QC Manager.
69 | P a g e
8.5 System Availability Test
QA/QC Manager will be responsible for oversight of the conduct of the availability test. The test
shall consist of normal AMI Systems operations without special test equipment or procedures.
Test records defined in the availability test plan and procedures will be maintained by QA/QC
Manager. The empanelled agency will operate and maintain the system according to procedures
described in the empanelled agency documentation. QA/QC Manager shall raise incident reports
for every incident that is encountered and closed with response time, resolution time and hold times.
AMI systems maintenance on an on-call basis shall be provided by the empanelled agency during
the availability test period. When on-site maintenance support is needed, qualified empanelled
agency personnel shall arrive at the site within maximum four (4) hours of notification and shall
keep records of the progress in problem resolution. For availability purposes, this service response
time and the associated on-site maintenance time shall be taken into account as defined in sections
of “Downtime” and “Hold time”.
The empanelled agency shall maintain an inventory of spare parts, which may be required to
achieve the specified availability. These spares shall be in addition to the mandatory spares. All
spare parts used during the availability test shall be drawn from empanelled agency’s inventory.
8.5.1 Downtime
Downtime occurs whenever the criteria for successful operation defined in Clause 9.6.1 of
this Section are not satisfied. Downtime shall be measured from the start of diagnostic
procedures until full service is restored. In the event of multiple failures, the total elapsed time
for repair of all problems (regardless of the number of maintenance personnel available) shall
be counted as downtime. For onsite response the delay in response time (more than four hours)
shall be added to downtime.
8.5.2 Hold time
During the availability test, certain contingencies may occur that are beyond the control of
any stake holder. These contingencies may prevent successful operation of the system but are
not necessarily valid for the purpose of measuring AMI systems availability. Such periods of
unsuccessful operation may be declared "hold time”. Specific instances of hold time
contingencies are:
a) 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 empanelled
agency -specified procedures within 30 minutes.
b) 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
is operated during periods of power or environmental conditions beyond those specified,
any resultant downtime shall also be considered hold time.
c) Intermittent Failure: Periods during which an intermittent, recurring software or
hardware failure is experienced will be considered hold time, provided that the
empanelled agency is engaged in remedial action and normal functions can be restored by
70 | P a g e
empanelled agency -defined procedures whenever the failure occurs. Instead of
accounting for the actual intermittent downtime, one hour of downtime shall be counted
for each 24 hours of otherwise successful operation while the problem persists.
d) Service Response Time: A maximum four (4) hours of hold time will be allowed for the
empanelled agency to respond to each call for maintenance support.
e) Corrected Design Defect: Hold time may be declared to ensure against similar future
occurrences if a failure occurs due to a defect in system design for which the empanelled
agency defines and implements corrective measures. In such a case, hold time shall be
allowed in increments of 24 hours to allow verification of the corrective action.
8.5.3 Test Duration and Criteria for Acceptance
After the elapse of [120 hours] of cumulative test time, the availability shall be calculated.
Should availability fall short of specified percentage as defined in Clause 9.6.1 of this Section,
the empanelled agency may either (a) Continue the test by moving the starting time of the test
forward and continuing the test until the consecutive hours have been accumulated and the
specified availability has been achieved subject to maximum of 5 days, Or (b) the empanelled
agency may restart the test for 120 hours.
To establish that all failures have been satisfactorily repaired prior to the end of the availability
test, no downtime, intermittent (hold time) failures, or more than one un-commanded fail over
shall have occurred within 48 hours of the test's conclusion.
8.5.3.1 Criteria for successful operation
The AMI system shall be designed to meet the system availability as defined below:
Minimum System
S. No. System Availability
Requirements
1. Smart Meters 99.5%
2. DCU/ AP 99.5%
3. MDM 99.5%
4. HES 99.5%
5. NOMC Hardware such as UPS, Router, etc. 99.5%
6. Utility and Consumer User Interface 99.5%
The total operational time shall not include the hold time. The system shall be considered available
as long as all the requirements defined under Clause 9.5 are available.
8.6 Operational Go Live of the AMI System:
8.6.1 Conditions to be Met for Operational Go Live for the AMI system (based on MDM and
System Integrator’s deliverable in the project)
The Operational Go Live of the AMI system shall be considered as completion of the
71 | P a g e
SAT for [5%] or [25,000] of Smart Meters whichever is less (along with its related
hardware and software equipment) supplied installed and integrated. The Empaneled
agency’s obligations for Operational Go Live of the system shall be deemed to be met
when the following milestones are achieved by Empaneled Agency:
a) Completion of training obligations pre-Operational Go-Live;
b) Integration of [5%] or [25,000] of Smart Meters of the respective project as per the
definition of Go-Live/ UAT specified therein whichever is less (along with its related
hardware and software equipment);
c) Successful completion of SAT for the quantity of Smart Meters as mentioned in serial
no (b) above;
d) Successful completion of system availability test for 120 (one hundred twenty) hour.
This shall be conducted on supplied systems under normal day-to-day operating
conditions. The test shall verify the reliability and integrity of the Field devices,
Central Systems, Communication & networking systems, database, displays, report,
and all communication interfaces.
e) Independent third-party cyber security audit to be done.
The Availability Test mentioned in Clause 9.6.1 (d) Section-6 of AMISP SBD v4 published
by REC Limited is meant for the initial supply as mentioned in Clause 9.6.1 (b) Section-6
of AMISP SBD v4 published by REC Limited. For the subsequent lots of Smart Meters
along with associated equipment, only up to SAT will be required for operationalizing the
lot.
8.6.2 Certification of Operational Go Live
Following the successful completion of System Availability Tests as per Clause 9.5 of this
Section, the empanelled agency has to submit the following documentation to the RECPDCL
Project Manager:
a. Utility certification of training obligations pre-Operational Go-Live
b. SAT and resolved variance reports of initial installation phase co-signed by the QA/QC
Manager and the Inspection and Test Manager.
c. Availability and resolved incident reports of System Availability Test signed by QA/QC
Manager
d. Initial third-party Cyber Security Audit Report
Based on these submittals the RECDPCL shall check for the completeness and accuracy of
the submittals and issue Operational Go Live certificate to the empanelled agency in not more
than [3] days from the date of submittal. Commercial operation shall be effective from the
date of declaration of Go Live of the AMI project the Utility in the project.
9. Manpower Requirements (Per 10 Lakhs of the Project Size.)

9.1 During Implementation Phase (till the period of Installation milestone of the AMI project
at hand):
72 | P a g e
On site:
• Integration Specialists (Experience- 10+ years)
• Data Base Developer- Sr. (Experience- 5+ years)
• Security Specialists (Experience- 10+ years)
• Core Application Developer- Sr. (Experience- 5+ years)
Off site:
• Architecture Specialists (Experience- 10+ years)
• Web/ Mobile Application Developer- Sr. (Experience- 5+ years)
9.2 During O&M Phase (till the period of O&M of the AMI project at hand):
On site:
• Data Base Developer- Jr. (Experience- Less than 5 years)
Off site:
• Web/ Mobile Application Developer- Jr. (Experience- Less than 5 years)
• Core Application Developer- Jr. (Experience- Less than 5 years)
RECPDCL shall be seeking CVs and other details for the experts above purpose for submission of
Bids to the Utility as the case requires. (The Financial quote to be submitted by MDM provider
and System Integrator at later stage ONLY when sought by RECPDCL on case-to-case basis for
tender/project at hand must factor in the costing of above experts)
Further as a part of New Requirement, RECPCL shall also seek the manpower cost to be
submitted as a part of its bid on case basis as per tender/project at hand. The tentative cost sheet
to be submitted later when asked by RECPDCL after the bidder is Empanelled is as:
Person GST Total

Person (L= J X
S.No. Item Description (I)
Month rate Month (applicable (1+K%) Months
rate (J) in) % (K) Required
4 New requirement for software components
Architecture Specialists
4.1 Month
(Experience- 10+ years)
Security Specialists Month
4.2
Integration Specialists
4.3 Month
73 | P a g e
Person Person GST (L= J X Total
S.No. Item Description (I) Month (applicable Months
Month rate (1+K%)
rate (J) in) % (K) Required
Data Base Developer- Sr. Month
4.4
Web/ Mobile Application Month
4.5 Developer- Sr. (Experience-
5+ years)
Core Application
4.6 Month
Developer- Sr. (Experience-
5+ Developer-
Data Base years) Jr.
4.7 Month
(Experience- Less than 5
years)
Web/ Mobile Application Month
4.8 Developer- Jr. (Experience-
Less than 5 years)
Core Application
4.9 Month
Developer- Jr. (Experience-
Less than 5 years)
Total
Please note that the above financial sheet is only descriptive and no financial sheet has to be sent
with the Empanelment documents and the same shall be sought by RECPDCL at later stage on
case-to-case basis for tender/project at hand.
74 | P a g e
6. TERMS OF CONTRACT
a) The EOI shall empanel the vendors initially for 1 year extendable up to 1 year on the same Terms
and Conditions.
b) The Period of engagement shall be as per the definitive agreement executed for project at hand
and shall be not less than 120 months.
c) The Bidder shall have to adhere to the minimum requirement of SBD v4 of AMISP floated by
REC Ltd. and its amendments issued thereafter. Furthermore, the Bidder shall have to conform
to the requirements of Utility specifications pertaining to the project.
d) The Service Provider shall have to sign Contract/ Agreements and provide Contract related
Forms, PO/WO etc, Performance/Client Certificates and other technical/commercial/statutory
documentation at no cost to RECPDCL with respect to the documents to be submitted during
submission of tenders or during the duration of contract, if in case work is awarded to the Bidder
as requested from time-to-time with. For clarity, the documents required shall be in line with the
requirements as per the of the AMISP SBD v4 meant to participate in various AMISP tenders and
to execute AMISP contracts and implement the AMI projects.
e) RECPDCL shall be usage the credentials of empaneled agency for the purpose of bid submission
for various AMISP projects. In case any new documentation is required, the same shall be sought
by RECPDCL on case-to-case basis.
f) The Empaneled agency shall have to enter into agreement with RECPDCL as per Form-23 of
SBD v4 and issue Form-22 of SBD v4 to enable RECPDCL to submit the bid for various AMISP
projects from time to time.
g) RECPDCL is also in the process of Empaneling HES system provider. The MDMS Service
Providers and System Integrator shall have the responsibility to integrate their MDMS with all the
HES systems offered by RECPDCL. Accordingly, all Service Providers of MDMS applying under
this EOI shall be required to extend all possible support to HES system provider engaged under
separate EOI for integration of their MDMS with HES system providers. This envisages that all
MDMS systems are integrated with HES system empaneled by RECPDCL.
h) Post preliminary empanelment, RECPDCL shall provide 7 working days among all the parties
(HES and Communication Infrastructure Service Providers along with MDMS system providers)
to integrate their respective component. No cost shall be paid by RECPDCL to either party for
this integration. Additional integration shall also have to be performed on project-to-project basis.
i) The HES & Communication Infrastructure and MDMS integration is a precursor activity for the
empaneled vendors before calling for Financial Quotations.
j) The Empaneled Agency shall have to arrange the Communication System Provider, in case
Cellular network is required.
k) Based on above activities, RECPDCL shall participate in AMISP tender. The Bidder shall have
to provide quotations for smart meters as requested from time-to-time by RECPDCL in line with
Annexure B. The financial quotation shall be valid till the end of bid validity period of AMISP
tender at hand. In case the bidder doesn’t reply within stipulated time period, RECDPCL shall
proceed with other bidders.
l) The communication technology to be offered for an AMISP Project shall be under the scope of
the Empaneled Agencies. The communication technology thus offered shall maintain the SLAs
75 | P a g e
as required by SBD version 4 and its amendments. There might be additional SLA standards
required by Utility which shall have to be adhered by the Empaneled Agencies.
m) RECPDCL shall sign Definitive Agreement with the empaneled agencies on case-to-case basis on
successful award of AMISP contract to RECPDCL.
n) In case RECPDCL is successfully awarded an AMISP contract, RECPDCL shall award the same
to the empaneled Meter Data Management System (MDMs) Provider and System Integration
services provider based on L1 Quoted. RECPDCL in interest of project and priorities of DISCOM
may vary the quantity of allocation during the execution of project or involve one or more MDM
service provider in a given project at hand.
o) Payment Terms:
a. 5% - Acceptance of successful VAPT of AMISP system inclusive of Meter and HES
solution by Utility
b. 5% - Acceptance of Third-Party Cyber Audit by Utility
c. 5% - Certification of Successful integration and SAT of MDMS system on site with
HES system empaneled by RECPDCL and Utility IT/OT systems
d. 5% - At the time of Project Go-Live (UAT) declared by the Utility
e. 80% - Equal Monthly instalments during O&M Phase.
p) RECPDCL shall keep a Performance Bank Guarantee at the time of Contract Agreement, the
amount and validity of PBG shall be in line with AMISP Contract and shall be proportionate
with AMISP PBG.
q) At the end of installation milestone of AMISP Project, 27 Months, 10% retention shall be released
at the submission of equivalent Bank Guarantee.
r) The Empaneled Agency shall provide complete end-to-end support for its delivered IT solution
during the O&M phase of the project.
76 | P a g e
Annexure A – Covering Letter
[Reference No.]
From:
[Address of the Bidder]
[Telephone No., Fax No., Email]
[Date]
To:
[RECPDCL]
[Address]
Sub: EOI for providing Meter Data Management System (MDMS) system provider and System
Integration Services for Advance Metering Infrastructure (AMI) Prepaid Solution
Ref: [Tender Details]
Dear Sir/ Madam,

We, the undersigned ……………. [Insert name of the Bidder] having read, examined and understood
in detail the EOI for providing Meter Data Management System (MDMS) system provider and
System Integration Services for Advance Metering Infrastructure (AMI) Prepaid Solution basis
hereby submit our Bid comprising of Technical Bid.
1. We give our unconditional acceptance to the EOI including but not limited to all its instructions,
terms and conditions, and formats attached thereto, issued by RECPDCL, as amended. In token
of our acceptance to the EOI, the same have been initialed by us and enclosed to the Bid. We
shall ensure that our Consortium shall execute such requirements as per the provisions of the
EOI and provisions of such EOI shall be binding on us.
2. Fulfilment of Eligibility
We undertake that we fulfil the Qualifying Criteria stipulated in the EOI and fulfil all the eligibility
requirements as the Bidder as outlined in the EOI.
3. No Deviation
We have submitted our Bid strictly as per terms and formats of the EOI, without any deviations,
conditions and without mentioning any assumptions or notes in the said format.
4. Acceptance
We hereby unconditionally and irrevocably agree and accept that the decision made by RECPDCL
in respect of any matter regarding or arising out of the EOI shall be binding on us. We hereby expressly
waive any and all claims in respect of Bid process.
We confirm that there are no litigations or disputes against us, which materially affect our ability to
fulfil our obligations with regard to fulfilling our obligations as per the EOI.
5. Familiarity with Relevant Indian Laws and Regulations
77 | P a g e
We confirm that we have studied the provisions of the relevant Indian laws and regulations as required
to enable us to submit this Bid and execute the EOI Documents, in the event of our selection as
Selected Bidder. We further undertake and agree that all such factors as mentioned in the EOI and
have been fully examined and considered while submitting the Bid.
6. Compliance with applicable laws/ guidelines for public procurement in India
We confirm that we shall adhere to applicable laws for public procurement in India including the
guidelines issued in Order No. F/No.6/18/2019-PPD by Ministry of Finance, Department of
Expenditure, Public Procurement Division dated 23 July 2020, Order No No.9/16/2016-Trans-Part
(2) dated 18 November 2020, latest Government of India Guidelines for Make in India, Domestically
manufactured products, Atmanirbhar Bharat and circulars DIPP Office Memorandum No. P-
45021/2/2017-PP (BE-II) date:16th Sept. 2020, MeitY Circular No.1(10)/2017-CLES dated
06.12.2019 and Order No. 11/05/2018-Coord. by the Ministry of Power dated 17 September 2020
including any amendments or modifications to the same from time to time.
7. Contact Person
Details of the contact person representing Bidder (registered Company) for the EOI are furnished as
under:
Name: ………………………………………………….
Designation: ………………………………………………….
Company: ………………………………………………….
Address: ………………………………………………….
Mobile: ………………………………………………….
Phone: ………………………………………………….
Fax: ………………………………………………….
Email: ………………………………………………….
1. We are submitting herewith the Technical Bid containing duly signed formats, both in
electronic and physical forms, (duly attested) as desired by you in the EOI for your
consideration.
8. It is confirmed that our Bid is consistent with all the requirements of submission as stated in the
EOI and subsequent communications from RECPDCL.
9. The information submitted in our Bid is complete, strictly as per the requirements stipulated in the
EOI and is correct to the best of our knowledge and understanding. We would be solely
responsible for any errors or omissions in our Bid.
10. We confirm that all the terms and conditions of our Bid are valid for acceptance for a period of 1
(one) year from the Bid Submission Deadline.
11. We confirm that we have not taken any material deviation so as to be deemed non-responsive with
respect to the provisions stipulated in the EOI.
12. We confirm that no order/ ruling has been passed by any Competent Court or Appropriate
Commission against us or any of our Consortium Members or in the preceding 1 (one) year from
the Bid Submission Deadline for breach of any contract and that the Bid Security submitted by us
or any of our Consortium Members has not been forfeited, either partly or wholly, in any bid
process in the preceding 1 (one) year from the Bid Submission Deadline.
78 | P a g e
13. We confirm that we are not currently blacklisted/debarred/banned/suspended as per clause 5
under Section 4 of this EOI.
14. A brief information regarding Sole/Lead Bidder is as follows:
S. No. Information Requirement Details
1 Company Name and Details
2 Address of its place of business in India
3 List of board of directors or regulating/controlling body
4 Attested copy of Certificate of Registration/ Incorporation

issued by the Registrar of Companies
5 Memorandum and Articles of Association or document

constituting the company and regulating its affairs
6 Certificate of Commencement of Business issued by the

Registrar of Companies
7 Copy of the Goods and Services Tax (GST) Registration

Certificate
8 Provident Fund (PF) Certificate indicating PF Code
9 Copy of Permanent Account Number (PAN) Card
10 Copy of the Goods and Services Tax (GST) Registration

Certificate
11 Audited annual financial statements and financial Net worth

for the last three years
12 Any other papers or documents required by RECPDCL at a

later stage or in future
We are submitting the relevant documents as proof of above declaration.

Dated the ……………. [Insert date of the month] day of ……………. [Insert month, year] at …………….
[Insert place].
Thanking you,
Yours Sincerely,
[Insert Signature here]
[Insert Name here]
[Insert Designation here]
79 | P a g e
80 | P a g e
Annexure B – Draft Format for Request for Quotation
Letter No.:
To:
[Name of Authorized Person]
[Address of the Bidder]
[Telephone No., Fax No., Email]
[Date]
Sub: Request for Quotation (RfQ) under EOI NO: RECPDCL/SM/2024-25/004
Sir,
In line with the governance of EOI preferred in the subject line, you are requested to send your
quotation for supply of smart meters under the following categories for their respective quantities.
Sr. No. Category Quantity Price
1. Number of Consumers
The terms and conditions of the EOI shall prevail viz-a-viz, technical specifications, timelines,
splitting among others. You are requested to submit your financial offer in a sealed envelope to
the signatory of this letter within three (3) working days of this letter.
Looking forward towards an early reply.

Annexure: Draft Category – wise specification of Smart Meters
Your sincerely,
[Name of HoD Smart Metering]
[Designation]
81 | P a g e
Annexure C – Record of Similar Work Done
Name of Confirm
Technical Relations PO/ WO Confirm attachme
No. of
ly Date of Contract Descriptio Value attachment nt of
S. hip with Consumer,
Evaluated the Bidder PO/ WO Period n of Work of PO/ Installati
No. Nodes, etc. (In INR)
Entity WO on
(ies) Mileston
e/
1.
executio
n
2.
certificat
3. e
4.
5.
82 | P a g e
Annexure D – Consortium Agreement
[To be on non-judicial stamp paper of Rupees One Hundred Only (INR 100/-) or appropriate value as per
Stamp Act relevant to place of execution, duly signed on each page. Foreign entities submitting Bid are
required to follow the applicable law in their country.]
FORM OF CONSORTIUM AGREEMENT BETWEEN

M/s…........................................, M/s. .........................................., M/s.
.........................................., AND M/s. .......................................... for bidding for EOI No. [Tender
Details] (the “EOI”) dated [Date]
1. THIS Consortium Agreement (hereinafter referred to as “Agreement”) executed on this ..........
[date] day of .......... [month], .......... [year] between
2. M/s. .........................................., a company incorporated under the laws of .................... and
having its Registered Office at .........................................., (hereinafter called "Party 1,” or “Lead
Consortium Member” which expression shall include its successors, executors and permitted
assigns);
having its Registered Office at .........................................., (hereinafter called "Party 2,” which
expression shall include its successors, executors and permitted assigns);
having its Registered Office at .........................................., (hereinafter called "Party 3,” which
5. …..
having its Registered Office at .........................................., (hereinafter called "Party n,” which
[The Bidding Consortium should list the name, address of its registered office and other details of all the Consortium
Members above.]
WHEREAS the Parties abovenamed are entering into this Consortium Agreement for the purpose of
submitting the Bid in response to the EOI and in the event of selection as Selected Bidder to comply
with the requirements as specified in the EOI and ensure execution of the Contract as may be required
to be entered into with RECPDCL.
Party 1, Party 2, Party 3, ... and Party n are hereinafter collectively referred to as the “Parties” and
individually as a “Party.
WHEREAS the EOI stipulates that the Bidders applying as a Bidding Consortium shall submit a
legally enforceable Consortium Agreement in a format specified in the EOI, whereby each
Consortium Member undertakes to be liable for its Roles and Responsibilities, provide necessary
guarantees and pay required fees as required as per the provisions of the EOI, as specified herein.
WHEREAS any capitalized term in this Agreement shall have the meaning ascribed to such term in
the EOI document.
NOW THEREFORE, THIS AGREEMENT WITNESSTH AS UNDER:
83 | P a g e
In consideration of the above premises and agreement all the Parties in this Consortium do hereby
mutually agree as follows:
1. In consideration of the selection of the Consortium as the Bidding Consortium by Utility, we the
Members of the Consortium and Parties to the Consortium Agreement do hereby unequivocally
agree that M/s........................................................... [Insert name of the Lead Member], shall act as
the Lead Member as defined in the EOI for self and agent for and on behalf of M/s.
.........................................., M/s. .........................................., M/s.
.........................................., and M/s. .......................................... [the names of all the other
Members of the Consortium to be filled in here].
2. The Lead Consortium Member is hereby authorized by the Members of Consortium and Parties
to the Consortium Agreement to bind the Consortium and receive instructions for and on behalf
of all Members. The Roles and Responsibilities of all other members shall be as per the Annexure
to this Agreement.
3. In the event the Consortium is selected pursuant to the Bidding Process, the shareholding of all
each of the Consortium Members during the entire time of empanelment in the Consortium shall
be as under:
Name of the Bidding Relationship

Name of the
with Sole % of equity
Company/ Member Company
S. Bidder /
in investing in the participation in the
No. Member of the
equity of the
case of a Bidding Bidding SPV
SPV
Consortium Consortium
1. Lead Consortium (Not Less than 51%)

Members
2. Consortium Member 1 (Not Less than 10%)
4. Each Consortium Member undertakes to be individually liable for the performance of its part of
the Roles and Responsibilities without in any way limiting the scope of collective liability
envisaged in this Agreement in order to meet the requirements and obligations of the EOI. The
Lead Consortium Member shall be liable and responsible for ensuring the individual and collective
commitment of each of the Members of the Consortium in discharging all their respective Roles
and Responsibilities.
5. In case of any breach of any of the commitment as specified under this Agreement by any of the
Consortium Members, the Lead Consortium Member of the Consortium shall be liable to meet
the obligations as defined under the EOI.
6. Except as specified in the Agreement, it is agreed that sharing of responsibilities as aforesaid and
obligations thereto shall not in any way be a limitation of responsibility of the Lead Member under
these presents.
84 | P a g e
7. The Members expressly agree to adhere to all the terms and conditions of the EOI and confirm
that we don’t have any Conflict of Interest (as defined in the EOI).
8. This Consortium Agreement shall be construed and interpreted in accordance with the Laws of
India and Courts at [Place] shall have the exclusive jurisdiction in all matters relating thereto and
arising there under.
9. It is hereby agreed that the Lead Consortium Member shall furnish the Bid Security, as stipulated
in the EOI, on behalf of the Bidding Consortium.
10. It is hereby agreed that in case of selection of Bidding Consortium as the EA, the Parties to this
Consortium Agreement do hereby agree that they shall furnish the Performance Security and other
commitments to Utility as stipulated in the EOI and EA Contract. The Lead Member shall be
responsible for ensuring the submission of the Performance Security and other commitments on
behalf of all the Consortium Members.
11. It is further expressly agreed that the Consortium Agreement shall be irrevocable and, for the EA,
shall remain valid over the term of the Project, unless expressly agreed to the contrary by Utility.
12. The Lead Consortium Member is authorized and shall be fully responsible for the accuracy and
veracity of the representations and information submitted by the Consortium Members
respectively from time to time in response to the EOI for the purposes of the Bid. The
representation by the Lead Member shall be deemed to be on behalf of and binding on all members
of the Consortium.
13. It is expressly understood and agreed between the Members of the Consortium and Parties that
the responsibilities and obligations of each of the Members shall be as delineated as annexed hereto
as Annexure-A forming integral part of this Agreement. It is further agreed by the Members that
the above sharing of responsibilities and obligations shall not in any way be a limitation of
responsibilities and liabilities of the Members, with regards to all matters relating to the execution
of the Bid and implementation of the Project envisaged in the EOI Documents.
14. It is clearly agreed that the Lead Consortium Member shall ensure performance indicated in the
EOI. In the event one or more Consortium Members fail to perform its/ their respective
obligations, the same shall be deemed to be a default by all the Consortium Members.
15. It is hereby expressly agreed between the Parties to this Consortium Agreement that neither Party
shall assign or delegate or subcontract its rights, duties or obligations under this Agreement to any
person or entity except with prior written consent of Utility.
16. This Consortium Agreement:
a) has been duly executed and delivered on behalf of each Party hereto and constitutes the legal,
valid, binding and enforceable obligation of each such Party;
b) sets forth the entire understanding of the Parties hereto with respect to the subject matter
hereof; and
c) may not be amended or modified except in writing signed by each of the Parties and with prior
written consent of Utility.
For M/s. .......................................... (Party 1)

Common Seal of .................................. has
been affixed in my/ our presence pursuant [Signature of Authorized Representative]
to Board Resolution dated .....................
................................................................
85 | P a g e
[Name of the Authorized Representative]
[Designation of the Authorized Representative]
Witness 1
[Signature of Witness 1]
................................................................
Name:
Designation
Witness 2
................................................................
Name:
Designation:
..
N. Common Seal of .................................. For M/s. .......................................... (Party N)

has been affixed in my/ our presence [Signature of Authorized Representative]
pursuant to Board Resolution dated
..................... ................................................................
N.1. Witness 1 N.2. Witness 2
[Signature of Witness 1] [Signature of Witness 1]

................................................................ ................................................................
Name: Name:
Designation: Designation:
Annexure-1
Role and Responsibility of each Member of the Consortium:
1. Roles and Responsibilities of the Party 1 (Lead Consortium Member):
86 | P a g e
2. Roles and Responsibilities of the Party 2
3. Roles and Responsibilities of the Party 3
.
.
N. Roles and Responsibilities of the Party N
Annexure E – SLA penalties
87 | P a g e
Performance
Requirement SLA Penalty Calculation
Data Type Penalty (For understanding
(Averaged over a purpose only)
month)5
A. Scheduled Tasks
1. Scheduled Interval data readings
Deduction of 0.2% of
Periodic collection
empaneled agency Service Maximum Penalty of 1%
of the interval load From 95% of meters
Charge for every 1% or if action takes place for
profile data for the within 8 hours
part there of capped at 1% <91% of meters
day6
penalty
2. Scheduled Interval data readings
Periodic collection
empaneled agency Service Maximum Penalty of 1%
of the interval load From 98% of meters
Charge for every 1% or if action takes place for
profile data for the within 12 hours
part there of capped at 1% <94% of meters
day7
penalty
3. Scheduled daily meter readings
Previous days’8
From 99.5% of empaneled agency Service Maximum Penalty of 2%
interval energy and
meters within 24 Charge for every 1% or if action takes place for
total accumulated
hours after midnight part there of capped at 2% <90.5% of meters
energy
penalty
4. Scheduled billing profile data for the bill period
From 99.5% of
meters within 72
hours of the Deduction of 0.5% of
Collection of billing scheduled periodic empaneled agency Service Maximum Penalty of 3%
data for the bill collection/ end of Charge for every 0.5% or if action takes place for
period the billing period part there of capped at 3% <97.5% of meters
and From remaining penalty
0.5% of meters
within 168 hours of
the scheduled
5
Local intervention allowed to achieve SLAs
6
Assuming interval of 30 minutes. <In case, Utility aims to change the interval, accordingly the performance
requirement may need to be changed>
7
Assuming interval of 30 minutes. <In case, Utility aims to change the interval, accordingly the performance
requirement may need to be changed>
8
All previous days from the last billing cycle
88 | P a g e
Performance
month)5
periodic collection/
end of the billing
period. Please refer
to Annexure K for
the billing schedule
5. Scheduled energy audit and reliability indices report9 (DT wise)
Generation of From 100% of DT
empaneled agency Service Maximum Penalty of
monthly energy installed meters
Charge for every 1% or 1.5% if action takes place
audit and reliability within 384 hours
part there of capped at for <93% of meters
indices report (16 days)
1.5% penalty
6. Scheduled energy audit and reliability indices report10 (Feeder

wise)
Generation of From 100% of
monthly energy installed Feeder
Charge for every 0.5% or 1.5% if action takes place
audit and reliability meters within 384
part there of capped at for <97.5% of meters
indices report hours (16 days)
1.5% penalty
B. Remote Actions / tasks performed by AMI System
7. For remote connect/disconnect with acknowledgement/ response

for selected meters
Maximum Penalty of
Remote connect / Action performed at empaneled agency Service
2.0% if within 15 minutes,
disconnect of the 90% of meters Charge for every 0.5% or
delivery takes place for
AMI meters within 15 minutes part there of capped at
<88.5% of meters
2.0% penalty

for selected meters
9
As defined in Clause 6 of this Section. Unless both energy audit and reliability indices report (DT wise) are
generated at scheduled periodic interval, empaneled agency shall be considered non-compliant to the defined SLA
and shall be liable to penalties.
10
As defined in Clause 6 of this Section. Unless both energy audit and reliability indices report (Feeder wise) are
89 | P a g e
Performance
month)5
Maximum Penalty of
Remote connect / Action performed empaneled agency Service
1.0% if within 6 hours,
disconnect of the 99.5% of meters Charge for every 0.5% or
AMI meters within 6 hours part there of capped at
<98% of meters
1.0% penalty
9. Remotely top-up amount (for pre-paid application only)
Delivery of top up
amount/ credit
recharge in case of 99.9% meters within Deduction of 0.5% of
Maximum Penalty of
prepayment post 30 minutes empaneled agency Service
successful (delivered and Charge for delay of every
transaction from intimated to 0.5% or part there of
<97.4% of meters
payment gateway up consumer) capped at 3.0% penalty
to consumer
interface11
C. System Availability
10. Availability of AMI System per month
empaneled agency Service Maximum penalty of 4%
Availability of AMI Charge for every 0.5% or shall be deducted when
≥99.5%
System per month part there of reduction in system availability is
availability capped at 4.0% <95.0%
penalty
Performance
month)12
D. Scheduled Tasks
11
Delay in delivery of credit recharge information to payment gateway or Utility Billing System excluded from
the SLA measurement
12
Local intervention allowed to achieve SLAs
90 | P a g e
Performance
month)5
11. Scheduled energy audit and reliability indices report13 (DT wise)
Generation of From 100% of DT
monthly energy installed meters
Charge for every 1% or 1.5% if action takes place
audit and reliability within 384 hours
part there of capped at for <93% of meters
indices report (16 days)
1.5% penalty
12. Scheduled energy audit and reliability indices report14 (Feeder

wise)
Generation of From 100% of
monthly energy installed Feeder
Charge for every 0.5% or 1.5% if action takes place
audit and reliability meters within 384
part there of capped at for <97.5% of meters
indices report hours (16 days)
1.5% penalty
E. Remote Actions / tasks performed by AMI System

for selected meters
Maximum Penalty of
Remote connect / Action performed at empaneled agency Service
disconnect of the 90% of meters Charge for every 0.5% or
AMI meters within 15 minutes part there of capped at
<88.5% of meters
2.0% penalty

for selected meters
Maximum Penalty of
Remote connect / Action performed empaneled agency Service
1.0% if within 6 hours,
disconnect of the 99.5% of meters Charge for every 0.5% or
AMI meters within 6 hours part there of capped at
<98% of meters
1.0% penalty
13
As defined in Clause 6 of this Section. Unless both energy audit and reliability indices report (DT wise) are
14
As defined in Clause 6 of this Section. Unless both energy audit and reliability indices report (Feeder wise) are
91 | P a g e
Performance
month)5
15. Remotely top-up amount (for pre-paid application only)
Delivery of top up
amount/ credit
recharge in case of 99.9% meters within Deduction of 0.5% of
Maximum Penalty of
prepayment post 30 minutes empaneled agency Service
successful (delivered and Charge for delay of every
transaction from intimated to 0.5% or part there of
<97.4% of meters
payment gateway up consumer) capped at 3.0% penalty
to consumer
interface15
F. System Availability
16. Availability of AMI System per month
empaneled agency Service Maximum penalty of 4%
Availability of AMI Charge for every 0.5% or shall be deducted when
≥99.5%
System per month part there of reduction in system availability is
availability capped at 4.0% <95.0%
penalty
15
Delay in delivery of credit recharge information to payment gateway or Utility Billing System excluded from
the SLA measurement
92 | P a g e
Annexure F - Conditions/protocols for auto-disconnections
<These conditions/ protocols should be reviewed and updated by utilities as per their requirement>
a) <Utility to mention for which consumer categories would the protocol for auto-disconnections shall apply
and for which consumer categories the same shall not be applicable.>
b) The auto-disconnection shall not be allowed during gazetted holiday / national holidays and
during night-time
93 | P a g e
Annexure G - System Sizing Requirement
E.1 Sizing Parameter
The system shall be designed as per the technical parameters defined in this specification and as
specified in this Annexure.
The AMI system (MDM, Historian, NMS etc.) shall be suitably sized based on expansion
requirements mentioned in Article 14 of Section 7.
CSP should offer auto-scaling of the compute resources based on the defined threshold of resource
utilization. There should be a minimum and maximum limit defined for auto-scaling for a workload.
This memory utilization includes the memory used for storage of data (including expansion
requirement defined in above para) for the defined duration as specified in the Technical Specification.
The system architecture and the network design shall have the ability to handle the growth with respect
to functions, and user as defined.
94 | P a g e
Annexure H - Future Demand Response Program Use Cases for Reference
The objective of the Demand Response is to optimal utilization of energy resources by uniform
distribution of load across the day, to save additional investment in capacity addition within the utility,
improved access of power to rural areas, reduction in technical losses, enhanced consumer satisfaction
by load curtailment in place of load shedding.
S. Functional
Description of Functional requirement
No. requirement
System will determine based on day ahead schedule for available

Load generation capacity and load forecasting the load curtailment events.
1. Curtailment Advance notice will be sent to a group of consumers affected by this
event in place of load curtailment. DR system will send the load curtailment
Load Shedding command to the MDM. The MDM will forward this command to
the appropriate AMI Head-End.
Once the consumer is set up with all the devices necessary, the
2. DR Program consumer details will be sent to DR system. Premium charges for
Commencement assured power supply with SLA and/or Rebates and incentives can
be given to consumers who participate in DR programs.
3. Real time Utility shall be able to send real-time pricing signals to end
Pricing consumers/ AMI system
Utility limits consumer’s load due to reasons like exceeding contract

load
Curtailment due
4. to Contract Alarms (visual and audio) shall be provided in case of load violation
Violation (in home device, Email, SMS etc.). The billing system shall be
notified of the load violation, and the corresponding charges shall be
applied to consumer (based on tariff rules).
In every 15-minute interval Meter data should be captured,

5. Demand side Confirmation of action taken for demand response should be
Management mentioned as well as monitoring of historical Consumer Load
Profile should be done.
Daily Meter Reading, Status and associated details capturing for

Load records of consumer consumption data, TOU details, real time
6. Monitoring at trends and Load profile Details. Along with this whenever there is a
Demand side load violation event recorded in the meter, the information is sent to
the control center
Utility calls a Direct Load Control Event using the Peak Load
Initiate Direct
7. Management (PLM) Application and executes through head-end by
Load Control
sending a load control signal to Smart Appliances thru HAN/Smart
Event
Meter or other means
95 | P a g e
S. Functional
No. requirement
Register and Interval based accounting:

Register based
Register based accounting supports requirements for prepaid energy
accounting based on register reads.
It includes billing cycle data services that deliver billing determinants
via an interface to CIS/Billing on the billing cycle date and on
request when special reads are required. A Billing Determinant
Calculator provides the flexibility to compute the billing determinant
values based on utility defined formulas. Formulas are built around
logical and arithmetic operators, and can contain other billing
determinants, constants, and consumer functions.
Bi-directional
MDM should support bi-directional metering by processing the
delivered and received channels for a given meter in two separate
channels.
Net Metering (using Virtual channel)
MDM should support net metering by processing the delivered and
received channels from the meter/recorder and calculating a net
amount. The calculated net will be stored onto a virtual channel.
Energy
MDM should provide full tracking, management, and storage of
8. accounting
usage data related to each data channel. This allows summation of
system
usage data separately for each data channel.
Usage Calculated from Register Reads
MDM can create usage data from register reads received from AMI
systems or gathered manually through HHUs. MDM will calculate
the difference between the current bill period register read and the
previous bill period register read, applying the ratio required
converting to the correct kWh usage. Rollover conditions are also
considered when computing usage. The calculated usage is stored
in the billing table and accessible to all applications that require the
data.
Interval Billing:
The Interval Billing should include all of the functionality offered in
the Register Billing in addition to support Advanced Billing
Determinants (ABD) calculated from interval reads.
As interval data is retrieved by the AMI systems, the Advanced
Billing Determinant (ABD) engine should process the interval reads
into daily and billing cycle usage-based billing determinants (as
compared to register-based billing).
For example, if 15 min interval data is retrieved by the system,
MDM calculates the proper billing determinant which is based on
96 | P a g e
S. Functional
No. requirement
RTP/ Time-of-Use (TOU) tariff, then ABD engine will make this
computation based on tariff configuration data in the database.
Then it stores this daily data set (RTP/TOU values with usage
details for each), along with the interval data in the Metered Usage
Data Repository (MUDR). On each billing cycle, the ABD engine
will summarize the RTP/TOU and demand data for each period
over the requested billing span and deliver these billing determinants
to the billing system. By performing the billing determinant
summations daily, MDM support end-user presentation of "month-
to-date" information as well as spread computational loads over time
(including weekends).
97 | P a g e
Form 22: Manufacturer Authorization Form (MAF)
(On Letterhead of Bidders)
To:
[RECPDCL]
[Address]
Dear Sir/Ma’am,
We [insert: name of Manufacturer] who are established and reputable manufacturers of [insert: name
and/or description of the plant & equipment] having production facilities at [insert: address of factory]
do hereby authorize [insert: name & address of Bidder] (hereinafter, the “Bidder”) to submit a bid,
and subsequently negotiate and sign the Contract with you against [insert: title and reference number
of Invitation for Bids] including the above goods and services.
We hereby extend our full guarantee and warranty for the above specified plant & equipment materials
or other goods offered supporting the supply, installation, commissioning and achieving of
Operational Go-live of the plant by the Bidder against these Bidding Documents, and duly authorize
said Bidder to act on our behalf in fulfilling these guarantee and warranty obligations. We also hereby
declare that we and ……………, [insert: name of the Bidder] have entered into a formal relationship
in which, during the duration of the Contract (including warranty / defects liability) we, the
Manufacturer or Producer, will make our technical and engineering staff fully available to the
technical and engineering staff of the successful Bidder to assist that Bidder, on a reasonable and best
effort basis, in the performance of all its obligations to the Purchaser under the Contract.
For and on behalf of [insert: name of Manufacturer]
Signed: _______________________________________________________________
Date: __________________________________
In the capacity of [insert: title of position or other appropriate designation] and this should be signed
by a person having the power of attorney to legal bind the manufacturer.
Date:....................
Place:................... (Signature)........................................….........………..
(Printed Name)...........................................………….
(Designation)................…………................................
98 | P a g e
(Common Seal).…………..........…...….......................
Note:
1. The letter of Undertaking should be on the letterhead of the Manufacturer and should be signed by
a person competent and having Power of Attorney to legally bind the Manufacturer. It shall be
included by the Bidder in its bid.
2. Above undertaking shall be registered or notarized so as to be legally enforceable.
99 | P a g e
Form 23: Format of Agreement to be entered by sub-contractors with the sole bidder / lead
member of a Bidding Consortium
[To be on non-judicial stamp paper of Rupees One Hundred Only (INR 100/-) or appropriate value as per Stamp
Act relevant to place of execution, duly signed on each page. Foreign entities submitting Bid are required to follow
the applicable law in their country.]
FORM OF AGREEMENT BETWEEN

M/s…........................................, AND M/s. .......................................... for bidding for Tender No.
[Tender Details] (the “EOI”) dated [Date] as per its Clause 4.3.2
1. THIS Agreement (hereinafter referred to as “Agreement”) executed on this .......... [date] day of
.......... [month], .......... [year] between
having its Registered Office at .........................................., (hereinafter called "Party 1,” or “Lead
Consortium Member” or “Sole Bidder” which expression shall include its successors, executors
and permitted assigns);
having its Registered Office at .........................................., (hereinafter called "Party 2,” or “Sub-
contractor” which expression shall include its successors, executors and permitted assigns);
[The Sub-contractor should list the name, address of its registered office and other details above.]
WHEREAS the Parties abovenamed are entering into this Agreement for the purpose of submitting
the Bid in response to the EOI and in the event of selection as Selected Bidder to comply with the
requirements as specified in the EOI and ensure execution of the EA Contract as may be required to
be entered into with Utility.
Party 1, and Party 2, are hereinafter collectively referred to as the “Parties” and individually as a
“Party.
WHEREAS the EOI stipulates that the sub-contractors shall submit a legally enforceable Agreement
in a format specified in the EOI, whereby each sub-contractor undertakes to be liable for its Roles and
Responsibilities, provide necessary guarantees and pay required fees as required as per the provisions
of the EOI, as specified herein.
WHEREAS any capitalized term in this Agreement shall have the meaning ascribed to such term in
the EOI document.
NOW THEREFORE, THIS AGREEMENT WITNESSTH AS UNDER:
100 | P a g e
In consideration of the above premises and agreement all the Parties in this Consortium do hereby
mutually agree as follows:
1. In consideration of the selection of the bidder by the Utility, we as the sub-contractor to the sole
bidder/ lead member of the bidding Consortium and Party to this Agreement do hereby
unequivocally agree that M/s........................................................... [Insert name of the Sole
bidder/ Lead Member of the bidding consortium], shall act as the Lead Member as defined in the EOI
for self and agent for and on behalf of M/s. .........................................., [the name of the sub-
contractor to be filled in here].
2. The Roles and Responsibilities of the sub-contractor shall be as per the Annexure-1 to this
Agreement.
3. Th sub-contractor undertakes to be individually liable for the performance of its part of the Roles
and Responsibilities without in any way limiting the scope of collective liability envisaged in this
Agreement in order to meet the requirements and obligations of the EOI. The Sole bidder/ Lead
Consortium Member shall be liable and responsible for ensuring the individual and collective
commitment of the sub-contractor in discharging their respective Roles and Responsibilities.
4. In case of any breach of any of the commitment as specified under this Agreement by the sub-
contractor, the Sole bidder/ Lead Consortium Member shall be liable to meet the obligations as
defined under the EOI.
5. Except as specified in the Agreement, it is agreed that sharing of responsibilities as aforesaid and
obligations thereto shall not in any way be a limitation of responsibility of the Sole bidder/ Lead
Consortium Member under these presents.
6. The Members expressly agree to adhere to all the terms and conditions of the EOI and confirm
that we don’t have any Conflict of Interest (as defined in the EOI).
7. This Agreement shall be construed and interpreted in accordance with the Laws of India and
Courts at [Place] shall have the exclusive jurisdiction in all matters relating thereto and arising
there under.
8. It is further expressly agreed that the Agreement shall be irrevocable and, for the EA, shall remain
valid over the term of the Project, unless expressly agreed to the contrary by Utility.
9. The Sole bidder/ Lead Consortium Member is authorized and shall be fully responsible for the
accuracy and veracity of the representations and information submitted by the Sub-contractor
respectively from time to time in response to the EOI for the purposes of the Bid. The
representation by the Sole bidder/ Lead Consortium Member shall be deemed to be on behalf of
and binding on the sub-contractor.
10. It is expressly understood and agreed between the Sole bidder/ lead consortium member and the
sub-contractor that the responsibilities and obligations of each of the Members shall be as
101 | P a g e
delineated as annexed hereto as Annexure-1 forming integral part of this Agreement. It is further
agreed by the Members that the above sharing of responsibilities and obligations shall not in any
way be a limitation of responsibilities and liabilities of the Members, with regards to all matters
relating to the execution of the Bid and implementation of the Project envisaged in the EOI
Documents.
11. It is clearly agreed that the Sole Bidder/ Lead Consortium Member shall ensure performance
indicated in the EOI. In the event the sub-contractor fails to perform its/ their respective
obligations, the same shall be deemed to be a default by the Sole Bidder/ Lead Consortium
Member.
12. It is hereby expressly agreed between the Parties to this Agreement that neither Party shall assign
or delegate or subcontract its rights, duties or obligations under this Agreement to any person or
entity except with prior written consent of Utility.
13. This Agreement:
a) has been duly executed and delivered on behalf of each Party hereto and constitutes the legal,
valid, binding and enforceable obligation of each such Party;
b) sets forth the entire understanding of the Parties hereto with respect to the subject matter
hereof; and
c) may not be amended or modified except in writing signed by each of the Parties and with
prior written consent of Utility.
Common Seal of .................................. has For M/s. .......................................... (Party 1)

been affixed in my/ our presence pursuant to
[Signature of Authorized Representative]
Board Resolution dated .....................
................................................................
Witness 1
................................................................
Name:
Designation
102 | P a g e
Witness 2
................................................................
Name:
Designation:
..
N. Common Seal of .................................. For M/s. .......................................... (Party 2)

has been affixed in my/ our presence [Signature of Authorized Representative]
pursuant to Board Resolution dated
..................... ................................................................
N.1. Witness 1 N.2. Witness 2
[Signature of Witness 1] [Signature of Witness 1]

................................................................ ................................................................
Name: Name:
Designation: Designation:
Annexure-1
Role and Responsibility of each Member of the Consortium:

1. Roles and Responsibilities of the Party 1 (Sole Bidder/ Lead Consortium Member):
2. Roles and Responsibilities of the Party 2 (Sub-contractor)
103 | P a g e

Rec Power Development and Consultancy Limited (Recpdcl)

Uploaded by

Copyright:

Available Formats

Rec Power Development and Consultancy Limited (Recpdcl)

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

Rec Power Development and Consultancy Limited (Recpdcl)

Uploaded by

Copyright:

Available Formats

INVITATION OF EXPRESSION OF INTEREST (EoI) FOR EMPANELMENT OF

METER DATA MANAGEMENT SYSTEM (MDMS) PROVIDER and SYSTEM

REC POWER DEVELOPMENT AND CONSULTANCY LIMITED (RECPDCL)

EOI NO: RECPDCL/SM/2024-25/004

DATED: 04 June 2024

Sr. No. Particular Date

1 Issuance of EOI 04.06.2024

2 Pre-Bid Meeting 07.06.2024

3 Receipt of Clarification from Bidders to RECPDCL 10.06.2024

4 Reply to Clarification by RECPDCL 12.06.2024

5 Last Date of Bid Submission 18.06.2024

S. No. Requirements Supporting Documents

The Bidder shall have positive net

The proposed MDM solution a) References along with requisite contract/

Should have CMMi (Capability

Should have experience of

Should have valid ISO

8. Annexure A As per prescribed format

9. Annexure D, if required As per prescribed format

1.2 Brief Scope of Work:

A. Supply, installation, integration, testing and commissioning of:

B. AMI System integration as per Clause 3 of this Section;

C. Consumer indexing and Meter Installation Application on de-novo basis for

2. Supply, installation, integration, testing and commissioning of:

At scheduled frequency HESshould Meter Number, reading date

MDM should send the required Meter Number, reading date

2. Monthly Billing profile collection

Meter Number, reading date

At scheduled frequency HES should Meter Number, reading date

Meter Number, reading date

Meter Number, reading date

3. Remote Meter disconnection

Meter Number, group of

Meter disconnection operator Meter number, action

Meter Number, switch

Meter Number, switch

Meter Number, switch

4. Remote Meter Reconnection

Meter number, action

Meter number, action

Meter number, action

5. Utility detects tampering at consumer site

Meter Number, event date &

Consumer number, Meter

On analysis and detection of valid Consumer number, meter

HES sends disconnectcommand to Meter Number, action

Tamper event shared with Meter Number, event date &

Meter re-connection order once Meter number, action (re-

HES sends re-connectcommand to Meter Number, action (re-

6. Missed interval readings

On identifying missed interval, HES Meter Number, from date &

On receiving data requestcommand, Meter Number, reading date

Missed Interval and ReadsData Meter Number, readings

7. Consumer connection outage/restoration event

Outage/restore event recorded by Meter Number, Outage /

Meter Number, Outage /

Meter Number, Outage /

Meter read request from OMS to

Meter responds to event poll from Meter number, Status