Dynamic sensor data processing for utility systems

Abstract

The telemetry device is configured to receive data from one or more sensing devices associated with a component of the utility system. The telemetry device processes the received data by determining a range associated with values of the received data, and in response to determining that the values of the received data are within the first range, generates a first data packet having a second number of received data values, and transmits the first data packet at a first transmission interval. In response to determining that the values of the received data are within the second range, the telemetry device is configured to generate a second data packet having a second number of received data values and to transmit the second data packet at a second transmission interval.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority and benefit to U.S. Provisional Patent Application No. 63 / 450,263, filed March 6, 2023, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0003] Utility systems, such as distribution or transportation systems, typically include various sensor devices used to sense a wide range of parameters of the utility system. Typically, sensors, along with associated telemetry devices configured to receive data, are powered via batteries or other energy storage devices. Due to this dependence on the power of energy storage devices, data transmission between sensor and telemetry devices is minimized to extend the lifespan of the energy storage devices. This can result in incomplete data or data not being available in a timely manner when needed. In some cases, real-time data can be requested and sent by the telemetry unit in response to an alarm condition. However, this results in real-time data only being provided after an alarm has occurred, reducing the opportunity to resolve the situation before it develops into a condition requiring an alarm. Furthermore, traffic on the data network can be cumbersome for the infrastructure due to the large number of devices that may be present within the utility system. Therefore, when sensed parameters are below alarm levels, it is not necessary to provide real-time or near-real-time data to the utility controller. Therefore, a system that modifies the transmission of sensor data based on various sensed data levels would be beneficial in allowing maintenance or other corrective actions to be taken before an alarm condition is generated, while still optimizing battery life and network utilization for the various sensor devices and / or telemetry units within the system. Summary of the Invention

[0004] The devices, systems, and methods described herein allow data collection devices in utility systems (such as telemetry devices) to dynamically adjust the content of data packets and the transmission interval of data packets based on data received from sensors falling within one or more predetermined ranges.

[0005] In one embodiment, a telemetry device associated with a utility system is described. The telemetry device includes a communication module and one or more electronic processors in communication with the communication module. The one or more electronic processors are configured to receive data from one or more sensor devices, where the sensor devices are configured to sense one or more parameters of a component of the utility system. The electronic processors are further configured to determine a range associated with values of the received data, and in response to determining that the values of the received data are within a first range, generate a first data packet having a first number of the values of the received data, and transmit the first data packet at a first transmission interval. In response to determining that the values of the received data are within a second range, the electronic processors are further configured to generate a second data packet having a second number of the values of the received data, and transmit the second data packet at a second transmission interval. The second number of the values of the received data is greater than the first number of the values of the received data, and the second transmission interval is a shorter interval than the first transmission interval.

[0006] In one aspect of the above embodiment, the first range is a nominal value range, and the second range is an intermediate value range. The intermediate value range is between the nominal value range and an alarm range.

[0007] In another aspect, the one or more electronic processors are further configured to, in response to determining that the values of the received data are within the alarm range, generate a third packet having a third number of the values of the received data, and transmit the third data packet at an alarm transmission interval, where the alarm transmission interval is a continuous or near-continuous interval. The third data packet includes real-time or near-real-time data received from the one or more sensor devices.

[0008] In another aspect, the third data packet further includes an alarm bit.

[0009] In another aspect, the first and second data packets include an amount of the values of the received data included in the data packet and an associated transmission interval.

[0010] In another aspect, the data packets are transmitted to a central utility controller.

[0011] In another aspect, the first transmission interval is 12 hours and the second transmission interval is 6 hours.

[0012] In another embodiment, a method of processing data by a telemetry device having one or more electronic processors for performing the method is described, in accordance with some embodiments. The method includes receiving data from one or more sensor devices configured to sense one or more parameters of a component of a utility system; and determining a range associated with values of the received data. The method further includes generating a data packet based on the determined range, and transmitting the data packet at an interval based on the determined range.

[0013] In one aspect of the above embodiments, generating the data packet based on the determined range includes generating a first data packet having a first number of received data values in response to the determined range being a nominal range, and generating a second data packet having a second number of received data values in response to the determined range being an intermediate range. The second number of received data values is greater than the first number of received data values.

[0014] In another aspect, transmitting the data packet at the interval based on the determined range includes transmitting a first data packet at a first transmission interval in response to the determined range being a nominal range, and transmitting a second data packet at a second transmission interval in response to the determined range being an intermediate range. The second transmission interval is shorter than the first transmission interval.

[0015] In another aspect, generating an alert data packet having a third number of received data values in response to the determined range being an alert range, where the third number of received data values is greater than the second number of received data values. The alert data packet is transmitted at a third transmission interval, where the third transmission interval is shorter than the second transmission interval.

[0016] In another aspect, the alert data packet includes an alert bit.

[0017] In another aspect, the third transmission interval is a continuous or near-continuous interval.

[0018] In another aspect, the first data packet and the second data packet include an amount of received data values included in the data packet and an associated transmission interval.

[0019] In another embodiment, a telemetry device associated with a utility system is described. The telemetry device includes a communication module and one or more electronic processors in communication with the communication module. The one or more electronic processors are configured to receive data from one or more sensor devices, where the sensor devices are configured to sense one or more parameters of a component of the utility system. The electronic processors are further configured to determine a range associated with a value of the received data, and in response to determining that the value of the received data is within a first range, generate a first data packet having a first number of received data values and transmit the first data packet at a first transmission interval. In response to determining that the value of the received data is within a second range, the electronic processors are further configured to transmit a polling command to the one or more sensor devices at a first polling interval, receive updated data from the one or more sensor devices in response to the transmitted polling command, generate a second data packet having a second number of received data values, and transmit the second data packet at a second transmission interval. The second number of received data values is greater than the first number of received data values, and the second transmission interval is shorter than the first transmission interval.

[0020] In one aspect of the above embodiments, the first range is a nominal value range, and the second range is an intermediate value range, which lies between the nominal value range and the alarm range.

[0021] On the other hand, one or more electronic processors are also configured to, in response to determining that the value of the received data is within the alarm range, send a polling command at a second polling interval shorter than the first polling interval, receive updated data from one or more sensor devices in response to the sent polling command, generate a third data packet having a third number of received data values, and send the third data packet at an alarm transmission interval. The alarm transmission interval is a continuous or nearly continuous interval.

[0022] On the other hand, the third data packet also includes alarm bits.

[0023] On the other hand, the first data packet and the second data packet include the amount of received data value contained in the data packet and the associated transmission interval.

[0024] On the other hand, the data packets are sent to the central utility controller.

[0025] Other aspects of this technology will become apparent upon consideration of the detailed description and accompanying drawings. Attached Figure Description

[0026] Figure 1 This is a block diagram illustrating a utility system according to some embodiments.

