The Automatic Meter Reading System (AMR) is aimed at collecting data captured in the static electronic meters installed at consumer premises by employing appropriate communication technology. The AMR System is ncategorized in three segments based on the method deployed for the reading of the meters, namely:
• Walk By: Where a meter communicates with a handheld device carried by the meter reader; after the communication is established, the data is downloaded in the hand held device from which it is downloaded in the host computer system at the utility office.
• Drive By: The system works on the same principles as those of the walk by system. However, the instrument, instead of being carried by the meter reader, is mounted in a vehicle and the readings are collected in the system through some wireless medium (radio frequency, etc.), as the vehicle passes through the pre-defined route.
• Fixed Network: In this category a communication network is established so as to ensure connectivity between the meter and the base computer station. A communication is established with the meter on a scheduled basis and data is downloaded to the base computer station. The networking can be established through PSTN (landlines), RF (radio frequency) or GSM (Fig.).
• Walk By: Where a meter communicates with a handheld device carried by the meter reader; after the communication is established, the data is downloaded in the hand held device from which it is downloaded in the host computer system at the utility office.
• Drive By: The system works on the same principles as those of the walk by system. However, the instrument, instead of being carried by the meter reader, is mounted in a vehicle and the readings are collected in the system through some wireless medium (radio frequency, etc.), as the vehicle passes through the pre-defined route.
• Fixed Network: In this category a communication network is established so as to ensure connectivity between the meter and the base computer station. A communication is established with the meter on a scheduled basis and data is downloaded to the base computer station. The networking can be established through PSTN (landlines), RF (radio frequency) or GSM (Fig.).
 |
| Fixed Communication Network |
Benefits of AMR
All the static meters installed at the consumer end capture data in the form of cumulative data (useful for billing − energy consumed), profile data (useful for load surveys), instantaneous data, events data (log of various abnormal events occurred at meter end − useful for vigilance purposes).Monthly meter readings for billing purposes, using Common Meter Reading Instruments (CMRI) are carried out. The cumulative data required for billing is forwarded to the Computer for bill processing. The entire billing cycle takes a certain amount of time. The AMR system is able to read the billing data of meters “remotely”. It sends the billing data directly into the billing system, thus eliminating the interim step of “downloading” meter reading data to the host computer from CMRI. This helps reduce the infrastructure for meter reading and subsequent billing cycle time. It also eliminates human involvement.The Data Analysis system as an output of the AMR is able to analyze the meter data (like tamper information, attempts of theft of energy and events/exceptions) and raise alerts for concerned user departments. This results in effective utilization of the information rich meter data leading to arrest of AT&C losses.
The benefits of AMR are summarized in Box .
Box: Benefits of AMR
• Reduction in meter reader count.
• No travel related expenses.
• Saving on seals and stationeries.
• Faster meter reading to cash realization.
• Improved cash flow.
• Improved vigilance further improving revenues.
The success of this technology lies in the successful operation of three separate functions − the meter itself, the connectivity network and the software for the analysis and billing of the data captured. As on date, the returns of AMR implementation mainly depend on the effectiveness of the communication network and mapping and analyzing of the data by an effective software.
Hardware Requirements for AMR
All the static meters installed at the consumer end capture data in the form of cumulative data (useful for billing − energy consumed), profile data (useful for load surveys), instantaneous data, events data (log of various abnormal events occurred at meter end − useful for vigilance purposes).Monthly meter readings for billing purposes, using Common Meter Reading Instruments (CMRI) are carried out. The cumulative data required for billing is forwarded to the Computer for bill processing. The entire billing cycle takes a certain amount of time. The AMR system is able to read the billing data of meters “remotely”. It sends the billing data directly into the billing system, thus eliminating the interim step of “downloading” meter reading data to the host computer from CMRI. This helps reduce the infrastructure for meter reading and subsequent billing cycle time. It also eliminates human involvement.The Data Analysis system as an output of the AMR is able to analyze the meter data (like tamper information, attempts of theft of energy and events/exceptions) and raise alerts for concerned user departments. This results in effective utilization of the information rich meter data leading to arrest of AT&C losses.
The benefits of AMR are summarized in Box .
Box: Benefits of AMR
• Reduction in meter reader count.
• No travel related expenses.
• Saving on seals and stationeries.
• Faster meter reading to cash realization.
• Improved cash flow.
• Improved vigilance further improving revenues.
The success of this technology lies in the successful operation of three separate functions − the meter itself, the connectivity network and the software for the analysis and billing of the data captured. As on date, the returns of AMR implementation mainly depend on the effectiveness of the communication network and mapping and analyzing of the data by an effective software.
Hardware Requirements for AMR
 |
