Corrigendum
PART -2
Technical Specifications And Scope Of Work for Automatic Meter Reading (AMR) System
(Ref no: Dist/AMR/2004-2005/01)
Technical specifications
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 frommeters from different vendors.
The Software should run on any standard IBM PC or compatible computer for stand-alone applications to support data collection, validation, editing and data analysis. It should also run on network environment such asor Novell and Windows NT.
MSEB expects the entire project has to be based on modern telecommunication facilities available in India like PSTN/GSM/CDMA /optic fiber 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 metersof meterscustomers 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(The total quantityqty. and price of HHUof 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 providerprospective bidder. 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.
Following a successful deployment of the AMR system by the MSEB, in concert with a custom application. 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 numbers of meters at HT Consumers, EHV Sub-Stations and DTC Meters in MIDC & Urban areas spread over the entire State but extendable to 330,000 numbers of industrial & commercial meters. load-profile industrial and commercial meters.
The proposed AMR system includes application package, system software and tools whereever appropriate. Computer Hardware includes sServers, wWorkstations, & Networking and operating systemsrelated hardware. Professional services includesProfessional services include customization of software package, as and when required (when need be), implementation and post-implementation 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 Nagpur and Mumbai offices, so the system must be capable of being operated across the MSEB networkintranet.
1. Key Main functions of the system will include:
Daily automatically scheduled collection of intervalinterval data from 20000 existing (currently deployed in the field) three phase electrionic meters. at specific intervals (interval data).
ThTe system must he system must have proven capability to extend extended this functionality to further 330,000 or more meters.
Storage and management of all meter base data, and required 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 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 MSEB’s 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 modulereading module, and to provide that data, and its derivatives to the specified officesusers in the district offices using client-server technology through the MSEB intranet. Each of the threethreetwo specified offices should have an operator workstation to perform manual/scheduled meter reading, data management /analysis. All meter interval data are 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
Architecture
The Ssystem Aarchitecture shall utilize a standard muliti-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 user’s 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 XX or higher.
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 iInternet eExplorer 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. or higher.
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 system’s 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.1 Availability
The system shall be configured for remote meter data collection from 004:00 hour to 067:00 hour on all week daysfrom Monday to Friday. 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 shouldcan 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 20000supports 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 eEach interval containing edited data shall be marked with a status to indicate that the data has been edited.
The pre editedpre-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 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 retrieveableretrievable 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 X. X13.2 of this specificationdocument. The data model diagrammed below is an example of aof 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 channel’s unit of measure, interval length, links to the appropriate meter, any formulaes 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
Device and 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