[0027] Figure 2 This is a block diagram illustrating a utility sensing device according to some embodiments.

[0028] Figure 3 This is a block diagram illustrating a telemetry unit of a utility system according to some embodiments.

[0029] Figure 4 This illustrates the use according to some embodiments. Figure 2 A flowchart illustrating the process by which a sensing device senses data.

[0030] Figure 5 This illustrates, according to some embodiments, in Figure 3 The flowchart shows the process of data processing at the telemetry unit.

[0031] Figure 6 This illustrates, according to some embodiments, in Figure 3 A flowchart of an alternative process for processing data at the telemetry unit. Detailed Implementation

[0032] Before any embodiments of the application are explained in detail, it is to be understood that the application is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The application is capable of other embodiments and of being practiced or being carried out in various ways.

[0033] Figure 1 An example utility distribution and / or transportation system 100 is shown in accordance with some embodiments. For brevity, for the purposes of this application, the utility distribution and / or transportation system 100 will be referred to as a "utility system." The utility system 100 includes a plurality of utility components 102a-c. The utility components 102a-c can be various components associated with the utility system. For example, the utility components 102a-c can include pipes (e.g., natural gas, water, sewage, etc.), wires, transformers, substations, water treatment facilities, substations, power plants, solar panels, windmills, and / or any other components associated with the utility system. Moreover, while the system 100 shows only three utility components 102a-c, it can be appreciated that the system 100 can include more than three utility components 102a-c or less than three utility components 102a-c.

[0034] Each utility component 102a-c can have one or more sensor devices 104 associated therewith. The sensor devices 104 can be configured to sense one or more parameters associated with the particular utility component 102a-c. In some embodiments, the sensor devices 104 are coupled to existing utility components 102a-c. In other embodiments, the sensor devices 104 are integrated into the utility components 102a-c during installation or manufacturing. In some embodiments, the sensor devices 104 can include one or more sensors for detecting one or more parameters, such as those described above. For example, the sensor devices 104 can be configured to sense parameters such as methane gas saturation, fluid pressure, liquid level (or presence), gas detection, gas concentration, pressure, voltage, current, temperature, light level, corrosion, chemical presence, flow, overflow, flood, tilt, vibration, acceleration, velocity, volume, pH, conductivity, oxidation, chlorine, chlorophyll, algae, humidity, resistance, inductance, sound level, proximity, motion, air quality, total dissolved solids ("TDS"), chemical concentration, or other parameters associated with the utility system required for a given application.

[0035] In some embodiments, the sensor devices 104 can be in communication with one or more sensors or other devices. For example, the sensor devices 104 of the utility system 100 can be configured to communicate with one or more telemetry units (devices) 106. In some examples, the sensor devices 104 can be configured to receive power via the utility components 102a-c, such as via a hardwired connection. However, in other examples, the sensor devices 104 can include a power source, such as a battery or other energy storage device (e.g., supercapacitor). In further examples, the sensor devices 104 can be configured to receive power from an associated utility component 102a-c and / or an internal or external power source, depending on the given application.

[0036] As described above, the utility system 100 also includes one or more telemetry units 106. The telemetry units 106 are configured to receive data from one or more sensor devices 104, process the received data, and send the processed data to one or more other devices, such as a central utility controller 108. As will be described in greater detail, the telemetry units 106 can package the data received from the one or more sensor devices 104 based on the value of the received data. For example, in the case that the data is below a threshold (e.g., “normal”), the telemetry units 106 can only send the data once a day. However, in the case that the data is above a threshold or within a predefined range, the telemetry units 106 can change the frequency and type of data they send.

[0037] In some examples, the telemetry unit 106 is configured to communicate with one or more sensor devices 104 using one or more wireless communication protocols, such as Bluetooth, Bluetooth Low Energy (“BLE”), cellular (e.g., 3G, 4G, 5G, LTE, CDMA, TDMA, etc.), RF, Wi-Fi, LoRa, LoRaWAN, Z-wave, Thread, Zigbee, Matter, and / or any other applicable wireless communication protocol, as described in more detail below. In some examples, the telemetry unit 106 can communicate using a proprietary communication protocol. The telemetry unit 106 is also configured to communicate with other devices, such as a central utility controller 108. The telemetry unit 106 can communicate with the central utility controller 108 using the same or different wireless communication protocols used to communicate with the sensor devices 104. For example, the telemetry unit 106 can communicate with the central utility controller using a wireless communication protocol, such as Bluetooth, Bluetooth Low Energy (“BLE”), cellular (e.g., 3G, 4G, 5G, LTE, CDMA, TDMA, etc.), RF, Wi-Fi, LoRa, LoRaWAN, Z-wave, Thread, Zigbee, Matter, and / or any other applicable wireless communication protocol. While only two telemetry units 106 are shown in the system 100, it should be considered that the system can include more or fewer telemetry units 106.

[0038] As noted above, the telemetry unit can also be configured to communicate with a central utility controller 108. The central utility controller 108 can be a dedicated server system, a cloud-based controller, or the like. In one embodiment, the central utility controller 108 can communicate with one or more cloud-based platforms or internet observers. The central utility controller 108 can be configured to control and monitor various portions or all of the utility system 100.

[0039] Turning now to Figure 2 , a block diagram of a sensor device 200 is shown, in accordance with some embodiments. The sensor device 200 can be similar to the sensor devices 104 described above. Similar to the above, the sensor device 200 is configured to interface with one or more utility components, such as the utility components 102a-c described above, to monitor one or more parameters associated with the utility components and communicate data to one or more other devices, such as the telemetry unit 106, as described above.

[0040] As Figure 2As shown, the sensor device 200 includes processing circuitry 202, input / output (“I / O”) module 204, communication module 206, and one or more sensors 208. The processing circuitry 202 can include an electronic processor 210 and memory 212. The processing circuitry 202 can be communicably connected to one or more of the I / O module 204, the communication module 206, and / or the sensors 208. The electronic processor 210 can be implemented as a programmable microprocessor, application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

[0041] The memory 212 (e.g., a non-transitory computer readable medium) includes one or more devices (e.g., RAM, ROM, flash memory, hard drive storage, etc.) for storing data and / or computer code for completing or facilitating the various processes, layers and modules described herein. The memory 212 can include a database component, a rule set component, a script component, or other types of code and / or information used to support the various activities and information structures described in this application. According to an example, the memory 212 is communicably connected to the electronic processor 210 via the processing circuitry 202 and can include computer code suitable for implementing one or more of the processes described herein (e.g., by the processing circuitry 202 and / or the electronic processor 210).

[0042] In one embodiment, the memory 212 can include one or more applications, programs, or the like, such as a data packaging application 214. The data packaging application 214 can be configured to perform one or more functions or operations, such as collecting, packaging, and sending data associated with a utility component coupled to the sensor device 200, as will be described in greater detail below.

