1 .

0 TECHNICAL SPECIFICATION OF AMR SYSTEM:

The General Technical Specification of MDAS System is as under.

1.1. System Features:

1.1.1. Provision to collect and manage the data:

A system that collects and comprehensively manages meter data from system (utility
network) meters and select customer meters using MODBUS/DLMS/COSEM/IEC
compliant protocol. As most of the meters provided presently are Modbus compliant,
Modbus/ TCP shall be the preferred mode of communication.

1.1.2. Remote capturing of meter data from system & select consumer meters: A
system that captures the meter data remotely from all the meters at 33 KV & 11 KV
Feeders, Distribution Transformers and HT/select LT Consumers for sending it directly
to the remote collection center.

1.1.3. Provision of communication media.

The system provides for GPRS Communication technology between Meters located at
Distribution transformer/HT/LT consumers and Central office.

1.1.4. Optimal utilization of meter data.

A system that optimally utilizes meter data for distribution management and billing.

1.1.5. Provision of a decision support system.

A decision-support system for distribution operations, asset management and planning
actions, e.g. Peak load monitoring shall help in finalizing the requirements for creation
of additional electrical network element or up-gradation of existing electrical network
element to meet the increased demand / load growth, Power factor monitoring shall
help in capacitor placement requirement, voltage monitoring shall help in identifying low
voltage areas for network up-gradation, data captured on imbalance between phases
for DT, substation and 3 phase consumer meters can be used to increase reliability/plan
load balancing jobs / advise customer to transfer loads between phases etc.

1.1.6. Identification of poorly performing areas.

A system that pinpoints poorly performing areas in the sub transmission / distribution
network, based upon the technical parameters, such as area wise distribution losses,
theft, outages, overloaded circuits/equipment, voltage imbalance, reliability indices,
power quality etc.

1.1.7. Helping in network upgrade actions.

A system that aids decision making on network upgrade actions by leveraging of

historical meter data to calculate area-wise load growth, equipment wise,
downtime/outage statistics, seasonal effects and usage pattern for long term and
short term planning.

1.1.8. Enabling health and performance monitoring of assets.

A system that enables ‘health’ and performance-monitoring and management of

important system assets (feeders/ transformers).

1.1.9. Detection of HV/DTR outages.

A system that enables quicker, ‘event-driven’ detection of HV/DTR outages thereby

improving reliability indices and customer satisfaction.

1.1.10. Monitoring of customer performances.

A system that enables monitoring of customer “performance”, e.g. contract demand

violation, peak load violation, tamper counts, average power factor etc. The system
should also have provisions to cover usage patterns to solve high consumption
complaints, facilitate calculation of assessed readings for stopped meter cases, detect
low consumption cases by comparing average historical consumption with actual
consumption.

1.1.11. Enabling event dispatch of notifications.

A system that enables dispatching of event notifications to targeted recipients for

faster field response and decision making.
1.2. Scope of deliverables:

Application for software, capturing and validating the analyzing meter data.
Application software for capturing, validating, scheduling and analyzing the Meter data
at the HT Consumer scalable for a size of Network as defined in Annexure-A.

Application software at Central Server

Application software for acquiring incremental meter data from all HT Consumers
under DGVCL area for aggregation, analysis and generation of various MIS report
through appending of the Metering module.

1.2.3. Supply/ installation of Modems at DTs and HT/ Select LT consumers. Supply
and installation of suitable Modem GPRS at meter ends for communication between
Meters located at Distribution transformer and HT/select LT consumers and Central
office server. If required necessary, the Modem may be retrofitted on optical port of
the meter.

1.2.4. Supply/ installation of any other equipment or accessories.

Any other equipment or accessories required for operation of the system.

1.3. System Architecture : General Notes

1.3.1. Provision of an integrated software system to meet the functionality of AMR.

An integrated software system should be provided to meet the following Functional

requirements spanning Automated Meter Reading :-

Real Time data acquisition from Meters.

Historical data acquisition from Meters.

Supervisory function i.e. processing, monitoring, analysis and diagnostics.

Data exchange

Storage of data

Report generation and reporting

Facility for user defined forms and reports e.g. calculation of Feeder/DT performance
Statistics.

Facility for time synchronizing.

Alarm list

Event list
Limit value violations

Flexible deployment / implementation of software system.

The software system deployment/implementation should be flexible. The deployment

may include installing the software at various locations like substations, sub divisions
and data center. The system architecture will be modular so that only the required
modules need to be installed at any given location. (e.g. installation at substation
computer may have modules like data acquisition or network topology management.
But data aggregation/analysis modules may be installed at sub division offices, data
center etc. as per the requirement of DGVCL)

