ANNEXURE-I

DETAILED SCOPE OF WORK AND CERTAIN SPECIFICATIONS OF

ADAVANCED METERING INFRASTRUCTURE (AMI)

1. Introduction

Advanced Metering Infrastructure (AMI), is the combination of the electronic meters

with two-way communications technology for information, monitoring and control as per IS
16444 part1 & IS 15959 part2. Smart Meters are advanced electronic energy measurement
devices having the capacity to collect information about energy usage at various intervals and
transmitting the data through a communication network to utility and receiving instructions
from utility as well. In addition to conventional electronic metering functionality smart
meters through its built-in communication module can undertake load switch activities for
disconnecting/connecting the load. Smart meter transmits readings and other relevant data to
central server/Government Community Cloud/ MEITY approved cloud (as detailed in this
specification) at periodic intervals. Smart metering system aims to deliver multiple benefits
by providing a platform for improved customer service, e.g. timely and accurate readings
support billing without need for estimation, detailed and in time information of energy usage
for identifying opportunities for energy savings, building a platform for future smart grids,
allow remote connection/disconnection of supply and measurement of electricity exported.

The basic smart metering system is based on two-way communication (data

transferred to and from the meter). The two-way communication provide data to the utilities
however additional functionalities like power quality monitoring, outage management, load
limiting and remote cut-off requires availability of ancillary devices at additional cost,
similarly for analyzing the data transmitted by meter for deriving meaningful information an
IT system is imperative.

The AMI Project shall be implemented in the Project Area (contiguous or non-
contiguous) & all consumers shall be smart metered to enable complete energy accounting
with zero manual intervention. The Bidders shall visit the project area before designing the
AMI and quoting the tender to clearly understand the site conditions including feasible
communication options.

2. Project Area

The Project Areas for AMI deployment are in the places of GE (N) Bangalore, GE (S)
Bangalore and GE (C) Bangalore in the AOR of CWE Bangalore.

3. Basic Functions of Smart Metering System i.e. AMI

The main objective of AMI is to establish two-way communication between smart

energy meter and Head End System (HES) and enable remote reading, monitoring & control
of energy meters and electrical network meters to serve as repository of record for all raw,
validated and edited data. The AMI helps MES utility to manage their resource and business
process effectively and efficiently.

The basic functionalities of the Smart Metering System defined by CEA are as
below:-
a) Remote Meter data reading at configurable intervals (push/pull).
b) Data logging and reporting
 ANNEXURE-I

c) Time of day (TOD)/TOU metering.

d) Prepaid/ Post-paid functionality in the same device.
e) Net Metering /Billing.
f) Alarm/Event detection, notification and reporting.
g) Remote load Limiter and connection / disconnection at defined / on demand
condition.
h) Remote firmware upgrade.
i) Integration with billing & collection software, mapping, consumer indexing,
connections & disconnection, analysis software, Outage Management System
etc.
j) Security features to prevent unauthorized access to the AMI including Smart
meter & meter data etc. and to ensure authentication of all AMI elements by
CERT Auditors of Armed forces.

In addition to above following functionalities are also required:-

k) Field replaceable Modular Communication Module (shall be bundled in meter

Housing and replace with same make of meter with different category 1Ph to
3ph & vice versa)
l) Pairing with Communication Module.
m) Geo Location identification.
n) Time Synchronization.

4. Components of Smart Metering System

AMI solution components of different makes (Make neutral) must comply as per IS
15959 part 1 & 2 to have interoperability of different makes. The AMI solution design shall
be based on cross-functional components or subsystems and shall be implemented in such a
way that there is an opportunity for reuse. The integration architecture shall be based on the
concept of a service, so all the applications of the AMI solution are able to integrate without
any complexity. AMI system is envisaged as a service driven architecture at the core of it.
AMI system feature can be accessed via any user interface (internal of 3rd party applications)
which shall work on top of these services. Adoption of DLMS standards is of paramount
importance for the robust and scalable AMI System. Data access must be always
through services, no application will access AMI data directly from the storage layer or data
access layer. For every internal data access also (access between various modules) there will
be services and no direct access will be there to ensure the AMI system is scalable and
secure.

Proposed architecture shall have adequate redundancies to have no single point of

failure for the solution. The solution tier for critical applications should consist minimum of
two nodes clustered on a fail-over configuration forth critical component like Web,
application, and database servers/Government Community Cloud at the Data Centre Site. On
failure of the primary application server, the standby server shall take over processing,
similarly on failure of a database server, the other server shall continue seamlessly, thus
providing the desired availability. AMI applications shall have the capability to failover to a
redundant or secondary unit upon failure of the primary unit. Likewise, the load on the
primary unit shall be shared with a secondary unit upon the primary unit reaching its
capacity.
The AMI system shall be designed to meet the minimum system availability as defined
below:
 ANNEXURE-I

S. No. System Minimum System

Availability Requirements
1. Smart Meters 99.5%
2. DCU 99.5%
3. HES 99.5%
4. MDM 99.5%
5. NOMC Hardware such as UPS, Router, etc. 99.5%
6. Utility and Consumer User Interface 99.5%

4.1 Smart Energy Meters:

Smarts meters shall be in conformity to IS 16444 Part 1 & IS 15959 part 2 amended
up-to-date. It is mandatory to have BIS identification mark (ISI Mark) on the name plate of
the Smart Energy Meter. The AMISP has to furnish valid BIS certifications & valid in house
NABL lab certification from the manufacturer before the supply of meters.

Smart energy meters shall be capable of measuring electrical parameters i.e. with the
ability to measure electricity consumption with bill through Auto Email to individual
customers in monthly basis and SMS in monthly basis with separate user ID &Smart Mobile
App provisions.
In addition, energy meter shall have capability to configure in prepaid or post-paid
functionality remotely, as and when needed.

4.1.1 Basic Features of AC whole current, single phase, 2 wires Smart Energy Meter&
Three phase, 4 wires Smart Energy Meter:

The Smart Meter would have the following minimum basic features-

● Measurement of electrical energy parameters

● Bidirectional Communication
● Integrated Load limiting /connect/disconnect switch
● Tamper event detection, recording and reporting
● Power event alarms as per IS 16444 Part 1
● Remote firmware upgrade
● Pre-paid and Post-paid features at MDM end (as per IS 15959 Part 2)
● TOD features
● Net Metering (kWh) features (optional as per requirement of MES)
● On demand reading

4.1.2 Communication: Meter shall have the ability to communicate with Head End System (HES)
as per the communication technologies (RF / GPRS 4G/5G) mentioned in IS16444 Part 1 in a secure
manner. The selection of communication technology should be as per the site conditions and as per
design consideration of implementing agency to achieve the best performance. In case of a GPRS
based meter, the meter shall accommodate a SIM card /e-SIM of any all service providers.
(Should not restrict to single service provider) In case of Plug-in type communication module, the
 ANNEXURE-I

meter shall log communication module removal /non-responsive event with snapshot. Data
communication shall be in the bidder’s scope upto end of the contract period.

4.1.3 Remote connect/disconnect/load limiting: Remote Connect/disconnect/Load control

facilities would be as per IS 16444 part 1.

4.1.4 Other Specifications:

Features Minimum Requirement of Features

Applicable Standards
Reference Voltage
Current Rating
Category
Starting Current
Accuracy
Limits of error
Operating Temperature range
Humidity
Frequency
Influence Quantities
Power Consumption of meter
Current and Voltage Circuit
Running at No Load
Test output device
Meter Display
Name Plate & marking Meter
Display
Parameters to be measured
Maximum Demand resetting
Time of Use registers
Power Quality Information
LED/LCD Indicators
Load Survey/Interval Data
Tamper/ Event Recording
Measuring Elements
The meters shall comply with IS16444 Part1 for all
requirements.
As per relevant IS- 240V for single phase meter &
415V for three phase meter
5-30A and 10-60A for single phase meter
10-60A for three phase meter
UC1
As per IS 16444 Part 1
Class 1.0 as per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 13779
As per IS 13779
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1 / As per IS 15959 Part-2
As per IS 15959 Part 2
As per IS 15959 part 2
As per IS 15959 part 2
As per IS 16444 Part 1
As per IS 15959 part 2
As per IS 15959 part 2
As per IS 16444 part 1
 ANNEXURE-I

Features Minimum Requirement of Features

Alarm
Load Control
Connect/Disconnect switch
Status of load switch
Programmability
Communication
Data Exchange Protocol
Remote Firmware upgrade
Real Time Clock (RTC)
Data Retention
Battery Backup
First Breath (power on) and Last
gasp (power off) condition detection As per IS 16444 Part 1
and communication to HES
Plug-in Communication Module
As per IS 16444 Part 1/ 15959 Part 2
As per IS 16444 Part 1
UC1 (As per IS 16444 part 1)
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 16444 Part 1
As per IS 15959 Part 2
As per IS 16444 Part 1/ IS 15959 Part1 & Part 2
As per IS 16444 Part 1
Meter shall be supplied with separate battery
backup for RTC.
The Smart Meters shall have a dedicated sealable
slot for accommodating plug-in type bi -directional
communication module which shall integrate the
respective communication technology (RF/PLCC/
Cellular) with the Smart Meters, leading to easy
adaptability for network interfaces (WAN/NAN).
The Plug-In module shall be field swappable/
replaceable with same make of meter with different
category 1Ph to 3ph & vice versa.

4.1.5 Data Display Facility (auto/manual): To be as per IS16444

However minimum requirement should include the following:
Data Display shall be in two modes-
1. Auto Scroll
2. Scroll with Push / Touch Button
The display parameters shall be:
▪ Auto Scroll
o Display Check
o Date and Time
o Last Recharge Amount
o Last Recharge Time
o Current Balance Amount
o Current Balance Time
o Cumulative Active Energy kWh with legend.
o Current calendar month MD in kW with legend.
o Instantaneous Phase voltage(s)
o Instantaneous Phase current(s)
o Instantaneous Load kW
 ANNEXURE-I

o Instantaneous average Power Factor

These parameters should be displayed on the Meter Display continuously for a period of 10
seconds on Auto scroll.

▪ Scroll with Push-button

All Parameters mentioned under Auto-Scroll mode should be displayed.
Additionally, the following Parameters shall also be displayed:
● Internal diagnostics (display check)
● Meter Serial No.
● Cumulative Energy in kVArh Lag/Lead with legend
● Cumulative Active Energy kWh ToD wise with legends.
● Cumulative Apparent Energy kVAh ToD wise with legends.
● Current month MD in kVAh with legends
● Last month cumulative kWh with legends
● Last month cumulative kVAh with legends
● Last month MD in kW with legends
● Last month Average Power Factor
● Current month Average Power Factor

Further, the Meter should display high resolution energy values with resolution of 3
digits before decimal and 2 digits after decimal in push button mode.

The meter’s display should return to default display mode (continues auto scroll) if
push button is not operated for more than 10 seconds. (The order of display may be revised
as per requirement of the utility). Meter display should not go into sleep mode during
Power-On condition.

4.1.6 Anti-tamper features:

The meter shall continue recording energy under tamper conditions as defined in IS 15959
Part 2 and would log the event and send alarm at Head End System after detection of the
defined tamper features as per IS 15959 Part 2.

4.1.7 Type Tests & Test Certificates.

Smart Meter shall be type tested for all the tests as per relevant parts of IS 16444 part 1
(With latest Amendments) , IS 15959 DLMS compliance and certified by Indian Standard
wise list of BIS recognized labs as available at https://bis.gov.in/index.php/laboratorys/list-
of-bis-recognized-lab/. The number of sampling for testing of meters and criteria for
conformity would be as per IS 16444 (as amended up to date). Necessary copies of test
certificates shall be submitted and the type test certificates shall be within 5 years or below
from the bid date.

4.1.8 Meter base & cover shall be as per IS 16444 Part1 / IS 13779. The meter Base &
cover shall be break to open design. The material for meter base and cover shall be made of
high-grade Polycarbonate. The meter Base & cover shall be ultrasonically welded /
chemically welded or other suitable bonding technology and it will not be possible to
remove the cover from the base without evidence of damage. Terminal block & cover shall
be as per IS 16444 Part 1/IS 13779 and meter suitable for IP 54

4.1.9 Fixing Arrangements:

 ANNEXURE-I

