Technical Specifications And Scope Of

Work for Automatic Meter Reading(AMR)

System
(Ref no: Dist/AMR/2004-2005/01)

1.0 General
An Integrated Software for data collection, data transfer and load research of meter data. The
Software shall be able to handle a wide range of revenue meters from different vendors.
The Software should run on any standard IBM PC or compatible computer for stand-alone
applications to support data collection, validation, and editing and data analysis. It should also
run on network environment such as Novell and Windows NT.
MSEB expects the entire project has to be based on modern telecommunication facilities
available in India like PSTN/GSM/CDMA etc. For bid evaluation it is suggested that the bidder
should quote considering following percentage distribution of the consumers to be monitored by
various systems and quote accordingly. This is for bringing all the offers on common platform.
However the selected agency will have to conduct detailed survey regarding availability of the
particular system for prospective consumers/meters.
The estimated break up of meters based on telecommunication methods;
1) 90 % GSM/CDMA
2) 10% PSTN
3) Use of standby CMRI (Common Meter Reading Instrument), manual or automatic, in case of
any of the above mentioned fails to collect data.
(The total quantity and price of HHU (Hand Held Unit) should be quoted separately other than
main offer)
The current metering environment in India does not support any advance or state of art
Integrated AMR technology or solution. Hence to ensure 100% success of this project
MSEB keeps the rights to change or replace partially or all the meters installed already in
the field, if required, in consultation with the selected technology provider. The list of
acceptable meter manufacturers has been made available in technical specifications.
The Power Line Carrier communication based system shall not be acceptable and shall be
rejected outright. No pilot proposals shall be acceptable under this project.

Scope of Supply:
Maharashtra State Electricity Board is seeking an integrated system for meter reading, data
management and data processing and analysis. The tendered system includes the supply,
delivery, installation, training, commissioning and maintenance (for 3 years) of a remote meter
reading system for initially 20000 numbersof meters at HT Consumers, EHV Sub-Stations and
DTC Meters in MIDC & Urban areas spread over theentire State but extendable to
30,000 numbers of industrial & commercial meters.
The proposed AMR system includes application package, system software and tools
whereever appropriate.Computer Hardware
includes Servers, Workstations, & Networking and related hardware. Professional services

include customization of software package, as and when required, implementation and postimplementation support services.
This integrated system shall include two major components: a hardware AMR module which can
be used to provide telephone AMR capabilities at the meter site, and a central data collection,
management and analysis software system. Users of the system will be located at
Pune , Nagpur and Mumbai offices, so the system must be capable of being operated across the
MSEB network.

1. Main functions of the system will include:

Daily automatically scheduled collection of interval data from 20000 existing (currently
deployed in the field) three phase electronic meters..
The
system
must have
proven
capability
to extend this
functionality
to further 30,000 or more meters.
Storage and management of all meter base data, and meter reading data in a central database.
The data management system shall have the capacity to accept reporting on external factors from
the MSEB billing system such as outage credits and curtailment intervals
The data management system shall have the capacity to calculate billing factors including the
following: TOU Buckets, Demand Charges, Interruptible Program baselines, and other usage
data calculated from the interval data-stream through an easy-to use calculation engine without
the need for additional software development.
Users shall be able to perform any specified functions through a secure client module that
operates using MSEBs LAN and intranet networks.

2. System overview
The proposed system shall provide a suite of applications for AMR, meter data management,
processing and analysis tools.
This platform will provide MSEB with the ability to centrally manage interval data collected by
meter reading module, and to provide that data, and its derivatives to the specified offices using
client-server technology through the MSEB intranet. Each of the three specified offices should
have an operator workstation to perform manual/scheduled meter reading, data
management/analysis. All meter interval data is to be stored in the headquarter server and disk
mirroring of the same is to be done at location specified by MSEB.

3. System infrastructure Architecture

The System Architecture shall utilize a standard multi-tier architecture. This architecture shall
include at least the following separate tiers.
A central database for the storage and management of all meter readings, load profile, and meter
configuration data.
An application tier which provides processing power to accomplish automated, scheduled, and
ad-hoc requests from the client tier.
A Client tier which includes a rich client installed on the users computer through which system
operators can accomplish standard operations including:
Set up and maintenance of meter configuration.
Scheduling of automatic meter readings and data transfer.
Editing and estimation of meter data.

Ad-hoc meter readings.

4. Key Technologies
The system shall be based around the following key technologies which will ensure a consistent
operating platform, which is scaleable for future growth and integration of new technologies.

5. Database Tier
The database tier shall utilize the Microsoft SQL Server RDBMS, latest version

5.1 Application Tier

The delivery of application content shall be managed by the Microsoft.NET framework. All
applications related to the operation of the system shall utilize the Microsoft.NET framework for
interoperability.

5.2 Rich-Client Tier

Day-to-day system operations and the activities of the system operators shall be performed using
a rich client developed using the Microsoft.NET framework. All applications related to the
operation of the system shall utilize the Microsoft.NET framework for interoperability. The rich
client shall be able to be updated automatically, and installed using the
Microsoft Internet Explorer web browser.

5.3 Optional Web Tier

Any web applications which interface with the system shall utilize the .NET framework, and
Microsoft Internet Information Server (IIS) latest version.

6. Security
The system shall provide an integrated security system which allows administrators to create
users and grant those users permission to see/use the required data.
User permissions shall be set at the following functional levels:
Administer User Security
Administer system settings such as:
Task Cycles
Holiday Schedules
Report Configurations
Manage System Tasks
Edit Configuration data at various levels:
Customer Configuration
Account Configuration
TOU Schedule configuration
Meter Configuration
Service Point Configuration
Schedule Tasks
Aggregation
Remote interrogation

Billing exports
Using Advanced Formula Builder
Using Basic Formula Builder
Access Reports through the GUI Client
Access Interactive Graphics through the GUI Client
Modify Existing Tasks
View running tasks
View task monitor
View time of use definitions
Failed Logins
The system shall disable a username-password combination after a number of failed login
attempts and report it to the Administrator. The number of login attempts shall be settable by
administrators as a system setting.

6.1 Groups
The system shall allow administrators to create groups of users with the same permission set. All
users assigned to a given group shall have the same permissions at the system level.

6.2 Security Interface

Advanced users shall be permitted to grant and alter user and group permissions through the GUI
client. Users who are not administrators shall not be given any menu option for security or other
administrative functions.
The system provides the following security features:
Access to the system must be authorized by and authenticated by individual Login ID &
Password.
The system will capture logs of user activities and user logins.
The system will protect the integrity and confidentiality of the data by allowing authorized staff
access only.
The system has the ability to log all access to the system.
All passwords shall be encrypted

7. Automated Processing
To support production scale operation, the system shall automatically manage its load and
processing tasks with minimal operator intervention. The system shall provide tools for
automated scheduling and load balancing.

7.1 Automated Scheduling

Scheduling of routine tasks such as data collection and export to the billing system shall be
handled automatically through the use of cycles. Cycles shall be user-defined schedules to which
meters and tasks can be assigned. When a cycle time or date is reached, any task associated with
that scheduled shall be scheduled for all meters assigned to that schedule. Automated scheduling
by cycle should be accomplished without user intervention.

7.2 Workflow

The system shall provide automated execution of common workflow processes in meter reading,
specifically the read, validate, estimate, transfer process that is at the core of meter reading. This
workflow process should be accomplished as automatically as possible, stopping only where
human intelligence is required for tasks such as data editing or estimation.

7.3 Task Management

The system shall provide a centralized management system for all tasks, automated or ad-hoc,
performed by the systems back room processing servers. This task management system shall
schedule and manage the balancing of task load across multiple processing servers.

7.4 Processing Server Maintenance