[0043] As described above, the I / O module 204 can be configured to interface directly with one or more devices, such as the utility components 102a-c. In one embodiment, the I / O module 204 can interface with one or more devices using general purpose I / O (GPIO) ports, analog inputs, digital inputs, etc. In one embodiment, the I / O module 204 can be configured to interface with a utility component, such as the utility components 102a-c, such that various parameters associated with the utility component can be provided to the sensor device 200. For example, a utility component can have one or more internal sensors, such as temperature sensors, current sensors, voltage sensors, etc., that can be communicated to the sensor device 200 via the I / O module 204. Other data, such as operational times, determined faults, location information, etc., can also be provided to the sensor device 200 via the I / O module 204. In further examples, the sensor device 200 can receive power directly from a utility component via the I / O module 204. In other embodiments, the I / O module 204 can be coupled to one or more energy harvesting devices, such as a current transformer (“CT”), which can provide energy to the sensor device 200. In one embodiment, energy received via the I / O module 204 can be stored in an energy storage device 216, such as a battery (e.g., lithium ion, lithium iron phosphate, etc.), supercapacitor, etc.

[0044] The communication module 206 can be configured to provide communication between the sensor device 200 and one or more external devices, such as the telemetry unit 106 described above. The communication module 206 can use one or more wireless communication protocols to provide communication to or from the external devices. In one embodiment, the local communication module uses Wi-Fi to provide communication to or from the external devices. However, other wireless communication protocols, such as Bluetooth, cellular (e.g., 3G, 4G, 5G, LTE, CDMA, TDMA, etc.), RF, Wi-Fi, LoRa, LoRaWAN, Z-wave, Thread, Matter, and / or any other applicable wireless communication protocol. As described above, in some examples, the communication module 206 can use a proprietary communication protocol to facilitate communication to or from one or more external devices.

[0045] The sensor device 200 can include one or more sensors 208 configured to monitor one or more aspects of the associated utility component. The sensors can include voltage sensors, current sensors, power sensors, motion sensors (e.g., inclinometers, accelerometers, etc.), light sensors (e.g., photovoltaic sensors), sound sensors, liquid level sensors, flow sensors, pressure sensors, temperature sensors, humidity sensors, gas and chemical sensors, biological sensors, leak sensors, metal sensors, motion sensors, force sensors, defect sensors, contact and non-contact sensors, and / or other sensors as needed for a given application. The sensors 208 can be configured to detect various parameters of the utility system, including parameters such as methane gas saturation, fluid pressure, liquid level (or presence), gas detection, gas concentration, pressure, voltage, current, temperature, light level, corrosion, chemical presence, flow, overflow, flood, tilt, vibration, acceleration, velocity, volume, pH, conductivity, oxidation, chlorine, chlorophyll, algae, humidity, resistance, inductance, sound level, proximity, motion, air quality, total dissolved solids (“TDS”), chemical concentration, or other parameters associated with the utility system as needed for a given application. The above sensor types and associated parameters are for exemplary purposes only, and it should be considered that additional sensor types can be used as needed for a given application.

[0046] Turning now to Figure 3 , a block diagram of a telemetry unit 300 is shown in accordance with some embodiments. The telemetry unit 300 can be similar to the telemetry unit 106 of Figure 1 , and can be used interchangeably herein. The telemetry unit 300 includes processing circuitry 302, an I / O module 304, and a communication module 306. The processing circuitry 302 can include an electronic processor 308 and a memory 310. The processing circuitry 202 can be communicably connected to one or more of the user interface module 304 and the communication module 306. The electronic processor 308 can be implemented as a programmable microprocessor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a set of processing components, or other suitable electronic processing components.

[0047] Memory 310 (e.g., a non-transitory computer readable medium) includes one or more devices (e.g., RAM, ROM, flash memory, hard disk storage, etc.) for storing data and / or computer code for completing or facilitating the various processes, layers and modules described herein. Memory 310 can include a database component, a target code component, a scripting component, or other types of code and information used in the present application. According to an example, memory 310 is communicably connected to processor 308 via processing circuitry 302 and can include computer code for (e.g., executed by processing circuitry 302 and / or electronic processor 308) executing one or more processes described herein.

[0048] In one embodiment, memory 310 can include one or more applications, programs, or the like, such as a data processing application 312. Data processing application 312 can be configured to process data received from one or more sensor devices, such as sensor device 200 described above. As will be described in greater detail, data processing application can package and send data received from sensor device 200 to various other devices, such as central utility controller 108. Data processing application 312 can package and / or send data based on one or more sensed values within the received data. For example, where the sensed values fall within a range, data processing application 312 can increase the amount or type of data sent, as well as increase the frequency at which data is sent, as will be described in greater detail below.

[0049] As described above, I / O module 304 can be configured to interface directly with one or more devices, such as sensor device 200. In one embodiment, I / O module 304 can interface with one or more devices using general purpose I / O (GPIO) ports, analog inputs, digital inputs, and the like. In further examples, telemetry unit 300 can receive power directly from an external power source via I / O module 204. In other embodiments, I / O module 204 can be coupled to one or more energy harvesting devices, such as a current transformer (“CT”), which can provide energy to telemetry device 300. In one embodiment, energy received via I / O module 304 can be stored in an energy storage device, such as a battery (e.g., lithium ion, lithium iron phosphate, etc.), super capacitor, or the like.

[0050] As described above, the communication module 306 can be configured to provide communication between the telemetry unit 300 and one or more external devices, such as one or more sensor devices 104 and / or a central controller, such as the central utility controller 108. The communication module 306 can use one or more wireless communication protocols to provide communication to or from the external devices. In one embodiment, the communication module uses Wi-Fi to provide communication to or from the sensor device 200. However, other wireless communication protocols, such as Bluetooth, cellular (e.g., 3G, 4G, 5G, LTE, CDMA, TDMA, etc.), RF, Wi-Fi, LoRa, LoRaWAN, Z-wave, Thread, Matter, and / or any other applicable wireless communication protocol. As described above, in some examples, the communication module 306 can use a proprietary communication protocol to facilitate communication with or from one or more external devices. In one embodiment, the communication module 306 is coupled to an antenna (not shown) for communicating with or from the telemetry unit 300. In some examples, the communication module 306 can be configured to use multiple communication protocols. For example, the communication module 306 can use a first communication protocol (e.g., Bluetooth, Wi-Fi, etc.) to communicate with one or more sensor devices 200 and then use a second communication protocol (e.g., cellular, WiFi, etc.) to communicate with other devices, such as the central utility controller 108.