1.3.3. Menu driven software system.

The software shall be menu driven functions for automatic data capturing, periodic
data uploading etc.

1.3.4. Provision for local / remote data collection.

The software shall have option for data collection from meters connected locally or that
are located in remote locations, through modem communication.

Facility for Web based front end. Software shall have web based front end.

Provision for data validation at both ends.

The software shall ensure data validation at both ends e.g. at the consumer end
before transmission and Central office after reception to eliminate possibility of
garbage data. The system at Central office should apply comprehensive data
validation before accepting and using meter data.

1.3.7. Provision for flexibility, user friendly and scalability.

The software system shall be flexible in terms of System & Application software, user
friendly and scalable upwards and downwards.

1.3.8. Software system with robust architecture, high availability and reliability. The
software should be based on a robust architecture model / framework that is highly
scalable/available/reliable, gives good performance, and offers distributed computing.

1.3.9. N-tier design methodology.

The software would be designed with multi-tier (Ntier) design methodology. It should
have distinct tiers representing the client/ business/database layers etc.

1.3.10. Client tier.

The client tier will be the interface of the software with the utility’s operations/
dashboard user. The client tier will provide all the user interfaces for the operational
and supervisory activities involved in meter data acquisition, processing and analysis.

1.3.11. Business logic tier.

The business logic tier would service the requests made by the client tier. These
requests could be automated, based on user-defined schedules or on demand from
the user.

1.3.12. Automatic workflow process from data acquisition to analysis.

Normal workflow processes from meter data acquisition to analysis would be as

automated as possible; for example user intervention would be sought only for data
editing or verification decisions.

1.3.13. Database tier.

The database tier should comprise an RDBMS that should be designed to be able to
maintain the relationships between meter and network assets, network topology, user
privileges, service points, customer accounts and other entities.

1.3.14. Maintenance of time stamped database.

The database should also maintain a time-series repository that stores the data
collected and processed from meters, including interval usage data, event logs and
outage history, as well as derived data such as aggregations and asset performance
indicators like load factor and load duration curves.

1.3.15. Optimal designing of database.

The database tier should be optimally designed to exploit both normalized as well as
multidimensional data models.

1.3.16. Provision of OLTP and OLAP models.

Both OLTP (Online Transaction Processing) and OLAP (Online Analytical Processing)
models should be exploited for ensuring performance and scalability.

1.4. Features of Data logging system at Central office: 1.4.1. Periodicity of

data collection.

System shall be capable of collecting data from all the HT consumers at least every
one Hour.

The number of HT consumers have been furnished in the enclosed Annexure-B.

However, the bidder may visit the area and collect the exact details about the number
of HT consumers and number of DTs at site and design and supply the system as per
actual availability at site. Further, the system shall be designed and shall have
provisions for inclusion of new Consumers and Assets in future and shall provide
additional spare capacity to cater 7.5% per annum growth over and above the actual
requirement at site on account of the future provisions.

1.4.2. Functionality of Central office Data acquisition software.

The Data acquisition software at Central office must have the following functions:

Data Collection: It shall collect data from Meter data directly from DTs and HT/select
LT consumers through GPRS Modems and store in its database.

Data Processing: It shall use data from the database to create reports, charts and
spread sheets. It shall also perform aggregation, analysis and MIS generation as per
request from various utility offices.
Messaging : Via GPRS

Program Generator : It shall have editors and configuration software.

Facility to communicate with multiple clients simultaneously through multiple

communication lines.

The communication shall be scalable and configurable to various media like PSTN,
CDMA, GSM, GPRS, EDGE or LPR Modem etc.

Availability of sufficient storage capacity.

The system shall have sufficient memory capacity for storing every Analog, Digital and
Accumulator data of all connected HT Consumer modems in the field as well as all
DTs and Consumer data for a period of at least one year.

1.4.4. Generation of Consumer wise and DT wise data base.

The software shall provide DT wise, Feeder wise and Substation wise data for
generating summary reports, statistical data, performance indices etc. in user defined
forms.

1.4.5. Ability of software to integrate, extract and analyze data of different make of
Meters.
Software shall be capable of collecting data on a common data structure / format
from DT meters and HT/select LT consumers of various manufacturers. The data
logging software package should be able to integrate, extract and analyze data of
different make of Meters.

1.4.6. Manual/ automatic mode of data transmission.

There should be provision for manually dialing the modems connected to the DT and
Consumer meters or by configuring the software to collect the data from meters
automatically with the help of Scheduler feature provided for auto dialing.