The meter shall be mounted type. The Meter should have three fixing holes, one at
top and two at the bottom. The Top hole should be such that the holding screw is not
accessible to the consumer after fixing the meters. The lower screws should be provided
under sealable terminal cover.

4.1.10 Sealing Arrangement:

Arrangements shall be provided for proper sealing of the meter cover so that access
to the working parts shall not be possible without breaking the seal. The sealing arrangement
and number of seals shall be as per relevant IS/ requirement of utility.

4.1.11Name plate and marking & Connection diagram:

As per IS 16444 Part 1.However minimum requirement should include the following:
1. Property of MES
2. PO No & Date
3. Guarantee Period
4. Smart meter as per IS16444 part 1.
5. WAN /NAN Communication

4.1.12 Suitable Meter Box shall be provided with each meter and the material of the Meter
Box should be such that it does not hamper communications. It should be preferably
transparent.

4.2 Communication Infrastructure :

It consists of two parts - the Near Area Network (Localized to meters in the field) and
the Wide Area Network (GPRS/Optical Fibre to centralization-this communication
infrastructure enables two-way transmission of data between smart meters and MES utility).
There are several different ways this field-based communications infrastructure can be
implemented, depending on the metering system selected.

Communication technologies for API need to be decided based on field conditions

and most suitable communication technologies in that area shall be selected for two way
communication with Smart meters and associated AMI nodes to ensure reliable interference
free data transfer. Selected communication technologies should either be of RF/ RF-Mesh
network/ cellular network (4G/5G with fallback on 2G/3G) or combination of these or any
other advanced technology all as per CEA/TRAI regulations.

4.2.1 Network Management System (NMS):

A suitable Network Management System (NMS) functioning within the Head End
System (HES) is to be provided which is responsible for the establishment and management
of all networks, the discovery of all nodes once deployed in the field, the overall system
management as well as security management of devices. The proposed NMS shall facilitate
following activities:

a) Security Management to protect systems and network from unauthorized access,

manage user access, authorizing rights and privileges.
b) Viewing of all network elements deployed in the field and administer configuration
changes of the network devices and nodes through toolkits to automate the following
tasks:
i. Capture running configuration, capture start-up configuration, upload
configuration
 ANNEXURE-I

ii. Compare configuration

iii. Real-time or scheduled capture of device configurations
iv. Store historical device configurations captured and enable comparison of
current device configuration against a previously captured configuration
c) Security patch management of all applications shall be encrypted and signed.
d) Performance Management to monitor network performance as specified.
e) Fault Management to recognize, isolate, log and identify fault on network and
connected nodes, devices.

The NMS software shall have a simple browser-based user interface to provide all the
pertinent information about the system. The NMS shall not impact the availability and
performance of AMI applications and shall load not more than 1% of network bandwidth and
shall have secure communication. The Network Management Software shall have following
functionality:
a) It shall maintain performance & error statistics, and present this information via
displays, periodic reports and on-demand reports.
b) Apart from real-time monitoring of critical network devices, the above information
shall be collected and stored at user configurable periodicities i.e., 5 minutes to 60
minutes. The NMS shall be capable of storing the above data for a period of one (1)
year at an interval of 5 minutes.
c) It shall maintain a graphical display for connectivity and status of peripheral devices.
The monitored devices shall be configured to send SNMP notifications, and the
graphical element representing the device shall change to a different colour depending
on the severity of the notification received.
d) It shall issue alarms when error conditions occur.
e) The period over which the statistics are gathered shall be adjustable by the user and the
accumulated statistics shall be reset at the start of each period.
f) The statistics shall be available for printout and display after each period and on demand
during the period.
g) In case more than one technology of AMI (example PLCC and RF between Smart
Meter & DCU) deployed in the field. It shall maintain statistics on the performance and
availability of node being delivered per AMI technology.

4.2.2 Network Protection and Security:

The AMI Network shall have adequate cyber security measures not limited to the
measures as described below. The network security would be extended to all the interfaces
also.
Secure Access Controls: The system shall include mechanisms for defining and controlling
user access to the applications environment. Best practices from enterprise security including
password strength, password aging, password history, reuse prevention etc. must be followed
for access control.
Authorization Controls: A least-privilege concept such that users are only allowed to use
or access functions for which they have been given authorization shall be available.
Logging: Logs must be maintained for all attempts to log on (both successful and
unsuccessful), any privilege change requests (both successful and unsuccessful), user actions
affecting security (such as password changes), attempts to perform actions not authorized by
the authorization controls, all configuration changes etc. Additionally, the access to such logs
must be controlled in accordance with the least-privilege concept mentioned above, so that
entries may not be deleted, accidentally or maliciously.
 ANNEXURE-I

The overall cyber security policy and implementation shall account for:
a) Prevent unauthorized users from reading or writing data or files, executing programs
or performing operations without appropriate privileges.
b) Document all user sign on procedure
c) Record all network traffic for detecting unauthorized activity, unusual activity and
attempts to defeat system security (AMISP to propose and document what
constitutes normal activity/traffic)
d) A user authentication scheme consisting of at least a user identification and password
shall be required for the user to request a connection to any network node.
e) Graphical User Interface (GUI) to provide role-based access based on user identity
and user role. Shall have following types of users:
i. Administrator
ii. Operator
iii. Field staff
iv. Viewer/Guest

4.2.3 Communication network Elements:

Following sections provide detail on both DCU based communication network and
router-based RF mesh network. The bidder shall select relevant parts as applicable for
designing and establishing communication infrastructure. The network shall be horizontally
and vertically scalable to accommodate future meter installations. The network elements
may be comprised of the following.

4.2.3.1 Data Concentrator Unit (DCU) if applicable :

The Data Concentrator Unit is a gateway for communication of data between the
Smart Meters and the HES enabling continuous/periodic meter-read and control. DCU shall
exchange data from Smart Meters on RF / PLCC communication and with HES on WAN.

Minimum Requirements of Features in DCUs:-

a) Enclosure/box of DCU shall be IP65 or better compliant. A suitable mounting

arrangement required for DCU installation shall also be provided.
b) A suitable and optimum power supply shall be provided keeping in view that even in
case of outage in one or two phases, DCU can be powered. DCU should be capable of
withstanding surges & voltage spikes of 6 kV. Power supply shall be terminated on
suitable sized Miniature Circuit Breaker (MCB) to facilitate isolation during on-site
maintenance.
c) DCU shall have battery with backup for 1(one) hour for normal meter reading, to
push tamper event, carry out on demand reading and the network health status/
connectivity continuity & check. DCU should have the suitable feature to send power
outage and restoration message to the HES.
d) DCU shall have built-in Real Time Clock (RTC) with separate battery backup. It shall
have self- diagnostic feature for RTC, memory, battery, communication module, etc.
e) It shall be able to configure the communication with underlying nodes/ meters.
f) It shall pull data from the field devices and push the data at configured intervals to the
HES. It should also support the HES in pulling data from the field devices/meters.
 ANNEXURE-I

The data acquisition (Push/Pull) frequency shall be programmable.DCU shall be

capable to prioritize control commands.
g) DCU shall ensure a secure communication to HES and have internal memory for
storing interval data for at least 5 (five) days.
h) DCU shall support on demand read and ping of individual/group of meters.
i) The communication architecture shall be any, as defined under IS 16444.
j) The DCU shall ensure the appropriate backhaul for secure transfer of data to HES
either via cellular or Fiber Optic communication. In case of cellular backhaul, it shall
support SIM card with dynamic IP from any service provider, It shall have Wide Area
Network (WAN) connectivity to the HES through suitable means.
k) DCU shall be able to communicate with meter either on RF (Unlicensed or Licensed
frequency) band as permitted by WPC/Statutory Bodies in country of deployment as
applicable) of PLCC.
l) DCU shall periodically monitor meter reads/ downstream commands and shall retry
and reconnect in case of failed events/ reads.
m) It shall push events such as tamper, power off etc. to HES immediately on occurrence/
receipt from field devices/ meters. DCU shall be able to acquire and send data to
HES for full capacity (as designed for no of meters/field devices) to ensure the
performance level. Full capacity of DCU is required to be indicated in the offer.
n) After power interruption and on restoration of power supply, DCU shall establish
communication with underlying devices as well as upstream application
automatically.
o) DCU shall be able to communicate with the nearest meters depending on
topographical features. For further communication among the meters, distance of the
other meters with the DCU shall not be a constraint as communication of the nearest
meters shall be established with other meters through appropriate mesh
formation/other formation.
p) Remote Firmware Upgrade: The DCU shall support remote firmware upgrades as
well as remote configuration from the network operation cum monitoring centre.
Configuration of programmable parameters of Smart Meters shall be done through
HES.
q) DCU shall facilitate recording of minimum of the following events at HES (for 7
days):
i. No of packet failures
ii. Retry attempts
iii. Missed periodic readings
iv. Failure to connect
v. Tamper events

4.2.3.2 Gateway/ Router/ Access Point based RF Mesh Network:

In this type of communication network, different network nodes including end points
(Smart Meters) shall interconnect with each other using RF mesh network and they shall
communicate with nearby gateways/ routers to transfer the data to access points. If any
gateways/ routers/ repeaters/ access points fail, then nodes connected on that device shall
automatically reconfigure the mesh with available nearby nodes. Thus it shall have dynamic &
self-healing capability.

Minimum Requirements of RF Mesh network:-

a) Each node shall keep a track of best available nearby nodes or access points.
 ANNEXURE-I

b) All the communication network equipment shall be as per WPC (Wireless Planning &
Coordination Wing) guidelines, Government of India for operation in licensed /
license free frequency band as permitted by WPC/Statutory Bodies as applicable.
c) It shall be secure enough to avoid all cyber threats and it shall support remote
firmware upgrading. It shall also ensure secure communication of data to HES.
d) The equipment shall be weatherproof, dustproof and constructed for outdoor
installation on poles (minimum rating: IP65). A suitable mounting provision shall be
made for the equipment.
e) Gateway/ Router/ Access Point shall have battery with backup for 1(one) hour for
normal meter reading, to push tamper event, carry out on demand reading and the
network health status/ connectivity continuity & check etc. during battery operations
also. It should have the suitable feature to send power outage and restoration message
to the HES even during battery back-up.

Access points shall meet the following functionalities:-

f) It shall be able to configure the communication with underlying nodes/end points and
it shall have Wide Area Network (WAN) connectivity to the HES through suitable
means. It shall also support on demand read and ping of individual/group of meters.
g) It shall push events such as tamper, power off etc. to HES immediately on
occurrence/receipt from field devices/meters.
h) It shall communicate with gateways/ routers/ nodes/ end points/ access points on RF
mesh network (Unlicensed or Licensed frequency band as permitted by
WPC/Statutory Bodies in India as applicable).
i) It shall periodically monitor meter reads/downstream commands and shall retry and
reconnect in case of failed events/reads.
j) After power Interruption, on restoration of power supply, it shall establish
communication with underlying devices as well as upstream application (HES)
automatically.
k) Access point shall facilitate recording of minimum of the following events at HES
(for seven (7) days):
i. No of lost packets
ii. Retry attempts
iii. Missed periodic reading
iv. Failure to connect
v. Tamper events

l) It shall be capable to handle interval data of suitable nos. of any type of Smart Meter.
Access point shall be able to acquire and send data to HES for full capacity (No. of
meters/field devices it is designed for) within a suitable time period to achieve the
performance level.
m) Gateway / Router / Access point shall support remote firmware upgrades as well as
remote configuration from the Network Operation cum Monitoring Centre.
n) The Gateway / Router / Access Points shall have provision to maintain the time and
date information and shall always be in Time synchronization to the HES server via
NTP to sub second accuracy. The Gateway / Router / Access Points shall support time
distribution to each Mesh Node.

4.3 Head End System (HES) :

 ANNEXURE-I

The main objective of HES is to acquire meter data automatically avoiding any human
intervention and monitor parameters acquired from meters. The contractor shall provide a
HES which is suitable to support the collection and storage of data as per performance level
for a defined no. of Smart Meters with facility of future expansion as per the requirement
specified in the tender.HES includes supply of all the requisite software and hardware to
achieve the defined functionalities of AMI.
HES shall be developed on open platform based on distributed architecture for
scalability without degradation of the performance using additional hardware. The scalability
shall ensure the ability to handle applicable workloads including the following: An indicative
list of parameters is provided below:
(i) Up to 7500 numbers of meters installed
(ii) 5/15mins interval meter reads
(iii) Up to 7500 users requesting data from meters
(iv) Other events and statuses coming from meters