[0051] Turning now to Figure 4 , a flowchart of a process 400 for collecting and transmitting data from a sensor device, such as the sensor device 200 described above, is shown in accordance with some embodiments. While described with respect to the sensor device 200, it should be understood that the sensor devices 104a-c can be used interchangeably herein. In one embodiment, the data packaging application 214 described above is responsible for controlling the sensor device 200 to perform the process 400. At process block 402, the sensor device 200 senses one or more parameters of the associated utility component, as described above. For example, the sensor 208 can sense one or more parameters of the associated utility component. As described above, the sensed parameters can include a variety of parameters, such as voltage, current, force, pressure, flow, etc. In some examples, the sensed parameters can include external factors related to the utility component, such as temperature, humidity, gas presence, visual data, audio data, etc. As described above, the sensor 208 can be configured to sense any parameter associated with the utility system. In some embodiments, the sensor 208 can sense the values at an interval, such as every minute. However, values less than or greater than one minute can also be considered. In other examples, the sensor 208 can sense the data in real-time.

[0052] Upon sensing the data, the sensor device 200 determines whether any of the sensed data values exceed a predetermined value at process block 404. The predetermined value can be associated with an alarm condition. The predetermined value can be programmed into the sensor at different times, such as during manufacturing. In other embodiments, the predetermined value can be provided to the sensor device 200 by a user, such as via the I / O module 204. In response to determining that a sensed data exceeds the predetermined value, an alarm message is generated and transmitted at process block 406. In some examples, the alarm message is transmitted by the communication module 306 to one or more devices, such as the telemetry unit 300. The alarm message can include an indication of the alarm (e.g., an alarm bit) and data associated with the alarm. The sensor device 200 then continues to sense data at process block 402.

[0053] In response to determining that no sensed data values exceed the predetermined threshold, the sensor device 200 packages the data at process block 408. In one embodiment, the data packaging application 214 packages the data. In one embodiment, packaging the data can include converting the data into a transmittable data packet. For example, the sensed data can be integrated into a Wi-Fi SSID packet. In other examples, the sensed data can be integrated into a Bluetooth message packet. Generally, the data is packaged for transmission over a communication protocol for communication with one or more data collection devices described above, such as the telemetry unit 300. In some embodiments, the data can be packaged to contain the most recently sensed data. In some examples, the data can be packaged as multiple values over a predefined time period, such as one minute. However, values greater than one minute or less than one minute can also be considered. In some embodiments, the sensor 208 can only update a value once per minute, but the data packaging application 214 can read the data at a faster frequency, such as once every 5 seconds. Thus, for each minute of packaged data, only a single reading change. Other data packaging schemes can also be used depending on the needs of a given application.

[0054] Upon packaging the data, the sensor device 200 checks a transmission interval time at process block 410. The transmission interval time can be a set interval between transmissions by the sensor device. In some embodiments, the transmission interval time can be one minute. However, transmission interval times greater than one minute or less than one minute can also be considered depending on the needs of a given application. In some examples, the transmission interval time can be dynamically determined based on a state of the energy storage device 216. For example, when the state-of-charge (SoC) of the energy storage device falls below a predetermined level, such as 50%, the transmission interval time can be increased to reduce energy consumption due to sending the packaged data. The above values are for example purposes only, and various other energy storage device parameters and / or thresholds can be used to modify the transmission interval time depending on the needs of a given application.

[0055] At process block 412, the sensor device 200 determines whether the transmission interval time has expired. In response to determining that the transmission time has not expired, the sensor device 200 continues to check the interval time at process block 410. In response to determining that the transmission interval time has expired, the sensor device 200 transmits the packaged data at process block 414.

[0056] Turning now to Figure 5 A process 500 for processing data at a telemetry unit, such as the telemetry unit 300, is described in accordance with some embodiments. While described with respect to the telemetry unit 300, it should be understood that the process 500 can be performed by the telemetry unit 106 described above, which can be used interchangeably. In one example, the processor 308 is configured to perform the process 500 by executing an application, such as the data processing application 312.

[0057] At process block 502, the telemetry unit 300 receives sensor data from one or more devices, such as the sensor device 200. In some embodiments, the sensor data can be received via the communication module 306. However, in other examples, the sensor data can also be received via the I / O module 304. At process block 504, the telemetry unit 300 determines whether the received sensor data falls within a first range (“Rl”). The first range can include a range of values for a sensed parameter of a given utility system component that is considered normal or nominal.

[0058] In response to determining that the received sensor data does indeed fall within the first range, at process block 506, the received data is packaged in an Rl data packet. The Rl data packet can include the sensed data values over a first time period, such as one sensed value per 24 hours. However, time periods greater than 24 hours or less than 24 hours can also be considered depending on the needs of the given application. This allows for a reduction in network traffic by limiting the amount of data in the data packet. Since the first range is associated with normal sensed data values, there is no need to provide a large and / or granular reading to the receiving device, such as the central utility controller 108. In some embodiments, the previous 24 hours of data can also be included in the Rl data packet for error checking and data redundancy. For example, in the event that the central utility controller 108 does not receive a data packet including the previous 24 hours of data, the Rl data packet will also include that data, and increase the likelihood that the data will be received by the central utility controller 108. In other embodiments, the Rl data packet can include additional data points, such as every 12 hours, 6 hours, etc. In some embodiments, the Rl data packet can include an average of the values received over the first time period. The Rl data packet can also include additional information, such as the number of data readings within the message (e.g., different sensed data values), transmission intervals, etc.

[0059] Once the received sensor data is packaged, the Rl data packet is transmitted at an Rl interval at process block 508. In one embodiment, the Rl interval is 24 hours. However, values greater than 24 hours or less than 24 hours can also be considered depending on the needs of the given application. The Rl interval is configured to reduce the energy usage of the telemetry unit 300, as well as reduce the traffic and data on a given communication network. This is particularly beneficial in large utility systems having a large number of sensors. As previously mentioned, the Rl data packet can be transmitted via the communication module 306.

[0060] In response to determining that the data is not within the first range, at process block 510, the telemetry unit 300 determines whether the data is within a second range ("R2"). The second range can include a range of values that are slightly above the normal or nominal values, but still within a non-alarm generating range. For example, when the sensed data is a methane concentration level, there can be an alarm level, such as a 10% concentration. However, values below 10% while still within the nominal range can indicate that there is a potential problem based on the value. For example, the second range can be approximately 20-40% of the alarm value. However, values greater than 40% or less than 20% can also be considered depending on the needs of the given application.

[0061] In response to determining that the received sensor data does indeed fall within the second range, at process block 512, the received data is packaged into an R2 data packet. The R2 data packet can include the sensed data values over a second time period, such as one sensed value every 12 hours. However, time periods greater than 12 hours or less than 12 hours can also be considered depending on the needs of the given application. In one embodiment, the second time period is less than the first time period. Since the second range is still associated with sensed data values that are below the alarm level, there is no need to send real-time or near real-time data to the central utility controller 108. However, as the sensed data values have increased, it is beneficial to provide more data to the central utility controller 108 at more frequent intervals. Further, the R2 packet can include data every hour over a 12 hour interval received from the sensor device 200. Thus, twelve separate data readings can be provided to the central utility controller 108 within the R2 packet. The above-described R2 packet data is for exemplary purposes only, and it should be understood that more or less data can be provided within the R2 packet depending on the needs of the given application. However, generally the amount of data included in the R2 packet is greater than the amount of data in the Rl packet.