It shall be possible for a properly authorized user to utilize tools within the GUI to configure and
manage the balancing of task load across processing servers.

7.5 Task Processing Threads

It shall be possible for a user to specify the number of task processing threads available on a
given processing server. The user shall be able to assign the particular tasks to be accepted and
processed by a given task processing thread. Each task type shall be assigned a priority which
governs the order in which tasks are processed by a particular thread.

7.6 Ad-Hoc Task Scheduling

The task management system shall provide properly authorized users to schedule tasks to be
processed by back room processing or dialing servers. Users shall be able to select all
parameters associated with the task, and to select the time and date at which the task shall be run,
and to request that the task be run on a particular processing server.

7.7 Task Monitor

The task management system shall provide a graphical user interface for the monitoring, control,
and reporting on tasks. The task monitor shall allow the user to perform the following functions
through an intuitive graphical user interface.
List all tasks
Filter the tasks list based on common task parameters:
Task Status: Running, error, failed, cancelled, on hold, successfully executed
Processing Workstation on which the task is executed or assigned
Task Type
Which System User scheduled the task
Time task was submitted
Time the task was scheduled to be performed
Show task statistics
Cumulative number of tasks performed
Cumulative number of tasks at a particular status level
Total number of tasks currently running
The number of tasks in a particular state such as error or failed.
Using the task monitor GUI, a system administrator or lead operator user shall be able to perform
the following tasks:

Hold a task
Reschedule a task
View and edit a task and Stop and re-start task processing

8. System Performance
8.1 Availability
The system shall be configured for remote meter data collection from 00:00 hour to 06:00
hour on all week days. Critical tasks such as data collection, automatic validation, automatic
estimation and transmission of data to other systems are designed to be completed within a
specified window time period. Other tasks such as batch processing, ad-hoc reading, manual
editing and estimation, system maintenance, report generation, system backup, archiving and
housekeeping can be completed within normal working hours on weekdays.

8.2 Reliability
Backup and redundant modules and procedures should be in place. In the system specified, extra
dialing capacity will be included. Therefore if one PC is off production, the system can still
perform the specified functionality in time.

8.3 Sizing & Scalability

The system initially supports 20000 meters. Vendor shall demonstrate the capacity to support at
least 100,000 C&I (interval meters) and 500,000 mass market meters if required.

8.4 Auditing
The system shall provide audit trail of user and system activities that enables data changes to be
tracked and reported, including changes made by the system administrator.
For editing of meter reading and load-profile data, the system shall record the following
information in a log and store it for a minimum of 12 months:
User ID
Date and Time of Change
User shall be prompted to input a reason for editing using either a standard reason code or a
freeform text field.
In addition to data stored in the edit log each interval containing edited data shall be marked with
a status to indicate that the data has been edited.
The pre-edited value shall be stored in the database as a previous version which can be retrieved
using as-off date functionality.
Changes to configuration data by users shall be logged by date, time, and user ID and such logs
shall be stored for a minimum of 12 months.
Critical changes relating to measuring parameters (pulse multipliers, transformer ratios, etc.) and
formulae change shall be stored indefinitely as a previous version.
For regular system tasks, such as meter communication, task processing, validation, etc the
information will be kept for minimum one month.

Full data and system audit ability such as version controls and retrieving data according the date
and time. Additionally, all versions of meter data shall be stored and retrievable by as-off date
so that users may inspect data
Users shall be able to report on connectivity by meter type

8.5 Maintenance
The system needs to be designed for easy maintenance, including utilities and GUI interface
modules.

8.6 Performance, Size and Scalability

The system shall be designed to accommodate the C&I meter data management needs of MSEB
as it grows in the future.
The following are expected response times for specific types of processing. Processing time
does not include time for data transfer across a wide area network interconnection between LV
and an off-site customer.
The system shall read, validate, upload, and export 2 million intervals/hour
The system shall export 5 million intervals per hour
The system shall aggregate and transfer 0.5 million intervals/hour
The system shall respond to a data view query in the user interface of one channel consisting of
3000 intervals of time series data in less than 60 seconds
The system shall allow channels of load profile data to be configured with sampling rates
(interval lengths) as short as one (1) minute.

9. Data Management
The primary function of the system being contracted by MSEB is the collection, management,
and exploitation of load profile data. As such, the data storage and management of the system is
a key function. The database shall support the storage of metering data, and shall enable MSEB
to easily associate metering data with meters, customers, and service points within the MSEB
network.

9.1 Relational Database Management System

The system must store all data in a relational-type database which also has the capacity to
manage the objects. The preferred database for this application would be Microsoft SQL Server
or Oracle or DB2.

9.2 Distributed RDBMS.

The administration system of the relational database must work on the server-type system, work
in distributed environments and have the capacity to define the distributed database.

9.3 Distributed Database.

The database must be distributed-type and its related processes must have the capacity to be
configurable in one or more personal computers.

9.4 Administration of the data traffic.

The database and its related processes must have the capacity to administrate the data traffic to
avoid bottle neck and blocking records.

9.5 Massive load.

The database technology must be able to support data massive load.

9.6 Multi-user and concurrent database.

The administration system of the database must be multi-user and allow the access to the client's
softwares simultaneously (minimum of 100 users).

9.7 Data Model

This data model shall support the storage of standard reading and register data, and channels of
load profile data. Load profile data shall be able to be defined either as a channel of actual
load profile data from a particular meter, or as a channel of virtual data calculated using the
formula engine defined in section 13.2of this specification. The data model diagrammed below
is an example of a data model which would meet the requirements of MSEB for flexibility and
data integrity.

9.8 Customer
Customer is an owner of one or more Accounts. The customer is the entity with which the
utility has a contractual relationship. A customer shall be uniquely identified by Customer ID or
customer name.

9.9 Account
Account is the contractual relationship between a Customer and one or more quantities
delivered at one or more Service Points. An Account shall be uniquely identified by Account
Number.

9.10 Service Point

Service Point is the electrical point at which a quantity is considered to be delivered to the
customer by the utility. A service point can also be the electrical point at which a quantity is
received from the customer by the utility.
The is intended to be a constant identifier, unchanging over time, that provides users outside of
the billing process, as well as inside the billing process, a consistent mechanism for identifying a
given point, that is unaffected by metering and account changes over time.
The Service Point concept is also referred to in the industry as Point of Service, Delivery
Point and Point of Delivery.

9.11 Premise
Premise refers to a physical location, such as a building, complex, street address, etc. A premise
can have one or more Service Points.
Premise refers to a physical location, whereas service point refers to an electrical location.

9.12 Service Point Channel

A service point channel is an interval or register data quantity at a service point.
A service point channel can be metered, calculated, or imported. This refers to the origin of the
data. The origin of data for a metered service channel is a metered channel. The origin of data
for a calculated service point channel is a formula that references other service point channels.
The channels referenced in the formula may themselves be metered, calculated, or imported. The
origin of data for an imported service point channel is an external system. These channels
generally represent data from sources other than meters, such as temperature, pricing, or
forecasted loads.
9.12.1 Metered Channel
A metered channel is an interval or register quantity recorded by a meter. It is the reference to the
physical channel on the meter, whereas the service point channel is a reference to the quantity
being measured.
9.12.2 Meter
Meter is a device used to measure and/or record one or more quantities at a meter point.
A meter may act as a measuring device, a recording device, or both. A meter may measure a
single quantity at a meter point or a meter may measure multiple quantities at a meter point.

10. Database Content

10.1 Configuration Data
The system shall store all configuration data required to read a meter, and to associate that meter
with a service point, a customer, an account, and a premise. This shall include the profile for the
settings of each individual meter as well as the data required to relate the commercial data of
each one of them. This data shall include the following:

