Automated meter reading system, communication and control network for automated meter reading, meter data collector, and associated methods

[0001] This is a non-provisional patent application, which claims the priority of provisional patent application U.S. Ser. No. 60/447,815, filed Feb. 14, 2003, titled Automated Meter Reading System, Communication and Control Network for Automated Meter Reading, Meter Data Collector, and Associated Methods, and which is incorporated herein by reference in its entirety.

[0002] 1. Field of the Invention

[0003] The present invention relates in general to the field of utility meters. More particularly, the present invention relates to automatic equipment, systems, networks, and software for remote reading of utility meters, such as electric, gas, water, or steam meters.

[0004] 2. Description of Related Art

[0005] Utility companies and municipalities for many years have been burdened with the labor intensive and cumbersome task of manually collecting meter readings, managing data from the field into the accounting area, and managing the billing and collection of invoices. Typically each customer is provided with a mechanical utility meter for each individual service provided, for example, a meter for water, a meter for steam, a meter for gas, and a meter for electric power. A periodic reading of the utility meter is necessary to determine the usage and to bill the customer for the amount used. These meters are normally manually read using utility company or municipality employees physically visiting each meter at the customer's location, reading the meter, and recording the previous month's usage into a written route book for delivery to accounting personnel. This process is costly, is time consuming, and can involve various risks to personnel involved in manually collecting meter data. The process involves labor, motorized transportation, and numerous employee overhead-related costs. Once the readings from the meter are obtained, accounting personnel manually transfer the readings into a database for billing and collection of the invoices for service.

[0006] Manually reading the meters often results in numerous other expenses including those related to human error. For example, a high bill caused by an incorrect manual read or estimated read often motivates customers to pay later, resulting in increased working capital requirements and corresponding expenses for the utility. Additionally, the utility has to handle the customer complaints (a call center cost) and may have to read the meter again to verify the error. As the complaint progresses, the utility faces administrative costs associated with routing and processing the complaint from the call center to the meter department. An additional cost includes the potential loss of a customer who, even after resolution, feels the process was such an excessive burden as to prompt the customer to switch utility providers.

[0007] Recently, hand-held reading units have been developed that typically provide a data collection unit attached to the consumer's utility meter having some form of data transmitter. The unit or system has some form of receiver. There are different variations in methodology of receiving the data. One methodology of hand-held “local” collecting meter reading requires an operator having a meter or collection unit interrogation device to be in close physical proximity of the meter to obtain the meter reading and transport the data to a central computer such as shown in U.S. Pat. No. 5,559,894 by Lubliner et al. titled “Automated Meter Inspection and Reading” and U.S. Pat. No. 5,856,791 by Gray et al. titled “Port Expander For Utility Meter Reading.” For example, in a radio drive-by or walk-by unit, a utility service vehicle having a mobile receiver mounted in a service vehicle or a utility worker having a hand-held unit passes by the consumer's facility to receive the data from the meter. As the vehicle or hand-held unit passes near the electric meter, the receiver emits a signal to the collection unit, which causes the collection unit to transmit or send its meter reading data to the receiver. This consumption data is then stored and later entered into a billing system. This approach, however, still requires the manual visit to each meter location and time downloading the data to the billing system. Nevertheless, the physical meters can be read much more quickly which reduces manpower, vehicular, and soft costs. Also, the data is transferred from the mobile receiver to the database, which again reduces manpower and data handling. This methodology also has a benefit to the customer of preventing intrusion into the customer's premises and improved accuracy of the reading. Remaining system negatives, however, included prohibitive capital costs, i.e., vehicles, and software and hardware requirements, and providing a reliable and cost-effective power solution for the individual radio transmitter in the individual meters.

[0008] Recently, automatic meter reading (“AMR”) has been developed. Automated meter reading has become more desirable than using meters that require manual reading and recording of the consumption levels. AMR consists of technologies and methods to remotely read a plurality of electric meters, such as a consumer base for an electric power supply company, into a billing database by installing or utilizing fixed networks that allow billing or meter usage data to be transmitted without human intervention to a host computer having the billing database. AMR produces many benefits and several companies such as Hunt Technologies, Schlumberger, CellNet, Itron, Amco Automated Systems, and Distribution Control Systems have developed AMR units. For the utility, reading meters without setting foot on customer's property substantially reduces risks associated with climbing over fences, slipping on ice and snow, dangerous animals, snakes, and spiders, and other types of risks which in turn, result in significant savings in liability insurance, disability benefits, and worker turnover/replacement. For the customer, reading meters without entering a customer's property provides a less intrusive service and reduces criminal activity such as when a criminal manages to gain entry into a customers property by posing as a meter reader. Moreover, the need for a higher frequency of meter reading is increasing, e.g., daily, hourly, or every 15 minutes, in order to take advantage of real time pricing. Also, the amount of data is increasing, due to the necessity to bill on more than just consumption, e.g., time of use. Thus, automated recording and reporting of the utility usage at customer sites is rapidly replacing the manually read utility meters.

[0009] AMR systems can use a dial-up modem in the collection unit to dial a remote billing system and transmit its reading data via telephone lines such as that shown in U.S. Pat. No. 6,163,602 by Hammond et al. titled “System and Method for Unified Telephone and Utility Consumption Metering, Reading, and Processing” and U.S. Pat. No. 5,128,988 by Cowell et al. titled “Telephone Switched Network, Automatic Meter-Reading System Based Upon Service Address.” In the past, there have been on-site meter reading equipment having a modem capable of receiving telephone calls from a central office through the use of special equipment located at the telephone company, and there have also been on-site meters with modems which were capable of placing telephone calls to the central office. In general, these systems incorporate an auto-dial, auto-answer modem in each customer site to receive interrogation signals from the telephone line and to formulate and transmit meter readings via the telephone line to the utility company. These systems record information on utility usage and periodically dial into a central office to report the utility usage for recording and billing purposes. This methodology provides two-way communication and control between the meter and the central office. The modem shares the telephone line with the customer's normal usage, such as incoming and outgoing voice communications. Such sharing requires that the system be able to recognize when the telephone line is in use, and to delay demanding use of the telephone line until it is free. Steps must be taken to prevent the data communications system from interfering with other uses and to prevent other uses from corrupting the transmitted data.

[0010] A variation of this methodology includes using the power line as a carrier medium. This approach connects the meter through the power lines and relays the meter reading over the power lines to the utility company. This approach, however, can require a complicated infrastructure to be installed. Power lines operate as very large antennas and can receive a large amount of noise. Therefore, signal-cleaning filters must be installed periodically along the power lines to attenuate the noise. These filters can be very expensive. Also, the connections often are at line voltage, making it more dangerous and time consuming to install.

[0011] Another problem with expanding the use of control systems technology to such distributed systems are the costs associated with the sensor-actuator infrastructure required to monitor and control functions within such systems. A more modem approach to implementing control system technology is to install a local network of hard-wired sensors and actuators along with a local controller. Not only is there the expense associated with developing and installing appropriate sensors and actuators, but there is the added expense of connecting functional sensors and controllers with the local controller and the cost of the local controller. This methodology is also quite intrusive as the cables must be run to physically interconnect the various nodes in the network. An alternative variation includes interfacing the meter with a community cable television system. In addition to the high cost of installation, however, such a system is not useable in areas without access to a cable system. Moreover, networks that are interconnected with cables are subject to physical disruption of the cables.

[0012] Recently, wireless networks have been developed. These networks, typically installed in a point-to-point loop configuration, are used to collect information from and to disseminate information to individual nodes of the network. In conventional wireless networks using a point-to-point loop configuration, each node in the network is interconnected and communicates with two neighboring nodes. Information or commands are passed from node to node around the point-to-point loop until they arrive at a master node. The master node is used to communicate information that is gathered to a central station or to accept and distribute information received from a central station throughout the network. These conventional wireless networks, however, have limitations. For example, because these conventional wireless networks generally have a point-to-point loop configuration, when one node is disabled, the integrity of the entire network can be affected. Moreover, if the master node of such a conventional network is disabled, the network can become isolated.

[0013] Other variations in methodology include using data channels in wireless telephone systems to transmit usage data to a remote billing system via a wireless telephone network, such as PCS, satellite, or cellular. Other methodologies also include the use of low earth orbiting satellites. Building, launching and maintaining a fleet of satellites, however, is very expensive.

[0014] Yet another methodology includes the use of small RF transmitters. Because systems having sufficient range normally are subject to regulations and licensing requirements that are prohibitively expensive, however, the centralized wireless control systems for locally distributed devices using RF transmitters have not been widely utilized. Also, systems that are sufficiently powerful to be used in widely distributed installations are unnecessarily expensive in smaller installations. Additionally, there is limited availability of RF carrier frequencies, and potential interference with other nearby systems that might be operational.