[0062] In some embodiments, data from the previous 12 hour period can also be included in the R2 data packet for error checking and data redundancy. For example, in the event that the central utility controller 108 does not receive a data packet including data from the previous 12 hours, the R2 data packet will also include that data, and increase the likelihood that the additional data will be received by the central utility control device 108. The R2 data packet can also include additional information, such as the number of data readings (e.g., different sensed data values) within the message, the transmission interval, etc.

[0063] Once the received sensor data is packaged, the R2 data packet is sent at an R2 interval at process block 514. In one embodiment, the R2 interval is 12 hours. However, values greater than 12 hours or less than 12 hours can also be considered depending on the needs of the given application. The R2 interval is configured to reduce the energy usage of the telemetry unit 300, as well as reduce the traffic and data on a given communication network. This is particularly beneficial in large utility systems having a large number of sensors. As previously described, the R2 data packet can be sent via the communication module 306.

[0064] In response to determining that the data is not within the second range, at process block 516, the telematics unit 300 determines whether the data is within an additional range ("RA-n"), where "n" represents one or more sensed data values that are lower than the alarm value "A" and higher than the R2 value. Thus, the n range represents a range that is higher than the R2 range and lower than the alarm range ("RA"). While shown as a single range, it should be considered that there can be multiple ranges between the R2 range and the alarm range RA. The RA-n range can include a range of values that are higher than the R2 value but still within a non-alarm generating range. For example, when the sensed data is a methane concentration level, there can be an alarm level, such as a concentration of 10%. However, values lower than 10% while still within a nominal range can indicate that there is a potential problem based on the value. For example, the RA-n range can be approximately 40-70% of the alarm value. However, values greater than 70% or less than 40% can also be considered depending on the needs of the given application. Furthermore, as described above, there can be multiple ranges within the RA-n range. For example, in the above example, there can be an RA-nl range that has a value of 40-60% of the alarm value, an RA-n2 range that has a value of 60%-80% of the alarm value, and an RA-n3 range that has a value of 80%-99% of the alarm value. Thus, it should be considered that there can be multiple data ranges that have values less than the alarm value, as needed for the given application.

[0065] In response to determining that the received sensor data does fall within the RA-n range, at process block 518, the received data is packaged into an RA-n data package. The RA-n data package can include sensed data values over n time periods, such as one sensed value every 6 hours. However, time periods greater than 6 hours or less than 6 hours can also be considered depending on the needs of the given application. In one embodiment, the n time periods are less than the second time period. Furthermore, where there are multiple Rn data packages associated with different n ranges, each Rn data package associated with an n range can have a different time period. For example, an RA-nl data package can include sensed data over a 6 hour time period, an RA-n2 data package can include sensed data over a 1 hour time period, and an RA-n3 data package can include sensed data over a 30 minute time period. The above examples are merely illustrative, and it should be considered that the RA-n packages can include data over a variety of time periods depending on the needs of the given application. Generally, it is assumed that the closer the sensed data is to the alarm value, the shorter the time period of the sensed data packaged within the RA-n data package.

[0066] Since the RA-n range is still associated with sensed data values that are below the alarm level, there is no need to send real-time or near real-time data to the central utility controller 108. However, as the sensed data values have increased to be closer and closer to the alarm value, it is beneficial to provide more data to the central utility controller 108 at more frequent intervals.

[0067] In some embodiments, data from a previous time period can also be included in the R2 data packet for error checking and data redundancy. For example, in the event that the central utility controller 108 does not receive a data packet that includes data from a previous time period, the RA-n data packet will include that data to increase the likelihood that the data will be received by the central utility controller 108. The RA-n data packet can also include additional information, such as the number of data readings (e.g., different sensed data values) within the message, the transmission interval, etc.

[0068] Once the received sensor data is packaged, the RA-n data packet is sent at the RA-n interval at process block 520. In one embodiment, the RA-n interval is 6 hours. However, values greater than 6 hours or less than 6 hours can also be considered depending on the needs of a given application. Furthermore, in the event that there are multiple Rn ranges, there can be multiple RA-n intervals. For example, the RA-nl range can have a transmission interval of 6 hours, the RA-n2 range can have an interval of 1 hour, and the RA-n3 range can include an interval of 30 minutes. The above examples are merely illustrative, and it should be appreciated that the RA-n interval can be an interval as needed for a given application. Generally, we assume that the closer the sensed data is to the alarm value, the shorter the transmission interval. As previously mentioned, the RA-n data packet can be sent via the communication module 306.

[0069] In response to determining that the data is not within the RA-n range, the telemetry unit 300 determines that the received data value is within the alarm range, RA, at process block 522. The RA range includes all values that are equal to or greater than a predetermined alarm value. For example, when the sensed data is a methane concentration level, there can be an alarm level, such as a concentration of 10%. Thus, any received value that is at or above the 10% threshold is within the RA range. The above 10% threshold is merely exemplary, and it should be appreciated that various applications, utility components, etc. can have various alarm thresholds. In some embodiments, the telemetry unit 300 can determine that the data is within the RA range based on an alarm message received from the sensor device 200. The telemetry unit 300 can automatically determine that the data is within the RA range based on receiving the alarm message using an interrupt.

[0070] In response to determining that the received data is within the RA range, the telemetering unit 300 then generates an RA data packet at process block 524. The alarm packet can include the sensed values for the alarm time period, such as one sensed value per minute. In one embodiment, the alarm time period can be equal to the transmission interval of the associated sensor device 200. Thus, where the sensor device 200 has a transmission interval of one minute, the alarm time period can be equal to one minute. However, alarm time periods greater than one minute or less than one minute can also be considered. In one embodiment, the RA data packet can also include an alarm bit. The alarm bit can trigger an alarm notification or other function in response to being received at the central utility controller 108. In some embodiments, the data generated by the telemetering unit 300 for a previous data transmission can also be included in the RA data packet for error checking and data redundancy. For example, where the central utility controller 108 does not receive a data packet including the data of the previous transmission, the RA data packet will also include that data to increase the likelihood that the data will be received by the central utility controller 108. Once the received sensor data is packetized, the RA data packet is transmitted at an RA interval at process block 526. In one embodiment, the RA interval is one minute. In other embodiments, the RA interval can be a continuous or near-continuous interval. For example, the RA interval can be every 2 seconds, or at the fastest possible frequency that can be supported by the telemetering unit 300 and / or the sensing device 200. However, values greater than one minute or less than one minute can also be considered depending on the needs of a given application. In some embodiments, the RA interval can be equal to the transmission frequency of the associated sensor device 200. The RA interval provides near real-time (or real-time) data to the central utility controller 108 during an alarm condition in order to provide the central utility controller 108 with accurate, up-to-date information as the alarm occurs. In response to determining that the received data is not within the RA range, the process ends at process block 528.