| Modem and its Connections |
The hardware requirements for AMR are:
• Meters, and
• Modems.
The schematic diagram of a modem and its connections is given below.
GSM-AMR System Modem Specifications
It consists of the following subsystems:
• GSM Modem
• High Gain Antenna
• 6 kV Surge Protected Power Supply
• Common Optical Port (COP3)
• IP-55 Rugged ABS Enclosure
We now describe their features, in brief.
•GSM Modem
− Dual Band 900/1800 MHz or 900/1900 MHz Data Modem.
− Internal Modem supply 5.5 V to 12 V DC.
− Data rate up to 14.4 kbps.
− Temperature –25 C to + 70 C
High Gain Antenna
− Standard 3dB gain antenna
− 2 Meter RG 174 cable
− Screw mount facility
• Meters, and
• Modems.
The schematic diagram of a modem and its connections is given below.
GSM-AMR System Modem Specifications
It consists of the following subsystems:
• GSM Modem
• High Gain Antenna
• 6 kV Surge Protected Power Supply
• Common Optical Port (COP3)
• IP-55 Rugged ABS Enclosure
We now describe their features, in brief.
•GSM Modem
− Dual Band 900/1800 MHz or 900/1900 MHz Data Modem.
− Internal Modem supply 5.5 V to 12 V DC.
− Data rate up to 14.4 kbps.
− Temperature –25 C to + 70 C
High Gain Antenna
− Standard 3dB gain antenna
− 2 Meter RG 174 cable
− Screw mount facility
− Input voltage range : 110 V AC / VDC, 300 V AC / VDC ± 30%
− Input frequency : 50 Hz ± 3 Hz / 0 Hz
− Inrush current : < 800 mA rms @100 VAC or 140 VDC
− Efficiency : > 70 % typical at full load
− The average burden on PT during GSM data transmission is 4VA (24VA being peak burden during transmission at 2W power on antenna).
•COP-3 (consider only PACT communication)
Networking Technologies
• Public Switch Telephone Network (PSTN): The wire-pair in local loop based telephone service.
• Wireless in Local Loop (WLL): This category of communication option includes:
Global System for Mobile Communication (GSM) which is also called as cell-phone.
Code Division Multiple Access or CDMA.
• Dedicated radio link: Dedicated radio link is used for RMR for mission critical metering applications like summation meters or for remote metering.
• Fibre optic/coaxial cables: This option is used for substation monitoring where the data payload is large enough to justify the cost
Infrastructure and Set-up Requirements
•Office
− Exclusive workstation for AMR desk,
− High speed computers,
− Server,
− UPS, and
− Workforce.
Field
−Exclusive AMR field team,
Procurement of necessary materials.
Software Requirements for AMR
The AMR and DA system software functionalities can broadly be categorized as follows:
• Scheduler
• Communication Server
• Alert Manager
• Audit Trails and Tracking
• Logs and Archives
• Data Loading/Entry
• Data Analysis
• Interface with other utility Applications
• Reports
• User Interfaces
• Backup and Recovery
• Data Formats
• Data Migration
We now describe them briefly.
•Scheduler: The AMR and DA system should schedule reading meters for specified data, as per the schedule defined in the system, according to the meter reading priority category (listed below):
− Class 1 (Highest Priority): The meter could be read on an hourly/half hourly basis on the timing set.
− Class 2 (High Priority): The meter would be read twice a day depending on the timing set.
− Class 3 (Medium Priority): The meter would be read once in a week.
− Class 4 (Low Priority): The meter would be read once in a month.
It is recommended that the number of meters in the highest priority category should be limited. Only instantaneous data should be obtained from meters in the high priority schedule. The default priority for any meter should be low category.A User Interface should be available to the user, to define or modify the meter reading schedule. This schedule is to be maintained in the AMR & DA database.
The following override mechanisms would be provided for the schedulers:
− Based on billing calendar of the consumer,
− Communication test requirements,
− Manual read by intervention to the system, and
− Re-Schedule or change priority of specific meter reading operations as per Vigilance department requests.
Incremental Data: The schedule priority for meter reading is hourly/twice daily/weekly/monthly. The meter always has data available for the last 60 days. Therefore, a meter is read at least twice in sixty days. If the meter API supports reading of, say, the last 30 days meter data (i.e., incremental meter data) then the Scheduler can be configured by the user to fetch the incremental data for the last 30 days only.
Communication Server
The actual Meter data reading, and conversion of the meter data into uniform XML format, is done by meter manufacturer APIs – residing in theCommunication Server (CS) machine. There can be several“Communication Server” machines, with multiple communication serial ports for simultaneous communication with the meters using the meter APIs. The number of communication server machines depends upon the individual meter reading duration, and the number of meters to be read simultaneously in a particular cycle. The same should be finalised during the system design phase. The entire meter APIs should reside on each of the communication server machines.
Meter Read: The CS machine will get the list of meters to be read from the AMR & DA schedule. It will then call the relevant meter manufacturer Read API for reading data from the remote meter. An independent meter read operation can be carried out on each communication port of the CS machine, simultaneously. The Read API shall establish connection with the meter, obtain the required meter data and place it in a specified file (in manufacturer encrypted form) in the “conversion pending folder” of the CS machine. It shall also provide the result of its operation (success or fail) to the CS in the form of a Result File.The details of the meters to be read, GSM no., data to be read, CS server communication port to be used for making the call, and path for data file provided by API is specified in the configuration file passed on to the API while invoking it. The connection settings for establishing communication with the meter (like communication port configuration, etc.) should also be passed to the Read API through a specified XML configuration file. The CS calls separate API instance for each meter read operation, and assigns an PI instance number to the called API. The API should be monitored with this instance number as reference.
The status of each meter read operation (successful or failed) is conveyed to the main AMR & DA Application Server.Convert Meter Data into XML: The CS invokes specific meter manufacturer’s Convert API – for converting the data file supplied by Read API (manufacturer specific proprietary format) into XML format (in uniform format across all manufacturers). Details of the source and destination data files, seed value, etc. are passed to the CFC API by the Common Framework (CFW). (The Communication Server module of AMR & DA Application is known as CFW (Common Framework) to the Meter APIs).Meter Data Authenticity: The Meter Manufacturer’s convert API, (during conversion of the meter encrypted data into uniform XML format), automatically calls its authenticator API, which generates an “authenticator”, based on the contents of the XML file and the “seed” passed to the CFC API by the calling CFW. The Authenticator API generates the Authenticator number, based on the values of the seed and the data in the converted file. This authenticator is further transferred to the AMR Application Server and logged into the system – and used for verification the authenticity of the XML data.
The authenticator API can be invoked by a user at a later stage on a particular Meter XML data file, by passing the same seed value to it, which will generate the authenticator number again. If the value of the authenticator so generated is different from that of the authenticator for the same XML file as logged in the system, then it means that the XML file has been tampered with. It is assumed that the authenticator API can be run independently from a separate machine (non-CFW machines). The Communication Server will handshake with Meter APIs as one time operation at the start of the machine – to exchange license key information and get authenticated. The system proceeds only after successful license key verification for the meter APIs (make wise).
Meter Data Logging: The data of the XML “meter data” files are transferred from the various CS machines to the AMR Application Server for further logging into the AMR database. The Read API may not be able to provide all the data elements as specified in the meter data format document drop some of the tags due to unavailability of data from the meters. AMR & DA System logs these missing tags in the database with a “data unavailable” attribute.
MRI Data: User can also request the system to upload data from meter MRI file into the AMR & DA system by calling the MRI API from a designated MRI enabled CS machine. The MRI API converts the MRI data into meter data files (separate meter data file for each meter’s data in the MRI File), which is in the meter manufacturer encrypted format. Further conversion of this data into XML format, etc. is as per the process outlined earlier.
•Alert Manager
The AMR & DA system is unmanned. Any “exceptions” raised during meter read/convert operations and/or during data analysis have to be intimated to the concerned users by the AMR & DA system, through its“rule based” exception handling mechanism. The various exceptions raised by the system during data analysis are notified to the concerned users through specified formats/e-mail. In case the user does not respond to this e-mail within the stipulated time, the system escalates this exception to the next user role as per defined hierarchy. A role based escalation hierarchy is to be defined, which the system should implement in the AMR & DA software. Reconfiguring of hierarchy should also be possible in the system. Examples of exceptions generated by the system are given below:
− System not able to read certain meters configured in the schedule.
− The current parameters logged in the profile data of consumer meters should be in line with the data received about the corresponding feeder.− The events data logged in the meter for loss of voltage, etc. should correlate with the feeder interruptions data.
− Discrepancies in the meter parameters such as MD Reset Count, Software Version, Program Dates.
− The energy consumption pattern should be within the limits for the consumer and category.
− The seasonal consumption pattern of the consumers for the past period is similar.
The status of each exception should be tracked by the system.
•Audit Trails And Tracking
The system should maintain the following logs:
− Log indicating start, end and result status for each scheduler cycle.
− Audit trail regarding overrides applied to the scheduler.
− Audit trail regarding transfer of consumer from one priority to another.
− The calls made including start and stop time of call and success status.
− Unsuccessful Calls with reasons (line busy, meter not responding, etc.)
System level audit trail would capture
− Any attempt to log on (successful or unsuccessful).
− Log on ID.
− Date and time of log on.
− Date and time of log off.
Application level audit trails should record user activities such as
− All updating in the database.
− “Before” and “after” picture of each modified record for sensitive data and applications using database audit trails.
Method for Auditing Database Tables: A common approach to auditing data requires adding columns such as created by/created on, and updated by/updated on to every targeted table. At commit time, these fields are set to the current user and system date. It also conveys the time of the last update.
• Logs and Archives
The AMR & DA system logs should include following data:
− Daily meter reading schedule.
− Meter reading configuration files.
− Read API progress audit trail logs.
− Read API files in manufacturer specific formats.
− Result file logs of various APIs.
− Meter data Converted files.
− MRI downloading configuration file logs.
− CFC configuration files.
The AMR & DA system should be capable of storing three years consumer data (in the database). Data older than this should be archived by the System Administrator. AMR & DA system should store one year old data files received from meters. Data files older than this should be archived by the System Administrator.
•Data Loading/Entry
Meter repository database has to be made available to the system. The schema of the various databases interacting with the AMR & DA system should also be made available. The ODBC and OLEDB connectivity to the interacting databases has to be provided. Data loading/entry screens should be provided for the following:
− user defined tolerance parameters (e.g., % overload, UV settings, etc.);
− Inspection Report Entry, verification and reporting;
− schedule overrides entry and removal;
− details of the CT/PT units at the consumer premises and their installation date and time details;
A simple meter-consumer table entry interface should be provided in the AMR & DA system to facilitate direct entry/modification of meter-consumer information required in the AMR system for carrying out meter readingsThis will help the AMR user update the AMR application directly about any meter-consumer changes (viz. meter replacement, etc.) and thus continuewith scheduled meter readings. Data entry through this interface will not support any data validation checks.
•Master Data
− Holiday Schedule
− Meter master
− Consumer master
•Analysis
The result files of the Meter Read API and Convert APIs from each CS machine are analyzed in the system Application Server. Rule based
Exceptions are raised during this analysis and notified to the concerned user. The data available from meters is of the following types:
− General information;
− Instantaneous snapshot;
− Cumulative data;
− Profile data; and
− Events data.
The AMR data logged into the system is analyzed based on exception rules defined in the system. The exceptions detected should be notified to the concerned users via e-mail alerts. The relevant data, as applicable, should also be sent to the user as part of the alert message. Users can configure exceptions in the system, based on a set of available conditions. AMR & DA system generates exceptions based on the following principles:
(a) Current parameters as per the profile data of consumer meters is not in line with the feeder currents recorded in the GSS.
(b) The Events data logged in the meter for loss of voltage should correlate with the feeders interruption data.
(c) Discrepancies in the meter parameters – MD Reset count, S/W version, Program dates.
(d) Consumption Pattern for consumers in similar categories should be similar.
(e) The seasonal consumption pattern of the consumers for the past period is similar.
(f) Staggering days, holiday patterns.
An authorized user may also access the AMR data in the system – to analyze it and assign a particular case for analysis to another user. The assigned case is notified to the user as an assigned case e-mail. All the meter makes do not support all the data parameters. Earlier versions of the same meter make may also not support the entire data set. The mete APIs do not return any data for such missing parameters. AMR & DA system flags these as “data not available from meter”.
The following need to be ensured to enable data analysis:
− The feeder current data should be provided as data input to the AMR & DA system.
− Feeder interruption data should be provided as data input to the AMR & DA system.
− Reference time for the entire system needs to be set.
− Drifts with respect to the reference time should be measured and monitored.
− Result Tolerance limits should be derived considering the accuracy
class of meters, difference in PT voltages at consumer and GSS end.
Interface with Other Utility Applications
The AMR & DA system should interface with the following utility databases/applications for carrying out meter readings, transferring billing related information and analysis of the AMR data:
− Meter Repository System
− DEBS, HT Billing system.
− Grid S/S Monitoring System
− Consumer Feeder Connectivity
− Enforcement System.
 |