[0015] Further AMR servers have been developed, such as shown in U.S. Pat. No. 6,088,659 by Kelley et al. titled “Automated Meter Reading System,” in attempts to address the metering data management needs of entities involved in energy distribution. Such AMR servers use an open, distributed architecture that collects, loads, and manages system-wide data collected from energy meters and routes data automatically to upstream business systems. Although such AMR servers may address some meter data management concerns, these systems still fail to address communication concerns set forth above with respect to collecting billing or usage data and transmitting the data to a control center, e.g., perhaps having an AMR server.

[0016] In view of the foregoing, Applicant has recognized a need to automate and transform the process of metering electricity, gas, water, steam, and the like, while reducing costs, adding value, enhancing service, and decreasing time of collection.

[0017] When utilities such as gas, electricity, or water are most expensive to the customer, they are also correspondingly most expensive to the utility company. Accordingly, Applicant also has recognized a need for control systems technology to such distributed systems that provide the customer with information to reduce costs and help the utility by reducing demand at peak hours. Applicant further has recognized a need for a fixed network AMR that includes a multifunction data collector capable of transmitting meter readings for multiple meters to the control center and relaying meter readings of other collectors.

[0018] An embodiment of the present invention advantageously provides a distributed network system including at least one utility meter, and preferably a plurality of utility meters, at least one sensor interfaced with each meter, a meter data collector positioned in communication with the at least one sensor to receive meter usage reading data. The system also includes a remote automatic meter reading control center including a computer, e.g., a server, for gathering and processing the usage reading data. The system also includes system software associated with the computer of the remote control center and associated with the collector. Preferably, the system software has network software including a network protocol, e.g., preferably a preselected application layer protocol, to communicate over a network connected to each of the meter data collectors and meter sensors. The network software is preferably capable of querying each meter data collector and assigning the meter data collector a physical location based on the actual physical location with reference to other collectors or “nodes.”

[0019] The meter data collector gathers a usage reading from each sensor communicating with the collector and transmits the data to and receives instructions from the control center. The collector advantageously can include a power module, a controller, a telemetry module, a memory module, a multiple input connection block and a housing preferably meeting NEMA standards, as understood by those skilled in the art, to enclose the unit. In an embodiment, the multiple input connection block includes expandable or input/output ports capable of accepting either digital or analog input. In embodiments of the system, each of the sensors can be tailored to the specific type of meter to be read. For example, for a water meter, the sensor or the collector itself can be attached at the same point that the outside dial attaches. For the gas meter and steam meter, a pulse initiator can be added to the respective meter to digitize the usage. For the electric meter, a pulse board can be added.

[0020] In an embodiment of the system, the collector uses frequency hopping radio frequency (RF) electromagnetic radiation as understood by those skilled in the art. Use of an RF based network advantageously reduces data transmission cost, is flexible, and has low deployment costs. In some embodiments, the system uses low-power RF transmissions. In a medium-range embodiment, the range between collectors and the control center for associated substations can be between 500-1500 meters. In a long-range embodiment, that distance can be between 2000-6000 meters. In an embodiment, the collector is powered through a connection to the electric utility meter. Another embodiment for powering the collector includes the use of a cable having an electrical outlet interface. An alternative embodiment for powering the collector includes use of batteries.

[0021] Functionally, data is acquired from the sensor interfaced with its respective individual meter. Data is obtained by the collector, from the meter sensor, where it is temporarily stored. In an embodiment, all metering data is date and time stamped to provide an accurate record of the read. Typically and functionally this data is then forwarded directly to the control center or a substation if within range and not blocked or impeded by a physical structure or other obstacle. If the collector is not within range, the data is forwarded to another collector associated with a location closer to the control center or a substation, to an intermediate collector, to be forwarded to the control center or substation. In essence, the network structure turns every collector into an individual network node capable of transmitting its respective meter indication data from either “nodes.” Thus, an embodiment of the present invention advantageously provides a self-healing network having minimal infrastructure that significantly reduces line-of-site issues whereby a physical structure may block the transmission of an individual collector. Advantageously an embodiment of the present invention also allows for scalability as the addition of a new collector at a new location that is merely tantamount to adding an additional “node” to the network. In the preferred implementation, however, the network node level between the various nodes and either the control center or a substation can be limited to 15. Advantageously the system provides for both passive and dynamic execution of a meter read. Although the control center can prompt for an additional read if greater delay accuracy is required, the collector can send a current read to the control center every 15 minutes.

[0022] The system control center further includes at least one computer, e.g., a server, including a processor to store, process, and manipulate data gathered by the collectors and transmitted to the control center. The control system correspondingly includes at least one data storage medium to provide for meter record storage and retrieval. The data storage medium is adapted to interface with software for storing and updating a database. The database includes a table(s) to assign the at least one collector physical address and assign various usage data. The usage data is compared to a temporal usage rate to formulate and store with the meter data to a record of consumption totals.

[0023] The computer system also advantageously provides various functions of the utility's control center with the meter data. Regarding a billing office, accurate timely data insures efficient monthly consumption billing on a customer-requested date. Regarding the customer service department, the collection of daily metering data enables the utility to efficiently manage final reads and switching as well as customer complaints without the expense of dispatching someone to the field to re-read the meter. Regarding the scheduling department, daily reads on all the meters in the service territory significantly improves load-forecasting accuracy. Regarding the loss management department, the collection of tamper status information on a daily basis enables quick identification and resolution of energy theft. The marketing department, daily reads allows targeting and delivery of new rates or selectable billing dates to specific customers. Daily reads on a customer that has multiple meters in multiple locations also enables delivery of aggregated billing services, or same-day billing services for all its locations. For the engineering/distribution planning department, daily data collection provides an accurate, continually updated picture of daily load that can be isolated to a specific area, enabling optimum efficiency and system planning, outage management, equipment installation, and maintenance. Additionally, frequent data collection of actual usage can be compared to estimating usage, which enables quick and efficient reconciliation and settlements between utilities, generators, ESPs, and power exchanges. For the end customer, access to daily usage information increases customer satisfaction by enabling more efficient management of energy usage and predicting energy expenditures more accurately.

[0024] Advantageously, an embodiment of the system and system software provides for the customer an increased understanding of its usage patterns. This understanding enables the proper selection of rate options, supplier choices, aggregation and balk purchasing opportunities and efficient forecasting and settlements. The system also advantageously provides for power outage notification and restoration notification. Additionally, the system provides for billing options such as selectable billing dates, selectable billing frequencies, and on-demand billing, which are not cost-efficient when using manual reading of the meter.

[0025] Advantageously, an embodiment of the system and system software provides for the utility increased distribution effectiveness including improved facilities and infrastructure planning, maintenance improvements, improved system reliability, operational efficiencies, improved customer service, outage detection, forecasting and settlements, and load balancing and planning. The system software also advantageously provides for data warehousing and data mining, historical patterns and expectations analysis, analysis for new rates structures, and services bundling such as aggregation of billing to an individual customer, outage detection monitoring, and Internet access to the data

[0026] Advantageously, an embodiment of the system and system software additionally benefit the utility by providing cost savings on regular “on-cycle” meter readings, the ability to obtain more easily (e.g., instantly) final meter reads for opening/closing accounts, stream-lined high bill investigations, the ability to flag potential high consumption before consumers get a high bill, help in pinpointing system losses and detect theft in service. Additionally, the system and system software also advantageously enable more frequent reads with minimal incremental cost, enable custom billing dates, support customized rates for large customers, provide detailed consumption information to customers to provide watchdog services, like leakage monitoring, improved cash flow management due to a reduction in bill contests, improved revenue forecasting by tying detailed consumption information to production data and expected billings, enable more sophisticated rates, and reduce billing adjustments.

[0027] The system and system software of the present invention also advantageously provide for reduced capital costs due to the reduced number of vehicles necessary to physically service the meters, labor savings including the reduction in staff hours for meter reading and meter reading-related customer service, savings on vehicles and miscellaneous costs associated with meter reading, and provide for increased revenues from reducing system losses or replacing older inaccurate meters. Also, an embodiment provides the utility company with the ability for “back-end” billing and accounting software to bundle with the collector, preferably the RCU-41, and associated system software to provide a gathering, transmission, billing, collection and reporting solution.

[0044] The present invention will now be described more fully hereinafter with reference to the accompanying drawings, which illustrate embodiments of the invention. This invention may, however, be embodied in many different forms and should not be construed as limited to the illustrated embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. The prime notation, if used, indicates similar elements in alternative embodiments.

[0045] As illustrated in FIGS. 1-15E, an embodiment of the present invention provides a distributed network system 30 including a multifunction collector or controller 41, a utility meter e.g., electric 72, water 74, gas 76, or other usage, and an at least one sensor (not shown), e.g., an encoder, interfaced with the meter. The sensor is positioned in electrical communication with the collector 41 in order to provide a meter usage reading data. The system 30 also includes a remote control center 60 for gathering and processing the usage reading data. The system 30 also includes system software. Preferably, the system software has network software including a network protocol (preferably an application layer protocol, described below) for communicating over a network e.g. mesh network 32 (FIGS. 1 and 6) connected to each of a plurality of controllers 41, if desired, and at least one sensor. The network software is preferably capable of querying at least one collector 41 and assigning the at least one collector 41 a physical location based on the actual physical location with reference to the other collectors 41 or “nodes” within a network.