[0071] The process 500 allows for data to be provided to the central utility controller dynamically before an alarm condition is reached. This allows for a reduction in traffic within the communication network while still providing relevant data to the central utility controller 108. By providing data dynamically based on sensed data values, the central utility controller 108 can perform various operations such as trend analysis or other types of analysis on the data to potentially address issues before adverse conditions occur. For example, where the sensed data is methane concentration, by receiving data more frequently as the concentration increases, the central utility controller 108 is able to generate trends or predictions that indicate that the level is increasing at a rate that is of concern. Prior to an alarm condition being reached (e.g., a concentration threshold being exceeded by a predetermined value), a work order can be generated to perform maintenance or other corrective measures. By providing more data at shorter intervals as the sensed values move closer to the alarm value, critical information is provided to the central utility controller 108 earlier than if the data transmission frequency of the telemetry unit 300 was only increased when an alarm condition occurred.

[0072] Turning now to Figure 6 An alternative process 600 for processing data at a telemetry unit, such as the telemetry unit 300, is described in accordance with some embodiments. While described with respect to the telemetry unit 300, it should be understood that the process 600 can be performed by the telemetry units 106 described above, which can be used interchangeably. In one example, the processor 308 is configured to perform the process 600 by executing an application, such as the data processing application 312. The process 600 can be used where a sensor device, such as the sensor device 200, only outputs data at long intervals without being queried and / or polled for updated data. For example, the sensor device 200 can only send data at intervals such as every two hours, one hour, 30 minutes, etc. Thus, when the data received by the telemetry unit begins to exceed a minimum / nominal threshold, the telemetry unit 300 can request that data be provided at a higher (e.g., faster) frequency to provide more updated data to the central utility controller 108.

[0073] At process block 602, the telemetry unit 300 receives sensor data from one or more devices, such as the sensor device 200, at a first data interval. The first data interval can be a standard interval for data transmission of the sensor device 200. For example, the first data interval can be one hour. However, first data interval values greater than one hour or less than one hour can also be considered. In some embodiments, the sensor data can be received via the communication module 306. However, in other examples, the sensor data can also be received via the I / O module 304. At process block 604, the telemetry unit 300 determines whether the received sensor data falls within a first range (“Rl”). The first range can include a range of values for a sensed parameter of a given utility system component that is considered normal or nominal.

[0074] In response to determining that the received sensor data does fall within the first range, at process block 606, the received data is packaged in an Rl data packet and transmitted. The Rl data packet can include only sensed data values for a first time period, such as one sensed value per 24 hours. However, time periods greater than 24 hours or less than 24 hours can also be considered depending on the needs of a given application. In other embodiments, the Rl data packet can include multiple data points for the first time period, such as one data point per hour (i.e., equal to the first data interval time value). In some embodiments, data for the previous 24 hours can also be included in the Rl data packet for error checking and data redundancy. For example, in the event that the central utility controller 108 does not receive a data packet including data for the previous 24 hours, the Rl data packet will also include that data to increase the likelihood that the data will be received by the central utility controller 108. Once the received sensor data is packaged, the Rl data packet is transmitted at an Rl interval. In one embodiment, the Rl interval is 24 hours. However, values greater than 24 hours or less than 24 hours can also be considered depending on the needs of a given application.

[0075] In response to determining that the data is not within the first range, at process block 608, the telemetry unit 300 determines whether the data is within a second range (“R2”). The second range can include a range of values that are slightly above the normal or nominal values but still within a non-alarm generating range. For example, when the sensed data is a methane concentration level, there can be an alarm level, such as a 10% concentration. However, values below 10% while still within the nominal range can indicate that there is a potential problem based on the value. For example, the second range can be approximately 20-40% of the alarm value. However, values greater than 40% or less than 20% can also be considered depending on the needs of a given application.

[0076] In response to determining that the received sensor data does indeed fall within the second range, at process block 610 the telemetry unit 300 polls the sensor device 200 to receive data at a second data interval. Generally, the second data interval is shorter than the first data interval. The second data interval can be the interval at which the telemetry unit 300 polls the sensor device 200. For example, the second data interval can equal 30 minutes. However, second data interval values greater than 30 minutes or less than 30 minutes can also be considered. Polling the sensor device 200 includes sending a polling command, such as via the communication module 306, which is then received by the sensor device 200 via the communication module 206. The polling command can include a request for data at the time of receipt of the polling command by the sensor device 200. In response to receiving the polling command, the sensor device 200 sends the currently sensed data to the telemetry unit 300 in response to receiving the command. This can allow the telemetry unit 300 to receive data more frequently in the event that the data exceeds the first range.

[0077] The received data is then packaged into an R2 data packet and sent at process block 612. The R2 data packet can include sensed data values over a second time period, such as one sensed value every 12 hours. However, time periods greater than 12 hours or less than 12 hours can also be considered depending on the needs of a given application. In one embodiment, the second time period is less than the first time period. Since the second range is still associated with sensed data values that are below the alarm level, there is no need to send real-time or near real-time data to the central utility controller 108. However, as the sensed data values have increased, it is beneficial to provide more data to the central utility controller 108 at more frequent intervals. Further, the R2 packet can include data every 30 minutes over a 12 hour interval received from the sensor device 200. In some embodiments, the R2 data packet includes all data received over the past 12 hours as described above, such as at the frequency received at the second data interval. Thus, multiple individual data readings can be provided to the central utility controller 108 within the R2 packet. The above-described R2 packet data is for example purposes only, and it should be understood that more or less data can be provided within the R2 packet depending on the needs of a given application. However, generally the amount of data included in the R2 packet is greater than the amount of data in the Rl packet.

[0078] In some embodiments, data from a previous 12 hour period can also be included in the R2 data packet for error checking and data redundancy. For example, in the event that the central utility controller 108 does not receive a data packet including data from the previous 12 hours, the R2 data packet will also include that data to increase the likelihood that the data will be received by the central utility controller 108. Once the received sensor data is packetized, the R2 data packet is transmitted at the R2 interval. In one embodiment, the R2 interval is 12 hours. However, values greater than 12 hours or less than 12 hours can also be considered depending on the needs of the given application. The R2 interval is configured to reduce the energy usage of the telemetry unit 300, as well as reduce the traffic and data on a given communication network. This is particularly beneficial in large utility systems having a large number of sensors. As described above, the R2 data packet can be transmitted via the communication module 306.