1.4.7. Viewing / exporting of collected data.

The collected data can be viewed in the form of customized reports. User can take
print outs of these reports, export the data into spreadsheets, or convert the data in
the form of flat file.

1.4.8. Facility for archiving, deletion, backup & restoration of the data.

Facility for archiving, deletion and taking backup & restore of entire or part of the data
collected at Central office shall be provided in Software.

1.5. Meter Data Acquisition : software requirements

1.5.1. Configurable data collection engine for meters of different make.

The Data collection engine of the Data logging software shall be configurable for
Meter of different make and shall have the ability to perform remote data acquisition
from system and customer meters.

1.5.2. Enabling of data acquisition from different AMR configuration.

The software will enable data acquisition from different AMR configuration schemes
(based on location and selection of system/consumer nodes)

1.5.3. Enabling of data acquisition over any communication media.

The software will enable data acquisition over any of the locally and reliably available
communication media: GSM/ GPRS, EDGE, CDMA, PSTN, Low power radio etc.

1.5.4. Provision to configure and manage technical parameters for communication

media.The software will be able to configure and manage technical parameters for the
communication media used in the project.

1.5.5. Provision of remote reading & collection in both scheduled batch mode.
Remote reading collection will be possible in both scheduled batch mode (automated)
as well as in the on-demand (real-time) mode.

1.5.6. Features of scheduled mode of data collection.

In the scheduled mode of data collection, the software will allow reading cycles to be
configured for either individual meters or groups of meters. Appropriate time windows
for data collection from different meters based on location/type can be set. The data
collection could be at any one of the pre-defined monthly, daily, hourly or quarter-
hourly frequencies or at any user defined frequency greater than 15 minutes.

1.5.7. Support for both inbound and outbound communication.

The software will support both inbound and outbound communication, i.e. data transfer
could be initiated by either the remote meter or the central software.

1.5.8. Type of Inbound communication.

At minimum, inbound communication will include event notification calls for power
outage and restoration events. The event driven polling of meters shall enable
pinpointing of faults during outages, defective or stopped meter.

1.5.9. Type of outbound communication.

In outbound communication, the number of retries made by the software for failed
meter readings will be configurable. If the meter cannot be read even after the
specified number of retries, the system will raise an alarm and generate meter
reading exceptions to enable tagging of cases for site verification.

1.5.10. Ability to retrieve both instantaneous and logged data.

The software will have the ability to retrieve both instantaneous and logged data from
the meter.

1.5.11. Support for import of meter data.

The software will support import of meter data from external sources in industry
standard formats like ASCII, CSV or XML. It will also allow manual entry of meter data
in exceptional cases only with appropriate user identification, security and audit trail.
The input sources of meter data could be CMRIs (Common Meter Reading
Instruments), substation log books etc.

1.5.12. Synchronization of all meters to a common fixed reference.

The software will be able to synchronize the date and time of all meters to a common
fixed reference. All the raw meter data entering the system via AMR

or any external means is time stamped and stored for audit and further analysis.

1.6. Network Topology Management

1.6.1. Ability to capture and maintain the geographic / administrative / regional

hierarchy.

The software will be able to capture and maintain the geographic / administrative /
regional hierarchy of a utility’s control area, i.e., the tree hierarchy of zones, circles,
divisions, subdivisions and substations constituting a utility.

1.6.2. Ability to capture and maintain the electrical network topology.

The software will be able to capture and maintain the electrical network topology, i.e.
substations, feeders, transformers and HT consumers.
1.6.3. Flexible Indian and oriented regi context onal hierarchy and topology. Both the
regional hierarchy and topology would be specific to the Indian context and flexible
enough to account for different voltage levels in Indian sub-transmission and
distribution networks e.g. 66/33/22/11/ 0.4 KV.

1.6.4. Provision to capture and maintain associations between various metering

nodes.

The software will be able to capture and maintain associations between various
metering nodes (both system and consumer meters) and the regional hierarchy /
network topology.

1.6.5. Typical list of System metering nodes.

System metering nodes could include AMR-enabled meters located at these network
points, among others: (i) Outgoing feeders from grid substations (at 33kV/ 11kV etc), (ii)
Incomers (33kV etc) at the power/secondary substations,

Outgoing feeders (11kV/ 6.6kV etc) from the power/secondary substations,

inter-region power import / export tiepoints on sub-transmission/ distribution feeders,

(v) Distribution transformers (DTR) primary/secondary.

Typical list of Consumer metering nodes.

Consumer metering nodes could include AMR-enabled meters located at the service
points of selected H.T./L.T. consumers (e.g. those with load above 25kVA).
1.6.7. Provision for modification in existing metering nodes.