[0046] As shown in FIGS. 3-6, the collector unit 41 gathers a usage reading from the at least one sensor and transmits the data to and receives instructions from the remote control center 60. The multifunction collector 41 (FIG. 9) includes a power module 42, a controller 43, a telemetry module 44, a memory module 45, a multiple input connection block 46, and a housing 47 preferably meeting NEMA standards to enclose the unit. In an embodiment of the present invention, the multiple input connection block 46 advantageously can include input/output expressions modules or ports capable of accepting either digital or analog input. In embodiments of the collector, the sensor can be tailored to the specific type of meter to be read. For example, as understood by those skilled in the art, regarding a water meter 74, the sensor or the collector 41, itself, can be attached at the same point as the outside dial attaches. For the gas meter 76 and steam meter (not shown), a pulse initiator can be added to the respective meter to digitize the usage. For the electric meter 72, a pulse board can be added.

[0047] In an embodiment of a system, such as shown in FIG. 5, the system 30 uses frequency hopping radio frequency (RF) electromagnetic radiation as understood by those skilled in the art. Use of an RF based network reduces data transmission cost, is flexible, and has low deployment costs. In an embodiment of a system, the system uses low-power RF transmissions. In a medium-range embodiment, the range between collectors 41 and the control center 60 or associated substations 50 can be between 500-1500 meters. In a long-range embodiment, that distance can be between 2000-6000 meters. In an embodiment of a collector 41, the collector 41 is powered through a connection to the electric utility meter 72. Another embodiment for powering the collector 41 includes the use of a cable having an electrical outlet interface. An alternative embodiment for powering the collector 41 includes use of batteries.

[0048] As shown in FIGS. 3-4, functionally, data is acquired from the sensor interfaced with its respective individual meter. Data is obtained by the collector 41, from the meter sensor, where it is temporarily stored. All metering data can be date and time stamped to provide an accurate record of the read. As shown in FIG. 5, typically and functionally, this data is then forwarded directly to the remote control center 60 or a substation 50 if within range and not blocked or impeded by a physical structure or other obstacles.

[0049] The collector 41, as shown in FIG. 4 and as described herein, can have the following features:

[0050] Functional Specifications:

• • [0051] power source: 5VDC or 120, 240VAC transformer
  • [0052] tamper detection: meter removal, outage detection
  • [0053] operating temperatures: −40° to +85° C.
  • [0054] operating humidity: 5 to 95% non-condensing relative humidity
  • [0055] FCC Compliance: Part 15 certified
  • [0056] Certification: ANSI C12 Standards

[0057] Operation Specifications:

[0058] Radio Module:

• • [0059] Transmit and receive frequency: 902-928 MHz
  • [0060] CRC error checking on every message

[0061] Base Board

• • [0062] Discrete Inputs (4 pt.) Optically isolated 5VDC
  • [0063] Five I/O expansion modules

[0064] Physical Specifications

• • [0065] ABS plastic housing UL-94-0
  • [0066] 10″H×10″W×5″D
  • [0067] Pole or wall mountable

[0068] I/O Expansion Modules

• • [0069] Discrete input (4 pt.) optically isolated 5VDC
  • [0070] Discrete input (4 pt.) optically isolated 12VDC
  • [0071] Discrete input (4 pt.) optically isolated 24VDC
  • [0072] Discrete input (2 pt.) optically isolated 5VDC
  • [0073] Discrete input (2 pt.) optically isolated 12VDC
  • [0074] Discrete input (2 pt.) optically isolated 24VDC
  • [0075] Discrete output (4 pt.) relay 12-280VAC 5A
  • [0076] Discrete output (4 pt.) relay 0-60VDC 5A
  • [0077] Discrete output (4 pt.) relay 0-60VDC 10A
  • [0078] Discrete output (2 pt.) relay 12-280VAC 5A
  • [0079] Discrete output (2 pt.) relay 0-60VDC 5A
  • [0080] Discrete output (2 pt.) relay 0-60VDC 10A
  • [0081] Analog input (4 pt.) 4-20 mA

[0082] Telemetry Modules

• • [0083] RS-232 Module, DB9, DCE
  • [0084] RS-485 Module

[0085] Memory Module

• • [0086] 48K Memory module

[0087] If the collector 41 is not within range, the data is forwarded to another collector 41 associated with a location closer to the control center 60 or a substation 50 meter, to an intermediate collector 34, 35 (see FIGS. 7 and 8), to be forwarded to the control center 60 or substation 50. In essence, the network structure turns every collector into an individual network node capable of transmitting its respective meter indication data and transmitting meter indication data from other “nodes.” Thus, an embodiment of the present invention provides a self-healing network having minimal infrastructure that alleviates a line-of-site issue whereby a physical structure may block the transmission of an individual collector 41. An embodiment of the present invention also allows for scalability as the addition of a new collector 41 at a new location that is merely tantamount to adding an additional “node” to the network 32. In an implementation, however, the network node level between the various nodes and either the control center 60 or a substation 50 can be limited to a preselected number, such as 15. The system 30 provides for both passive and dynamic execution of a meter read. In an embodiment, the collector 41 sends a current read to the control center 60 or substation 50 every 15 minutes, although the control center 60 can prompt for an additional read if greater than 15 minutes delay accuracy is required.

[0088] The system control center 60 further includes at least one computer system 61, e.g., a server, including a processor to store, process, and manipulate data gathered by the collectors 41 and transmitted to the substation 50 or system control center 60. The computer system 61 correspondingly includes at least one data storage medium (not shown) to provide for meter record storage and retrieval. The data storage medium is adapted to interface with software for storing and updating a database (the database includes a table(s) to assign the at least one collector physical address and assign various usage data). The usage data is compared to a temporal usage rate to formulate and store with the meter data to a record of consumption totals.

[0089] The computer system 61 also provides various functions of the utility's control center 60 with the meter data. For a billing office, for example, accurate timely data insures efficient monthly consumption billing on a customer-requested date. For a customer service department, for example, the collection of daily metering data enables the utility to efficiently manage final reads and switching as well as customer complaints without the expense of dispatching someone to the field to re-read the meter. For a scheduling department, daily reads on all the meters in the service territory significantly improves load-forecasting accuracy. For a loss management department, the collection of tamper status information on a daily basis enables quick identification and resolution of energy theft. For a marketing department, for example, daily reads allow targeting and delivery of new rates or selectable billing dates to specific customers. Daily reads on a customer that has multiple meters in multiple locations also enables delivery of aggregated billing service, or same-day billing services for all its locations. For an engineering/distribution planning department, daily data collection provides an accurate, continually updated picture of daily load that can be isolated to a specific area, enabling optimum efficiency and system planning, outage management, equipment installation, and maintenance. Additionally, frequent data collection of actual usage can be compared to estimating usage, which enables quick and efficient reconciliation and settlements between utilities, generators, energy service providers (ESPs), and power exchanges. For an end customer, access to daily usage information increases customer satisfaction by enabling more efficient management of energy usage and predicting energy expenditures more accurately.

[0090] An embodiment of the system 30 and system software provides for a customer an increased understanding of its usage patterns. This understanding enables the proper selection of rate options, supplier choices, aggregation and balk purchasing opportunities and efficient forecasting and settlements. The system 30 also advantageously provides for power outage notification and restoration notification. Additionally, the system 30 provides for billing options such as selectable billing dates, selectable billing frequencies, and on-demand billing, which are not cost-efficient when using manual reading of the meter.

[0091] An embodiment of the system 30 and system software provides for the utility increased distribution effectiveness including improved facilities and infrastructure planning, maintenance improvements, improved system reliability, operational efficiencies, improved customer service, outage detection, forecasting and settlements, and load balancing and planning. The system software also advantageously provides for data warehousing and data mining, historical patterns and expectations analysis, analysis for new rates structures, and services bundling such as aggregation of billing to an individual customer, outage detection monitoring, and Internet access to the data.

[0092] An embodiment of the system 30 and system software additionally benefit the utility by providing cost savings on regular “on-cycle” meter readings, the ability to obtain more easily (instantly) final meter reads for opening/closing accounts, streamlined high bill investigations, the ability to flag potential high consumption before consumers get a high bill, help in pinpointing system losses and detect theft of service. Additionally, the system 30 and system software also advantageously enable more frequent reads with minimal incremental cost, enable custom billing dates, support customized rates for large customers, provide detailed consumption information to customers to provide watchdog services, like leakage monitoring, improved cash flow management due to a reduction in bill contests, improved revenue forecasting by tying detailed consumption information to production data and expected billings, enable more sophisticated rates, and reduce billing adjustments.