The HES shall be on cloud/ Local server enabled and support deployment with high
availability clustering and automatic load balancing that ensure hardware as well as
application failover. Adequate data base and security features for storage of data at HES end
to be ensured.

4.3.1 Minimum required functions of HES are as under:

a) On power up after installation, Smart Meter shall register itself automatically into the
HES along with its metering profile. The HES shall store meter profile status by meter
type, hardware & software versions, device IDs, logged in / logged out details etc.
b) Upon deployment and establishment of communication, it shall be possible for field
level end device nodes (NAN/WAN) like Router/Gateway, Access Point, DCU to
have self-discovery and registration.
c) Acquisition of meter data on demand & at user selectable periodicity. On demand
meter read may be for single meter (uni-cast) or for a group of meters (multi-cast).
d) Two-way communication with meter/ DCU & Maintain time sync with them.
e) Signals for connect & disconnect of switches present in end points such as meters.
This facility shall be provided for both single meter (uni-cast) as well as for a group of
meters (multi-cast).
f) Audit trail and Event & Alarm Logging.
g) Ability to redirect messages including configuration commands from the Meter Data
Management System (MDM) in order to reach the desired meter.
h) HES shall hold / Store raw data for defined duration (minimum 3 days) before it is
transferred to the MDM.
i) Handling of Control signals / event messages on priority.
j) Manage time distribution to ensure that nodes / meters always have an accurate Real
Time Clock (RTC) using Network Time Protocol (NTP) servers. The time distribution
mechanism shall take into account the network latencies.
k) Setting of Smart Meter configurable parameters.
l) Critical and non-critical event reporting functionality.
m) Device management functionality to get periodic updates from devices on health
check, hardware & firmware version, location mapping etc.
 ANNEXURE-I

n) The data collection and computation for the purpose of SLA penalties (as mentioned
in the following

4.3.2 Configuration requirement of HES:

HES shall facilitate configuration of following minimum AMI parameters:

a) Load profile capture period & Demand integration period

b) Setting of parameters for TOU billing
c) Prepaid / post-paid configuration
d) Billing date / month-to-date for Smart meters
e) Clock setting/time synchronizations
f) Load curtailment limit
g) Event setting for connect/disconnect
h) Number of auto reconnection attempt
i) Time interval between auto reconnection attempts
j) Lock out period for endpoint (meter) relay
k) Remote firmware update: It shall be possible to update the firmware of the
meters in both Unicast (one to one) and in Multicast fashion (Group of
meters). It shall be also possible to have remote firmware upgrade for an
individual and a group of nodes (NAN/WAN, Routers/Gateways/Access
Point, DCU).
l) Password setting
m) Push schedule
n) Setting threshold limits for monitored parameters

4.3.3 Communication requirement of HES shall be as under:

The following communication functions with network devices shall be supported:

a) HES shall communicate with DCUs/access points using WAN technology

b) HES shall encrypt data for secure communication
c) HES shall be able to accept data according to IS 15959 part-2 /part 3 and
latest amendments.
d) HES shall automatically retry for missed data; the number of retry attempts
shall be configurable
e) To receive confirmation on successful execution of a command
f) HES shall ensure data integrity checks, for example, checksum, time check,
pulse, overflow, etc. on all metered data

4.3.4 Monitoring and Reporting capability of HES shall be as under:

Critical Reporting ---

HES shall have alarms and keep record of following events:

a) Event log for node‘s (meter) events such as tamper/power failures etc.
b) Data not received from nodes/end points
c) Relay does not operate for connect / disconnect
d) Communication link failure with nodes/end points
e) Network Failure
 ANNEXURE-I

f) Power Failure

Non-Critical Reporting---

HES shall report and keep record of following communication failure events:

g) Retry attempts
h) Missed periodic reading
i) Failure to connect

HES shall support reporting of communication failure history of nodes/routers/access

points etc. and give an exception report for nodes/routers/access points not communicating
for last 0 – 24 hours (the reporting period shall be on user configurable period). HES shall
have feature to send email/SMS notification of configured alarms & events to its users.

4.4 Meter Data Management System (MDM) :

The Meter Data Management system (MDM) shall support storage, archiving,
retrieval & analysis of meter data and various other operational systems along with validation
& verification algorithms. The MDM shall be a scalable and commercial-off-the-self (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. in the
formats as desired by MES authorities.

The illustrations of key use cases to be enabled by the AMI service provider are as
under:

S Use Case Activity Description Source Destin- Info Exchanged

No
1. Collection of Daily Meter Profile
1.1 At scheduled frequency HES should pull
the Daily Meter Data from Smart Meter
over communication Channel
1.2 Meter should send the data to HES.
Provision for retrial should be there if
Meter data is not collected within time.
Consumption details including non-
critical events will be in 15 min/30 min
block data, and data could be
incremental to what was sent by meter
in preceding instance
1.3 HES should send the data to MDM
1.4 MDM should send the required
parameter to Prepaid system for daily
charge calculation at least once on daily
basis
2. Monthly Billing profile collection
ation
HES Meter Meter Number, reading date &
time, kW, kVA, kWh, kVAh, PF,
Non-critical Event Code / Date
Meter HES Meter Number, reading date &
time, kW, kVA, kWh, kVAh, PF,
Non-critical Event Code / Date
HES MDM Meter Number, reading date &
time, kW, kVA, kWh, kVAh, PF
MDM Prepaid Meter Number, reading date &
Engine time, kW, kVA, kWh, kVAh, PF,
Non-critical Event Code / Date
 ANNEXURE-I

2.1 Command from Billing system triggered Billing MDM / Meter Number, reading date &
and send to MDM / HES for collection of System HES time, kW, kVA, kWh, kVAh, PF,
Monthly billing Data Non-critical Event Code / Date
2.2 At scheduled frequency HES should pull HES Meter Meter Number, reading date &
the monthly meter data from Smart time, kW, kVA, kWh, kVAh, PF,
Meter over the communication channel Non-critical Event Code / Date
2.3 Meter should send the data to HES. Meter HES Meter Number, reading date &
Provision for retrial should be there if time, kW, kVA, kWh, kVAh, PF,
Meter data is not collected within time. Non-critical Event Code / Date
2.4 HES should decrypt and validate the HES MDM Meter Number, reading date &
data collected and send to MDM time, kW, kVA, kWh, kVAh,
PF, Non-critical Event Code /
Date
2.5 MDM should send the required MDM Billing Meter Number, reading date &
parameter to Billing system for Monthly Engine time, kW, kVA, kWh, kVAh,
Bill calculation PF, Non-critical Event Code /
Date

S Use Case Activity Description Source Destin- Info Exchanged

No ation
3. Remote Meter disconnection
3.1 Meter disconnect operation command Prepaid MDM Meter Number, group of
after wallet balance calculation Engine/ meters, instruction to close
Billing switch
system
3.2 Disconnection alert sent to consumer MDM Billing Meter Number, group of
System meters, instruction to close
switch
3.3 Meter disconnection operator command MDM HES Meter number, action
(disconnect)
3.4 Consumer meter disconnection HES Meter Meter Number, switch status
3.5 Disconnection Status Update Meter HES Meter Number, switch status
3.6 Disconnection Status Update HES MDM Meter Number, switch status
4. Remote Meter Reconnection
4.1 Meter reconnect operation command Billing MDM Meter Number, group of
after wallet recharge Billing system/ meters, instruction to close
Prepaid switch
Engine
4.2 Meter reconnect operation command MDM HES Meter Number, group of
meters, instruction to close
switch
4.3 Consumer meter reconnection HES Meter Meter number, action
(reconnect)
4.4 Reconnection Status Update Meter HES Meter number, action
(reconnect)
4.5 Reconnection Status Update HES MDM Meter number, action
(reconnect)
5. Utility detects tampering at consumer site
5.1 High priority events captured by Meter Meter HES Meter Number, event date &
sent to HES as and when occurred time, event Code /description
 ANNEXURE-I

5.2 High priority events reach MDM for HES MDM Meter Number, event date &
further action. time, event Code /description
5.3 Share with WFM to Notify utility MDM WFM Consumer number, Meter
personnel for site inspection Number, Tamper code,
address
5.4 On analysis and detection of valid Meter HES/ Consumer number, meter
tamper event or malfunction, the tamper MDM number, action to be
event must be sent / pushed by the meter triggered (disconnect), action
to the HES /MDM date & time
5.5 HES sends disconnect command to HES Meter Meter Number, action
meter (disconnect)
5.6 Tamper event shared with CIS/CRM. MDM CIS / Meter Number, event date &
Billing determinants are updated for CRM time, event Code /description
tamper invoicing
5.7 Meter re-connection order once tamper MDM HES Meter number, action (re-
issue is resolved connect)
5.8 HES sends re-connect command to HES Meter Meter Number, action (re-
meter connect)
Note :- CIS/CRM --- Consumer Information System/Consumer Relationship Management

S Use Case Activity Description Source Destin- Info Exchanged

No ation
6. Missed interval readings
6.1 On identifying missed interval, HES will HES Meter Meter Number, from date
re-acquire data for the missing period & time, to date & time (for
from meter which data is missing)
6.2 On receiving data request command, Meter HES Meter Number, reading date
meter will send data to HES & time, kW, kVA, kWh,
kVAh
6.3 Missed Interval and Reads Data HES MDM Meter Number, readings with
acquired by MDM date & time
7. Consumer connection outage/restoration event
7.1 Outage/restore event recorded by meter Meter HES Meter Number, Outage /
is sent to HES as and when event occurs restoration Date / Time,
Power On or Off count
7.2 Outage / Restoration Notification HES MDM Meter Number, Outage /
restoration Date / Time,
Power On or Off count
7.3 Sharing Outage / Restoration MDM OMS/ Meter Number, Outage /
Notification CIS- restoration Date / Time,
CRM Power On or Off count
7.4 Meter read request from OMS to OMS MDM Meter Number,
identify service outage / restoration → HES
7.5 Meter responds to event poll from HES Meter HES Meter number, Status
(live/dead)
8. Remote firmware upgrades/ meter configuration changes
8.1 Remote firmware upgrade HES Meter Firmware

8.2 Configuration Commands: HES Meter Meter number, tariff

Change tariff parameters, parameters, registers status,
Synchronize clock, Registers reset event type and priority
(status, max, tampering)
8.3 Status update of Firmware / Meter HES
Configuration
 ANNEXURE-I

9. Load monitoring at demand side

9.1 When there is a load violation event Meter HES → Meter Number, max
recorded in the meter, the information is MDM demand, date & time of load
sent to the CC violation
10. Time synchronization
10.1 Synchronizing RTCs of meters / HES DCU/ Time Setting
DCUs/ACP Meter
11. Metering network changes
11.1 Change / new installation in Meter / Meter / HES Network identification info
DCU Network Hierarchy DCU including DCUs
11.2 Change / new installation in Meter / HES MDM Network identification info
DCU Network Hierarchy including DCU
12. New consumer connection
12.1 Receive verified pre & post-paid new CIS- MDM Consumer name, address.
consumer requests CRM/ Connection request etc.
Billing
12.2 Generate meter installation order MDM /WFM Consumer ID & details

Note :- OMS --- Order Management System

S Use Case Activity Description Source Destin- Info Exchanged
No ation
12.3 Receive meter installation report WFM MDM Meter number, DT no,
Feeder & reading
12.4 Requesting instant, MDM HES → Meter Number, Reading date
interval & events data from meters Meter & time, reading params
(kWh, kVAh, kW etc.)
12.5 Acquire instant, interval / events data HES MDM Meter Number, Reading date
from meter by HES which then reaches & time, reading params
MDM system. (kWh, kVAh, kW etc.)
12.6 Once new meter remote read MDM Billing / Consumer ID, Consumer
verification is over, confirm new CIS- address, Meter Number,
connection with other applications CRM initial reading etc.
13. Migrate post-paid consumer to prepaid mode
13.1 Receive migration request CIS- MDM Migration request for post-
CRM/ paid consumer with profile
Billing
13.2 Setup prepaid consumer profile in MDM Prepaid Prepaid consumer profile
prepaid engine. If no change in meter Engine
is required, skip next two steps
13.3 Generate prepaid meter installation MDM WFM Consumer ID & details
order if required
13.4 Receive meter installation report WFM MDM Meter number, DT no,
Feeder & reading
13.5 Enable prepaid mode in meter Prepaid HES → Engineering token
engine Meter
13.6 Receive activation confirmation HES MDM Activation status

13.7 Request instant, interval & events data MDM HES → Meter Number, Reading date
from meter Meter & time, reading params
(kWh, kVAh, kW etc.)
13.8 Acquire instant, interval / events data HES MDM Meter Number, Reading date
from meter by HES which then reaches & time, reading params
MDM system. (kWh, kVAh, kW etc.)
13.9 Once meter remote read verification is MDM Billing / Prepaid consumer profile
 ANNEXURE-I

over, share migration request CIS-

completion detail with other modules CRM
14. Migrate prepaid consumer to post-paid mode
14.1 Receive migration request CIS- MDM Migration request for prepaid
CRM consumer with profile
14.2 Request meter data MDM HES → Meter Number, Consumer ID
Meter
14.3 Acquire instant, interval / events data HES MDM Meter Number, Reading date
from meter by HES which then reaches & time, reading params
MDM system. (kWh, kVAh, kW etc.) with
balance 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 → Engineering token
Meter
14.7 Receive activation of post-paid mode HES MDM Activation Status
Note :- WFM --- Work Force Management

S Use Case Activity Description Source Destin- Info Exchanged

No ation
14.8 Request instant, MDM HES → Meter Number, Consumer ID
interval & events data from meter Meter
14.9 Acquire instant, interval / events HES MDM Meter Number, Reading date
data from meter by HES which then & time, reading params
reaches MDM system. (kWh, kVAh, kW etc.)
14.10 Once meter remote read MDM Billing / Post-paid consumer profile
verification is over, share migration CIS-CRM and meter data along with
request completion detail with other credit balance
modules
15. Consumer Registration in Consumer Portal/ App
15.1 Consumer clicks on new user on Portal/ CIS/CRM Request for registration with
consumer portal/ App, provides App RMN/email ID
RMN or email ID and submits data
15.2 Utility receives request for CIS/ Email/ OTP
registration and sends OTP after CRM Message
verification Gateway
15.3 Consumer submits OTP Portal/ CIS/
App CRM
15.4 Consumer receives registration CIS/ Email/ Login ID and default
detail CRM Message password
Gateway
15.5 Consumer submits first login Portal/ CIS/ CRM
request App
15.6 System seeks password change CIS/ Portal/ App
CRM
15.7 Consumer changes default Portal/ CIS/ CRM
password App
16. Consumer Access to Consumption, Billing & Profile Data
16.1 Consumer logs in to Portal/ App Portal/ MDM
App
16.2 Consumer Profile for Portal/ App CIS- MDM Name, Account, Address,
CRM →Portal/ Service Points, K Number
App
 ANNEXURE-I

16.3 Consumption Data MDM Portal/ App Consumption profile

→UI
16.4 Billing (post-paid) / Credit Balance Billing Portal/ App Post-paid Billing history/
(prepaid) → Current Bill, Prepaid
MDM Recharge history
17. Prepaid Consumer Recharge
17.1 Consumer logs into Portal / Mobile Mob UI Login
App App /
Portal
17.2 Consumer fills-in required detail in UI→ Payment Consumer ID, Recharge
UI and requests recharge Prepaid Gateway amount
App
17.3 Consumer selects payment method Payment Net
Gate- banking /
way Credit Card
/ Wallet
etc.

S Use Case Activity Description Source Destin- Info Exchanged

No ation
17.4 Consumer receives payment Payment Prepaid
acknowledgement Gate- App→Portal
way →UI
17.5 Calculate credit balance for prepaid Prepaid HES→Met Consumer credit balance
consumer & update prepaid meter App er (virtual token)
17.6 Notify credit balance to consumer Prepaid Email/SMS Credit Balance
App Gateway
18. Post-Paid Consumer Bill Payment
18.1 Consumer logs into Portal / Mobile Mob UI Login
App App /
Portal
18.2 Consumer is presented with Billing Billing Portal/ Outstanding Bill
history and current outstanding Bill → App→UI
MDM
18.3 Consumer requests bill payment. UI→BilPayment
Option to download bill ling Gateway
18.4 Consumer selects payment method Payment
Net
Gate- banking /
way Credit Card
/ Wallet
etc.
18.5 Consumer receives payment Payment Billing→
acknowledgement Gate- Portal/
way App→UI
18.6 Payment acknowledgement through Billing Email/SMS Payment acknowledgement
email/SMS Gateway
19. Consumer Service Request including Occupation/Vacancy of Accn
19.1 Consumer logs in to Portal/ App Portal/ CIS/CRM
App
19.2 Consumer requests for service UI CIS/CRM Service request

19.3 System assigns SRN & sends CIS/ Portal/

acknowledgement CRM App→UI,
 ANNEXURE-I

Email/SMS
Gateway
19.4 System resolves request & updates CIS/ Portal/
consumer records CRM App→UI,
CIS/CRM
19.5 System closes SRN CIS/ Email/SMS
CRM Gateway
20. Consumer Complaints
20.1 Consumer logs into Portal/ App Portal/ CIS/CRM
App
20.2 Consumer registers complaint UI CIS/CRM Specific complaint

20.3 System assigns CRN & sends CIS/ Portal/

acknowledgement CRM App→UI,
Email/SMS
Gateway

S Use Case Activity Description Source Destin- Info Exchanged

No ation
20.4 System assigns resolution based on CIS/ CIS /
nature of complaint CRM OMS /
WFM
20.5 Target system reports completion OMS / CIS/CRM
of complaint WFM
20.6 System updates records and closes CIS/ CIS,
CRN CRM Email/SMS
Gateway
21. Demand read of meters from consumer premises
21.1 Requesting instantaneous, interval, MDM HES→Met Meter Number, Reading date
load profile & events data from er & time, reading params
meters (kWh, kVAh, kW etc.)
21.2 Acquire instant, interval, load Meter→ MDM Meter Number, Reading date
profile & events data from meters HES & time, reading params
by HES which then reaches MDM (kWh, kVAh, kW etc.)
system.
22. Staff User Access to Utility Portal
22.1 User logs in to Portal Portal MDM Login with appropriate
credentials
22.2 User selects available functions MDM Portal →
UI
22.3 User logs out Portal MDM
→ UI

4.4.1 Asset Management :

MDM shall maintain& track information and relationships between Smart meter and
consumer and also maintain the history of in-service asset location throughout the device life
with start and end dates associated with each in-service location reference as under---
- Meter location ( House / shop No, Colony , address etc.)
- Consumer information ( Name/Code No, Account, ID etc.)
- Meter Details (1Ph/3PH, Meter No, with or without Relay)
 ANNEXURE-I

- Meter configuration (Demand Integration Period, Load Profile Capture Period etc.)
- GIS Information ( Longitude, Latitude, connection with feeder/Tr/Pole etc.)
- Ability to report and log any damage/deterioration in the meter

4.4.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 generate reports on the number of meters installed in comparison to the number
of meters successfully communicating.

4.4.3 Meter Data :

a) The MDM shall have the ability to manage at minimum 15 minute interval data.
b) The MDM shall accept input, process, store, and analyze Meter data from HES and
meter data collected through handheld meter reading instruments and manual meter
reads in case of 07 day failure of automatic data transfer such as communication
failure etc.
c) The MDM shall provide meter data as per schedule and on demand meter read and
pinging of meter.
d) The MDM shall provide storage and retrieval of all collected Meter Data, events and
alarm. It shall have capacity of storing minimum five year data via archiving. The
archiving of data should be done at a suitable frequency and all data older than 60
days should be archived. AMISP’s 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) Handle special metering configurations such as net metering/pre-paid
metering/multiple meters at same premises.
h) The AMISP shall ensure data integrity checks on all metered data received from data
collection systems.