The software will allow modification of existing metering node parameters. 1.6.8.
Provision to add virtual metering nodes.

The software will allow addition of virtual metering nodes and associate the same to
the regional hierarchy / network topology.

1.6.9. Provision to Navigate to any level of the regional hierarchy/ network topology.

Navigation to any level of the regional hierarchy / network topology would be simple
and intuitive via drill-down mechanism.

1.6.10. Provision to display SLD.

Software will be able to display SLD schematics for important network areas. 1.6.11.
Provision to depict Single line diagram.

Software shall have facility for creating data base and display of single line diagram of
entire electrical network and embedding of acquired data (both analog & digital) of
each feeder in real time.
1.7. Data Validation, Editing and Estimation (VEE) 1.7.1. Supporting of automated
rule based validation.

Software will support automated rule-based validation and estimation of raw metered
data.

1.7.2. Supporting of multiple data states.

The software would support multiple data states for metered data through its
transition from acquisition to analysis e.g. invalid, estimated, edited, verified,
validated etc.

1.7.3. Configuration of validation rules.

The software will allow configurable validation rules that may be selectively applied to
an individual metering node or groups of metering nodes or to channels common to
different metering nodes.

1.7.4. Logging of validation failures.

Validation failures would be logged for audit purposes. 1.7.5. Backing up of raw data.

Raw data would be backed up for audit purposes. 1.7.6. Provision of meter data
estimation routine.

The software will have a meter data estimation routine that will be triggered on
occurrence of validation failures.
1.7.7. Enabling of estimation routine.

The estimation routine can be selectively enabled/disabled. 1.7.8. Provision of manual

editing.

The software allows manual editing of metering data with audit trail. 1.7.9. Provision
for audit trail.

All data state transitions would be logged for audit trail.

1.8. Data Analysis & Charting

1.8.1. Processing of validated meter data.

The software will enable processing of validated meter reading data for generation
and storage of different time series channels. A channel would hold data pertaining to
one particular parameter.

1.8.2. Support for multiple channels for multi parameters.

The software will support multiple channels for multi parameter such as Voltage,
Current, Frequency, Energy, Energy demand, performance indicator and event related
data.

1.8.3. Support for channels of different time series.

The software will support channels of different time granularities, i.e. hourly, daily,
monthly etc.

1.8.4. Support for different channels for different type of data.

The channels could hold direct measured data, derived (calculated) data, or data
imported from external sources.

1.8.5. Viewing of time series data in tabular / graphical form.

User will be able to view time series data in tabular as well as graphical format. 1.8.6.
Ability to show status of time series data element.

The software will be able to highlight the state of a particular time series data
element, e.g. if it is absent, edited, estimated etc.

1.8.7. Comparison of multiple time series data.

The software will enable user to compare multiple time series together. The data
series could pertain to the same channel or different channels.

1.8.8. Facility for automated filling up of certain derived time series channels based
on data in one or more other channels.

Automated filling up of certain derived time series channels based on data in one or
more other channels will be enabled; e.g. data for the power factor channel of a
particular metering node can be calculated using the data in the active power and
reactive power channels of the same node. The latter two may have been directly
filled with measured data from the meter.

1.8.9. Provision of setting/editing of the conversion formulae.

The software will allow setting / editing of the conversion formulae for the derived
channels. The conversion formulae can be based on simple arithmetic /
trigonometric / aggregation functions.

1.8.10. Provision of aggregation of time series data.

The software should allow aggregation of time series data based on parameters like
geography (regional hierarchy), network topology, time and customer category.

1.9. Executive Dashboard

1.9.1. Provision of Executive dashboard.

Various offices of DGVCL, such as Circle, Division, Sub division etc. can interact with
master Metering (AMR as well as non AMR enabled) / Billing database at Central
server to provide the below mentioned features.

1.9.2. Provision of selective monitoring of summarized data.

The software would support selective monitoring of important summarized data at
user-defined intervals that would aid in decision-making for distribution operations
and planning actions.

1.9.3. Highlighting of key performance indicators.

Key performance indicators, like AT&C losses, SAIFI, SAIDI, CAIDI (but not limited to)
will be highlighted for every level of the network hierarchy.

1.9.4. Energy balance at different network levels.

Energy balance at different network levels will be captured and displayed. This
enables monitoring losses by region (subdivision/division /circle etc) and by network
asset (transformer/feeder).

1.9.5. Monitoring of losses at different voltage levels. Monitoring of losses at different

voltage levels will be enabled.

1.9.6. Display of load survey analysis.