[0093] The system 30 and system software of the present invention also provide for reduced capital costs due to the reduced number of vehicles necessary to physically service the meters, labor savings including the reduction in staff hours for meter reading and meter reading-related customer service, savings on vehicles and miscellaneous costs associated with meter reading, and provide for increased revenues from reducing system losses or replacing older inaccurate meters. Also, an embodiment a system 30 provides the utility company with the ability for “back-end” billing and accounting software to bundle with the collector and associated system software to provide a gathering, transmission, billing, collection and reporting solution.

[0094] In the preferred embodiment of the present invention, the network software associated with a server 61 and associated with each collector 41 in the system 30 can include a preselected protocol, such as an application layer protocol positioned at level 7 of an OSI model as understood by those skilled in the art, which provides communication between devices connected on different types of buses or networks. This software, for example, can allow collectors to communicate with each other and a server or substation. The preselected protocol can be a request/reply protocol and offers services specified by message type.

[0095] A preselected protocol message packet is built by a master application that initiates a preselected transaction. The message type indicates to the slave application what kind of action to perform. The size of the preselected protocol message packet is device dependent and can have a maximum of 256 bytes. In an embodiment of the present invention, the preselected protocol uses a focused representation for addresses and data items. This focus, for example, can occur such as when a numerical quantity larger than a single byte is transmitted, the most significant byte is sent first.

[0096] The preselected protocol includes a non-routed protocol frame and a routed protocol frame. In an embodiment, the routed protocol frame includes the following elements: a Start of Message (SOT), Message Type (MT), Message Sequence Number (MSN), Message Length (ML), Message Date Time (MDT), Routing Source Node Information (RSN), Routing Source Node Identification (RSID), Routing Subnet Mask (RSM), Routing Destination Node Identification (RDID), Routing Gateway Information (RGI) or Routing Gateway Number (RGN), Routing Gateway Index (RGI), Routing Gateway Node Identification (RGID), Payload Data (PD), and Cyclical Redundancy Check (CRC).

[0097]

SOT	MT	MSN	ML	MDT	RSN	RSID	RSM	RDID	RGI	RGID	PD	CRC

[0098] The non-routed protocol frame is nearly identical except for does not include the RGID.

[0099]

SOT	MT	MSN	ML	MDT	RSN	RSID	RSM	RDID	RGI	PD	CRC

[0100] The following have an example of the Protocol Frame Element Definitions:

[0101]

	Descrip-
Element	tion	Length	Range	Comments
SOT	Start of	1 byte	[0xEE]	Constant Value
	Transmis-
	sion
MT	Message	1 byte		See below
	Type
MSN	Message	1 byte	[0x00-0xFF]	Message originator
	Sequence			connection depen-
	Number			dent incremental
				message identifi-
				cation number.
ML	Message	1 byte	[0x00-0xFF]	Device Dependent
	Length
MDT	Message	4 bytes	[0x00000000-	Message Date
	Date		0xFFFFFFFF]	Time Stamp
	Time
RSN	Routing	1 byte		Reserved for
	Source			future use.
	Node
	Information
RSID	Routing	4 bytes	[0x00000000-	Message originator
	Source		0xFFFFFFFF]	unique unsigned
	Node			long identifi-
	Identifi-			cation number.
	cation
RSM	Routing	4 bytes	[0x00000000-	Message filtering
	Subnet		0xFFFFFFFF]	mask
	Mask
RDID	Routing	4 bytes	[0x00000000-	Message destina-
	Destination		0xFFFFFFFF]	tion unique
	Node			unsigned long
	Identifi-			identification
	cation			number.
RGI	Routing	1 byte	[0x00-0xFF]	High nibble RGN.
	Gateway			Low nibble RGI.
	Information
RGN	Routing	4 bits	[0x00-0x0F]	Number of Routing
	Gateway			Gateways required
	Number			transmitting
				message from
				source node to
				destination node.
RGI	Routing	4 bits	[0x00-0x0F]	Current Routing
	Gateway			Gateway index
	Index			while transmit-
				ting message from
				source node to
				destination node.
RGID	Routing	4 bytes		Routing Source
	Gateway	* RGN		Identification
	Node			Number of each
	Identifi-			Routing Gateway
	cations			along path from
				source node to
				destination node.
PD	Payload			Payload Data is
	Data			dependent upon
				message type.
CRC	Cyclical	2 bytes	[0x00-0xFF]	CRC-16 Polynomial
	Redundancy			Mask 0x1021
	Check

[0102] According to an embodiment, the preselected protocol can support three levels of message security. Each security level is validated by an up to eight-byte security password. Each security level password byte may be any ASCII character. Each security level password is stored relevant to the routing source identification number. For the purpose of CRC calculation only, the security level password is appended to the message.