10.2 Customer Data

The data required to uniquely identify the customer including contact details customer
name, address, etc.

10.3 Account Data:

Data required to relate a service point or service point channel to a customer or account, and a
link to any time of use or other data required for billing.

10.4 Service Point and Premise Data

Data required to identify a service point and premise including: Location, name, Unique ID,
purpose, and other relevant data.

10.5 Service Point Channel Configuration

Channel configuration data for each individual service point channel. This includes the
channels unit of measure, interval length, links to the appropriate meter, any formulae used to
calculate the channel values, etc.

10.6 Meter Configuration Data

Any data required to accurately read data from a recorder or meter. This data will include:
Meter type
Serial Numbers
Meter Passwords
CT/PT ratios
Channel
Communications system information and telephone numbers
System Configuration data as specified by users
Read Cycles
Task definitions
TOU schedule definitions
Operational data
Task Lists
Logs
Templates
The Described data model is very flexible and can support different configurations for different
customer and metering configurations. To simplify this process, the system shall allow named
configuration templates to be created, so that different product types can be easily configured by
choosing from a pre-established list of named configuration templates.

10.7 Meter Data

The system shall have the capacity to store all data collected from meters at intervals.

10.8 Load Profile Data

The system shall have the capacity to store load profile data generated by the meters at all
common load profile intervals including: 5 minute, 15 minute, 30 minute and hourly. Each load

profile interval shall be stored with a time, a value, and any interval status information applicable
to that interval stored by the meter, or created by the system.

10.9 Meter Event Data

The system shall have the capacity to store meter events recorded and stored in the event buffer
of the meter. These alarms shall be stored in a separate alarm table that provides users and
applications with access to the following information:
Event identifier: Identification number assigned to the alarm in the database.
Date of alarm occurrence
Event description
Meter and service point at which the event occurred

10.10 User and Security Configuration

All information relating to access accounts, rolls and privileges for system users shall be stored
in the database and protected by the database administrator password.

10.11 Data Versioning and Data integrity

The system shall provide fully versioned data system that tracks and maintains both corrections
and changes.
True changes that naturally occur over time, such as meter changes, multiplier changes, account
number changes, changes to invoice calculation definitions, etc., shall be tracked over time with
effective dates, and the appropriate values shall be used for each effective time range in all
reports, exports, and calculations, including seamless handling of request time frames that cross
change boundaries.
All corrections of meter data shall be maintained in the system, including the maintenance of
multiple versions when multiple corrections have been made to the same data. Functionality
shall allow comparisons between versions and also allow previous versions to be restored.
For all changes and corrections made in the system, the following information shall be tracked
and made available to users with the appropriate security permissions:
User ID
Date and time
Application that was used to make the change or correction (User Interface, API, etc)
Reason
Future dates for effective data ranges, for changes that will occur in the future, shall be allowed,
so that users can modify the system prior to scheduled changes to improve operational efficiency.

11. Data Collection Capabilities

The system shall include data collection functions necessary to read meter interval data and store
that data in the central database.
The system shall be able to read 20000 meters included in this project. And Also be able to read
at least three phase electronic meters provided by ABB, L&T,DataPro, Dukes Arniks and Secure,
Landis & Gyr, and Schlumberger. MSEB currently has more than 20,000 High end metering
points and industrial customers. So bidder shall explain how this system may be expanded to
accommodate and communicate with 30,000 three phase electronic meters in the future.

11.1 Multi-vendor and Large Scale Operation Support

The provided system shall have a proven track record of at least 10 years of supporting multivendor systems. MSEB currently has more than 11,000 large industrial customers and the meters
used or in investigation include ABB, L&T,Dukes-Arnics, Datapro, Secure Landis & Gyr, and
Schlumberger. The supplier shall demonstrate the capacity of the system by
submitting documentary evidence and actual field functioning of 20 different make with 20
different protocol for C & I energy meters with the system for successful operation.
The system shall also have a proven record to support large scale and mission critical metering
data collection operation.

11.2 Meter Reading System Functionalities

In order to ensure a successful and effective meter reading system, the vendor shall provide the
following features.
Supports partial read. If the read meter supports partial read to reduce meter reading time and
cost
Support both inbound and outbound calls.
Support event inbound call: for at least power outage and restoration.
Support daisy-chaining and master/slave phone lines
System shall automatically retry failed meter reading at least 3 times after a user specified
period. If all 3 trial fails, system will then raise an alarm to notify operator to further investigate.
Support multiple communication channels to the same meter. MSEB might expand
each specified office system to read interval data for 20,000 meters on daily basis. In order to
support this heavy loading, bidder shall provide proof that the proposed system has ability to be
expanded to read at least 100 meters simultaneously. And meet at least following requirement
The system shall support up to 30 communication channels on one single workstation. (Which
means, one single computer can read 30 meters simultaneously)
Supporting multi-site and multiple operator workstations to perform meter reading
simultaneously
All data shall be stored in one central database, and operators can access these data from multiple
workstations simultaneously.

11.3 Event notification:

The system shall provide an event table which allows the utility to interface tometer outage
notification and other trouble tracking systems with a Standard Query Language interface.
For potential future expansion, MSEB might consider expanding the system to accommodate
other meter types. Therefore bidder shall demonstrate the capability to read or manage data
collection from electric, gas, and water AMR systems.

11.4 Communication Support

The proposed system shall support the following media for the meter reading:
PSTN network
GSM / CDMA network
TCP/IP networks
Such reading process shall be protected by password and meter configuration details.

11.5 Data Collection tasks

To support production scale operation, the system shall automatically manage its load and
processing tasks with minimum operators intervention. Therefore the system shall
support scheduled or pre-specified meter reading. The system shall allow operator to define at
least 100 different reading cycles. And associate each individual meter to a reading cycle at any
frequency down to 5 minutes.
It shall be possible to associate each meter with at least four reading cycles

11.6 Ad-hoc meter reading:

MSEB operator shall be able to use the GUI interface to initiate request to read a meter
immediately.

12. Time Changes (Daylight Savings Time, Time Zone Changes)

The system shall be designed to handle any combination of meter hardware in the field that can
be mixed between Standard Time and Daylight Savings Time. This is critical for time setting of
the field equipment when all metering hardware cannot be on the same time reference.
When data is retrieved from the meters, it shall be converted to a Standard reference time so that
the database has the same reference time regardless of the mixture of metering hardware.
When more than one time zone exists, the system shall adjust for the time zone change when
setting time in field metering equipment or will adjust the data so that it can be analyzed at the
system level by taking into account time zone changes.

13. Data Processing and Analysis

The system shall process the retrieved metering data and perform the necessary tasks to ensure
the metering data is valid and is ready for billng. It should offer following features

13.1 Calculation Engine for Meter Data Aggregation and Analysis

The system shall support complex aggregation and data analysis through a common calculation
module. This calculation module shall be capable of performing vector and scalar operations on
channels of meter data. The calculation engine should be simple to use, requiring no special
programming or programming skills. Users shall be able to utilize the calculation module to set
up formula channels in which calculations are performed and stored in the systems. Users
shall also be able to flexibly access the calculation module while using charting, graphing and
reporting tools. For example, the user shall be able to specify a formula (i .e. Channel 1 +
Channel 2) and immediately graph the result while performing analysis of data in the system.

13.2 Calculation module functions

The calculation module shall include functions in the following categories:
Vector calculations, where mathematical functions are performed on streams of interval data
(channels). Vector calculations will include at least the following functions:
Simple mathematical operators such as addition, subtraction, multiplication and division.
Complex mathematical operators such as sine, cosine, tangent, square and square root.
Unit Conversion functions such as:
A function to calculate power factor from kwh and kvarh
A function to calculate power factor from kwh and kvah