The software will enable capture and display of data from multi-parameter load survey
analysis. Monitoring of usage/demand patterns would thus be enabled.

1.9.7. Monitoring of peak load.

Peak load at different network levels could be monitored. 1.9.8. Monitoring of

performance factors.
Performance factors like load factor, power factor, utilization factor, load duration
curves would be monitored.

1.9.9. Provision of transformer load management.

The dashboard will enable transformer load management. User will be able to monitor
overloading/ under loading, phase imbalance, load factor, utilization factor, load
duration curves of transformers.

1.9.10. Provision of Feeder load management.

The dashboard will enable feeder load management. User will be able to monitor
overloading / under loading, phase imbalance, load factor, utilization factor, load
duration curves of feeders etc.

1.9.11. Personalization as per the user’s preferences.

The software would support personalization of the dashboard displays as per the
user’s preferences.

1.9.12. Navigation from one level of network hierarchy to another.

Navigation from one level of network hierarchy to another will be intuitive and
drilldown will be possible.

1.10. Reports
1.10.1. Generation of reports based on the results of data analysis.

The software will be able to generate and display reports based on the results of data
analysis. The reports module will be used as a more data heavy alternative to the
Executive Dashboard.

1.10.2. Reporting on energy flow, performance factor etc.

The software will be able to display reports on all energy, demand, performance factor
and event related data available for different metering nodes.

1.10.3. Generation of reports with date range.

Each report will allow user to specify parameters like date range, end points for which
reports need to be generated.

1.10.4. Type of reporting.

The reports shall be Web based.

1.10.5. Exporting of reports to other applications.

The software will enable the user to export reports into other application software like
ERP, Microsoft Excel etc. for further processing.

1.10.6. Provision for comprehensive reporting and MIS facility.

Software at Division/Sub Division office shall provide comprehensive reporting facility.
If required it may interact with Central server and should provide fixed format as well
as query based reports in tabular & graphic format as required by user.

1.10.7. Option to view data selectively in numerical /Graphical form.

The user should have option for viewing selective data like Instantaneous parameters,
Cumulative Energy Readings, Tamper information's, Tariffwise Billing Data for each
reset backup, Load Survey data, Meter Programming records. Option should be
provided to view the Load Survey data in both numerical as well as In Graphical
format with selective or composite view of parameters and in different styles viz. bar
and line.

1.10.8. Generation of summary report of meter data for any load violation and
tamper counts.

The software should scan through each meter data and generate a summary report of
billing data, contract demand violation / peak load violation/ off days violation along
with tamper counts for that particular meter.

1.10.9. Provision of menu option for viewing each data report.

Menu option shall be given for viewing each data reports. The options will be enabled
based on the availability of the data for the meter selected for data viewing. Each
report header should give the information regarding the Meter serial Number, RTC,
Date and Time of data collection, Type of collection, CT/PT details and other
important consumer details.

1.10.10. Typical list of reports to be generated.

Reports should provide detailed information on Billing data, Load Survey data,
Profiles, Tamper information, Programming mode records and other system
irregularities. Following is a representative list of reports for different levels of the
network hierarchy and for different timeframes.

Energy balance report

Consumption

trends report

Load factor report

Reliability analysis Report

Asset utilization report

Electrical network monitoring report

1.10.11. Availability of extensive search options.

User should have extensive Search option for search using Meter number, Consumer
Number, Consumer Name, Location, Date of Reading of meter. An explore option
should also be given for listing out all the meter data available in the system. This
menu option will provide the list of data files sorted in the order of serial numbers,
consumer account number and location.

1.10.12. List of a few typical reporting requirements.

Few typical reporting, requirements are mentioned below, exact formats &
requirement may be finalized as per the requirement of the Utility.
Display of Electrical Parameters (Load current in Amp, power factor frequency,
voltage, active, reactive and apparent power etc.) in Tabular Formats and as Trends
(Graphs) Over Periods (e.g. for a week or month).

Comparative tabular & graphical reports for more than one meter & more than one
parameters

Min, Max, Sum, Average electrical parameters values, its time of occurrence and
duration of maximum and minimum values.

Graphical Display of Maximum Power Demand Analysis.

Software shall have facility to query data based on dates & parameter name

Software shall be able to show trend for single parameter & comparative trend for
multiple parameters based on the selection.

Support for sending report using Email or Alerts

User Configurable Reports using MS Excel

Detailed Error Reporting and diagnosis through Log Files and online display of Error
Status

Printing and Exporting of Reports to MS office.

% availability factor of feeder (i.e. % of time for which power was available for
feeders to know the reliability index of the feeder).