[0103] In this embodiment, the preselected protocol frame Message Type element is a bit-significant field and includes the following elements: Security Level (SL), Message Type (MT), Read or Write Direction Flag (R#/W), and Acknowledgement Flags (ACK).

[0104]

	SL	MT	R#/W	ACK

The following are an example of Message Type Byte Element Definitions:

[0105]

Element	Description	Length	Range	Comments
SL	Security	2 bits	[0x00-0x03]	0x00: None
	Level			0x01: Security
				Level 1
				0x02: Security
				Level 2
				0x03: Security
				Level 3
MT	Message	3 bits	[0x00-0x07]	See section 3.2:
	Type			Message Type
				Definition
R#/W	Read or	1 bit	[0x00-0x01]	0x00: Read
	Write			0x01: Write
	Direction
	Flag
ACK	Acknowl-	2 bits	[0x00-0x03]	0x00: Send/
	edgement			Negative
	Flags			Acknowledge
				0x01: Acknowledge
				Send
				0x02: Response
				0x03: Acknowledge
				Response

[0106] In an embodiment, when a master application directly addresses a slave application (non-routing), the slave application processes the message type specified action and responds by setting the acknowledge binary code to ‘Response’ (0x02) within the message type frame element. When a master application addresses a slave application via routing, the first gateway node will route the message to the next gateway node and respond to the master application by setting the acknowledge binary code to ‘Ack Send’ (0x01) within the message type frame element. When the destination node receives the routed message, the destination node processes the message type specified action and responds by setting the acknowledge binary code to ‘Response’ (0x02) within the message type frame element. If the message fails to respond from the destination node, the gateway node of last transmission will originate and route the return message to the source node by setting the acknowledge binary code to ‘Send/Negative Acknowledge’ (0x00) within the message type frame element.

[0107] In an embodiment, the following preselected protocol message types, for example, can be supported:

[0108]

Message	Message Type	Read	Write	Security
Type	Description	Supported	Supported	Level
0x00	Control	Yes	Yes	0x00-0x03
0x01	Control Route	Yes	Yes	0x00-0x03
0x02	Control Broadcast	Yes	Yes	0x00-0x03
0x03	Reserved	—	—	—
0x04	Configuration	Yes	Yes	0x02-0x03
0x05	Reserved	—	—	—
0x06	12C	Yes	Yes	0x03
0x07	Diagnostic	Yes	No	0x03

[0109] The preselected protocol frame element includes a payload data section. The payload data section of the message packet sent from master application to slave application contains information that the master application uses to take the action defined by the message type. The payload data section of the message packet may be nonexistent (of zero length) in certain kinds of requests. In such case the slave application does not require any additional information. The message type in this instance specifies the action. The following details the payload data requirements for each of the supported message types. Data registers are referenced by control type and control index. For example: To reference the first analog input point the control type would be 0x02 and the control index would be 0x00.

Examples of Control Data Types are as follows:

[0110]

Control Data	Control
Type	Description	Data Type	Data Range
0x00	Discrete Input	Byte	[0x00-0x01]
0x01	Discrete Output	Byte	[0x00-0x01]
0x02	Analog Input	Unsigned Integer	[0x00-0xFFFF]
0x03	Analog Output	Unsigned Integer	[0x00-0xFFFF]
0x04	Date Time	See below
0x05	Counter	Unsigned Log	[0x00-0xFFFFFFFF]
0x06	Reserved
0x08	Reserved
0x09	Reserved
0x10	History Record	See below
0x11	Event Record	See below

[0111] Discrete Control Data Types 0x00 and 0x01 are packed into bytes. As understood by those skilled in the art, a master query must divide the requested point index by 0x08 to obtain the proper control data index. For example: A master query for the status of discrete input 0x09 must request control data type 0x00 and index 0x01. The slave response data value bit 1 will contain the status of discrete input 0x09.

[0112] The most significant bit of the Control Data Type is an exception response flag. For example: if a control message requests an index that is not supported by the slave device, the slave device response will echo the requested data type and set the most significant bit. The byte following the control index will be a single byte Control exception code regardless of data type. Control exception codes are defined below. The Control Date Time data type can be defined as the number of seconds from the host server reference date and time. The Control History Record data type is defined as the following:

[0113]

		Control
Offset	Description	Data Type	Data Type	Comment
0x00	Data Time	Control	Unsigned	Control date time
	Stamp	Date Time	Long	stamp of stored
				data value
0x04	Data Value	Control	Byte	Control data type of
	Type	Data Type		stored data value
0x05	Data Value	Control	—	Control Data value
		Data Value

[0114] The Control Event Record data type can be defined as the following:

[0115]

		Control	Data
Offset	Description	Data Type	Type	Comment
0x00	Data Time	Control Date	Unsigned	Control date time
	Stamp	Time	Long	stamp of stored
				data value
0x04	Event Type	Event Type	Byte	Event Type Code
	Code			Reserved
				Always 0x00.
0x05	Data Value	Control Data	Byte	Control data type of
	Type	Type		stored data value
0x06	Data Old	Control Data	—	Control data old
	Value	Old Value		value
—	Data New	Control Data	—	Control data new
	Value	New Value		value

[0116] The Control exception codes can include the following:

[0117]

Control Exception Codes
Code	Name	Meaning
0x00	ILLEGAL	The requested operation to perform on the
	FUNCTION	referenced data type is not supported by the
		end device or not permitted due to security
		level access.
0x01	ILLEGAL	The data type received in the query is not
	DATA TYPE	an allowable type for the slave device.
0x02	ILLEGAL	The data index received in the query is not
	DATA INDEX	an allowable index for the slave device.
0x03	ILLEGAL	The value contained in the query data field is
	DATA VALUE	not an allowable value for the slave device.
0x04	SLAVE DEVICE	The slave device is engaged in processing a
	BUSY	long-duration program command. The master
		device should retransmit the message later
		when the slave device is free.
0x05	SLAVE DEVICE	An unrecoverable error occurred while the
	FAILURE	slave device was attempting to perform the
		requested action.

[0118] As shown in FIGS. 13-14, in an embodiment, the control message type includes a control read and a control write message type. The control read message type is used to read data registers from a slave device. Read access to data registers is dependent upon security level as defined as follows:

[0119]

Control	Control		Security
Data Type	Description	Data Type	Levels
0x00	Discrete Input	Byte	0x00-0x03
0x01	Discrete Output	Byte	0x00-0x03
0x02	Analog Input	Unsigned Integer	0x00-0x03
0x03	Analog Output	Unsigned Integer	0x00-0x03
0x04	Date Time	See above	0x02-0x03
0x05	Counter	Unsigned Long	0x01-0x03
0x06	Reserved	—	—
0x07	Reserved	—	—
0x08	Reserved	—	—
0x09	History Record	See above	0x01-0x03
0x10	Event Record	See above	0x01-0x03

[0120] In an embodiment, the payload data element of the control read message frame includes a master and a slave. The master can include the elements of:

[0121]

	COUNTN	CT1	CI1	. . .	CTN	CIN

where for each requested data value N, the control read message from the master must designate the control data type and control data index.

[0122] The slave can include the elements of:

[0123]

COUNTN	CT1	CI1	CV1	. . .	CTN	CIN	CVN

where for each requested data value N, the control read message response from the slave must designate the control data type, control data index, and control data value.

[0124]

Element	Description	Length	Range	Comment
COUNTN	Point	1 byte	[0x00-0xFF]	Slave Device Message
	Quantity			Length Dependent
CTI	Control Data	1 byte		See above
	Type
CII	Control Data	1 byte	[0x00-0xFF]	Slave Device
	Index			Dependent
CVI	Control Data			See above
	Value

[0125] In this embodiment, the control write message type is used to write values to data registers in a slave device. Write access to data registers is dependent upon security level as defined as follows:

[0126]

Control	Control		Security
Data Type	Description	Data Type	Levels
0x00	Discrete Input	Byte	Exception Code
			0x00
0x01	Discrete Output	Byte	0x01-0x03
0x02	Analog Input	Unsigned Integer	Exception Code
			0x00
0x03	Analog Output	Unsigned Integer	0x01-0x03
0x04	Date Time	See Control Date Time	0x02-0x03
		structure definition
0x05	Counter	Unsigned Long	0x02-0x03
0x06	Reserved
0x07	Reserved
0x08	Reserved
0x09	History Record	See Control History	Exception Code
		Record structure	0x00
		definition
0x10	Event Record	See Control Event	Exception Code
		Record structure	0x00
		definition

[0127] In an embodiment, the payload data element of the control write message frame includes a master and a slave. The master can include the elements of:

[0128]

COUNTN	CT1	CI1	CV1	. . .	CTN	CIN	CV1

where for each requested data value N, the control write message from the master must designate the control data type, control data index, and control data value.

[0129] The slave can include the elements of:

[0130]

	COUNTN	CT1	CI1	. . .	CTN	CIN

where for each requested data value N, the control write message response from the slave must acknowledge the control data type and control data index.

[0131]

Element	Description	Length	Range	Comments
COUNTN	Point	1 byte	[0x00-0xFF]	Slave Device Message
	Quantity			Length Dependent
CTI	Control Data	1 byte	See above: Control Data Types
	Type
CII	Control Data	1 byte	[0x00-0xFF]	Slave Device
	Index			Dependent
CVI	Control Data	•	See above: Control Data Types
	Value

[0132] This embodiment includes a Control Route message type, defined for increased efficiency of network bandwidth by allowing the collection of intermediate routing gateway data while acquiring end node data. Data types, exception codes, and security codes for the Control Route message types are defined with the Control message type.

[0133] The Control Route message type includes a Control Route Read and a Control Route Write message type. The control route read message type is used to read data registers from a slave device and each routing gateway node.

[0134] The payload data element of the control route read message frame also includes a master and a slave. The master can include the elements of:

[0135]

	COUNTN	CT1	CI1	. . .	CTN	CIN

where for each requested data value N, the control read message from the master must designate the control data type and control data index.

[0136] The slave can include the elements of:

[0137]

COUNTN*X	CT1	CI1	CV1	. . .	CT11	CI11	CV11	. . .	CTNX	CINX	CVNX

where for each requested data value N, the control read message response from the slave (and each routing gateway node X) must designate the control data type, control data index, and control data value.

[0138]

Element	Description	Length	Range	Comments
COUNTN	Point	1 byte	[0x00-0Xff]	Device Message
	Quantity			Length Dependent
CTI	Control Data	1 byte	See above: Control Data Types
	Type
CIIX	Control Data	1 byte	Control Data Type for routing
	Type		gateway node X
CII	Control Data	1 byte	[0x00-0xFF]	Device Dependent
	Index
CVI	Control Data		See above: Control Data Types
	Value

[0139] The control route write message type is used to write data registers from a slave device and each routing gateway node.

[0140] The payload data element of the control route write message frame includes a master and a slave. The master can include the elements of:

[0141]

COUNTN	CT1	CI1	CV1	. . .	CTN	CIN	CV1

where for each requested data value N, the control route write message from the master must designate the control data type, control data index, and control data value.

[0142] The slave can include the elements of:

[0143]

COUNTN*(X+1)	CT1	CI1	. . .	CT11	CI11	. . .	CTN1	CIN1	CT1X	CI1X	. . .	CTNX	CINX

where for each requested data value N the control write message response from the slave (and each routing gateway node X) must acknowledge the control data type and control data index.

[0144]

Element	Description	Length	Range	Comments
COUNTN	Point	1 byte	[0x00-0xFF]	Device Message
	Quantity			Length Dependent
CTI	Control Data	1 byte	See section 4.1.1: Control Data Types
	Type
CIIX	Control Data	1 byte	Control Data Type for routing
	Type		gateway node X
CII	Control Data	1 byte	[0x00-0xFF]	Device Dependent
	Index
CVI	Control Data		See section 4.1.1: Control Data Types
	Value

[0145] An embodiment can include a Control Broadcast message type. The Control Broadcast Message Type is defined for increased efficiency of network bandwidth by allowing the collection/control of multiple end node devices. Data types, exception codes, and security codes for the Control Route message types are defined with the Control message type.

[0146] The Control Broadcast command may be routed through the network and will be transmitted from the device identified by the routing destination identification number field. When the device identified by the routing destination identification number transmits the control broadcast message, the device will use a routing destination identification number of 0x00000000. If the routing destination identification number is unknown, a routing destination identification number of 0x00000000 may be used if the routing gateway information field is 0x00.

[0147] The Control Broadcast Message Type includes a Control Broadcast Read Message Type and a Control Broadcast Write Message Type. The Control Broadcast Read Message type is used to read data registers from multiple slave devices. Slave nodes to respond to specified action are determined by the routing subnet mask.

[0148] The payload data element of the control broadcast read message frame includes a master and a slave. The master can include the elements of:

[0149]

	COUNTN	CT1	CI1	. . .	CTN	CIN

where for each requested data value N, the control broadcast message from the master must designate the control data type and control data index.

[0150] The slave can include the elements of:

[0151]

COUNTN	CT1	CI1	CV1	. . .	CTN	CIN	CVN

where for each requested data value N, the control broadcast message response from each slave must designate the control data type, control data index, and control data value.

[0152] The control broadcast write message type is used to write values to data registers in multiple slave device nodes. Slave nodes to perform specified action are determined by the routing subnet mask.

[0153] The payload data element of the control broadcast write message frame includes a master and a slave. The master can include the elements of:

[0154]

COUNTN	CT1	CI1	CV1	. . .	CTN	CIN	CVN

where for each requested data value N, the control broadcast write message from the master must designate the control data type, control data index, and control data value.

[0155] The slave can include the elements of:

[0156]

	COUNTN	CT1	CI1	. . .	CTN	CIN

where for each requested data value N the control broadcast write message response from the slave (primary only) must acknowledge the control data type and control data index.

[0157] Embodiments of the present invention also provide an automated meter reading network system 30 having a plurality of utility meters each one positioned remote from the other ones of the plurality of utility meters, e.g., electric 72, water 74, gas 76, or other usage (FIG. 9), a plurality of sensors (not shown) interfaced with each of the plurality of meters so that at least one of the plurality of sensors interfaces with and is positioned adjacent at least one of the plurality of meters to, thereby sense utility usage data from each of the plurality of meters, a communication network 32, a plurality of meter data collectors 41 positioned to collect utility usage data from each of the plurality of sensors so that at least one of the plurality of meter data collectors 41 is positioned adjacent at least one of the plurality of utility meters and in communication with at least one of the plurality of sensors which interfaces with the at least one of the plurality of utility meters, the plurality of meter data collectors 41 also being adapted to be positioned in communication with each other through the communication network 32 so that each of the plurality of meter data collectors 41 defines a communication node 41 in the communication network 32 and the plurality of meter data collectors 41 define a plurality of communication nodes 41 in the network 32, and a host computer (e.g. primary host computer 61) positioned remote from the plurality of meter data collectors 41 at a utility central station 60 and in communication with each of the plurality of communication nodes 41 in the communication network 32 so that each one of the plurality of communication nodes 41 are adapted to communicate with other ones of the plurality of communication nodes 41 in the communication network 32 to thereby reduce line-of-site communication problems between each of the plurality of communication nodes 41 and the host computer 61.

[0158] Additionally, the system 30 can also have each of the plurality of meter data collectors 41 including a collector transceiver 44 positioned to transmit data to the host computer 61 and to other ones of the plurality of meter data collectors 41 through the communication network 32 and to receive data from the computer 61 and from the other ones of the plurality of meter data collectors 41 through the communication network 32, and a collector controller 43 positioned to control collecting of utility usage data and the transmitting and receiving of data to and from the collector transceiver 44. The host computer 61, for example, can include a host transceiver (not shown) positioned to transmit data to and receive data from each of the plurality of communication nodes 41 and a host controller (not shown) positioned to control collecting of utility usage data from each of the plurality of communication nodes 41, transmitting data to each of the plurality of communication nodes 41 through the host transceiver, and receiving data from each of the plurality of communication nodes 41 through the host transceiver. Each collector controller 43 of the plurality of meter data collectors 41 and the host controller can include controller software associated with the respective controller and having a network data communication protocol. The network data communication protocol includes a preselected application layer, and the communication network 32 comprises a radio frequency communication network. The radio frequency communication network has a frequency acceptable to the Federal Communication Commission or other regulatory agency as desired. For example, the frequency can be in the range of 850-1000 mega-hertz or 2.4-5.8 giga-hertz. The frequency can advantageously continuously change between a plurality of different preselected frequencies to thereby define frequency hopping. The controller software of the host controller initiates polling of the plurality of communication nodes 41 through the frequency hopping within the communications network 32, and each of the plurality of communication nodes 41 responds to the polling by the host computer 61, through the frequency hopping within the communications network 32. The network software (not shown) includes an autosequencer to initiate polling of the plurality of communication nodes 41 whereby each of the plurality of communication nodes 41 is individually attempted to be polled by the host computer 61 to determine a strength of communication signal between the host computer 61 and each of the plurality of communication nodes 41. Each of the plurality of communication nodes 41 also attempt to communicate with each other, responsive to the autosequencer, to determine a strength of communication signal between one of the plurality of communications nodes 41 and another one of the plurality of communication nodes 41, and the autosequencer further determines a communication sequence to each of the plurality of communication nodes 41 responsive to the strength of communication signal between the host computer and each of the plurality of communication nodes and responsive to the strength of communication signal between each of the plurality of communication nodes 41 to define a preferred communication sequence path to each of the plurality of communication nodes 41 from the host computer 61. The autosequencer updates the preferred communication sequence path to allow the preferred communication sequence path to vary over time.

[0159] The plurality of meter data collectors 41, for example, can include a first meter data collector 41, a second meter data collector 41 in communication with the first meter data collector 41, and a third meter data collector 41 in communication with one or both of the first and second meter data collectors 41. The first meter data collector 41 can be positioned remote from the host computer 61, to thereby have a greater signal strength than the second meter data collector 41 and the third meter data collector 41. The second meter data collector 41 can be positioned remote from host computer 61, to thereby have a greater signal strength than the third meter data collector 41, and the network software further includes a raking router (not shown) to collect meter usage data from the first meter data collector 41 responsive to polling received from the host computer 61 and to rakingly collect data from each of the second and third meter data collectors 41 responsive to the polling so that meter usage data is collected from each of the first, second, and third meter data collectors 41 responsive to polling the first meter data collector 41 and routed to the host computer 61.

[0160] At least one of the plurality of meter data collectors 41 is positioned within at least one of the following: the same housing as at least one of the plurality of utility meters (see e.g., FIG. 12), a separate housing positioned closely adjacent at least one of the plurality of utility meters, and a separate housing positioned closely adjacent a subset of the plurality of utility meters (see e.g., FIG. 9). The host computer 61 further includes memory (not shown) having a meter data collector database (not shown) associated therewith to thereby store meter collector data associated with each of the plurality of meter data collectors 41, the meter collector data including collector identification, collector physical address, and strength of signal between collectors 41.

[0161] Also, an automated meter reading network system 30 is provided according to an embodiment of the present invention. The system 30 includes a plurality of sensors (not shown) adapted to be interfaced with each of a plurality of utility meters each positioned remote from another one of the plurality of utility meters e.g., electric 72, water 74, gas 76, or other usage, so that at least one of the plurality of sensors interfaces with and is positioned adjacent at least one of the plurality of meters to thereby sense utility usage data from each of the plurality of meters, and a plurality of meter data collectors positioned to collect utility usage data from each of the plurality of sensors so that at least one of the plurality of meter data collectors is positioned in communication with at least one of the plurality of sensors. The plurality of meter data collectors 41 also is adapted to be positioned in communication with each other through the communication network 32 so that each of the plurality of meter data collectors 41 defines one of a plurality of communication nodes 41 in a communication network 32, and a host computer 61 is positioned remote from the plurality of meter data collectors 41 and in communication with each of the plurality of communication nodes 41 so that each one of the plurality of communication nodes 41 are adapted to communicate with other ones of the plurality of communication nodes 41.

[0162] The system 30 can also have each of the plurality of meter data collectors 41 including a collector transceiver 44 positioned to transmit data to the host computer 61 and to other ones of the plurality of meter data collectors 41 and to receive data from the computer 61 and from the other ones of the plurality of meter data collectors 41 and a collector controller 43 positioned to control collecting of utility usage data and the transmitting and receiving of data to and from the collector transceiver 44. The host computer 61 includes a host transceiver (not shown) positioned to transmit data to and receive data from each of the plurality of communication nodes 41 and a host controller (not shown) positioned to control collecting of utility usage data from each of the plurality of communication nodes 41, transmitting data to each of the plurality of communication nodes 41 through the host transceiver, and receiving data from each of the plurality of communication nodes 41 through the host transceiver. Each collector controller 43 of the plurality of meter data collectors 41 and the host controller include controller software (not shown) associated with the respective controller and having a network data communication protocol. The network data communication protocol includes a preselected application layer, and the communication network 32 includes a radio frequency communication network.

[0163] The radio frequency communication network has a frequency in the range of 850-1000 mega-hertz, wherein the frequency continuously changes between a plurality of different preselected frequencies to thereby define frequency hopping. The controller software of the host controller initiates polling of the plurality of communication nodes 41 through the frequency hopping within the communications network 32. Each of the plurality of communication nodes 41 responds to the polling by the host computer 61 through the frequency hopping within the communications network 32.

[0164] The network software includes an autosequencer (not shown) to initiate polling of the plurality of communication nodes 41 whereby each of the plurality of communication nodes 41 is individually attempted to be polled by the host computer 61 to determine a strength of communication signal between the host computer 61 and each of the plurality of communication nodes 41. Each of the plurality of communication nodes 41 also attempt to communicate with each other responsive to the autosequencer to determine a strength of communication signal between one of the plurality of communications nodes 41 and another one of the plurality of communication nodes 41. The autosequencer further determines a communication sequence to each of the plurality of communication nodes 41 responsive to the strength of communication signal between the host computer 61 and each of the plurality of communication nodes 41 and responsive to the strength of communication signal between each of the plurality of communication nodes 41 to define a preferred communication sequence path to each of the plurality of communication nodes 41 from the host computer 61. The autosequencer updates the preferred communication sequence path to allow the preferred communication sequence path to vary over time.

[0165] The plurality of meter data collectors 41 can include a first meter data collector 41, a second meter data collector 41 in communication with the first meter data collector 41, and a third meter data collector 41 in communication with at least one of the first and second meter data collectors 41. The first meter data collector 41 is positioned remote from the host computer 61, to thereby have a greater signal strength than the second meter data collector 41 and the third meter data collector 41. The second meter data collector 41 is positioned remote from host computer 61, to thereby have a greater signal strength than the third meter data collector 41. The network software (not shown) further includes a raking router (not shown) to collect meter usage data from the first meter data collector 41 responsive to polling received from the host computer 61, and to rakingly collect data from each of the second and third meter data collectors 41 responsive to the polling so that meter usage data is collected from each of the first, second, and third meter data collectors 41 responsive to polling the first meter data collector 41 and routed to the host computer 61. At least one of the plurality of meter data collectors 41 is positioned within at least one of the following: the same housing as at least one of the plurality of utility meters, a separate housing positioned closely adjacent at least one of the plurality of utility meters, and a separate housing positioned closely adjacent a subset of the plurality of utility meters. The host computer 61 further includes a memory (not shown) having a meter data collector database (not shown) associated therewith to thereby store meter collector data associated with each of the plurality of meter data collectors 41, the meter collector data including collector identification, collector physical address, and strength of signal between meter data collectors 41.

[0166] An embodiment of the present invention also provides a meter data collector 41 to interface with a utility meter, e.g., electric 72, water 74, gas 76, or other usage. The meter data collector 41 includes a stationary housing 47 adapted to be mounted adjacent a utility meter, a sensor (not shown) positioned to sense meter usage data from the utility meter, a high power transceiver 44 associated with the housing 47 to transmit meter usage data from the meter data collector 41 and to receive communication remote from the stationary housing 47 in a medium to high range, a collector controller 43 positioned within the housing 47 to control data communication to and from the high power transceiver 44 and to control collecting of meter usage data from the sensor responsive to a remote command, and a memory 45 positioned within the stationary housing 47 and associated with and in communication with the controller 43 to store data therein, the memory 45 including network software (not shown) to communicate the meter usage data remotely through a communication network 32. The network software can include a preselected network data communication protocol, which includes a preselected application layer, and the communication network 32 can be a radio frequency communication network. The radio frequency communication network can have a frequency in the range acceptable to the FCC such as 850-1000 mega-hertz or 2.4 to 5.8 giga-hertz and which allows the frequency to continuously change between a plurality of different preselected frequencies to thereby define frequency hopping. A remote host computer controller (not shown) can initiate polling of the meter data collector through the frequency hopping within the communications network, and the collector controller 43 responds to the polling by the host computer controller through the frequency hopping within the communications network 32.

[0167] The network software includes an autosequencer (not shown) to initiate polling by the host computer controller and to initiate polling of at least one of a plurality of communication nodes 41 whereby each of the plurality of communication nodes 41 is individually attempted to be polled by the host computer 61 to determine a strength of communication signal between the host computer 61 and each of the plurality of communication nodes 41. Each of the plurality of communication nodes 41 also attempt to communicate with each other, responsive to the autosequencer, to determine a strength of communication signal between one of the plurality of communications nodes 41 and another one of the plurality of communication nodes 41 to thereby assist in determining a preferred communication sequence path to each of the plurality of communication nodes 41 from the host computer 61. The autosequencer updates the preferred communication sequence path to allow the preferred communication sequence path to vary over time.

[0168] As shown in FIGS. 1-15E, as described above, the present invention also includes various embodiments of related methods. An embodiment of a method of collecting utility meter usage data includes sensing meter usage data from each of a plurality of utility meters, e.g., electric 72, water 74, gas 76, or other usage, positioned remote from each other, collecting utility usage data by each of a plurality of meter data collectors 41 positioned adjacent each of the plurality of utility meters, determining a preferred polling sequence route responsive to the strength of communication signal, polling each of the plurality of meter data collectors 41 by a host computer 61 positioned remote from the plurality of meter data collectors 41 to thereby determine a strength of communication signal between the remote host computer 61 and the plurality of meter data collectors 41 positioned adjacent the plurality of utility meters, and transmitting meter usage data to the host computer 61 from each of the plurality of meter data collectors 41 along the preferred polling sequence route responsive to the polling by the host computer 61. The steps of polling and determining, for example, are periodically performed to update the preferred polling sequence route over time. The plurality of meter data collectors 41 can include a first meter data collector 41, a second meter data collector 41 in communication with the first meter data collector 41, and a third meter data collector 41 in communication with at least one of the first and second meter data collectors 41, and the first meter data collector 41 is positioned remote from the host computer 61, to thereby have a greater signal strength than the second meter data collector 41 and the third meter data collector 41, the second meter data collector 41 is positioned remote from host computer 61, to thereby have a greater signal strength than the third meter data collector 41. The method can further include rakingly collecting data from each of the second and third meter data collectors 41 responsive to the polling of the first meter data collector 41 so that meter usage data is collected from each of the first, second, and third meter data collectors 41 responsive to polling the first meter data collector 41 and routing the rakingly collected meter usage data to the host computer 61.

[0169] At least one of the plurality of meter data collectors 41 is positioned within at least one of the following: the same housing as at least one of the plurality of utility meters, a separate housing positioned closely adjacent at least one of the plurality of utility meters, and a separate housing positioned closely adjacent a subset of the plurality of utility meters. The host computer 61, can include a memory (not shown) having a meter data collector database (not shown) associated therewith to thereby store meter collector data associated with each of the plurality of meter data collectors 41, the meter collector data including collector identification, collector physical address, and strength of signal between meter data collectors 41.

[0170] An embodiment of the present invention also provides a method of monitoring a utility meter, e.g., electric 72, water 74, gas 76, or other usage, mounted to a building. The method includes mounting a meter data collector 41 defining a remote collection unit 41 adjacent a utility meter mounted to a building, collecting meter data from the utility meter by the remote collection unit 41, transmitting the meter data to a router of a communication network service provider (not shown), transmitting the meter data through a communication network 80 associated with the communication network service provider, and receiving the meter data from the communication network 80 by a computer device. The remote collection unit 41 can be a first remote collection unit 41, the utility meter can be a first utility meter, and the building can be a first building, and the method further can include mounting a second remote collection unit 41 adjacent a second utility meter mounted to second building, collecting meter data from the second utility meter by the second remote collection unit 41 and transmitting the meter data from the second utility meter by the second remote collection unit 41, and transmitting the meter data of the second utility meter to the first remote collection unit 41. The meter data transmitted to the router, for example, can include meter data from the first and second remote collection units 41.

[0171] Yet another embodiment of a method of collecting utility meter data from a plurality of utility meters, e.g., electric 72, water 74, gas 76, or other usage, each mounted to a different building and each in communication with a respective one of a plurality of meter data collectors 41 defining a plurality of remote collection units 41, is also provided. The method can include transmitting utility meter data from a first remote collection unit 41 of the plurality of utility of remote collection units 41 to a second remote collection unit 41 of the plurality of collection units 41, and transmitting utility meter data of the first remote collection unit 41 and utility meter data of the second remote collection unit 41 from the second remote collection unit 41 to a host computer 61. The method can also include transmitting meter data from a third remote collection unit 41 to the first remote collection unit 41 and wherein the utility meter data of the first remote collection unit 41 includes utility meter data from the third remote collection unit 41.

[0172] Another embodiment of a method of collecting utility meter data includes positioning a meter data collector 41 defining a remote collection unit 41 having bi-directional RF data communication within a housing having a glass facing on at lest one side thereof (see FIG. 12), collecting utility meter data by the remote collection unit 41 positioned adjacent the housing, polling the remote collection unit 41 from a host computer 61 by RF data communication through the glass facing, and transmitting the collected utility meter data from the remote collection unit 41 through the glass facing to the host computer 61, responsive to the polling. The utility meter can include a first utility meter of a plurality of utility meters, and the first utility meter can be one or more of a gas utility meter 76, an electric utility meter 72, and a water meter 74. A second of the plurality of utility meters can be a different one of a gas utility meter 76, an electric utility meter 72, and a water utility meter 74. The step of collecting includes collecting utility meter data from both the first and second utility meters by the remote collection unit 41.

[0173] As shown in FIGS. 1-8, still another embodiment of a method of collecting utility meter data includes positioning a plurality of meter data collectors 41 defining a plurality of remote collection units 41 adjacent to respective one of a plurality of utility meters. Each of the plurality of utility meters is mounted to a different building. The method also includes polling each of the plurality of remote collection units 41 from a collection computer positioned remote from the plurality of remote collection units 41 and transmitting meter data from each of the plurality of remote collection units 41 to the collection computer responsive to the polling. The method can also include the collection computer being a field collection unit 51, such as, for example, another remote collection unit 41; or the collection computer being a host computer. The method can further include a host computer 61 positioned remote from and in communication with the field collection unit 51. The method additionally can include transmitting the utility meter data from the field collection unit 51 to a router of a communication network service provider, communicating the utility meter data through a communication network 80 associated with the communication network service provider, and receiving the utility meter data by a host computer 61 in communication with the communication network 80. The method still further can include a first remote collection unit 41 of the plurality of remote collection units 41 transmitting utility meter data to a second remote collection unit 41 of the plurality of remote collection units 41, the second remote collection unit 41 transmitting the utility meter data of the first and second remote collection units 41 to a third remote collection unit 41 of plurality of remote collection units 41, and the third remote collection unit 41 transmitting utility meter data of the first, second, and third remote collection unit 41 to the field collection unit 51.

[0174] For how each meter data collector 41 defining a remote collection unit operates, the device hardware, e.g., silicon integrated circuit such as Dallas Semiconductor DS2401/DS2411, provides a 6-byte unique identification number. The least significant 4 bytes of the unique identification number are utilized to determine a selected routing source identification number. The least significant 1 byte of the selected routing source identification number determines the device default frequency index within the attached array of transmit and receive settings for a transceiver such as a Chipcon 1020 bi-directional transceiver as understood by those skilled in the art. For example, as shown in FIG. 15A, if the least significant byte of the selected routing source identification number were 0x00, then the corresponding default receive frequency would be 909300000 hertz (Hz). If the least significant byte of the selected routing source identification number were 0x001, then the corresponding default receive frequency would be 924200000 Hz. In this way, for example, 256 frequencies are utilized and organized in a pseudorandom non-repeating manner, as illustrated in FIGS. 15A-15E.

[0175] As understood by those skilled in the art, the host computer 61, for example, can have server software (not shown) to initiate communication messages to each of the plurality of destination remote collection units 41. A destination remote collection unit 41, for example, can be: (1) directly connected to the host computer 61; (2) connected via radio frequency from the remote collection unit 41 directly connected to the host computer 61, or (3) connected via radio frequency for up to a preselected number, e.g., 15, radio frequency repeater remote collection units 41 to the remote collection unit 41 directly connected to the host computer 61. The communications portion of a message protocol packet can include the routing source identification number, routing source radio frequency index, routing destination identification number, routing destination radio frequency index, routing gateway node count, and up to the preselected number, e.g., 15, routing gateway identification numbers and their corresponding radio frequency indices. The communications portion of the acknowledgement packet can include the routing identification number, routing source radio frequency index, routing destination identification number, and routing destination radio frequency index. The routing source identification number identifies the remote collection unit 41 transmitting the message. The host server software, for example, can keep an internal database of the remote collection unit identification numbers and their active radio frequency indices based upon each successful communication. On startup, the host server software assigns the remote collection unit radio frequency index to the least significant byte of the unit unique address. The host server software, as understood by those skilled in the art, also can ensure non-consecutive identical frequency indices in any given communications path.

[0176] The message validation for the remote collection unit 41 can use a remote collection unit identification number to equal either the routing destination identification number or the first routing gateway identification number. The unit acknowledgment message validation can use the unit identification number to equal the routing destination identification number. Additional communication packet validation criteria include message sequence number, message type, and CRC calculations. Upon receipt of a valid message, the receiving remote collection unit 41 will increment/alter its radio frequency index and transmit an acknowledge packet to the received packet routing source identification number at the current radio frequency index. If the remote collection unit 41 was the intended destination, then after transmitting the acknowledgment packet the remote collection unit 41 will transmit the response at the incremented/altered radio frequency index. If the remote collection unit 41 was an intended receiver, but not the message destination (see, e.g., FIG. 5), after transmitting the acknowledgment packet, the remote collection unit 41 will forward the message utilizing the received packet first routing gateway frequency index. For example, the units 41 configured as receivers can shift frequencies in synchronization with the units 41 configured as transmitters as described above. The units 41, also for example, can use the same Chipcon 1020 bi-directional transceivers, or other transceivers as understood by those skilled in the art, and can be configured such that the remote collection unit receiver input bandwidth matches the hopping channel bandwidth of their corresponding remote collection unit transmitter.

[0177] As shown in FIGS. 1-8, this fixed automated meter reading network system 30 supports bi-directional communications with the capability of collection of digital and analog input data, as well as functional control, via digital output relays. The remote collection unit platform 41 monitors data, for example, from four digital inputs and two encoded inputs and transmits that data to a utility's central office via a 902-928 mega-hertz frequency hopping mesh network 32 as understood by those skilled in the art. The remote collection unit 41, for example, utilizes a medium to high range RF radio capable of communications of 1600 meters or approximately one mile and a field host unit 51 that connects the network 32 to a wireless, cable, fiber, or telephony wide area network 80. Field host units 51 (also which can be another remote collection unit 41) can reside at the municipality infrastructure level such as a sub-station, pump station, or municipal office 50. These intelligent units 51 have an embodiment of the software (not shown) of the present invention loaded and responsible for collecting interval data from the surrounding field 51 or remote 41 collection units then transmitting that data when requested by the primary host 61, located at the central office 60, in a batch format. Additional remote units 34, 35, (see FIGS. 7 and 8) can be used to bridge one set of remote field units 41 to another set of field units 41 otherwise not within communications range.

[0178] After the units 34, 35, 41, 51, are installed in the field and the primary host system 61 is in place, the software gathers a list of available field units 41, 51. This process is dynamic in nature and at its conclusion would have a complete network communications map through a communication network 80 ready to begin the job of data collection. As a mesh network 32, each unit 41 has multiple communication paths between it and the local field host unit 51, e.g., supporting up to 15 links or levels in a single path. The primary host system 61 located at the central office 60, for example, polls field units on a revolving schedule 24 hours a day, 7 days a week, 365/366 days a year. Metering data received at the host site 60 is then converted into OLE DB compatible database file formats, as understood by those skilled in the art, for input into existing customer information and billing systems. This system 30 and each remote collection unit 41, for example, allows for additional expansion of input/output as needed, including remote disconnect, appliance control for load curtailment, or outage detection to consumer value functions such as security, detection, or alarm notification. The system 30 can have a primary host 61 located at a central office 60 with connection capabilities to customer billing, and field host units 51 located through the city and connected to the fiber optic infrastructure to establish wireless communication to all available remote collection units 41. The field host units 51 establish the communication, request and store data, and pass the instructions from the primary host 61 to the remote collection units 41. The remote collection units 41, located at a customer location, such as mounted to residence or other building structure 40, can each be connected to all devices at the customer's location that are required to meet the appropriate phase requirements, such as metering aspects in phase one, community service aspects in phase two, and so forth as understood by those skilled in the art. The remote collection units 41 can collect metering data from the various meters, e.g., electric 72, water 74, gas 76, or other usage. The field host unit 51 periodically polls the remote collection unit 41 located at the customer location, e.g., approximately every 15 minutes, and receives a packet of information that includes I.D., consumption, date and time stamp, network stats, and other data, as desired. The field host unit 51 can maintain a consumption file (not shown) of all collected data received from each remote collection unit 41 in its range. The primary host 61 establishes a connection with each field host unit 51 and downloads the consumption file, process the file, and makes ready for billing as understood by those skilled in the art. The RF radio of each remote collection unit 41, field host unit 51, and/or host computer 61 preferably is a medium to high range radio as understood by those skilled in the art, e.g., preferably in a range of 1 Watt or greater. The RF radio of the field host unit 51 can establish communications 38 to far reaching remote collection units 41 and rake data back (e.g., see FIG. 4) or, directly through units 41, can establish communication links 36, 37, (e.g., see FIG. 5) and also rake data back, as desired.

[0179] In the drawings and specification, there have been disclosed a typical preferred embodiment of the invention, and although specific terms are employed, the terms are used in a descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims. The invention has been described in considerable detail with specific reference to these illustrated embodiments. It will be apparent, however, that various modifications and changes can be made within the spirit and scope of the invention as described in the foregoing specification.