4.4.4 Validation, Estimation, and Editing (VEE) OF Metered Data:

The MDM should also support and maintain following -

a) Registered Read Data including register reads, daily billing cycle, as well as derived
billing determinants such as TOU
b) Interval Data channels with variable intervals and variable units of measure.
c) Calculated Data that is derived or computed such as billing determinants and
aggregated loads.
d) Event data storage of all collected event and alarm data from meters, network
equipment, and MDM itself.
e) The MDM shall flag, alarm and trigger as and when abnormalities observed in
estimating processes or any anomaly occur in cumulative register read, TOU register
read, Demand register reads etc.
 ANNEXURE-I

f) All data shall be transferred to billing system after meter data validation and
estimation
g) The MDM shall maintain both the original received raw data in a non- manipulated
state, in addition to VEE data.
h) 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.

4.4.5 Billing Determinants Calculations:

a) The MDM shall allow configuring multiple TOU options.

b) The MDM 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

c) The MDM shall have the ability to properly account for special metering situations
such as check metering, sub metering, prepaid metering etc.
d) The MDM shall have the ability to properly account for special situations such as
curtailment requests, demand response scenarios etc.
e) The MDM shall have the ability to facilitate implementation of automatic
compensation payments.

4.4.6 Prepaid/Post-paid functionality:

The MDM with the help of the corresponding HES, should be able to switch the Smart Meter
between prepaid and post-paid modes for any consumer by a simple change in configuration
of the Smart Meter firmware remotely including enrollment/setup of new consumers. The
following prepaid functionality shall apply:

a) An appropriate pre-payment application engine shall support the pre-payment

metering capability through the delivered system.
b) Associated information required by consumer’s Mobile App and web portal are to be
shared in near real time.
c) Prepaid consumers shall be provided facility to recharge their account by logging on
to the consumer portal/app through payment gateways such as on-line banking, credit
cards, payment wallets, UPIs etc.
d) 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.
e) 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.
 ANNEXURE-I

f) The system shall periodically monitor the energy consumption of prepaid consumer
and decrease the available credit based on consumption. For this purpose, the MDM
shall fetch billing data (kWh/kVAh) consumption and MD at configured intervals (at
least one hour) 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.
g) 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.
h) The prepayment application should be able to automatically apply different TOU
tariffs for future date lines, while calculating consumer credits.
i) The system should send connect/disconnect command based on available credit as per
notified rules & regulations.
j) 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.
k) 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.
l) It shall be possible to configure certain prepaid consumers where auto-disconnections
shall not happen due to negative credit according to set protocols.
m) The pre-payment function as part of MDM shall also have a facility to configure
arrear recovery mechanism to recover arrears from a consumer.

4.4.7 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 Work
Force Management (WFM).
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

4.4.8 Service Orders:

 ANNEXURE-I

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.
4.4.9 Revenue Protection Support:

a) Ability to analyze 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.

4.4.10 Billing Module:

The billing module would collect the date from the meter data management module,
calculate billing determinant and make energy data / billing data available to admin and end
user.

4.4.11 Occupation/Vacancy Module:

Occupation/vacation module shall be provided & the system shall support based on
the unit categories. The system shall support automatic data capture on occupation and
vacation events.

4.4.12 Energy Accounting Module:

The system would include features of energy accounting, the system would to able to
account for total energy block wise, facility wise and would also allow calculations of the
unaccounted energy in case total energy meter is also available.

4.5 Utility Interface and Consumer Portal/ App:

4.5.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.
 ANNEXURE-I

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 User Interface (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) Graphical User Interface (GUI) to provide role-based access based on user identity
and user role. It Shall have following types of 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.
o) UI shall enable viewing of the credit amount updated in MDM for prepaid
consumers.
p) Option to send 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) Authorized 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 defined. It shall be also possible to export the report data in multiple
formats such as XLS, CSV format, etc.
u) Provide consumer interactions history to enable efficient consumer complaints and
queries resolution with consumer information in single screen.

4.5.2 Consumer Portal/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
 ANNEXURE-I

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 recognizing 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 Internet Explorer (IE), Chrome, Safari,
Firefox etc.
d) The application should be modular and scalable a COTS product.
e) The application should be made in India for better user experience.
f) It shall support Hindi& English 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.
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.

4.5.2.1 Functional Requirements of Consumer Portal/ Mobile 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
 ANNEXURE-I

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

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.

4.6. Hosting on Local Dedicated Server / Government Cloud/ :