1.10.13.Reporting facility at various utility offices.

Various utility offices can interact with Metering/ Billing database at Data center to
provide extensive analysis & reporting facility. It shall also have extensive search
options and should provide fixed format as well as query based reports in tabular &
graphic format as per the requirement of the utility and described in detail at para
Das.11.7 above (i.e. Reports at Sub division offices).

1.10.14.Geographic/ administrative/ regional hierarchy wise reporting facility. The

various offices of the utility e.g. zones, circles, divisions etc. can login to the system
for generating and viewing various MIS reports, statistical data, performance indices
etc. as per their requirement.

1.11. Event and Alarm Notification. 1.11.1. Monitoring of important events.

The event list shall contain events, which are important for monitoring. The date and
time has to be displayed for each event.

1.11.2. Chronological registration of events.

The events shall be registered in a chronological event list, in which the type of event
and its time of occurrence are indicated. It shall be possible to store all events in the
computer. The information shall be obtainable also from printed Event log.

1.11.3. Listing of faults, errors and limit value violation in alarm list.
Faults, errors and limit value violation of all values occurring shall be listed in an alarm
list. Audible annunciation must be provided on receiving alarm. It shall contain
unacknowledged alarms and persisting faults. Date and time of occurrence shall be
indicated.

1.11.4. Summary display of alarm situation.

The alarm list shall consists of a summary display of the present alarm situation. Each
alarm shall be reported on line that contains:

Alarm date and time

Name of the alarming object

A descriptive text

Acknowledgement state

1.11.5. Acknowledgement of alarms.

The operator shall be able to acknowledge alarms. Acknowledged alarms shall be

marked at the list.

1.11.6. Typical list of items on which system can generate alarms.

The system will analyze time series / meter data and generate alarms/notifications.
Following is the representative list of items on which system may generate alarms:
Alarms based on consumption patterns

Alarms based on loading conditions

Alarms based on tamper detection

Alarms based on outage detection

Alarm based on violation of limit values

Ability to configure criticality / priority of the events

1.11.7. Framework to configure thresholds for generating alarms at each end-point.

The system will have framework that allows user to configure thresholds for generating
alarms at each end-point. (e.g. one set of end points, user should be notified if daily
consumption exceeds Y kWh and for some other end points alarms should be generated
only if the daily consumption exceeds X kWh).

1.11.8. Alarm on failure in communication, loss of data etc.

The system will also generate alarms based on any failure in communication,
missing/loss of data.

1.11.9. Supporting of alarm/ notification dispatch via comm. Media.

The system will support dispatching alarms/notification using various communication

media like SMS, E-Mail, Desktop Application etc.

Ability to deliver alarm/ notification to multiple recipients.

The system will allow each alarm / notification to be delivered to multiple recipients.
(e.g. alarms corresponding to outage at DTR level should be sent to a J.E. and an
S.E.)

1.11.11. Provision for turning certain alarm generation on/off as per user
preferences.

The system will allow turning on/off certain type of alarms generation (at system wide
level or for particular end point) based on user preferences. (e.g. if one does not want
any Communication Failure alarms, he/she can turn off the alarm generation for this
criterion).

1.11.12. Provision for turning certain alarm dispatch on/off as per user preferences.

The system will allow turning on/off dispatching alarm notifications to required
recipients. e.g. if Chief Engineer, does not want to receive any alarms for some
reasons, system should be able to turn-off the same).

1.11.13.Provision to acknowledge or ignore events / alarms.

The system will allow user to acknowledge or ignore events/alarms. System will also
allow user to log the actions taken, if any, for any particular event.

1.11.14.Setting of different priority levels for different events /alarms.

The system will support different priority levels for different types of events/ alarms.
1.11.15.Provision of different dispatch schedules for different types of events/
alarms.

The system will support different dispatch schedules for different types of events/
alarms. (e.g. Outage Alarms to be dispatched within 5 minutes of receipt and Contact
Demand violation alarms should be dispatched before every billing cycle start).

1.12. Time synchronization.

Time synchronization : The time synchronization shall be possible from the Work
Station/ HMI through built-in function. An accuracy of ±1 milli second within the
station is required. However provision is to be made available for time stamping
through GPS.
2.0 TECHNICAL SPECIFICATION OF GPRS based MODEM :

The offered MODEM shall be an intelligent device connected to an Electronic Energy

Meter by means of optical and RS232 port, installed at various consumer premises
(HT/LT consumers) to collect the following data as per configured frequency/On
demand.

Complete Meter data stored in the meter. (hourly /daily /weekly /monthly)

Instantaneous parameters, at the time of reading