A function to calculate kwh from kvarh and kvah

A function to calculate kvarh from kwh and kvah
A function to calculate kvarh from kwh and kQh
A function to calculate kQh from kwh and kvarh
A function to calculate average volts from V2H
A function to calculate average amps from I2H
A function to calculate V2H from average volts
A function to calculate I2H from average amps
A function to convert secondary voltage or current values to primary voltage or current values
A Function to convert engineering units to pulses for metered channel interval data
A logical function set to allow users to specify if, then, else statements. The user shall be able to
nest if statements in a formula so as to allow for complex calculations such as baselines for
curtailment programs and billing factors for ratchet or stepped rates.
In addition to Vector functions, the calculation engine shall include scalar functions for
calculating or creating billing factors from load profile data. These factors shall include at least:
A function which returns the highest N numder of values for ch over the time period specified
and the values from k additional channels that occurred at the same times as the N highest value
on the reference channel, ch. Also returns the dates and times at which they occurred.
A function which calculates load factor for the entire period
A function which counts the number of intervals with zero value within the period
A function that returns a single value that is the Nth highest peak
A function that returns a single value that is the Nth lowest value
A function that returns the sum of all the values within the time period
A function that returns the average of all the values within the time period
This function returns the absolute value of a single scalar value
A function that counts the number of occurrences of a specified status (such as power outage)
being set or reset within the selected time range
A scalar if function, where condition, true result, and false result are all functions and
expressions that evaluate to a single value.
The formula engine shall include operators which allow for interval and channel statuses to be
set or examined as the result of a formula.

13.3 Energy Losses Calculation

The system shall support energy loss calculation. It should support complicated calculation for
both transformation and transmission loss. It can be used that for adjusted energy consumption.

13.4 Named Formulas

Because a complex mathematical formula may be re-used multiple times in the system, the
system shall allow users to create and save Named Formulas which are formulae comprised of
one or more functions of the calculation module so that those formulas may be created once and
used many times for different service points or service point channels.

13.5 Formula Constants

The system shall allow for the creation named formula constants which allow users to set
constant parameters for use in calculations. The formula constants shall be able to be set at the
system, service point, and service point channels. The calculation engine shall be able to
reference these constants by name for use in aggregations and other calculations.

14. Data Validation

Whenever data is collected, the system will automatically validate the data collected by checking
against user supplied tolerances, such as minimum and maximum demand, power factor, and any
status information returned by the meter (e.g. power outage). These parameter settings may be
either at system level and/or on individual meter level.

14.1 The system will provide the following features for automatic validation of
data:
During communication with the meter, the system shall verify the following parameters:
Verify that the device ID of the meter matches the device ID stored in the system
Verify that the clock of the meter is within a maximum tolerance compared to the standard time
of the collection system.
If the time difference is within a user set tolerances the system shall re-set the meter clock to
match the system clock, providing that re-setting the clock does not cause the meter to cross an
interval boundary

14.2 The system shall perform the following validations following collection of
the data from the meter.
Verify that the difference between the higher consumption peak and the one placed two before
the last in an interval is within a permitted range (configurable). This verification helps to detect
peaks arising from the transmission of data or peaks arising from tests in the meter.
Verify that the difference between the present daily average consumption and the historical daily
average consumption of the previous year or months is within a configurable range.
Verify that when the data is obtained with a specific meter, this is not in testing mode.
Verify that pulse overflow conditions are not present in each interval. This takes place when the
reading of the number of pulses measured is too high to store in one record of the meter. In case
this situation takes place, it means that there is a wrong stepping factor in the meter, that the
relationship between the transformers is not correct or that there are hardware problems in the
meter installation.
Verify that the metered energy in the cumulative consumption register is within a configurable
percentage or multiplier of the sum of the load profile.
Power Outage Status
Short/Long Interval Status
Reset
Watchdog Timeout
CRC/ROM/RAM Checksum Error
Edited Intervals: this valudation applies only to re-validation of edited data, or to data imported
from another system with editing capabilities.
High/Low Limit Demand
High/Low Limit Usage
Excluded Intervals print warning on report but pass data
Parity Error
Load Factor Limit
Power Factor Limit
Interval % Change
Alarms/Phase Error
Interval Tolerance
Usage Tolerance
Time Tolerance

Zero Interval Tolerance

Power Outage Tolerance
Visual Demand Tolerance
Overlap
Redundant Channel
[MSOffice1]

14.3 Validation Severity Levels

The validation functionality of the system shall allow different Validation checks to be assigned
different levels of severity. Primary levels of severity which are required in the system are as
follows:

14.3.1 Warning
Failure of a validation check with a warning level of severity generates a log event, and a
validation report to identify intervals which are out of tolerance but does not interrupt further
automated processing such as upload to billing systems. The intervals which have failed the
check will be marked with a status of Warning.

14.3.2 Fail
Failure of a validation check with a fail level of severity generates a log event, and a validation
report to identify intervals which are out of tolerance. If automatic estimation is configured, the
validation failure will cause the auto estimation routine to be invoked, and the validation routines
to be re-run. If automatic estimation is not enabled, or the data fails validation after autoestimation any further automated processing of the failed data will be halted, a report and log
event will be generated, and a task will be scheduled for manual editing or acceptance of the
data.

14.3.3 Logging of Validation Failures.

The system shall record all validation failures and warnings in a log which can be reviewed by
operators and stored for auditing and reporting purposes.

15. Meter Data Estimation

The Meter Data Estimation shall allow MSEB to configure whether automatic data estimating or
no automatic data estimating
The metering data can be estimated automatically in the system. The estimated data can either
be copied from a redundant/check meter if one exists, or copied from a reference meter (one that
will have a similar profile) with a scaling factor applied. There will be, as a minimum
requirement, a provision to retrieve data from another meter of the same time period from
'yesterday', 'last week', 'last month' or 'last year'. All data that has been estimated, whether
manually or automatically, will be assigned a different status flag depending on how the
estimation was done. The system shall allow at least five MSEB defined status flags.
For automated data estimation, the system can first check the length of the data gap. If the gap is
less than an hour, the system can use linear interpolation. If the period is longer than one hour,
the system will either copy data from a redundant channel if there is one. If there isnt one, the
system can be configured to copy data from a specific meter from last week, the current month,
last month or last year with a scaling factor applied.
The system will support manual estimation, such as second choice of meter ID if the first choice
is not available, four weeks average, linear interpolation for over one hour, etc.
When running the daily automatic estimation, the system will print a list of all meter IDs
scheduled for automatic estimation.

16. Data Editing and Estimation

The system shall provide a GUI interface for operators to manually editing the data. Whenever
data fails any of the validation checks, the system shall report and continue processing the data.
If the data exceeds the defined range, then an operator is needed to investigate and decide how to
repair the data. Once the data has been edited, it shall be validated and subjected to all standard
automated processing. The system shall allow for at least the following functions to be
performed in the estimation and editing engine.
parameter based estimation algorithms
user defined estimation algorithms
editing of individual values and statuses in the user interface.

16.1 Parameter based estimation functions shall include:

Estimation of interval data based on meter readings
Replace all values with constant value
Multiply or divide by a constant value
Add or subtract a constant value
Copy values from a reference channel or register with or without scale value
Copy values from a previous time period
Linear interpolation
Slide a range of interval data ahead or back in time
Split or combine intervals
Set or reset one or more statuses
Restore previous version
Delete data (mark as deleted)