The AMI System can be hosted & managed either on local dedicated rack servers
with standby servers (to be installed at NOMC) or Government of India Cloud (MeghRaj) or
any MEITY approved CSP etc.).

4.6.1 If local dedicated rack servers are opted, Capacity of the servers and accessories are to
be provided by the contractor and it shall be commensurate to number of the Smart Meters to
be connected to the servers and it’s response shall be fast enough to achieve specified
response time of various activities as mentioned in this document. It shall also have
expansion capacity of 25% to cater for future requirements, if any.

Minimum Server specifications --- 03 servers of 64 Core, 128GB RAM, 1TB SSD
Hard Disk for each server.

4.6.2 Cloud Service Providers (CSP)

This section mentions key requirements from the Cloud Service Provider (CSP). Bidder shall be
responsible to provide the services of CSP.

General Conditions for CSP

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 Bidder 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) Bidder need to ensure that the CSPs facilities/services are compliant to various security
standards and should be verified by CERT Auditors of Armed forces
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 Bidder shall be responsible for providing the cloud data center services. It shall be up to the
Bidder, to identify the critical service agreements with the concerned cloud data center provider
the better services without any interruption.
 ANNEXURE-I

f) All Services including data should be hosted only in India

g) 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
h) 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 MES.
i) All the data stored for the entire contract period should be migrated, to the new environment,
server/Cloud before the expiry or termination of the contract.

4.7 Network Operation & Monitoring Centre(NOMC):

Necessary Room(s) for setting up Network Operations and Monitoring Centre to cater
to the needs of the AMI network operations team shall be provided by the CWE at the station.
Necessary desktop for workstation monitoring & control centre shall be deployed as detailed
in this specification.

The Room(s) to be arranged by the utility shall be properly illuminated, and adequate
for at least two operator workstations. Required power supply required for AMI Hardware
shall be provided by MES at one place in the room and further distribution in the room will
be in the scope of the contractor. Provision of Split ACs as per Room and equipment load
shall be provided and maintained by the contractor. Cost of such work to be carried out by
contractor in the NOMC is deemed to be included in the scope of work.
AMISP/contractor shall establish connectivity between the workstations located at the
NOMC with that of the cloud-based MDM-HES system. In addition, the AMISP shall
establish connectivity between the cloud-based MDM system with utility‘s existing Billing
system. All the necessary Hardware and Software along with security patches/ software’s
required for setting up NOMC are to be provided by the contractor.

4.6.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 AMISP. 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 AMISP 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.
 ANNEXURE-I

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.

4.6.2 Minimum Technical Requirements for NOMC Hardware:

The network operation and monitoring centre shall be equipped with the following
minimum hardware components:
a) Two numbers 17” Operator/Supervisor workstations
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
e) One video display system of at least 70-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 color 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

In addition to above, One Number of work Station along with B/W A4 Laser printer
shall be provided to Each GE formation or it’s BSO at a specified place along with Internet
connection

The minimum technical specification and requirement to be followed for hardware equipment
is as per below:-

Firewall(s)
Firewalls should be properly configured to segregate networks into different
1. segments. The following strategies shall be followed for the secure configuration of
firewalls:-
a) Clean up rule
b) Place a "Deny Any-Any" rule at the end of the rule base.
c) Never create an "Allow any-any" rule.
d) Allow rules should be created only for required services
e) This will result in all traffic being disallowed unless specifically allowed.
f) Lockdown /stealth rule
g) All Traffic destined for the firewall itself should be disallowed
h) Place anti-spoofing rule as per RFC 2827
i) Enable DoS / DDoS features on the Firewall
j) Enable application-level filtering of firewall
Firewall with UTM solution
GENERAL REQUIREMENTS
1. The proposed system must be appliance-based and rack-mountable
2. All UTM features like Firewall, Anti-Virus, Anti-Spam, Web & Application filtering up to
Layer 7. IPS.DNS
 ANNEXURE-I

3. Security, SSL Decryption Technology, Wildfire & Sandbox Technology, DOS

Protection with protect interface & Zone label, Data Filtering and File Blocking should
be available for UTM requirement. Licensing should be per device and not user/IP
based.
4. The proposed solution should support Balancing and Failover among more than 2
ISP Links (with USB Port 3G/4G and Wimax Support)
5. The proposed solution should support integration with Windows NTLM, Active
Directory, LDAP, Radius, RSA Secure ID, Novell e-Directory or Local Database for
user authentication and Guest User authentication via SMS.
6. The proposed solution must be able to be capable of deploying in Route (Layer3) and
Transparent mode (Layer 2), individually and simultaneously.
7. The proposed solution should support dynamic routing like RIP1, RIP2, OSPF, BGP4.
8. The proposed solution must support Automatic Transparent Single Sign On for user
authentication.
9. The proposed solution should support DNS, DDNS, NTP, SNMP, DHCP
(server/Relay), VLANs etc.
10. The proposed solution should support user, IP and mac binding that can map
usernames with corresponding IP and MAC addresses for security reasons.
11. The proposed solution must support User-based policy configuration for security and
internet.
12. The proposed solution should support the High Availability of Active/Passive and
Active/Active.

HARDWARE REQUIREMENTS
1. The proposed solution must be based on ASIC or Multicore Parallel Processing
Architecture
2 The proposed solution should support an inbuilt HDD 250GB for storage or an
external device for Logs and Reports to meet the UTM Features.
3. The proposed solution should have a minimum 8 x Copper GbE ports &
Expandable to 24 x Copper GbE ports for Future Expansion & Segregation of
Zones.
4. There should be a provision to Load Fiber modules (1G & 10G) for future
Enhancements.
5. The proposed solution should have a minimum of 2 USB ports.
PERFORMANCE REQUIREMENTS
1 The proposed solution should meet the following performance criteria & should
mandatorily produce valid references for the same at the time of bidding.
a. Firewall Throughput of 20,000 Mbps or Above
b. Concurrent sessions: 3,200,000 or Above
c. New sessions/second: 1,00,000 or Above
d. IPSec VPN throughput: 1,300 Mbps or Above.
e. SSL VPN throughput: 500 Mbps or Above
f. Antivirus throughput: 2,900 Mbps or Above
g. IPS throughput: 4,000 Mbps or Above
h. UTM throughput (Firewall, IPS, Web & App, Filtering and Anti-virus): 1,700
Mbps or Above.
UTM FEATURES REQUIREMENTS
1. The proposed solution should facilitate the application of UTM policies like AV/AS,
IPS, Content filtering, Bandwidth policy and policy -based routing decision on the
firewall rule itself, Also, UTM controls should be able to be applied to inter-zone
traffic.
2. The proposed system must provide Mac Address (Physical Address) based firewall
rule configuration to provide OSI Layer 2 to Layer 7 security.
3. The proposed solution must support Application/Web Category-based Bandwidth
Management which allows the administrator to create application/web category-
 ANNEXURE-I

based bandwidth policies.

4. The proposed solution should have a minimum of 4000 signatures in its database
& provision for custom IPS.
5. The proposed solution should support Anti-Virus scanning for SMTP, SMTPS,
POP3, IMAP, FTP, HTTP, HTTPS, FTP over HTTP protocols.
6. For POP3 and IMAP traffic, the proposed solution should strip the virus-infected
attachment and then notify the recipient and administrator.
7. The proposed solution should support spam scanning for SMTP, SMTPS, POP3,
IMAP.
8. The proposed solution must support an on-appliance quarantine facility and also a
personalized user-based quarantine area which allows you to release legitimate
emails.
9. The proposed solution should support real-time spam detection and proactive virus
detection technology which detects and blocks new outbreaks immediately and
accurately.
10. The proposed solution should have specific Web categories that broadly classify
websites. For instance, websites that reduce employee productivity, bandwidth-
choking sites or malicious websites.
11. The proposed solution should support the creation of cyclic policies on a
Daily/Weekly/Monthly/Yearly basis for internet access for individual users/groups of
users

12. The proposed solution should provide an option to define different bandwidths for
the different schedules in a single policy and bandwidth should change as per
schedule on the fly.
13. The proposed solution must be capable of identifying hidden applications running
over standard ports
14 The proposed solution must be capable of blocking the following type of
applications P2P, VOIP. Games
Remote: Control, Chats etc.
VPN REQUIREMENTS
1 The proposed solution should support IPSec, L2TP, PPTP and SSL VPN
connection.
2 The proposed solution should support DES, 3DES, AES, Two fish, Blowfish, and
Serpent encryption algorithms.
3. The proposed solution must support automatic failover of Point-to-point links
(MPLS) with VPN for redundancy purposes.
4. The proposed solution must support Apple iOS and Android VPN clients.
LOGGING & REPORTING REQUIREMENTS
1. The proposed solution should have On-Appliance, integrated reporting solution or
External Device.
2. The proposed solution should allow exporting of reports in PDF and Excel format.
3. The proposed solution should support logging of Antivirus, Antispam. Content
Filtering, Traffic discovery, IPS, and Firewall activity on the Syslog server.
4. The proposed solution should provide connection-wise reports for the user,
source IP, destination IP, source port, destination port or protocol.
5. The proposed solution should provide compliance reports for SOX, HIPPA, PCI,
FISMA and GLBA compliance.
6. The proposed solution should support multiple Syslog servers for remote logging.
7. The proposed solution should have customizable email alerts/automated Report
scheduling.
WARRANTY, SUPPORT & CERTIFICATION REQUIREMENTS
1. Warranty & UTM Features Subscription: (full contract period)
2. OEM Web/Phone/Chat Support: 24x7 (full contract period).
 ANNEXURE-I

3. The proposed solution should meet the following Certification Criteria.

a. Common Criteria - EAL4+
b. "IPv6 Ready" Gold Logo
c. ICSA Firewall or equivalent.
Note: 1. Above mentioned requirements are minimum acceptable specifications and
may vary as per the requirements, from time to time, as per industry-accepted
standards.
2. Any License required for Operating system/AMISP-solution shall be provided
by AMISP till the completion of the contract.
Router(s)
Necessary control should be applied to the router to stop unwanted traffic and attacks at
the perimeter itself. In the secure configuration of a router, the following strategies should
be considered:
a. Deploy proper access management and avoid remote administration.
b. Enable password
c. Change the default SNMP community string.
d. ACLs (Access Control Lists) Should include:-
i. Apply egress/ingress filter
ii. Filter all RFC 1918, 3330 address space and special/reserved address
iii. Permit the required service for the required IP addresses only.
iv. Deny everything else.
 ANNEXURE-I

e. Turn on logging to a central sys log server

Note:- 1. Above mentioned requirements are minimum acceptable specifications and

may vary as per the requirements, from time to time, as per industry- accepted
standards.
2. Any License required for Operating system/AMISP-solution shall be
provided by AMISP till the completion of the contract.
Local Dedicated Servers
If local dedicated rack servers are opted, Capacity of the servers and accessories
are to be provided by the contractor and it shall be commensurate to number of the Smart
Meters to be connected to the servers and it’s response shall be fast enough to achieve
specified response time of various activities as mentioned in this document. It shall also
have expansion capacity of 25% to cater for future requirements, if any.

Minimum Server specifications --- 03 servers of 64 Core, 128GB RAM, 1TB SSD
Hard Disk for each server.
 ANNEXURE-I

Other Hardware Configuration

A. Desktop at NOMC

S.No Description Minimum Specification

1 Form Factor (Computer Desktop Mini/Micro (Provision to Mount the CPU behind
Type) it)
2. Processor & Chipset 10th Generation Minimum Core i7-8700T (Min 2.4 GHz
with Turbo up to 4 GHz, 12 MB Cache, 6 Cores, 12
Threads) or higher Q370 Chipset or higher
3. Monitor 19.5" or higher IPS Panel LED backlit with TCO 7.0 and
1440 x 900 Resolution
4. Memory 32 GB of ECC DDR4 Memory and Scalable up to 512
GB memory {Memory slots free for expansion}
5. RAM 16 GB delivered, expandable up to 64 GB
6. Display Minimum 2 Nos, *17" (1280x1024), Antiglare LED
Monitor Should have a display port and VGA connector.
Provision to mount the CPU behind it. Both monitors
are to be connected to the CPU with proper
connector/video cables.
7. Mounting Desktop mounting
8. Operating System Window 10 Professional (64-bit) with the latest Service
Packs pre-installed
9. Operating System (OS) Windows 10:64-bit (Original OS CDs and license keys
Support to be provided)
10. Processor Speed 3.0GHz each processor
11. Internal Auxiliary Memory 500GB delivered, expandable up to 1TB
12 Speakers Two internal Speakers
13 Interfaces  1 GB Dual Ethernet ports
 Min 4 USB Ports of which at least 2 USB Ports in