Billing data, present and last 12 months histories

Load survey, 30 days/complete no. of days stored

Tamper data, Settings/Configuration data

Instantaneous parameters (Every 15/60 minutes / daily)

Existing RAPDRP MDAS Architecture:

The GPRS MODEM at consumer meter end should have suitable interface facility to
connect with the meter by using the RS 232 cable. The GPRS MODEM shall also be
retrofitted on optical and RS232 port of the meter.
Key Features:

Compatible with various standard DLMS compliant Meters

Shall have meter detect and meter data read feature which

enables communication with all popular Indian energy meters including DLMS meters
using built-in meter specific protocol stack.

Shall have auto restart feature with built-in watchdog timers and intelligence

Shall have on-line tamper detection feature through which GPRS MODEM will
continuously pole the meter for any new tamper and will send the event to the
server and also to a set of pre- programmed mobile numbers as an SMS alert.

• Shall have program over the

air

(POTA) feature

which

will reduce

the manual field

visits and

also

save project
time.

The modem

firmware shall

be reprogrammed from the server remotely.

Remote start/stop and restart feature.

Auto recover feature incase modem / network hanging

Comprehensive self-diagnosis feature which will create log file with all at a periodicity
and link check for communication.

On demand SMS request through SMS for Instantaneous Parameters

• Real time outages, alarms as alerts to server and to configured mobile numbers
Automatic GPRS connection (no AT commands required) and watchdog for reliable
Communication

Inbuilt 3 Phase Power supply as well as operational on single phase

Automatic pushing of meter data at configured regular intervals

On line monitoring of vital Instantaneous parameters like voltages, currents energies,

powers, power factors.

IP (internet protocol) based Communication, enabling simultaneous data access from

thousands of GPRS Modems.
• Shall use meter supported baud rate to read meter data and shall use maximum
network supported baud rates to push the data to server.

Shall have a configuration over the air feature through which all the GPRS MODEM
operational settings will be configured.

Shall have a configurable scheduled meter read and data transmit feature to enable
grouping of the meters so that the loading on the server is equally distributed from
all the field installed modems.

Shall have selective on-demand meter read feature through which server can send
an on demand request to modem to read the selective parameters from the meter.

2.1 Power Supply Section:-

2.1.1 Input specifications:-

The offered GPRS MODEMs should capable of operating on three

phase supply drawn from

the meter input

itself.

Auxiliary

power supply
will

not be acceptable.

The

GPRS MODEM

shall

have three

phase

AC

input supply

and

should

be capable of proper functioning within the

power supply

range of 77 AC P-P to 470V AC P-P, 50 Hz so that

same GPRS MODEM shall be used for DTR meters, HT and LT Tri

vector meters.
•

However

the

GPRS MODEM

should

also

be

capable of

operating

on

single phase

230V,

50 Hz

power

supply.

The GPRS MODEM shall

be suitably protected against surges.

Average Power consumption of the GPRS MODEM shall not be more than 3.5 VA
under idle and during data transfer.

Withstand capacity against surges should be according to Indian conditions i.e. 6.0
kV.

Input terminals: The power supply input shall be a suitable two core integrated cable
coming out from AMR box.

2.1.4 The GPRS MODEM shall have capability to work under continuous power on
condition.

2.2 GPRS Section:-

The GPRS module shall comply with the following:

The module shall operate in dual Band GSM 900/1800MHz.

The module shall be compliant with ETSI GSM Phase 2+ Standard.

•Class 4 (2W) @ 900 MHz

•Class 1 (1W) @ 1800 MHz

2.2.3. The module shall support Point-to-Point transmission and Cell Broadcast
features.

Serial binary and suitable data format for data transfer.

Short messaging service (SMS) features.

•Text and PDU

•Point to point (MT/MO)

Cell broadcast

GPRS MODEM should support both data and SMS transmission.

2.3. SIM Card Section:-

2.3.1. For

placing the SIM

Card, a

SIM

Card

Holder shall

be

provided
on the motherboard and

shall

be

accessible only

by

opening/sliding the cover,

GPRS MODEM shall

not be opened for

replacing the SIM card.

The SIM Card supported shall be of 1.8V/3V Interface.

Interlocking facility shall be provided under the device cover.

SIM card slot/cover shall be sealed to avoid access to unauthorized. The offered
GPRS MODEM shall comply for ESD as per IEC61000-4-2.

2.4. Communication Interface & Capabilities:-

2.4.1. A RS232 Serial Link

supporting

up to 115,200 bauds with

an auto-

bauding option

shall be

provided. However the data

transfer