16.2 Capabilities for direct editing of individual values on-screen shall include:
Add or replace values manually on screen
Modify status manually on screen
Display and/or edit multiple channels on the same screen
Copy or cut and paste string of values and statuses from one channel to another
Copy or cut and paste string of values from spreadsheet
Copy or cut and paste values and statuses within the same channel
User defined estimation algorithms shall be able to use,
Any of the mathematical functions, nested conditional statements, unit conversion functions,
date/ time and TOU functions, historical time references, constants, unit conversions, and
references to additional channels supported by the calculation engine module described in
section 13.1 of this specification.
Editing and estimation shall be able to be manually initiated through the user interface or
configured to automatically occur based on criteria such as failed validation or missing data
being true. Automatic estimation shall use parameter based or user defined estimation
algorithms.

16.3 Edit Logging and Tracking

The system shall store original data and other information required to track any edited value
through all versions back to the original value obtained from the meter. Any edited intervals
shall be marked with an Edited status flag.
Additionally, the system shall have an edit log which records the following information anytime
an edit is performed:
User ID of user performing the edit
Data Edited

Date and Time

Reason
The system shall allow the edit log to be viewed or printed whenever necessary, and with any
subsequent validation reports for the edited data.

17. TOU Functionality

The system shall provide functionality to report and export data for use in billing on time of use
rates. This time of use functionality shall include the following:

17.1 Building Blocks

A time of use schedule is a combination of several building blocks arranged hierarchically.
These blocks shall include the following:
A block: the times during a week that a particular rate is in force. Types of block may include
on peak, off peak, shoulder peak. Block names shall be user-definable
A Season: the period of year for which particular time of use blocks are applicable. Seasons
shall be user definable. A given schedule shall support at least 10 seasons. Additionally, users
shall be able to define blocks which are applicable regardless of season.

17.2 Time of Use Block

A time of use block is defined as the period or periods of a given week for which a particular rate
is in force.
Each time of use block shall be defined by the following parameters:
Unique Name, to be assigned by MSEB
Day of week. Options for day of week shall include:
Individual Days of the week
All Weekdays
Weekend Days
Holidays
Any combination of the above
Time of day at which the block begins
Time of day at which the block ends
Parameters of interest
Energy
Demand
Energy & Demand
It shall be possible for a block to be defined for the entire year, or for a particular season.

17.3 General TOU requirements

Users shall be able to define time of use schedules for at least five years in the future. Each time
of use schedule shall be able to support up to five (5) seasons, and up to 100 different time of use
blocks. Additionally, users shall be able to define at least 50 holidays per year.

17.4 TOU User Interface

Users shall define time of use schedules using an intuitive graphical user interface which
represents schedules in a tree format.

18. Reports
The system shall generate reports for meter reading, data validation, estimation, export, events,
communications and logs. The system shall also integrate with a commercially available
reporting package, such as Crystal Reports, to allow MSEB to define custom reports for unique

operational requirements. Standard system reports shall include reports for use in the analysis of
data, and the operation of the system

18.1 Characteristics of standard reports

18.1.1 Export Format
Reporting tools shall offer users the option of exporting reports to disk using a variety of
standard windows formats including, at least, PDF, Word and rich text format.

18.1.2 Date selection

When running a report by date span, the system shall provide users with the option to enter
specific start and stop dates, or to run reports using standard time scales such as:
Today
Yesterday
Week To Date
Month to Date
Last Seven Days
Last thirty days
Last Week
Last Month
Last Quarter
Last Year

18.2 Operational Reports

The system shall provide standard reports to assist users in the operation and maintenance of the
system. Operational reports shall include the following reports, at a minimum:

18.2.1 Data Availability Report

The system shall provide a mechanism to report on the time periods for which data is available at
a selected service point.

18.2.2 Data Gaps Report

The system shall provide a report which identifies gaps in interval data during a user-specified
period.

18.2.3 Analytical Reports

The system shall provide extensive capabilities for analytical reporting on the interval data stored
in the system. The system shall include, at a minimum, the following reports.

18.2.4 Engineering Units Report

A report which provides an interval by interval listing data in selected channels. The user shall
have the option to select the timeframe, whether data is to be displayed in demand, energy, or
pulse units. The user shall also be able to select daily, detail, and peaks display

18.2.5 Coincident/Non Coincident Peak

The system shall provide a report which calculates and prints the non-coincident peak, coincident
peak, and load factor for each contributor.

18.2.6 Weekly Detail

The system shall provide an interval demand report for a specified channel or all channels. The
high, low and total for each day will be printed, along with a peaks summary.

18.2.7 KVA Report

The system shall provide a report, which provides an interval listing of calculated KVA and
contributing metered values, including kW, kVAR, Power Factor, Voltages, and Amps.

18.2.8 Reading Detail Report

The system shall provide a report, which provides a detailed listing of meter readings, associated
status flags, and a graph of reading data.

18.2.9 Time of Use

The system shall provide a report which displays usage and demand based on a points assigned
time of use schedule.

19. Interactive Graphics

The system shall provide an interactive graphics package which allows users to graph and
analyze load profile and load profile channels data in a flexible way. Interactive graphics shall
be accessed through the standard GUI of the system.

19.1 Graph types:

The interactive graphics module shall include, at a minimum, the following graph types:
A Detail demand graph which shows graphs of the detailed demand for one or more service
point channels for the specified time period
A peak day graph which shows the detailed demand profile for the peak day of a specified time
period
A summary graph which can display the following summary parameters for a channel
Peak demand
Low Demand
Total Consumption
Peak and Low Demand
Load factor

19.2 Graph Data

The interactive graphics module shall allow users to display data directly from service point
channels, metered or calculated, and to specify a formula in the syntax of the calculation module
and graph the result.

19.3 Date selection

The interactive graphics shall allow users to select the date span to graph, the system shall
provide users with the option to enter specific start and stop dates, or to run reports using
standard time periods such as:
Today
Yesterday
Week To Date
Month to Date
Last Seven Days
Last thirty days
Last Week
Last Month
Last Quarter
Last Year

19.4 Graph Operation

This screen must show a graph of each measured variable, with enough detail to visualize the
meter data. It must contain, at least, the following elements and options in screen:
Consumer s account number.
Service Point identification.
Premises Identification

Interval displayed
Start time of graph
Stop time of graph
Maximum Value
Time of maximum value occurrence
Summary value for the graphed variable
Graph type
Meter Identifier (if appropriate)
A graph of the selected parameter.
Time Zone
The scale of the Y axis of the graphic must be self-adjustable to clearly visualize the measured
variable.
A direct access to the data used to draw the graphic must be presented.

19.5 Graph Formats

It shall be possible to display interactive graphs a number of different formats. These formats
shall be able to be selected by the users in the GUI in the following formats:
Line graph
Area Graph
Bar Graph
Pie Chart
Individual Points
Combination Line and Bar Chart
It shall further be possible to display graphics in 2D or 3D formats.

20. Interactive Functionality

In addition to simple display of graph materials, the system shall provide the following
interactive functionality to make analysis and use of data simpler and more efficient for users.

20.1 Graph Re-Run

When the system displays a graph, it must preserve the set-up parameters used to configure the
graph, and provide users with the option to alter the set-up parameters and re-run the graph. It
must allow users a mechanism to tab through graphs which have been run previously to generate
comparisons and perform analyses.

20.2 Interactive Display Characteristics

Display characteristics such as line colour, graph type (i.e. line or bar or pie chart) shall be
selectable by the user on the screen.

20.3 Mouse-Over Functionality

If the mouse pointer is placed at a point on the graph, the screen must display the time, source,
and value for the point over which the mouse pointer rests.

20.4 Data Output

The system shall provide the user with the following options to export chart data from the
interactive graphing module:
The user shall be provided with an option to print the chart to a local printer.
The user shall be provided with an option to store a digital image of the chart on the users local
hard drive.

21. Interfaces to Other systems