[0079] In response to determining that the data is not within the second range, at process block 614 the telemetry unit 300 determines whether the data is within an additional range ("RA-n"), where "n" represents one or more sensed data values that are lower than the alarm value "A" and higher than the R2 value. Thus, the n range represents a range that is higher than the R2 range and lower than the alarm range ("RA"). While shown as a single range, it should be considered that there can be multiple ranges between the R2 range and the alarm range RA. The RA-n range can include a range of values that are higher than the R2 value but still within a non-alarm generating range. For example, when the sensed data is a methane concentration level, there can be an alarm level, such as a concentration of 10%. However, values lower than 10% while still within the nominal range can indicate that there is a potential problem based on the value. For example, the RA-n range can be approximately 40-70% of the alarm value. However, values greater than 70% or less than 40% can also be considered depending on the needs of the given application. Further, as described above, there can be multiple ranges within the RA-n range. For example, in the above example, there can be a RA-nl range with a value of 40-60% of the alarm value, a RA-n2 range with a value of 60-80% of the alarm value, and a RA-n3 range with a value of 80-99% of the alarm value. Thus, it should be considered that there can be multiple data ranges with values less than the alarm value depending on the needs of the given application.

[0080] In response to determining that the received sensor data does indeed fall within the RA-n range, the telemetry unit 300 polls the sensor device 200 at the RA-n data interval to receive data at process block 616. Thus, the telemetry unit 300 polls the sensor device 200 at a polling frequency that is substantially equal to the RA-n data interval. Typically, the n data interval is shorter than the second data interval. For example, the RA-n data interval can be equal to 15 minutes. However, RA-n data interval values greater than 15 minutes or less than 15 minutes are also contemplated. Further, it should be appreciated that since there can be multiple RA-n ranges, there can be an RA-n data interval associated with each RA-n range. It should be appreciated that as the RA-n range is closer to the alarm value, typically the RA-n data interval for each RA-n range value is shorter. As described above, polling the sensor device 200 includes sending a polling command such as via the communication module 306. In response to receiving the polling command, the sensor device 200 sends the currently sensed data to the telemetry unit 300 in response to receiving the command. This can allow the telemetry unit 300 to receive data more frequently based on the data received by the telemetry unit 300 being within one or more RA-n ranges.

[0081] At process block 618, the received data is packaged into an RA-n data package and sent. The RA-n data package can include sensed data values over n time periods, such as one sensed value every 6 hours. However, time periods greater than 6 hours or less than 6 hours are also contemplated depending on the needs of a given application. In one embodiment, the n time periods are less than the second time period. Further, where there are multiple Rn data packages associated with different n ranges, each Rn data package associated with an n range can have a different time period. For example, the RA-nl data package can include sensed data over a 6 hour time period, the RA-n2 data package can include sensed data over a 1 hour time period, and the RA-n3 data package can include sensed data over a 30 minute time period. The above examples are merely illustrative, and it should be contemplated that the RA-n packages can include data over a variety of time periods depending on the needs of a given application. Typically, it should be assumed that the closer the sensed data is to the alarm value, the shorter the time period of the sensed data packaged within the RA-n data package.

[0082] Since the RA-n range is still associated with sensed data values that are below the alarm level, there is no need to send real-time or near real-time data to the central utility controller 108. However, as the sensed data values have increased to be closer and closer to the alarm value, it is beneficial to provide more data to the central utility controller 108 at more frequent intervals.

[0083] In some embodiments, data from previous time periods can also be included in the R2 data packet for error checking and data redundancy. For example, in the event that the central utility controller 108 does not receive a data packet including data from previous time periods, the RA-n data packet will also include that data to increase the likelihood that the data will be received by the central utility controller 108. Once the received sensor data is packaged, the RA-n data packet is sent at an RA-n interval. In one embodiment, the RA-n interval is 6 hours. However, values greater than 6 hours or less than 6 hours can also be considered depending on the needs of a given application. Further, in the event that there are multiple Rn ranges, there can be multiple RA-n intervals. For example, the RA-nl range can have a 6 hour transmission interval, the RA-n2 range can have a 1 hour interval, and the RA-n3 range can include a 30 minute interval. The above examples are merely illustrative, and it should be considered that the RA-n interval can be an interval as needed for a given application. Generally, it should be assumed that the more closely the sensed data is to an alarm value, the shorter the transmission interval. As described above, the RA-n data packet can be sent via the communication module 306.

[0084] In response to determining that the data is not within the RA-n range, at process block 620 the telematics unit 300 determines that the received data value is within an alarm range, RA. The RA range includes all values that are equal to or greater than a predetermined alarm value. For example, when the sensed data is a methane concentration level, there can be an alarm level, such as a 10% concentration. Thus, any received value that is at or above the 10% threshold is within the RA range. The above 10% threshold is merely exemplary, and it should be understood that various applications, utility components, etc. can have various alarm thresholds. In some embodiments, the telematics unit 300 can determine that the data is within the RA range based on an alarm message received from the sensor device 200. The telematics unit 300 can automatically determine that the data is within the RA range based on receiving the alarm message using an interrupt.

[0085] In response to determining that the received data is within the RA range, at process block 622 the telematics unit 300 polls the sensor device 200 to receive data at an alarm data interval. In one embodiment, the alarm data interval can be a real-time or near real-time interval. For example, the alarm data interval can be one minute. However, values greater than one minute or less than one minute can also be considered. As described above, polling the sensor device 200 includes sending a polling command, such as via the communication module 306. In response to receiving the polling command, the sensor device 200 sends the currently sensed data to the telematics unit 300 in response to the received command. This can allow the telematics unit 300 to receive real-time or near real-time data in response to determining that the received data is within the RA range.

[0086] The telemetry unit 300 then generates and sends an alarm package at process block 624. The alarm package can include sensed values for the alarm time period, such as one sensed value per minute. However, values greater than or less than one minute can also be considered. In one embodiment, the alarm data interval can be equal to the polling alarm data interval. Thus, where the telemetry unit 300 polls the sensor device 200 every minute (e.g., the alarm data interval), the alarm time period can be equal to one minute. However, alarm time periods greater than or less than one minute can also be considered. In one embodiment, the RA package can also include an alarm bit. The alarm bit can trigger an alarm notification or other function at the central utility controller 108 upon receipt of the alarm. In some embodiments, data generated by the telemetry unit 300 for a previous data transmission can also be included in the RA data package for error checking and data redundancy. For example, where a data package including data for a package transmission is not received by the central utility controller 108, the RA data package will also include that data to increase the likelihood that the data will be received by the central utility controller 108. Once the received sensor data is packaged, the RA data package is sent at an RA interval at process block 526. In one embodiment, the RA interval is one minute. However, values greater than or less than one minute can also be considered depending on the needs of a given application. In some embodiments, the RA interval can be equal to the transmission frequency of the associated sensor device 200. The RA interval provides near real-time (or real-time) data to the central utility controller 108 during an alarm condition in order to provide accurate, up-to-date information to the central utility controller 108 in the event of an alarm.