Front
 Front I/O: (2) USB 3.1 Gen 1 Ports, Universal Audio
Jack
 Port for cartridge magnetic tape drive
 Graphic adapter cards (HDMI)
 Rear I/O : (4) USB 2.0 ports, (2) USB
 3.1 Gen 1 Ports, (1) VGA video port:(1)
Display Port Port,(1) RJ-45 Network Connector, (1) RS-
232 serial Port, (2) PS/2 Ports, 3 .5mm audio in/out
jacks.
14. User Interface Three/Two (as per list of Materials and Services at
Form 14 of Section 4 of the RFP) 24" widescreen (16.9
aspect ratio)
HD Resolution (1920x1080) TFT Colour monitors,
keyboard & optical mouse.
15. Graphic Integrated Intel ®HD Graphics 630 or higher
16. Audio High-Definition Integrated Audio with Internal Speaker
17. Hard Disk 1TB 2.5" SATA III 6.0Gbps HDD @ 7200 rpm,
Partitioned into 2 drives.
 ANNEXURE-I

S No Description Minimum Specification

Drives
18. Ethernet Integrated Gigabit (10/100/1000 NIC) LAN
19. Connectivity Integrated Gigabit LAN Network Connection 10/100/1000
Mbps NIC with RJ45/UTP Interface.
20 Keyboard USB 104 Keys or higher OEM make.
21. Mouse 2 Button USB optical scroll mouse OEM make.
22. Chassis Volume Max. 1.2 Litre (without Mounting Kit). CPU must be
mounted behind the monitor.
23 Power Supply Minimum 65W or above External Indian Power Adapter
for CPU with an average efficiency of 87% or more
24. Security Features TPM 2.0, Setup/BIOS Password, Slot for locking CPU
using lock and key (Lock with 2/3 keys should be
provided)
25. Software Office 365 Enterprise
Loaded in Desktop)
26. Diagnostics Tool Inbuilt Pre-Boot BIOS Diagnostics
27. Security TPM 1.2 Security Chip, SATA port disablement (via
BIOS), Serial, USB enable/disable (via BIOS),
Removable media write/boot control, Power-on.
Password (via BIOS) , the Administrator
Password (via BIOS), Setup password
(via BIOS), Support for chassis padlocks and cable lock
devices
28 Warranty 5 years Comprehensive onsite warranty
29. Compliance & Energy Star ver 6.1, EPEAT Certified for India for quoted
Certification desktop & Monitor, TCO
Certified for both Desktop & Monitor FCC CE, RoHS
certified UL Certified ISO 9001, 14001, 27001, Certified
OEM
29 Information Accessibility Product details, specifications, and brochure to be
available in the public domain
30. Support Drivers should be available for download from the OEM
site for at least 5 years from the date of purchase order.
B. Workstations with Monitor:
The workstation for the development system shall consist of dual monitors & single keyboard
and a cursor positioning device/mouse. The user shall be able to switch the keyboard and
cursor-positioning device as a unit between both monitors of the console. Workstation
consoles shall also be used as development consoles to take up developmental.

Maintenance activities such as generation updation of database, displays etc, and to impart
training. The minimum hardware configuration of the operator workstation and Display
monitors are as follows:
Operator Workstation -
1. Spec As per the base runtime requirements of SPEC CPU
2017 V1.0 Benchmarking Standards.
2. RAM 16 GB expandable upto 64 GB
3. Processor Speed 3.0 GHz
4. Internal Auxiliary Memory 2x500 GB RAID, expandable upto 1 TB
5. Speakers 2 Internal speakers
 ANNEXURE-I

S No Description Minimum Specification

6. Interface 1GB dual Ethernet Ports; Min 4 USB Ports;
Port for Cartridge magnetic type drive;
Graphic adapter cards (HDMI)
7. User interfaces 24" Widescreen (16:9 aspect ratio); HD resolution
(1920x1080), TFT Colour monitors, Keyboard and optical
mouse
8 Mounting Desktop Mounting
9. Power Supply Dual AC power Supply
10. Operating System Microsoft Windows 10 or Latest Professional (compatible
with the OEM Software)
Monitor-
1. Diagonal Viewable Size Yes
2. Colour Support 16.7 Million
3. On-Screen Control Required
4. Anti-Glare and Anti Yes
Static
5. Tilt, Swivel Yes
6. Aspect Ratio 16:9
C. UPS - 2KVA Line Interactive INTELLIGENT UPS for Desktop PC
1. Capacity 2KVA Line Interactive
2. Back up time 10 Minutes on 450 VA Continuous Load Overload
capacity: 125% of required capacity for at least 1 Minute
3. Input Voltage 230 V AC, Single Phase 3 Wire
4. Input Voltage Range 160 V AC to 270 V AC
5. Input Frequency Range 45 to 55 Hz
6. Input OV Protection 280 V AC
7. Input Under Voltage 155 V AC
8. Over Voltage Cut-Off Should be offered externally
9. Output Voltage 230 + 5% (on Battery) Automatic Voltage Regulation
10. Output Over-Voltage 245 V AC Single Phase
11. Out put Under Voltage 210 V AC Single Phase
12. Protection Load PF 0.8 Lag to Unity
13. Short Circuit Protection The Soft shutdown should occur without blowing any fuse.
14. General Features Automatic Voltage Regulation, Lightning & Surge
Protection; Output Waveform - Modified Sine wave
Audio Alarms: Low Battery; Battery ON: Overload
protection: Overload, Short Circuit, spike & Surge
15 Switching Time Less than 5 MS without data loss
16. Operating Temp Up to 40 Deg C.
17 Operating Humidity Up to 90%, Non-condensing
18. Battery type SMF-Hitachi/Exide/Global Yuasa/ Panasonic make or
equivalent
19. Make APC, Liebert, TVSE, PowerWare (Invensys) ,
Guard/NEXUS, Wep, HCL or Equivalent
20. Others Output Sockets - Min 3 Nos, Each 6 Amp-3 Pin with all
Sockets wired for UPS output Sockets of UPS must be
compatible with PC and Printer
UPS Input Power plug should be of Indian standard.
Software: Required for health monitoring of battery &
power mgmt., system RS232-C Serial port or USB port
with interface cable, min 3 Ft Long.
 ANNEXURE-I

S No Description Minimum Specification

D. A4 B/W Network Laser Printer
1. Make & Model As approved
2. Type Dry type Laser Electro Photography
3. Function Print, Copy, Scan
4. Resolution Colour 1200x1200 dpi
5. Speed (colour) 32 PPM or higher for A4 in normal mode, first page
out 8 seconds
6. Memory 256 MB or Higher
7. Processor 466 MHz or better
8. Paper Size A4 and Legal including Envelops & letter
9. Type of Media Bond Paper, Transparency Sheets, Envelopes
Labels, Cards.
10. Paper Handling 250 Sheet input Tray, 50 Sheet Bypass Tray.
150 sheet output Tray
11. Std Paper Trays input Two Trays (Total Paper input capacity 300 Sheets
or More)
12. Printing Languages PCL 6, PCI 5, Postscript 3 emulation
13. Interface Hi-Speed USB 2.0
14. Duplex Printing Capability Automatic Duplex
15. Duty Cycle 50,000 Pages per month or higher
16. Connectivity Hi-Speed USB, 2.0, Gigabit 10/100/1000
17. N/W Print Mgmt S/W Needed
Built in Wireless networking
Fast Ethernet network port
18. Power Requirement Less than 750 Watts
19. Copy Copy Speed Black (A4) up to 20 ppm
1200x2400 dpi: Originals content settings: Text,
Text/Photo, Photo, Map: Reduce/Enlarge scaling:
25 to 400% Copy Quantity setting: 1 to 999:
Darkness Controls: Scan 600
First Copy time 9.0 Sec
Maximum Number of Copies 999
Copy Features: Memory Sort. 2 on 1, 4 on 1, ID
Card Copy
20 OS Support Vendor to provide drivers for supporting all the
required OS
21. Scanner Specification Flatbed Scanner Handles up to 8.5 x 14 in
(216x356mm) Paper
Scan File Format: PDF, Single-Page-TIFF, JPEG,
Multi-Page-TIFF, Single Page-PDF, TIFF
Scanner Resolution: 1200 x 2400 dpi
Scanning Depth (Input/Output)
Colour: 48 Bit/ 24 Bit
Greyscale: 16 Bit/8Bit
E. A4 Size Inkjet/ Bubble Jet Printer
1. Printer Type Inkjet/Bubble jet;
2. Functionality Print, Scan, Copy: Printer Output - Color
3. Connectivity Wi-Fi and USB
 ANNEXURE-I

S No Description Minimum Specification

4. Compatibility Windows 10, Windows 8, Windows 7 SP1,
Windows Vista SP2 Mac OS X v10.8.5 an later
5. Power Requirements AC 100-240V, 50/60 Hz
6. Power Consumption Manual-off:0.2W: Standby: 1.6 W
7. USB Support USB 2.0
8. Page per minute 4 pages (Color), 8 pages (Black)
9. Page size Supported A4, A5, B5, Letter, Legal, 4x6", 5x7", Envelopes
(DL, COM10), Square (5x5") Custom size (width
101.6-215.9mm, length 127-676mm): Duplex
Print-Manual
10 Print Resolution 4800x600 dpi
11 Scan Resolution 600x 1200dpi

Note: 1. The above-mentioned Requirements are minimum acceptable

specifications and may vary as requirement, from time to time as per industry
accepted standards.
2. Any License required for Operating System/AMISP solution shall be
provided by AMISP till the completion of the Contract.

4.7 System Software Requirements:

4.7.1 All software provided by the AMISP/contractor, including the operating system,
database, AMI Applications, and support software (compilers, DBMS, display development,
network utilities, report generation, diagnostics and backup utilities) , 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
AMISP/contractor shall commit to meet the "open systems" objective promoted by industry
standards groups. All the software shall be compatible with smooth function with computer /
Work Stations with keyboard, Smart Mobile Phones etc.

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

a) Expansion: Software shall be dimensioned to accommodate the size of AMI

application system
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.
 ANNEXURE-I

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.

4.7.3 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 AMISP
and shall be valid throughout the contract period.

4.7.4 The AMI application & other servers shall maintain time and calendar for use by
various software applications and all of them shall be in synchronization with NTP.

4.7.5 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 AMISP/utility on such events of remote access and diagnosis.

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

4.7.7 The AMISP 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 System should support exchange of data from
utility‘s computerized billing & collection, consumer indexing and asset mapping systems
residing at different servers.

4.7.8 The AMISP shall provide necessary software tools preferably browser based for the
generation, management and Integration of AMI application displays. 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.
 ANNEXURE-I

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.

4.7.9 AMISP shall supply all software utilities used to develop and maintain these 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.
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.
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.
Facility of data export and import between this system and external systems shall be
provided through web services.

AMI Application management shall also 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.
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 AMISP 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 AMISP shall
be responsible for the maintenance & update of the antivirus software during the
contract period.
f) Software Upgrade-The AMISP 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.
 ANNEXURE-I

4.7.11 Cyber Security:

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 cyber security framework should be adopted by the AMISP. Global
Security Standards and Indian Standards that are relevant in context of underlying
technologies shall be used in securing AMI such as framework for Cyber Physical Systems
(CPS) developed by National Institute of Standards and Technology (NIST), National Cyber
Security Policy developed by Department of Electronics and Information Technology
(DeitY), Government of India etc.

Cyber security incident management will be managed as per ISO/IEC Standard 27035.

4.7.11.1 Notwithstanding the measures suggested above, the following

guidelines/strategies shall be taken care of by the AMISP 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
AMISP 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 AMISP 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 (Site Acceptance Test) & Operations and Maintenance period.
k) Auditing by third party during SAT and annually during operations and maintenance
period shall be in the scope of AMISP.
l) As the computer system in NOMC has access to external environment the AMISP
shall document and implement Cyber Security Policy/Plan in association with the
Utility to secure the system.
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) AMISP 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 AMISP shall provide in the form of a document
 ANNEXURE-I

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.