rate for remote meter reading shall depend on meter

compatibility.

The RS232 output shall be provided on a 9-pin female//RJ11 connector which can be
connected to electronic energy meter’s optical / serial communication port through
suitable communication cable.

The GPRS MODEM shall be suitably pre-configured for meter reading & transferring
the data to the DC.

GPRS MODEM should be Quad band GPRS MODEM capable of operating at 900 and
1800 MHz GSM transmission.

2.4.5. GPRS MODEM should support both Data and SMS transmission. It should have
GPRS features.

2.5. RF section:-

A SMA interface shall be provided on the GPRS MODEM to which either a fixed or a
wired (with magnetic base) Dual Band built-in Antenna
of minimum -6dbi

gain can be connected. Provision shall also be made

to connect 14dbi

high gain external yagi antenna to improve poor

signal strength.

2.6. Network Identification Section:-

For determining the health of

the device an LED shall

be provided

on the GPRS MODEM which will

depict the

current

functioning status (power up/registered in network/transmitting data).

2.7. Data Features for GSM/GPRS module:

Internet Services: TCP, UDP, HTTP, FTP

GPRS Data transmission features:-

GPRS Class B Multi slot class 12 or class B Multi slot class 10

Packet channel support: PBCCH

Coding Schemes: CS1 to CS4 compliant with SMG32 (Release 97)

2 . 8 . EMI/EMC Specifications:-

The GPRS MODEM shall meet the following EMI/EMC specifications:

Electrostatic Discharge IEC61000-4-2

Fast Transient Burst IEC61000-4-4

Surges Immunity IEC61000-4-5

Conducted Emission CISPR22 (class B)

2.9. Mechanical Specifications:-

The Mechanical Specifications of the GPRS MODEM shall be as follows:

• GPRS MODEM shall be compact, as this device will be placed in a compact meter
boxes,

Mounting Arrangement: Easy mounting arrangement with a hook Provisionon on the

GPRS MODEM supported with the screw fixing arrangement. So that it will be
comfortably fixed inside the meter Box.

The GPRS MODEM shall comply with IP55 rating.

• Sealing

Arrangement: The Top

and

Base Cover shall have a

suitable

sealing arrangement so

that

the GPRS MODEM cannot be

tampered.

The GPRS MODEM shall be a compact model housed in a polycarbonate /

engineering plastic enclosure.

2.10.Environmental specifications:-

The GPRS MODEM shall meet the following environmental specifications:

Temperature: -10 degrees to +55 degree and Humidity: up to 95% RH (non –
condensing)

2.11.Functional specifications:-

The GPRS MODEM should be an intelligent device and capable of providing the
following functionalities on GPRS network:

The GPRS MODEM should be capable for long duration data transfer to central
station as per configuration via suitable GPRS MODEMR software.

When the GPRS MODEM is busy in collecting the data from the meter

and the request comes to get the data, then priority shall be given to request from
central station software.

• Power Outage

Notification:

In the event of an

outage, the GPRS

MODEM

should be

able

to send the
outage alert to Data center,

there

after SMS to

predefined number to notify

the outage event

with date and time of occurrence/restoration.

• The GPRS MODEM should

be

capable

of operating with SIMs of local

GPRS/ Service provider in the area.

• GPRS MODEM should be capable for continuous working for

hours every

day under field conditions, even when enclosed in Metering Cubicles

at Consumer sites.
• Software shall have facility for

Auto-Scheduler to enable

Automatic/Unattended data collection during night hours.

2.11.1. Data transfer in push Mode:

• By default GPRS MODEM

should

be configured for push mode of

data

transfer i.e. GPRS MODEM shall

automatically establish a

session with

Static

IP of
MDA

Server

at DC

at specified time

(once

in a

hour/day/week/month) for the

purpose of meter reading through

GPRS

only.

This

configuration

of

the GPRS MODEM

shall

be

configurable remotely.
If GPRS MODEM could not establish connection to the Server placed at Data center
at specified time, then it shall retry the same as configured.

2.12.2. Data transfer in pull Mode

In case the data is required on demand from the Data center end (Server end), then
connection shall be established from head end to the device.

User shall have option to get the meter data available in the memory of intelligent
AMR, invoke the Modem to read & upload the meter data.

Provision to generate reports of successful automatic meter reading (AMR) Calls and
unsuccessful AMR calls separately shall be provided.

Provision for flexible scheduling of meter reading by AMR software automatically on a

pre-defined hourly, daily, weekly or monthly basis.

Provision shall be made to read the groups of energy meters in one

go from the AMR software and the searchable by Meter number, or as a separate
group.