The System shall provide a number of defined interfaces to existing systems as described below.
Additionally, the system shall provide an open APIs that will enable MSEB or a third-party to
build additional interfaces. The primary interface will be a text-file based interface to the
MSEBs billing system.

21.1 Billing system interface

The system shall provide an interface to the MSEB billing system using the nativefile format of
the existing MSEB billing system. Export shall be processed automatically on a cycle basis
using the automated scheduling engine. Data exported will include meter data, and other billing
factors calculated using the TOU module.

21.2 Open APIs

The system shall provide APIs for meter data and configuration data which enable MSEB or a
third party to integrate the system with CIS, CRM, Asset Management, or third-party analysis
systems.
APIs shall be based on an open standard.
The API shall allow for both programmatic and file based access. For programmatic access, the
communication mechanism shall be Web Services. For file based access, the system shall
provide a file scanner whereby formatted files are loaded to a predefined directory automatically
imported.
APIs shall be integrated with the security infrastructure of the system, and require a username
and password to operate. Access to functions using the API shall be granted and controlled in the
same way as access is granted and controlled through the user interface.

21.3 Configuration API

The system shall include a configuration API which supports EXTRACT/ADD/and EDIT
functions for all configuration data.

21.4 Meter Data API

The system shall include a meter data API which allows for metered values to be extracted,
added, and edited. Additionally, the meter data API shall allow access to the calculation
functions described in section 13.2 of this document to enable programmers of analytic
applications to access the calculation flexibility of the system.

22. Web Data Presentment

System should provide a simple to use web page user interface across the entireapplication.
Should be able to provide a location for all reports pertaining to particular user and can
store reports (and their selected parameters) that are most frequently viewed by end-users
enabling quick access to user-specific energy data.
Users may also be able to access saved reports via emails, which can be automatically pushed
to them on a user-defined basis. All users should be able to setup their own email distribution
schedules, specifying the frequency of distribution and email recipients.

23. Energy Analysis

Energy Analysis function shall provide users a series of analytical reporting tools and charts
that enable up-to-the-minute enterprise energy reporting and analysis for all commodity poi nts.
Results can be quickly aggregated, and normalized for key variables such as weather, area,
occupancy, or production units enabling benchmarking across any enterprise to identify the best
and worst sites, down to the device level. Energy Analyst supports all commodity points and
includes a number of display capabilities, including:

Total consumption for one or more individually selected meters or only the best or worst ranked
meters in an enterprise.
Interval (hourly, daily, monthly, annually) meter consumption.
Average aggregate hourly load profile for one or more meters.
Average or peak hourly load profile for one point, or aggregate point group, consumption,
maximum and minimum demand levels, and load factor on a monthly basis.
Aggregate interval meter values, coincident peak demand and time of occurrence, and percent
contribution to the peak for one or more meters.
Load Duration curves showing the percentage of time a load persists at a given demand level for
one or more meters.
Energy Analysis reports shall be able to track and aggregate at least 500 hundred meter points
to provide users with a comparative analysis of enterprise energy use across facilities or
departments. These comparisons then allow users to effectively:
Benchmark multiple facilities or departments based on actual activity levels or weather data.
Identify irregular occurrences of high-energy use.
Validate a facility or building systems operational performance over time.
Validate time of peak demand charges, and assess whether the peak consumption hours
correspond to peak time of use price periods.
Assess the frequency of time of peak demand, and assess whether more detailed alternate rate
scenario analyses should be performed using the Cost Analyst Module.
Energy Analysis supports all commodity points and includes the following standard reports:
REPORT NAME
REPORT DETAIL
Summary
Displays total consumption for one or more
individually selected meters or only the best or worst
ranked meters in an enterprise.
Time Interval
Displays interval (hourly, daily, monthly, annual ly)
meter consumption for one meter.
Average Hourly Profile
Displays an average aggregate hourly load profile for
one or more meters.
Aggregate Demand Summary
Displays an average or peak hourly load profile for
one point, or aggregate point group, and reports
consumption, maximum and minimum demand levels,
and load factor on a monthly basis.
Aggregate Peak Load
Displays aggregate interval meter values, and reports
coincident peak demand and time of occurrence, and
percent contribution to the peak for one or more
meters.
Load Duration
Displays the percentage of the time a load persists at a
given demand level for one or more meters

24. Data Analysis

Data Analysis functions shall provide standard charts, data visualization, statistical analysis,
and data export tools to help users analyze both commodity and process data collected through
the server. Data Analysis includes the following capabilities:

multi-point trends - time-series interval data for several points. At least 4 points can be displayed
in one trend graph.
Daily and average load profiles for multiple days.
3-D surface plots of the 24 Hour Line Plot (value vs hour vs day).
One point value against another for corresponding time intervals and determines a coefficient of
correlation between two points
Maximum, minimum, and average values for several points.
Histogram of hourly distribution of equipment runtimes for one point, total hours and percent
distribution of equipment runtimes for multiple points.
Archived interval data in a tabular grid for viewing, printing, and exporting.
The standard reports in the Data Analysis relieve users from having to sort through tedious
spreadsheets and data archives and provide a platform to collect, analyze, and archive key results
from these comparisons to form a database of knowledge. These reports shall be designed to
provide users with a systematic, repeatable process to view plots or data views of critical
relationships in a building system.
Data Analysis shall include the following standard reports:
REPORT NAME
REPORT DETAIL
Single Point Trend
Plots time-series interval data over any time period for one point.
Multi-Point Trend
Plots time-series interval data for several points with up to two point
unit types.
24 Hour Line Plot
Plots daily and average load profiles for multiple days.
3-D Surface Plot
Plots 3-D representations of the 24 Hour Line Plot (value vs hour vs
day).
Scatter Plot
Plots one point value against another for corresponding time intervals
and determines a coefficient of correlation between two points
Statistical Summary
Displays maximum, minimum, and average values for several points.
Single Digital Point
Displays a histogram of hourly distribution of equipment runtimes for
one point
Multi-Point Digital
Reports total hours and percent distribution of equipment runtimes for
multiple points.
Data View and Export Displays archived interval data in a tabular grid for viewing, printing,
and exporting.
Histogram
Displays frequency and cumulative % distribution for user-defined
value bins for a point.

28. Features Of The Network Licenses

Base System with report package
Remote Interrogation Package
Graphics Package
Spreadsheet File Formal Package
Direct Uphold of Handheld Readers
Time of- Use Package
Totalization Package

Portable Reader Package

Web Package which also includes ODBC Interface Package.

29. System Set Up For MSEB

MSEB intends to read remotely 20000 electronic meters installed at various EHV
substations / All HT consumers(Commercials and Industrial customers) of its transmission and
distribution network,
DTCs in MIDC and Urban areas spread over the entire state.
The Software Network License system will be installed at Mumbai, Pune and Nagpur. Dedicated
server, workstations, modems and phone lines will be installed at all locations. The data
collection, validation and export will be performed locally. However, MSEB will consider to use
existing LAN/WAN infrastructure to communicate between the offices and back-up both meter
and metering data information to the central office.
In the configuration / set-up, each Network site has a server which holds both the database as
well as Web database. The database controls both the meters and meter data information while
Web database contains metering data presentable to the end customers.
The Main server and the Workstations are dedicated hardware for meter data collection. They
are the production system and shall be installed in server environment with proper protections.
The workstations will dial the meters, validate and estimate the metering data and export these
data if requires. Also the workstations can automatically export validated data into web database
and ready for external customers access.
Since meter readings are considered critical, disc mirroring or similar approach shall be used to
provide redundancy. Secondary storage media such as magnetic tapes shall also be provided.
Automatic backup to tape of meter readings that one months old is preferred but a user-friendly
interface to do manual backup is acceptable.
In the design of the system, a strategy shall be used such that any failure of the
communication front end serving a group of meters (with the communication media still in tact)
will not disable the system from retrieving that same group.
Not all meter locations have telecommunication facility. Some are located in remote areas
with no nearby public telephone land lines. The Supplier shall propose different approaches to
the problem. MSEB will select among the proposed solution. The selected solution shall be part
of the Suppliers deliverables.