4.7.11.2 CERT Audit of Smart Metering System at the time of commissioning shall be
carried out. Subsequent audit of the system shall be carried out after every three years. Cost
of such audits and rectifications thereof shall be borne by the contractor. This clause shall be
applicable to both new as well as existing Smart Metering System. The following cyber
Security as aspect shall be adhered to: -

(a) Compliance to Information Security Management Standard such as ISO

27001.
(b) Securing network architecture of the system including hardening and secure
configuration.
(c) Physical security of Smart Metering System.
(d) Identify and authentication management, access control, Incident detection
and response.
(e) ICT components of the Smart Metering System should have logging feature
for monitoring of the parameters. Logs must be maintained for a period of six
months as per CERT-In guidelines and the same should be integrated with
central syslog server/SIEM.
(f) Use of Wi-Fi/Bluetooth are prohibited.
(g) Hardening including firmware updation, turning off all unwanted services,
Ports and features in the IT Assets of the system. This should be carried out
during installation and checked while undertaking Internal/External Audits.
(h) Admin accounts should always be managed by network admin using
dedicated/pre-designed machines only.
(j) Custodians of Smart Metering System will be single person i.e. Garrison
Engineer and not the Junior Engineer/Asst Garrison Engineer.
(k) Provision of SIEM at the centralized console to analysis logs of ICT Assets.

4.7.11.3 The IT Infrastructure will have multiple security layers to secure the
infrastructure from threats. The proposed deployment has different security zones as briefed
below and all zones shall have separated firewall in addition to the external (Perimeters
security appliances). The firewall policies shall be configured based on zone-based
requirements. All user traffic will enter in this security zone after firewall only. The
proposed solution will have provision of dedicated internal firewall to secure the critical
production (Data base and application) environment.
Web server/Application: This security zone will host all servers that can be
accessed from external users after authentication and traffic filtering. This zone shall host the
web servers, access control and sign on servers, antivirus server etc.
Testing and Development Zone: This zone will host all servers required for test
and development for applications. This zone will have limited access and it will not have any
direct access to Production Server Zone and the activity shall be monitored. It is to
implement Smart Meter / AMI system on GPRS/RF/Hybrid (RF+GPRS)/ any other advanced
communication technology i.e. communication technology need to be decided based on field
condition, and most suitable communication technology in that area shall be selected for
meter data acquisition.

4.7.12 Cloud Security: (In case Server is not provided)

 ANNEXURE-I

a) The following basic security features should be ensured by any Cloud Service
provider (CSP):-

(i) Strong encryption capabilities for data in transit or at rest.

(ii) Identity and Access Management (IAM) . This controls users access
to cloud services create and manage users and groups, and grant or
deny access.
(iii) Managed Threat Detection. This service provides a more
accurate and easy way to continuously monitor and protect cloud
accounts and workloads.
(iv) Managed DDoS Protection. This protection service that safeguards
web applications running on cloud
(v) Web Application Firewall. It helps protect web application from
common web exploits that can affect application availability,
compromise security or consume excessive resources.
(vi) Key Management Service (KMS). This service makes it easy to
create and control the encryption keys used to encrypt data.
(vii) Certificate Manger. This manager and deploys Secure Sockets
Layer/Transport Layer Security (SSL/TLS) Certificates.
(viii) Cloud Hardware Security Module (HSM).This meet regulatory
compliance requirements for data security by using dedicated HSM
appliances with the Cloud.
b) CSPs also offers access to additional third-party security tools (e.g. IDS/ Intrusion
Detection System (IDS), Intrusion Prevention System (IPS), System Information and
Event Management (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 comprehensive security architecture. These security tools
on cloud are equivalent and identical to the existing controls in an on-premises
environment.

c) The Contractor 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 captures for supporting
any downstream audits of the projects by the finance or audit organization such as
Standard Testing & Quality Certificate (STQC), Meity Govt of India.

4.7.13 Data Privacy:

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

The Utility shall be the sole custodian of the Smart Meter data. The AMISP and its
contracted vendors will have limited need basis access to the data.

AMISP is required to adhere 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:
 ANNEXURE-I

i. Aggregated Data: No identification individually and at neighbourhood 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.

Certain Do's & Don'ts have to be strictly implemented to ensure privacy & security of
consumers: -

Do's----
(i) User IDs must not reveal identity and locations.
(ii) User ID to be kept in confidentially by Competent Engineer Authority
maintaining the overall system.
(iii) Any breach of information from server/cloud should immediately be
reported to Local Military Authority
(iv) Syslogs by installing SIEM log collectors should be in place to
maintain records.
(v) Regular change of passwords is imperative. System driven periodic
change of passwords to be ab-initio built into the applications.
Don’ts----
(i) No Personal Identifiable Information (PIIs) be used in the system.
(ii) Tempering of meter.
(iii) Disclosure of Information of consumer to anybody other than the
consumer.
(iv) Access to servers by only authorized person.

4.7.14 Cyber Audit:

Audit of software for AMI will be done by CERT-India empanelled firm/ CERT
Auditor of Armed Forces. The cost of the audit will be borne by the Contractor.

4.7.15 Work of various subsystems of AMI shall be prioritized & executed in such a way
that AMI system is in place as soon as 20% Smart metres at a station are installed, Smart
Metering System is operational in ‘Go-Live’ phase.

5.0 AMI System Integration:

The AMISP‘s core deliverables are the MDM, the HES, the NMS and the smart field
devices (DCUs/Routers, Smart Meters etc.). Integration of different devices of different
makes/ equipment/ software is covered in scope of this project with each other as per
functional requirements, including water charges, furniture and license fee etc.
Integration/interface of the AMI system with application systems like
metering/billing/collection is to be ensured. Interface has to be provided in the proposed
solution to upload and process meter data from these systems.

Hence the system integrations shall comprise of the following:-

a) HES with field devices (DCUs/Routers and smart Meters) & NMS Module
 ANNEXURE-I

b) MDM with HES , Billing Module, Occupation/Vacancy Module and Customer

Module Other legacy IT/OT systems as required by the utility.

The integration middleware should be based on Service Oriented Architecture (SOA) and
other forms of Application Program Interface (API) and use publish subscribe mechanism.
The integration middleware has to be an open architecture based. Implementation and
configuration of functional APIs from different meter manufacturers and configuration of
Head End System/Meter Data Acquisition System has to be done. All meter data of 30/15
minutes block (Load profile) shall be polled at least once in a day. The duration to polling
frequency shall be remotely configurable and can be altered as per the requirement of MES.
The bidder must store and manage the security information related to Smart Meters. These
include Device Security keys and asset information for processing further by MES. The
bidder must support the mass receipt of data of each meter every day and subsequent update
of Meter Data Management System with the necessary asset information to complete meter
reading and billing. The integration middleware / interface must validate the data to be
integrated. It must maintain integration logs that confirm the success or otherwise of the
interface, complete with control totals. The integration mechanism adopted must have
minimal impact on the existing systems.

6.0 Consumer Indexing &Meter Installation:

Consumer Indexing (CI) and Meter installation & its inventory management will be the
responsibility of the Contractor/AMISP at each location covered in the project. CI database of
electrical indexing shall have the following broad parameters:

— Energy Meter name plate details

— Meter clustering if any
— Sealing Status
— Installation Date
— Start Reading (New Meter) and Last Reading (Old Meter)
— Geo Location
— Customer Identification No
— Username
— Postal Address / Telephone / Email — Sanctioned Load
— Pole/DT/Feeder Code etc.

This Data shall be automatically updated in AMI system. CI data is required to be

verified/ validated by the concerned MES Authorities.

6.1 The contractor shall prepare a SOP (standard Operating Procedure) document for
meter installation in consultation with MES and Meter installation activity shall adhere to this
document. Installation services shall be performed in a professional and courteous manner,
from initial appointment set up to final installation of the meter. Customer service, effective
project team and customer communication are of the utmost importance to this project. All
site installation personnel employed on this project will be subject to background checks and
shall, at all times, carry a suitable Govt. issues photo ID ( such as Driving License, Voter
Card, Aadhaar etc.) for identification. Scope of AMI Implementing Agency shall include but
not limited to:

o Removal of Old Meter & taking down the meter reading

o Installation of new advance prepaid meters IS 16444 -2015 (reaffirmed 2020)
 ANNEXURE-I

o Install SIM Card in the Suitable Range DCU, DCU/router/Gateway/Access

point & activate / register new meters with Head End System &MDMS
o Transfer Old & new meter data to the MES
o Manage the installation performance
o Provide daily, real-time project status updates of installations to MES

Most of the installations are meter replacement cases the contractor shall adhere as
per the Regulations on “ Installation and Operation of Meters”, 2006 to be read in
conjunction with amendments.

MES Project in- charge shall check on the quality of installation by checking methods
and its integration with AMI backend system by performing basic data communication with
the HES application. On successful test and field quality check the MES In charge engineer
will certify for acceptance to contractor.

6.2 SIM card Management:

AMI Implementation Agency shall ensure the availability, insertion and management to
be used in communication module of Automatic meters. However, GPRS M2M industrial
grade SIM has to be managed by the contractor. The installation and replacement of SIMs at
site shall be in scope of AMI Implementation Agency (IA). In order to pursue this, following
points need to be ensured by the system Integrator. The SIM will be in the name of GE and
the charges shall be paid by contractor as defined in BOQ.

o AMI Implementation Agency will be responsible for management of SIM

inventory including but not limited to total installed, in-stock, replaced and
rejected/suspended/ terminated SIMs.
o AMI Implementing Partner shall ensure that SIM information is availability.
o AMI Implementing Partner shall ensure quality aspect of physical NIC or SIMs
from NBSP along with the maintenance of buffer stock of NIC and SIMs & their
activation - deactivation.
o AMI Implementing Partner shall ensure timely suspension, termination, activation
and reactivation of NIC or SIMs and the process shall comply to the prevailing
regulations
o AMI Implementing Partner needs to monitor the usage, alarm, events for the SIM
cards used in AMI solution.
o SIMs needs to be preconfigured for activation before meter installation begins
o AMI Implementation Agency shall ensure that communication module is properly
sealed after SIM insertion before installation.

7.0 Analytics & Reports:

The MDM shall have analysis capability based on configurable business rules including but
not limited to the following:

7.1 Energy Audit:

Perform DT/Feeder/ Sub-Division/ Division 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. Energy Audit functions may be as under but
limited to these:-
 ANNEXURE-I

a) Display consumption/load profiles by configurable period

b) Generate peak & off-peak load patterns by aggregating all loads of consumer
group/consumer type/DT/Feeder over configurable period/day type.
c) Perform load analysis for different groups and categories of consumers in
different weather conditions.
d) 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.
e) Analyzing data to identify new patterns of usage, Setting fraud alert / transformer
overload alerts / demand – supply gap alert etc.
f) Ability to receive and store outage and restoration event data from Smart Meters
and outage systems and to log all such events for analysis
g) Ability to alerts on DT/ Feeder level overvoltage & back-to normal event and
under-voltage and back-to-normal events

7.2 Reporting Function:

The MDM shall generate following reports (an indicative list only). Utility may request
for additional reports as well during the contract period.

a) Daily data collection report

b) Usage exceptions
c) VEE validation failures
d) Missing interval Read date and times (on hourly, daily, weekly & monthly basis)
and their trends
e) Physical meter events (install, remove, connect, disconnect) & meter reset report
f) Meter flags
g) Meter inventory
h) Defective meters
i) AMI performance measurements
j) Threshold exception
k) DT condition monitoring
l) MIS reports and analytical reports including but not limited to following:

- Payment collection summary and details in a day/week/month/year or as per

user selectable period and trends
- Number / list of disconnected consumers due to inadequate prepaid account
balance
- Prepaid consumers running low on account balance
- Connected consumers
- Critical notifications sent to consumers
- Revenue analytics as per consumption pattern of consumers (in terms of
money and energy units).
- Data-driven Analytics reports by leveraging AI/ML based technologies

8.0 Pre-Commissioning Testing (Site Acceptance Test(SAT)):

The AMISP 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 AMISP’s recommended procedures.
The SAT shall exhibit generally all functions of the equipment as per factory test reports. All
variances must be corrected prior to the start of the SAT. The list of final tests to be carried out in the
 ANNEXURE-I

