>Flows are generated from reads and encoder changes. An exemplary flow is generated from two sequential reads and will include, among other fields, a start_read value and an end_read value, the difference of which is the flow delta for the time period between the two read messages. Flows are not messages received from devices 140, they are calculated by central event management system 210 from two sequential reads.

To calculate the flow from read values, central event management system 210 determines the number of dials on the meter. The number of dials determines the maximum possible read value for the meter and is used to distinguish between backflow and rollover events or forward flow and rollunder events. Rollover and rollunder occur when the read value on a meter crosses over the minimum or maximum possible read value resetting the reading. For example, on a 4-dial meter, having a start reading of 9990 and an end reading of 10 is much more likely to be a forward flow of 20 than a back flow of 9980. central event management system 21 classifies this event to be a rollover event. Rollunder is the reverse of this, and it occurs when the dials pass through 0 through backflow and end up at a very high read value. Central event management system 210 can determine the maximum read value of the meter using the number of dials.

To determine the number of dials, central event management system 210 first check if there is encoder information for the read with the dials field, for example stored within data store 124 or available from a utility system 110. If this is the case, then central event management system 210 uses this value as the dials value. If this information is not present, central event management system 210 determined the number of dials by setting dials=max(num digits(max(device reads[read value])), 4). In other words, central event management system 210 takes the maximum read value in the batch of reads, check the number of digits in the read value, and then estimates the dials to be the number of digits with a minimum of 4. Central event management system 210 calculates the maximum read value using the number of dials and uses this information as well as the read values to calculate the flow. The smallest difference is used as the most likely correct interpretation of the reads. Central event management system 210 may be further configured to identify flow anomalies and calculate estimated flow as data is received from data stream 215.

Similarly, events are also generated from reads and encoder changes. An exemplary event generated from 41 sequential reads may be used to define a leak event. The 41 sequential reads may be received, processed and stored within the event management memory 220 as the reads are received. Accordingly, the leak detection event is determined independent from traditional data mining operations that may be performed on datastore 124.

Similar to flows, events are also dependent on sequences of reads. Events indicate the occurrence of something for a certain device 140, 150 over a time period. In order to create events, central event management system 210 defines the one or more conditions which indicate an event is occurring. For example, a leak event may be defined as occurring when a first condition indicated that the flow is greater than 0 and the aggregation interval is less than or equal to the maximum supported interval for a particular meter 150 type. For anomalies and exceptions, the occurrence of an event is as simple as the presence of a certain anomaly or exception.

There are three operations which are performed on events: event creation, event updating, event ending. Each event may be defined by several key fields, such as: update date, time that the lambda created/updated/ended the event; event date range; field indicating a start and an end time for the event; event open, indicating if the event is ongoing or ended; event name: indicating the type of event; and duration seconds, indicating how long the event is. Not all fields are required. For example, ongoing events do not have an end time.

In operation, given two sequential reads, central event management system 210 create an event when the later read has the occurrence of an event and the first read does not have the occurrence. An event is updated when both reads have the occurrence of the event. Central event management system 210 ends an event when the first read has an occurrence of an event and the later read does not. Exemplary events can include indications of endpoint tampering, a read rollover, a leak event, etc.

Flows and Events are data types computed from reads and encoder changes and are subject to invalidation when new data enters central event management system 210. They are subject to invalidation when a read sequence changes. For example, out of sequence reads occur when central event management system 210 receive reads that are not at the end of our read time series. When we have one of these reads is identified, central event management system 210 need to recalculate certain flows and events. System 210 performs the recalculation by deleting the flows and events for the device and recalculating them using the new reads and encoder sequence.

Referring now to FIG. 3, a flowchart 300 illustrating a method for using central event management system 210 for real time identification of water usage violations is shown, according to an exemplary embodiment. The method may be implemented by a computer processor of the central event management system 210 and/or one or more independent data stores, such as non-utility data management systems 122 and utility data management systems 110. The computer system implementing the method may include a processor configured to implement a computer program stored in nonvolatile memory to implement the functionality described herein.

Government entities at various levels (e.g. state, city, district) may from time to time impose water usage guidelines when necessary in order to manage limited water supplies. For example, during a drought it may be necessary to limit when residential lawns can be watered. Typical rules include assigning certain days of the week or month (e.g. even-odd) to home owners based on their addresses (e.g. even-odd street numbers). Furthermore, lawn irrigation may be limited to certain times of the day (e.g. early morning, evening). Central event management system 210 may be utilized to overcome the difficulty of enforcing such guidelines using manpower-based approaches. At most, spot checks could be performed.

Central event management system 210 provides a simple and effective solution when customer information is available. Specification, customer information includes the street address of each water meter. The water usage guidelines can be translated into event conditions within central event management system 210 that detect irrigation at residential locations that violate the conditions for the given address.

Based on a detected event violation, central event management system 210 may be configured to send a message to a utility client computers 114 and/or consumer portal system 112 providing a warning notification informing them that they are violating the guidelines. The utility customer may be provided with a time and/or series of messages over a reasonable time period to remedy the situation, e.g. by reprogramming an automatic irrigation system. However, if the violation persists, central event management system 210 may be configured to note the extended violation and provide notification to utility client computers