30. Summary Of Required Software And HardwareConfiguration

Three Network License will be installed at Mumbai, Pune and Nagpur. Each Network system
configuration is designed to 20000 meters at a 6-hour time window.
For a Web server, the available data to customer will be up to three months. New and powerful
databases are required to support more data and customers.
Each Network System will consists of :
.
One Main server, which host server data, Web data
.
One web server, which will be installed in CCU for public data access
.
Four workstation. These are dedicated workstation for dialing validation and export.
.
Required PSTN telephone lines will be installed for dialing
The supplier must work closely with MSEB and their IT engineers to recommend solution on
issues like server redundancy, disk array/mirror, disaster recovery, etc.
SYSTEMS HARDWARE AND SOFTWARE REQUIREMENT TABLE (AT EACH
SITE). THERE ARE THREE NETWORK LICENSE STATION

ITEMS
Software License
Network License
Web License
Pervasive SQL License

QTY
3
1
1

AMR Center Hardware and Software

Main Server
2
Workstations
3
Web Server
2
Printers
3
Modem
6

PSTN Lines

ITEMS
UPS
Network Switch

QTY
3
3

Power Supply
Cables connection
Furniture
Meters End
Electronic meters

Meters programming software

GSM modems
GSM antenna/mount
Modem/PSTN lines
Meter boxes

SPECIFICATION

SUPPLIED BY

Meter data collection

Supplier
Web Presentation
Supplier
At least 10 Users
license, Supplier
Required for system operation
Detailed in Annexure-I
Supplier
Detailed in Annexure-I
Supplier
Detailed in Annexure-I
Supplier
Detailed in Annexure-I
Supplier
Good Hayes compatible modems, Supplier
preferably already tested in focal
environment.
Data graded PSTN lines
MSEB/Supplier
SPECIFICATION
SUPPLIED BY
Detailed in Annexure-I
Supplier
A switch enough ports for all plus Supplier
one for LAN. Also allow for any
future expansion.
Prefer dual power supply
Supplier
All
necessary
cables
and Supplier
connection
Computer table and chairs
Supplier
Electronic meters forinstallation, MSEB/Supplier
if needed
Provided by meter manufacture MSEB
alongwith
Proprietory
PROTOCOLS
for
meter
programming and interfacing.
If GSM modem is used
Supplier
If GSM modem used, antenna is Supplier
installed
If PSTN line is used
Supplier
If needed
MSEB/Supplier

31.METER COMPATIBILITY

The software should support at least the following brand of meters:

Datapro
Any model already approved by MSEB

L&T
Secure
ABBEMF
Dukes Arnics
Advanced Control System
EMAIL Ltd. (Australia)
Landis & Gyr (Europe)
Schlumberger (USA)
Schlumberger (UK)
Siemens (UK)

-do-do-do-doEmax Recorder
EI Meter
FCL/FCMFAF/EMT/EKM/FBC
DataStar, Quantum, Fulcrum,MT20
PXAR (indigo) Spectra
S4S Meter

32.SPARE PARTS, TOOLS, AND WARRANTY

The Supplier shall furnish spare parts for all replaceable parts of the Center Retrieval Station
with a list identifying each one and the specific sub-assembly to Retrieval Station with a list
identifying each one and the specific sub-assembly to which it applies. The spare parts shall be of
sufficient quantity to cover 2 years of maintenance, Spare parts support shall be made available
for at least 10 years.
The Supplier shall furnish the special tools necessary for installation, start-up, operation and
maintenance of the Central Retrieval Station and accessories furnished.
The Supplied materials shall come with a one-year warranty on parts and service provided by the
local representative of the supplier. In case of repair and/or replacement within the warranty
period, all costs, including out-of-country shipment insurance charges shall be borne by the
supplier.
The Supplier warrants that the Goods supplied under the Contract are new, unused 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 Supplier further warrants that all Goods
supplied under this Contract shall have no defect arising from design, materials or workmanship.
This warranty shall remain valid for twelve (12) months after the Goods, or any portion thereof
as the case may be, have been delivered to and accepted at the final destination indicated in the
Contract. In case of repair and/or replacement within the warranty period, all costs, including
out-of country shipment insurance charges shall be borne by the supplier.

33.QUALITY ASSURANCE REQUIREMENTS

The manufacturer shall have a well-organized Quality Assurance Program (QAP) based on ISO
9000 Series to assure that items and services, including subcontracted items and services comply
with this specification.
All design, manufacturing, processing, testing and inspection operations affecting the equipment
or material shall be governed by Quality Assurance procedures in accordance with the directives
of the ISO 9001 standards while the production and installation shall be governed by quality
assurance procedures in accordance procedures in accordance with the directives of the ISO
9022 standards. A tentative QAP shall be submitted together with the bid and shall meet the
requirements stated.
For the Central Retrieval Station where site installation, test and commissioning work is
involved, the Supplier shall prepare contract specific quality assurance procedures in agreement
with the Purchaser prior to commencements of such works.
The Supplier shall be responsible for specifying the quality assurance requirements to his
subcontractors, for approving subcontractors quality assurance program and for ensuring
compliance with the requirements.

ANNEXURE-I

Technical Specification for Computer Hardware to be provided by

SUPPLIER
1:Main Server / Web Server:
Sr. No Description
Specifications
1 Make
Manufactured by ISO 9000 and 14000 manufacturing unit
HP/COMPAQ/IBM ONLY
2 Model
Must be specified and manuals must be submitted
3 Processor
Intel Xeon 3.0 GHz or higher
1 MB L2 Cache memory, Front Side Bus - 800 Mhz
4 Rack Mountable 4U- Rack Mountable Server with rack (19 x 42U Rack)
5 No. Of processors One Up-gradable to two
6 Memory
2 GB DDR RAM / Scalable to 8 GB max ECC DDR RAM
memory (200 MHz)
Multibit Error Correction capability using ind std ECC
DIMM
7 Bays Available
8 bays - six hot swap disk bays, (1) diskette, (1) CDROM
8 HDD
4 * 73 GBGB(hot plug) Ultra160 SCSI disks, 10 K RPM,
9 Controller
Dual Channel Ultra 320 SCSI Controller
10 Raid
Dual Channel Ultra 320 Raid controller with 128 MB battery
backed ECC cache
11 Networking
2 x 10/100/1000 MBPS Ethernet controller
12 Ports
Two USB ports and 1 serial
13 Bus Slots
PCI 2.1 (33MHz), 5nos. PCI slots - 4 no.64 bit /100MHz + 1
no. 32bit/33 MHz
14 Systems
Dedicated Service Processor with LAN connectivity to
Management
provide for remote console and management / diagnostics
independent of the hardware and OS.
-Remote power cycling of server ( power on and off )
-Remote POST , Remote Access to RAID and SCSI
configuration through Remote POST Console
-Shared serial port allowing connection to the Dedicated
Service Processor / PCI Card and /or the operating system
through a single modem.
-Monitor temperature, fans and power supplies.
-Pre failure warranty on CPU, memory &
HDD
15 CD ROM drive
48 X speed or better EIDE CD ROM
16 Floppy drive
1.44 MB 3.5
17 Fans
System fans for cooling for power supply and processor

Sr. No Description
18 Power supply

Specifications
Redundant Hot pluggable power supply