field shall be listed in the site-testing document by the AMISP. The site testing document shall
include the following minimum performance tests:-

Data Type Performance Requirement

1. Load Profile Data Read
From 98% of the meters in
One-month block load profile for installed meters
12 hours after the midnight
2.Billing Profile Data Read
From 98% of the meters in 12
Billing profile data for installed meters
hours after the midnight
3.On-Demand Remote reads of meters

Collection of 7days 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;
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
Alert to be received within 3
Receiving of alert for an individual meter
minutes
9.Power Quality Alerts
Alert to be received within 5
Receiving of alert for an individual meter
minutes
10.Firmware upgrade with acknowledgement/ response for selected meters

Data Type Performance Requirement

Action performed at 99% of

meters within [18] hours; and
For installed AMI meters (for a batch of at least 20% of installed
Actionperformedat99.9% of
base)
meters within [24] hours
11.Remotely altering settings in meter

Action performed at 99%of

meters within [8] hours; and
 ANNEXURE-I

For installed AMI meters (for a batch of at least 20% of installed Action performed at 99.9% of
base) meters within [24] hours
12.Remotely read events logs
Action performed at 90% of
meters within [30] minutes;
Action performed at 99% of
For reading the full event log for installed AMI meter meters within 1 hour; and
Action performed at 99.9% 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
within1(one) hour
16.Utility User Interface
Manual data entry of new value appears on screen Less than 6secs
Acknowledgement of any action request Within 3 secs
Display update rate 2 secs
17.On-Demand Remote reads of meters
Collection of 7days 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)

The Pre-commissioning tests and inspection will be carried out after installation of
AMI completely by an Officer detailed by Accepting officer in presence of the GE, Engineer-
in-charge and the Contractor & OEMs. All the arrangement at site for testing/Re-testing and
its Cost will be borne by the contractor.

9.0 Operation & Maintenance:

The operation, maintenance, and support services start after the successful completion of
the operational go-live of the system. 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 (including licensing, version upgrades

if any and annual technical support cost)
b) Comprehensive maintenance of all hardware at the Operation and Monitoring Centre,
along with field devices (like Smart Meters, DCUs etc.) provided by AMISP under
the project
c) Comprehensive maintenance of all equipment under leased service like cloud data
centre, MPLS band width etc.
d) Comprehensive maintenance of NAN / WAN communication infra between field
devices and the cloud data centre
 ANNEXURE-I

e) Day to day operations of the AMI system under supervision and authority of the
Utility. These shall include among others:-
i. New meter installation
ii. Changeover of consumer meters from post-paid to prepaid mode and vice
versa
iii. Firmware update of remote devices (Meters and DCUs) as required
iv. Update of tariff slabs
v. Ensuring completion of recharge cycle of prepaid consumer meters
vi. Connecting, disconnecting or reducing consumer‘s licensed load under
approval from the Utility
vii. Initiating resolution of consumer trouble tickets raised by utility
viii. Ensuring availability of interval data and event notifications from meters in
time schedules as agreed with the utility
ix. Ensuring scheduled completion of billing determinant calculations
x. Ensuring daily reports from the AMI system as per agreed list, are made
available to utility
xi. Ensuring Consumer Portal is kept updated
xii. Ensuring smooth data traffic between the MDM and utility systems
xiii. Patch management of AMI applications at cloud data centre
xiv. Provide backup data to support SLA and AMISP invoicing
xv. Carry out performance checks of various functions as per agreed schedule or
on demand

As part of their Operation and Maintenance responsibilities, the AMISP shall develop
a compendium of Operation and Maintenance Manuals. These manuals shall be kept updated
as often as necessary to reflect best practices being employed in the project.

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

Scheduled preventive maintenance, performance monitoring, system backup,

hardware & software maintenance and update, field & network devices firmware update,
emergency response and troubleshooting etc. shall be carried out periodically.

9.1 Contractor should provide all the updates free of cost till completion of
contract. Contractor should also provide the required training to the users for operating,
developing system and administrative training to selective persons for running system after
support period free of cost. Any software updates, upgrades, patches released shall be
supplied & installed and commissioned till completion of contract under scope of agreement /
PO / RC. Contractor shall maintain the system on 24X7 basis as per contract conditions.

9.2 The contractor shall depute the requisite manpower at appropriate levels
across the project area for upkeep of the Advanced Metering Infrastructure
(Meters/DCU/Communication Modules) installed at sites. The contractor has to deploy the
requisite manpower (on site deployment) at appropriate levels for maintenance of the
software system, undertaking change requests, report generation etc. The contractor has to
maintain and continually monitor the assets installed and see to that all the infrastructure is
working for providing seamless data acquisition.

9.3 Post Implementation Support &Guarantee Requirements:-

 ANNEXURE-I

 The Contractor warrants that all the Goods are new, unused, and of the most recent or
current models, and that they incorporate all recent improvements in design and
materials, unless provided otherwise in the Contract.
 The Contractor further warrants that the Goods shall be free from defects arising from
any act or omission of the Contractor or arising from design, materials, and
workmanship, under normal use in the conditions prevailing in the country of final
destination.
 Guarantee of Hardware /software/ Communication infra which include bug fixing,
patches, replace, upgrade etc. and same shall be provided.
 Trouble shooting of AMI Hardware/Software.
 System and database administration
 Post implementation support and management shall be governed by performance
parameters as mentioned in this tender.
 Post implementation shall also cover the new requirement of tools, application,
reports etc. of MES.
 The contractor shall provide the off-site support of experts also to resolve the issues in
shortest time.

9.4 Stock Inventory Maintenance:

a) The contractor will be responsible for management of all the smart meters
mentioned in the BOQ with the same specification available in the tender as a
buffer stock 5% without any additional cost offered by MES.
b) The contractor shall ensure that in case of any observation arise from the field the
buffer stock shall be utilized as replacement with Prior approval from MES.
c) The contractor shall ensure at any point of time till the warranty period the
mentioned buffer stock must be available in their custody and the same shall be
acknowledge by MES where ever it’s applicable.
d) The contractor always responsible to carry out and complete the
replacement/Erecting activity mentioned in the Penalty class.

The contractor will be responsible for replacement and making operational of any
meter within 72 hrs of meter going faulty. The vendor must maintain suitable buffer stock to
ensure the same.

9.5 Penalty:

Contractor should be responsible for serviceability of all meters during guarantee

period contractor should also rectify the complaints of user within a period of 72 Hrs. A
penalty for not repairing /replacement within 72 Hrs will be charged at a rate of Rs 100 per
day per meter.

10.0 Training:

Minimum 60 Days Training to MES employees (To be detailed by CWE) on software

from the OEM or OEM’s certified training partner shall be arranged by the contractor
including end user training. In addition, MES Employees may also be detailed for day-to-day
on the job training.

The training modules shall include but not be limited to :

 ANNEXURE-I

a) AMI Administration & Configuration

b) AMI Installation and troubleshooting
c) Application Management and Operations
d) Database and Data Analysis Reports
e) Cyber Security
f) Smart Meter and communication technology

11.0 Key Personnel:

The AMISP/contractor shall appoint at least the following personnel dedicated for the
AMI Project from the commencement of the project till Commissioning of the project.
a) Project Manager: She / he shall have the authority to make commitments and
decisions that are binding on the AMISP. Utility will designate a Nodal officer to
coordinate all project activities. All communications between the Utility and the
AMISP shall be coordinated through the project manager and nodal officer. The
project manager should be an expert in AMI Implementation including metering and
related aspects, installation and management of Smart Meters, communication
network, last mile connectivity, HES and MDM. The project managers shall be
responsible for all communications between other members of the project staffs
including sub-contractors, if any.
b) System Integration Expert: An expert in System Integration covering application
software, hardware and network installation, integration design and ability to manage
multiple partners with different skill sets in different technology domains.
c) Cyber Security Expert: An expert in cyber security related aspects covering
planning and implementing high level system security requirements, managing data
privacy and confidentiality, information flow through adequate authorizations, threat
modelling and security testing.
d) Communication Protocol Expert: An expert in communication protocols and in
implementing applications using different communication technologies and ensuring
communication inter-operability across applications/ functionalities
The project manager shall be responsible for bringing in the Cyber Security expert and
Communication Protocols expert at the appropriate stage in the project as and when required.

12.0 Project Implementation Schedule:

S.No. Milestone Timeline(in months)

 ANNEXURE-I

1 Submission of detailed Project Implementation Plan Within 60 days from the date
giving the compliance sheet along with the make and of Commencement of the
model of various infrastructure, hardware & software Contract
that are proposed for delivery and operations incl.:
● Specification of System
● Architecture and Software Solution
2 Approval of detailed Project Within15days from the date of
Implementation Plan by the GE Submission of Project
Implementation Plan.
3 ● Delivery, site installation and commissioning of Within 7 months from the date
Network Operations cum Monitoring Centre with of Commencement of the
related hardware, software and equipment; and Contract
● Delivery, site installation, integration and
operationalization of [20%] of Smart Meters each
with related meter box, service cable, hardware,
software and equipment and successful
operational go-live
4 Delivery, site installation, integration and Within 10 months from the
operationalization of 50% of Smart Meters each with date of Commencement of
related meter box, serviceable, hardware, software and the Contract
equipment
5 Delivery, site installation, integration and Within 18 months from the
operationalization of 100% of Smart Meters each with date of Commencement of
related hardware, software and equipment the Contract
6 Testing and Commissioning of the AMI Within 20 months from the
date of Commencement of
the Contract

Eligibility Criteria. Following details shall be provided by the Tenderer alongwith

the Bid: -
 ANNEXURE-I

(a) Head-End System (HES).

S. No Description of the Features Compatibility with RF/GSM/HyBd

Note: - The firm for HES and MDM system must have integrated with at least 5000
meters with RF/ Cellular technology and meters should be of different make installed in any
DISCOM/State Govt/ Central Govt/ PSU.

(b) Meter Data Management System (MDMS)

S No Description of the Features Compatibility With RF/FGM/HyBd

Note: - For a Station with Smart Meters more than 10,000 there must be 02 Nos of
HES & MDM system of different makes so as to remain available as a standby in case of
failure of one system.

(c) Work Station Consoles

S No Description of the Features

(d) Firewall and Intrusion Protection System

S No Description of the Features

(e) Printers

S No Description of the Features

Ser Stage/Yard Stick Likely Time frame Payment Penalty for delay
 ANNEXURE-I

No from work order per week

1. Submission of site survey details 05 Weeks 5% 0.25%
and proposal for approval of
makes communication system
etc. Approval by accepting
Officer
Material at site for Meters of 12 Weeks 15% 0.
more than one make
Commencement and completion 24 Weeks 20% 0.5%
of installation of meters,
communication network
Installation of servers/hosting on 12 Weeks 20% 0.5%
GCC/ Meity approved CSP and
interconnections.
Development of open software 06 Weeks 20% 1%
and applications including
installation and cyber security
clearances.
Testing and commissioning of 6 Weeks 10% 1%
system
Payment after successful 104 Weeks after 15% 1% per week for
completion and end of two years completion certificate delay in completion,
of defect liability period 0.5% per week for
delay in training and
other in infirmities
as decided by
Accepting Officer

MOU Requirement:-

The Sole / lead bidder has to mandatorily mention the details of all the solution / component providers
(vendors) for each of them as given below:-

a) Smart Meter Manufacturers------ Minimum four Makes are to be provided.

b) Head End System (HES) solution provider ------ One vender is to be provided.
c) Meter Data Management System (MDMS) solution provider ------ One vender is to be provided.
d) System Integrator ------ One vender is to be provided.
e) RF Communication Provider (if applicable) ------ One vender is to be provided.

Accordingly, the various solution / component providers should also separately meet the following
requirements as on date of bid submission or as on date of replacement of solution/ component
provider post award of contract, subject to necessary approval in writing from the utility. Each of the
solution / component providers shall sign an agreement with the sole/ lead bidder, provided the
solution/ component provider is not the sole/ lead bidder, clearly mentioning:

a) Their intent to comply with the terms and conditions of the AMISP Contract in the event the
solution/ component provider is selected to undertake the Project
b) Their willingness to work with the said sole/ lead bidder; and
c) Their proposed roles and responsibilities.
ANNEXURE-I