[0087] In response to the received data not being within the range RA, the process ends at process block 626.

[0088] The process 600 allows for data to be provided to the central utility controller dynamically before an alarm condition is reached. This allows for reduced traffic within the communication network while still providing relevant data to the central utility controller 108. By providing data dynamically based on sensed data values, the central utility controller 108 can perform various operations such as trend analysis or other types of analysis on the data to potentially address issues before adverse conditions occur. For example, where the sensed data is methane concentration, by receiving data more frequently as the concentration increases, the central utility controller 108 is able to generate trends or predictions that the level is increasing at a rate that is worth attention. Prior to an alarm condition being reached (e.g., the concentration threshold exceeding a predetermined value), a work order can be generated to perform maintenance or other corrective measures. By providing more data at shorter intervals as the sensed values move closer to the alarm value, critical information is provided to the central utility controller 108 earlier than if the data transmission frequency of the telemetry unit 300 was only increased when the alarm condition occurred.

[0089] With respect to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that described steps could be modified, omitted, or expanded upon. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.

[0090] Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation.

[0091] All terms used in the claims are intended to be given their broadest reasonable construction and ordinary meaning, unless the context clearly dictates otherwise. In particular, use of "and / or" means that at least one of the conjunctive phrases is required and that the conjunctive phrase does not need to be present. Also, use of "comprising" means "including, but not limited to" and "consisting of means "including and limited to."

[0092] The abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that the abstract is to be construed narrowly as to the scope of the disclosure recited in the claims. Furthermore, the abstract is not intended to be used to interpret or limit the scope or meaning of the claims. Moreover, in the above Detailed Description, various features are grouped together in single embodiments for the purpose of streamlining the disclosure. This disclosure is not to be interpreted in the limiting sense of the requirement of patentability of any single patentable embodiment. Rather, inventive subject matter is directed to each individual feature or each combination of features presented in this disclosure. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate disclosed subject matter.

Claims

1. A telemetry device associated with a utility system, comprising: a communication module; and one or more electronic processors in communication with the communication module, the one or more electronic processors configured to: receive data from one or more sensor devices, wherein the sensor devices are configured to sense one or more parameters of a component of the utility system, determine a range associated with values of the received data, in response to determining that values of the received data are within a first range, generate a first data packet having a first number of the received data values and send the first data packet at a first transmission interval, and in response to determining that values of the received data are within a second range, generate a second data packet having a second number of the received data values and send the second data packet at a second transmission interval, wherein the second number of received data values is greater than the first number of received data values; and wherein the second transmission interval is a shorter interval than the first transmission interval.

2. The telemetry device of claim 1, wherein the first range is a nominal value range and the second range is an intermediate value range, the intermediate value range being between the nominal value range and an alarm range.

3. The telemetry device of claim 1, wherein the one or more electronic processors are further configured to: in response to determining that values of the received data are within an alarm range, generate a third packet having a third number of the received data values; and send the third data packet at an alarm transmission interval, wherein the alarm transmission interval is a continuous or near-continuous interval; wherein the third data packet comprising real-time or near-real-time data received from the one or more sensor devices.

4. The telemetry device of claim 3, wherein the third data packet further comprises an alarm bit.

5. The telemetry device of claim 1, wherein, the first data packet and the second data packet comprising an amount of received data values contained in the data packet and an associated transmission interval.

6. The telemetry device of claim 1, wherein the data packets are sent to a central utility controller.

7. The telemetry device of claim 1, wherein the first transmission interval is 12 hours and the second transmission interval is 6 hours.

8. A method for processing data by a telemetry device having one or more electronic processors for performing the method, the method comprising: receiving data from one or more sensor devices, the sensor devices configured to sense one or more parameters of a component of a utility system; determining a range associated with values of the received data; generating a data packet based on the determined range; and sending the data packet at an interval based on the determined range.

9. The method of claim 8, wherein generating a data packet based on the determined range comprises: in response to the determined range being a nominal range, generating a first data packet having a first number of the received data values; and generating a second data packet having a second number of received data values in response to the determined range being an intermediate range, wherein the second number of received data values is greater than the first number of received data values.

10. The method of claim 9, wherein, sending the data packets at intervals based on the determined range includes: sending the first data packet at a first transmission interval in response to the determined range being the nominal range; and sending the second data packet at a second transmission interval in response to the determined range being the intermediate range, wherein the second transmission interval is shorter than the first transmission interval.

11. The method of claim 9, further comprising: generating an alert data packet having a third number of received data values in response to the determined range being an alert range, wherein the third number of received data values is greater than the second number of received data values; and sending the alert data packet at a third transmission interval, wherein the third transmission interval is shorter than the second transmission interval.

12. The method of claim 11, wherein the alert data packet includes an alert bit.

13. The method of claim 12, wherein the third transmission interval is a continuous or near-continuous interval.

14. The method of claim 9, wherein, the first data packet and the second data packet include an amount of received data values included in the data packet and an associated transmission interval.

15. A telemetry device associated with a utility system, comprising: a communication module; one or more electronic processors in communication with the communication module, the one or more electronic processors configured to: receive data from one or more sensor devices, wherein the sensor devices are configured to sense one or more parameters of a component of the utility system, determine a range associated with values of received data, in response to determining that values of received data are within a first range, generate a first data packet having a first number of received data values and send the first data packet at a first transmission interval, and in response to determining that values of received data are within a second range: send a polling command to the one or more sensor devices at a first polling interval, in response to the sent polling command, receive updated data from the one or more sensor devices, generate a second data packet having a second number of received data values, and send the second data packet at a second transmission interval, wherein the second number of received data values is greater than the first number of received data values; and wherein the second transmission interval is a shorter interval than the first transmission interval.

16. The telemetry device of claim 15, wherein the first range is a nominal value range and the second range is an intermediate value range, the intermediate value range being between the nominal value range and an alert range.

17. The telemetry device of claim 15, wherein the one or more electronic processors are further configured to: in response to determining that values of received data are within an alert range: send the polling command at a second polling interval that is shorter than the first polling interval; receiving updated data from the one or more sensor devices in response to the transmitted poll command; generating a third data packet having a third number of received data values; and transmitting the third data packet at an alarm transmission interval, wherein the alarm transmission interval is a continuous or near-continuous interval.

18. The telemetry device of claim 17, wherein the third data packet further comprises an alarm bit.

19. The telemetry device of claim 15, wherein, The first data packet and the second data packet comprise an amount of received data values included in the data packet and an associated transmission interval.

20. The telemetry device of claim 15, wherein the data packets are transmitted to a central utility controller.

Images