2 x 600 W or more (N+1 redundancy)

19 Software
Installation and configuration utilities, System Administration
Software. Web based server management software for
monitoring system health, environment, alert notification,
critical event action
20 Certification
MS Windows 2000 /Linux essential
21 Operating System Win 2K Server, with media and manual, Antivirus for Win2K
Server
Antivirus should provide comprehensive Virus protection for
Windows based network.
It must provide Virus protection at the Gateway for all inbound
and Outbound HTTP, SMTP, & FTP Traffic across the
network (with Firewall for Web Server).
It should
- Detect and remove viruses hidden in email
attachments, prevent it from spreading through Microsoft
Exchange Environment, Lotus Notes.
- Efficiently safeguard Multiple Servers and Domains from
Virus attacks
- Provide centralized, Web based, real-time desktop virus
protection for Enterprise Desktops with integrated server based
deployment and control
- Manage virus protection across the enterprise network,
through single console.
22 Backup Device
VXA 1, 33/66 GB with 3/6 MBPS transfer rate /DAT drive
33/66 GB with 2 cartridge/media
23 Audited TPC-C Must have audited TPMC rating Certificate must be attached
throughput
23 Keyboard
Standard Keyboard (104 Keys)
24 Mouse
PS/2 type Microsoft or equivalent scroll mouse
25 Monitor
21" Colour Monitor, Max. pixel rate of 110 Mhz,0.28 MM Dot
Pitch with capability to support resolutions of 1024x768 or
more Monitor should be able to support Horizontal frequency
of upto 69kHz. and vertical frequency of upto 120Hz. Should
be MPR-II compliant/FCC Class B Certified/UL Certified.
26 Accessories &
Good quality mouse pad and dust cover for the system and
Service support
must have service support in Maharashtra
27 Furniture
Suitable Furniture for above specified Server
28 Warranty
3 Years Onsite

2 : Workstation
Sr. No Description
1
Make
1
2
3

6
7

8
9
10

11
12

13
14
15
16
17

Specifications
Manufactured by ISO 9000 and 14000 manufacturing unit
IBM/HP/Compaq Only
Model
Must be specified and manuals must be submitted
CPU
Pentium 4, 3.0 HT GHz (or higher speed) processor with 1 MB
L2 Cache memory
Memory
512 MB DDRAM Memory
(single DIMM) expandable up to 4 GB
minimum 1 DIMM slot should be free
Mother board
Intel 915G chipset based motherboard having following
features:
3 PCI & 1AGP slot Bus architecture.
Minimum 3 PCI slots
Should have Ultra ATA-100 controller onboard.
Chipset should support for 533 MHz Front side bus.
Monitor
Low radiation, 21SVGA, color Monitor offered should be
MPR-II compliant/ FCC class B certified/ UL certified. Max.
pixel rate 0.28 MM Dot Pitch and Support resolutions of 1024
x 768 and above
Display controller Intel Extreme 4X integrated graphics
Hard Disk
Minimum 80 GB, Ultra ATA-100(EIDE), 7200 RPM hard disk
with data transfer capability up to 100 MB/sec with SMART
III technology
Floppy Drive
1.44 MB floppy drive
CD ROM
48X or higher speed IDE CDROM drive.
Ethernet Interface 32 bit PCI, 10/100 Mbps Intel Ethernet (Integrated on
motherboard) with support for PXE and WAKE ON LAN. The
Enet should be supported under SCO, Unix, Novell Netware,
windows 98, windows 2000 and windows XP environment.
Audio Ports
Microphone jack ,Line in and line out with external speakers.
Ports
6 USB ports or more

1 serial (9pin), one parallel, one keyboard and one

mouse port
Key Board
104 Keys standard keyboard
Cabinet
5.25 Bays 2 Nos.
3.5Bays
2 Nos.
Mouse
PS2 type Microsoft or equivalent Mouse with scroll wheel
optical
BIOS
Plug and Play Flash BIOS with facility of power on password,
administrative password, Boot sequence control
Power Supply
180 watts or more SMPS with built in over voltage and surge

Sr. No Description
18
19

Power
Management
Manageability,
Safety &security

Specifications
protection. Power can be catered to all slots and bays.
APM (Advanced Power Management) feature.

DMI 2.0 compliant, WLP 1.1 program certified, in form of

model name, model no, part no, cpu speed & encrypted
security chip in build for security of data transfer in encrypt
mode
20
Operating System CERTIFICATION OF MICROSOFT WITH MODEL NAME
MODEL NO AND CPU SPEED MUST BE ATTACHED
(MANDATORY)
Pre-installed Windows XP Professional, Anti virus (latest
definition) with all related drivers of PC
Machine should be with an additional partition with the OS for
immediate recovery incase of OS crash (mandatory)
21
Office Software MS office 2000 with Media, Manual & License
22
Accessories &
Good quality mouse pad and dust cover for the system and
Service support
must have service support in Maharashtra
23
Furniture
Suitable Furniture for above specified PC
24
Warranty
3 years onsite
3: True Online Uninterrupted Power System (UPS)
Sr.
Item
Specifications
No.
1)
Make
APC/ TVSE/EMERSON Only
2)
Model
3)
Capacity
2 KVA True Online
4)
Technology
Microprocessor Based High Frequency Switching
5)
Input Voltage
190 V AC to 260 V AC or better on full load
6)
Input Frequency 50 Hz +/- 5 %
7)
Input Power
0.6 to 1
Factor
8)
Output Voltage 230 Volts +/- 2%
9)
Output Frequency 50 Hz Sync to mains supply User settable
50 Hz +/- 0.15% when on battery
10)
Total Harmonic Less than 5.0% and sinusoidal waveform on linear load
Distortion
11)
Load Power
0.6
Factor
12)
Certificate
International safety std. certification
13)
Efficiency
> 85%
14)
Communication RS 232 for UPS Monitoring Software

Sr.
No.

Item

21)

Port
Remote
Monitoring
Back-up Time
Battery Type
Alarm /
Indications
Audible Noise
Hot Standby
Static Bypass
with Automatic
Transfer
Protections

22)
23)
24)

Application
Furniture
Warranty

15)
16)
17)
18)
19)
20)

Specifications

Must be available
2 hours
Sealed Maintenance Free
LCD screen and LED display for UPS status, Alarm messages
& settings for user settable parameters
45 dba
Must be available

Circuit breaker at I/P, Fuse for Battery , Fuse for I/P,

Electronic short circuit protection , Electronic overload
protection
Suitable for Server
Suitable Furniture for above
3 Years Onsite

4: Laser Printer (Colour, A3 Size Paper)

Sr. Item
Required Specifications
No.
1
Make
Manufactured by ISO 9001 & 14001
2
Model
Must be specified. All the relevant product brochures and
manuals must be submitted.
3
Paper Size
A3, A4, Letter, Executive, Legal
4
Print Speed
27 ppm (letter)/28 ppm (A4) black & colour
5
Resolution
600 x 600 dpi
6
Memory
64 MB Standard Up-gradable to 256 MB
7
Paper Type
Plain paper, transparencies, thick stock (120 GSM), labels
and envelopes
8
Paper Handling Input Tray-500 sheet tray, 100 sheet multipurpose tray
Output Tray- 250 sheet face down bin
9
Duplex Printing Automatic two sided printing
10
Color Matching Automatic -document, photographic, graphics
11
Interface
1 Bidirectional IEEE-1284-C parallel port, 1 USB 1.1 port
12
Network Interface 10/100 Mbps Ethernet interface with UTP port
13
Printer Server
Standard Print Server Software
S/W
14
Compatibility
Windows 98, 2000, XP, NT, Server 2003
15
Duty Cycle
120000 pages per month