| Interface with Other Utility Applications |
The AMR & DA system should pull the data required for its masters, etc. from the above systems using the OLEDB/ODBC connectivity. The
synchronisation with these external databases should be done periodically.It is possible to modify the meter-consumer information in the AMR application from dual sources – the main meter repository system database and the meter-consumer rudimentary interface. Therefore, this interface should be used only in case of emergency, as it leads to synchronisation problems.
•Reports
The user should have the capability of defining Reports with drill down facilities through a query builder. Examples of such reports are:
− Exception based on the demand at the lowest power factor;
− Meter not getting accessible through the system;
− No data is read from the meter in spite of establishment of communication; and
− MDI, P.F, outage of the day data, MDI and LPF penalty details.
In addition to the above, the system should also have “fixed” predefined reports, which should be designed during the design stage. Examples of such reports are:
−Detail Report for a given consumer;
− Consumer sealing details;
− Drift in the real time clock in relation to the reference time;
− Any metering/sealing problems logged; and
− Installation inspection reports
User Interfaces
Users of various departments can access the AMR & DA system, according to the roles and privileges assigned to them by the utility. They should be able to:
− Use the AMR & DA system via interface screens,
− Define or view reports generated by the system.
Backup and Recovery
Backup and recovery plan is a mandatory process:
− Standard backup and recovery features provided by the database should be used for taking backups of AMR database.
− Meter manufacturer files, configuration files and result files should be backed-up/archived periodically by AMR group as per the backup plan.
•Data Formats
The formats of the configuration files and data files used for exchange of information between CFW and APIs should be mutually agreed to during the design phase.
•Data Migration
Consumer database and meter related database, etc. should be populated/migrated into AMR & DA database by the utility. No other migration is envisaged. AMR & DA database schema should be made available to the utility. Once the AMR & DA system has been deployed, the meter reading, billing data and data analysis for the meters integrated into the AMR & DA system should be done only through the AMR & DA system.
No comments:
Post a Comment