Utility meters that support remote display

Abstract

The method described herein is performed by a utility meter without an integrated display. The method includes measuring resource consumption and further generating consumption data based on measuring the resource consumption. The utility meter wirelessly connects directly to an external device having a display via a communication device. The utility meter verifies that the external device is authorized to access the utility meter. The utility meter transmits the consumption data to the external device and uses the display of the external device as an interface to the utility meter. The utility meter receives instructions via manual entry on the display of the external device, and the utility meter executes the instructions.

Description

[Technical Field]

[0001] The embodiments described herein relate to utility meters, and more particularly to utility meters that support remote (ie, non-integrated) displays. [Background technology]

[0002] Generally, a utility meter measures the consumption of a resource such as electricity, water, or gas. Typically, the utility meter is installed on or near a premises to measure consumption at the premises. The utility meter is typically provided by a service provider, who manages the utility meter as needed to ensure that the utility meter is fully operational and accurately measures consumption. In some cases, the utility meter has an integrated radio, thereby participating in a wireless mesh network. Through the wireless mesh network, the utility meter communicates with multiple utility meters and reports consumption to a remote, centralized head-end system that serves the multiple utility meters. Because consumers are billed based on the consumption measured by the utility meter, a high level of accuracy is required in measuring and reporting consumption.

[0003] Existing utility meters typically utilize microcontrollers, which have a central processing unit integrated with random access memory (RAM) and read-only memory (ROM) on a single chip. Firmware installed on the hardware performs operations such as collecting and reporting consumption data. Due to the limited storage space available on utility meters, the firmware is monolithic, with most or all aspects of the meter's functionality coded into and interdependent on each other.

[0004] Utility meters also include displays that are convenient for providing data to technicians or for reporting data locally, where maintenance is typically performed locally, with technicians reading displays integrated with the utility meter or attaching physical tools to the utility meter to perform service. Summary of the Invention

[0005] In one embodiment, the method described herein is performed by a utility meter without an integrated display. The method includes measuring resource consumption and further generating consumption data based on measuring the resource consumption. The utility meter wirelessly connects directly to an external device having a display via a communication device. The utility meter verifies that the external device is authorized to access the utility meter. The utility meter transmits the consumption data to the external device and uses the display of the external device as an interface to the utility meter. The utility meter receives instructions via manual entry on the display of the external device, and the utility meter executes the instructions.

[0006] In another embodiment, the system includes a utility meter without an integrated display. The utility meter includes a metering engine and a communications device. The metering engine measures resource consumption and generates consumption data based on the resource consumption measurements. The communications device wirelessly connects the utility meter directly to an external device having a display, and the utility meter verifies that the external device is authorized to access the utility meter. The communications device transmits the consumption data to the external device and utilizes the display of the external device as an interface to the utility meter. The utility meter receives instructions via manual entry on the display of the external device, and the utility meter executes the instructions.

[0007] In yet another embodiment, a computer program product for receiving and executing instructions in a utility meter without a display includes a computer-readable storage medium having program instructions embodied thereon. The program instructions are executable by a processor of the utility meter to cause the processor to perform a method. The method includes measuring resource consumption and further generating consumption data based on measuring the resource consumption. The method further includes directly and wirelessly connecting the utility meter to an external device having a display. The method further includes verifying that the external device is authorized to access the utility meter. The method further includes transmitting the consumption data to the external device and utilizing the display of the external device as an interface to the utility meter. The method further includes receiving instructions via manual entry on a display of the external device and executing the instructions.

[0008] This exemplary embodiment is mentioned not to limit or define the disclosure, but to provide an example to aid in understanding the invention. Further embodiments are discussed in the detailed description, and further description is provided therein. [Brief explanation of the drawings]

[0009] These and other features, aspects, and advantages of the present disclosure will be better understood from the following detailed description when read in conjunction with the accompanying drawings.

[0010] [Figure 1] FIG. 1 is a diagram of an example hardware configuration of a utility meter according to some embodiments described herein. [Figure 2] FIG. 2 is another diagram of an example hardware configuration of a utility meter according to some embodiments described herein. [Figure 3] FIG. 1 is a diagram of an example hardware and software configuration of a utility meter according to some embodiments described herein. [Figure 4]FIG. 2 is a diagram of another example hardware and software configuration of a utility meter according to some embodiments described herein. [Figure 5] 1 illustrates an example of a meter wirelessly connected to an external device according to some embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0011] Current utility meter hardware and firmware have several drawbacks. The single microcontroller unit (MCU) used in most utility meters does not allow for true multithreading to efficiently run complex applications. Furthermore, the firmware is a single piece of code for all meter operations. The code may contain portions that perform various tasks, but those portions are interdependent within the firmware. As a result, firmware upgrade times are long because each firmware upgrade affects all operations represented in the firmware code. If the code becomes corrupted, the corruption affects the entire utility meter, not just a single function.

[0012] However, according to some embodiments described herein, the utility meter has a multiprocessor configuration utilizing a microprocessing unit (MPU) coupled to (i.e., in communication with) an additional metering processor. The MPU may have multiple cores. The metering processor may be an MCU and is configured to operate time-critical metering functions in real time while the MPU executes various applications using multithreading or multiprocessing. In some embodiments, the metering processor executes a real-time operating system to ensure real-time processing of the metering functions. Applications for functions other than the primary metering function may run on the MPU, but the MPU need not have a real-time operating system or mandatory real-time operability. Some embodiments of the utility meter include additional MCUs or other processors to support other real-time operations, such as network communications.

[0013] Additionally or alternatively, according to some embodiments described herein, the utility meter lacks an integrated display, such as a liquid crystal display (LCD) screen. Rather than including its own display, the utility meter is connectable to a smartphone or other device. The utility meter is configured to transmit data describing consumption data, utility meter operation, or other data to the smartphone or other device, allowing a user to view such data on the smartphone or other device.

[0014] The embodiments of utility meters, also referred to as meters, described herein offer various technical advantages over conventional utility meters. By incorporating multiple cores in the MPU, instruction processing speed can be increased, e.g., 4-12 times. By utilizing additional memory in addition to the memory built into the MCU, memory capacity can be increased, e.g., by more than two times. In some embodiments, individual applications can be installed. This modularity supports the creation of independent applications, which can be selectively used across utility meters so that each utility meter is configured in a customized manner. More specifically, in some embodiments, a utility meter can be tailored with applications for the specific use of that utility meter. In some embodiments, the utility meter architecture allows applications to be deployed as needed after the utility meter is commissioned. Furthermore, the modularity of applications on a utility meter allows users to write, modify, or install their own applications for custom management of the utility meter. For example, a user can install applications for operating, processing, or managing the meter, or metering data generated or collected by the meter.

[0015] As a result, in some embodiments, while real-time functionality is still supported in some embodiment utility meters, the utility meter can also have broader and more complex functionality that runs efficiently on a high-performance MPU that acts as the application engine, where each application is individually upgraded, installed, or uninstalled as needed. The utility meter embodiments described herein provide a more robust platform for standard protocols, interfaces, and new or custom functionality. The hardware and software described herein together provide a feature set that is scalable, secure, and easily maintained.

[0016] Meter embodiments described herein enable powerful decision-making and the redistribution of tasks within a network of meters and other nodes. For example, traditionally, meters report consumption to other nodes in the network, which ultimately delivers it to a head-end system that makes centralized decisions. However, according to some embodiments, meters can include appropriate intelligence, in the form of hardware or software applications described herein, to make decisions themselves. For example, and not by way of limitation, meters described herein may monitor power quality and take corrective action. In this manner, meter embodiments provide edge intelligence that can reduce network communication overhead, reduce bottlenecks between endpoints and head-end systems, or reduce workload on head-end systems or other nodes. Utilizing a fleet of meters described herein connected via a network may enable distributed intelligence, such that a centralized source (e.g., a head-end system) no longer needs to be responsible for all or most of the analysis and decision-making.

[0017] FIG. 1 is a diagram of an exemplary hardware configuration of a utility meter 100, according to some embodiments of the present invention. The utility meter 100, also referred to herein as meter 100, is used to measure consumption of one or more resources, such as electricity, water, or gas. In some embodiments, the meter supports a metering function (e.g., consumption measurement) while supporting software applications that utilize data generated by the metering function, potentially in addition to other applications. As shown in FIG. 1 , in some embodiments, the meter 100 includes one or more of a metering engine 105 for performing primary metering functions, an MPU 110 having one or more cores, memory 120, and storage 130, which may be connected together by a system bus 101. Peripheral devices 145 may be built into the meter 100 or connected via spare slots, for example. In some embodiments, a communication bus 140 also integrates one or more peripheral devices 145, including one or more communication devices 150, into the meter 100. However, it will be appreciated that communication bus 140 is not required, and that instead each peripheral device 145 is connected to MPU 110 by a respective interface, such as a software driver.

[0018] In general, in contrast to conventional meters, the embodiments of the meter 100 described herein are MPU-based, with the MPU 110 being the heart of the meter 100. In some embodiments, the time-critical functionality of the meter 100 is performed by an embedded or connected metering engine 105 or on one or more peripheral devices 145. This time-critical functionality includes, for example, the determination and wireless-based reporting of consumption data. This consumption data is data describing the amount of a resource (i.e., utility) consumed during each of various time intervals associated with consumption. More specifically, for example, meter accumulation and calculations are determined by the metering engine 105, which can perform operations in real time. By way of example and not limitation, the metering engine 105 utilizes a real-time operating system (RTOS), and the wireless functionality executes on the same or a different RTOS on the peripheral devices 145. In some embodiments, higher-level applications that are less time-critical run on the MPU 110 and do not require mandatory real-time functionality. These aspects and others are described in more detail below.

[0019] The MPU 110 has one or more cores. In some embodiments, the operating system on the MPU 110 supports multithreading, multiprocessing, or both. Additionally or alternatively, if the MPU 110 has multiple cores, each core may be responsible for a portion of the functionality within the meter. Additionally or alternatively, multiple cores may perform the same function while allowing tasks to be performed in parallel (e.g., multithreading). Examples of the use of multiple cores are described in more detail below, with particular reference to FIGS. 3 and 4.

[0020] According to some embodiments, a wide range of functions may be implemented as applications supported by the MPU 110. By way of example and not limitation, one or more of the following functions may be implemented as applications supported by the MPU 110 and therefore operate on the MPU 110: usage time enablement, loading specific profiles of how resources are consumed, cryptocurrency transactions for payments and the like, automatic power outage reporting, crowdsourcing information about utility usage, usage pattern detection, electric vehicle charging enablement or detection, solar or other renewable energy source connection enablement, solar power detection, battery management, inverter management, load control, and enablement or detection of connection to a home automation or control system.

[0021] In some embodiments, the use of the multithreaded or multiprocessing MPU 110 described herein enables a wide range of complex applications not supported by existing meters. For example, an artificial intelligence (AI) application may run on meter 100. As a result, the AI ​​may be used to process consumption data associated with the premises served by meter 100, process data received from other nodes (e.g., other meters) on the common utility grid, or process other data associated with meter 999's utility grid. For example, an AI application may run on meter 100 to process consumption data describing consumption at the premises and determine which appliances are being used at the premises based on the appliance's power signature (i.e., load balancing). In another example, an AI application may run on meter 100 to process data received from another meter to determine that the other meter has lost power. As yet another example, if meter 100 has access to control a capacitor bank, an AI application may run on meter 100 to process data related to one or more other meters on a common utility grid and make a decision about whether or when to activate a capacitor bank to control power factor based on one or more power factor measurements on one or more electric meters. Additionally or alternatively, if meter 100 does not have direct control over the capacitor bank, meter 100 may initiate activation of the capacitor bank by issuing a notification to a remote resource that can activate the capacitor bank. One or more of these or other AI functions may be embodied within an application executed by meter 100.

[0022] More specifically, in some embodiments, a machine learning (ML) model may be implemented in the meter 100 and trained to recognize occurrences such as the operation of a particular appliance, a poor power factor, or a power loss in a nearby meter 100. The ML model may be, for example, a neural network, a decision tree, a classification model, or another ML model. For example, such an ML model is trained based on training data including a set of tuples before being loaded into the utility meter. Each tuple includes (a) a feature vector (e.g., a set of features) that describes the current state of the utility meter and (b) a label that indicates an event of interest. The features may include, for example, a usage pattern of the consumption of electricity or other resources being measured. Specifically, for example, the feature vector may include a set of values ​​corresponding to the amount of resource used (e.g., kilowatt-hours) at various intervals. The labels may indicate, for example, which appliance is being used, whether the power factor is poor, or whether the meter or a nearby meter has lost power. Given the training data, the ML model learns to map the feature vector to a label. Thus, during operation of a utility meter, an ML model on the utility meter can receive as input features describing the state of the meter at a given time and can therefore predict labels such as an indication of which appliances are in use, an indication of whether the power factor is insufficient, or an indication that the meter or a nearby meter has experienced a power outage.

[0023] In some embodiments, meter 100 performs one or more tasks described above as being performed by an ML model, but does so through techniques in addition to or alternative to the use of an ML model. For example, one embodiment of meter 100 maintains a decision tree that need not be based on machine learning. Meter 100 inputs the current state of meter 100 (e.g., a feature vector describing that state) into the decision tree, and using the decision tree, meter 100 may determine an action to take. Such actions may include one or more of the above, such as sending a notification or initiating activation of a capacitor bank. It will be appreciated that a variety of techniques can be used to provide edge intelligence in meter 100.

[0024] Additionally or alternatively, some embodiments of meter 100 may run one or more virtual machine or container applications not supported by traditional utility meters. Additionally or alternatively, to run local applications, meter 100 may utilize communication device 150 to access cloud-based applications. For example, a customer using meter 100 may be associated with a private cloud within the customer's management. In this case, meter 100 may access the cloud, e.g., via a gateway, and run any applications installed in the cloud. Cloud-based applications accessible to meter 100 may include, for example, applications that perform power quality monitoring, grid topology or mapping, phase identification, AI-based functions, or energy splitting. Meter 100 may connect to the cloud via a wireless mesh network, a cellular connection, or other communication technology.

[0025] Applications may be installed on the meter 100 in a variety of ways. For example, and without limitation, applications may be installed from a remote system, such as a head-end system or cloud server, installed locally via a wired connection to the meter, or installed locally via a direct wireless connection, such as near field communication (NFC), Bluetooth, or Wireless Fidelity (WiFi). Through access to one or more virtual machines or the cloud, the meter 100 may be able to run applications that are not supported by the meter's native operating system, for example.

[0026] As shown in FIG. 1 , in one embodiment, the meter 100 includes memory 120 separate from the MPU 110. In some embodiments, the memory 120 is RAM. By way of example and not limitation, the meter hardware utilizes 1-2 gigabytes of RAM. The storage may be, for example, flash storage, and in some embodiments, at least 8 gigabytes. However, it will be understood that various other memory 120 or storage 130 may be used, and the size of such memory 120 and storage 130 may vary depending on the embodiment.

[0027] The communication device 150 of the meter 100 may include, for example, a radio frequency (RF) radio 160 to enable wireless communication, a WiFi device (not shown) to enable WiFi communication, a cellular device (not shown) to enable cellular communication, and an NFC chip 170 to enable NFC communication. In some embodiments, the meter 100 utilizes the RF radio 160 for bidirectional communication with a head-end system, such as for reporting consumption data to the head-end system or for communicating other data related to a network of meters and other devices. In some embodiments, the RF radio 160 utilizes a physical layer (PHY) and a medium access control (MAC) layer. The PHY connects the MAC to a physical medium over which data can be transmitted. In some embodiments, the MAC and PHY perform time-critical functions that must be performed in real time. Therefore, the MAC and PHY layers may be executed by an RTOS or other operating system separate from the primary operating system of the MPU 110, and thus the RF radio 160 may be embedded in a peripheral device 145 integrated with or otherwise connected to the MPU 110. In use, the WiFi device may enable networking with nearby devices, such as other meters 100 or smart devices in proximity to the meter 100. By way of example and not limitation, the meter 100 may be an Internet of Things (IoT) device, and the WiFi device may enable the meter 100 to communicate with other IoT devices.

[0028] In some embodiments, meter 100 utilizes communication device 150 to collect consumption data from external sources. For example, and without limitation, peer meters or submeters may directly measure consumption not directly measured by meter 100 itself, and meter 100 may receive consumption data from such peer meters or submeters describing such measurements. For example, a submeter may measure the power consumed to charge an electric vehicle and transmit consumption data describing that consumption to meter 100. Meter 100 may receive such consumption data, for example, via WiFi or Bluetooth, or via a wireless mesh network. In this manner, meter 100 may collect consumption data from various sources and aggregate the consumption data for billing or other purposes.

[0029] As shown in FIG. 1 , one embodiment of meter 100 includes an NFC chip 170. By way of example and not limitation, NFC chip 170 may have a range of up to 4 centimeters, approximately 4 centimeters, up to 3 feet, 3-5 feet, or various other ranges. NFC chip 170 may have various uses in meter 100. For example, NFC chip 170 may be used during meter manufacturing or configuration, allowing meter 100 to track itself during manufacturing or configuration. As described in more detail below, NFC chip 170 or other communication device may be used to communicate with a local smartphone or other external device. For example, a smartphone may connect directly to meter 100 via meter 100's NFC chip 170, thereby enabling the smartphone to display the meter's 100 user interface. Thus, the smartphone may display consumption data or other information related to meter 100 in response to demand. As described in more detail below, some embodiments of meter 100 do not include a display, a traditional component integrated into utility meters. A display-less meter 100 may be less expensive to manufacture than a utility meter with a display. The use of an NFC chip 170 allows the exemplary meter 100 to utilize an external device, such as a smartphone, in place of a traditional display. Further examples of the usefulness of a display-less meter are described in more detail below.

[0030] Each peripheral 145 can expand the functionality of the meter 100. For example, and not by way of limitation, a service tool can be installed via a spare slot, thereby becoming a peripheral 145. As another example, if hardware (e.g., RF radio 160) fails, an additional or updated version of that hardware can be connected via a spare slot and become a peripheral 145. It will be appreciated that various possible uses of peripheral 145 are supported according to embodiments of the present invention.

[0031] In some embodiments, the metering engine 105 performs time-critical functions of the meter 100, such as accumulating and calculating consumption. For example, the metering engine 105 continuously measures consumption samples and calculates the accumulated consumption over an established period of time. For example, in the case of an electricity meter, the metering engine 105 calculates the accumulated consumption in kilowatt-hours (kWh). As described in more detail below, the metering engine 105 may include a processing unit, such as an MCU, that utilizes an RTOS. The use of an RTOS guarantees a consistent response time in the hardware, thereby ensuring that the consumption data is accurately calculated. Further details of the metering engine 105 are described in more detail below.

[0032] In some embodiments, by allowing the MCU to handle real-time tasks and the MPU 110 to handle higher-level applications (i.e., non-time-critical applications), the MPU 110 can effectively support a wide range of applications. The software applications installed on the meter 100 and executed by the MPU 110 can be modularized and decoupled from the underlying firmware. As a result, the meter 100 can be a system in which a variety of non-traditional functions are implemented as applications running on the MPU without interfering with the time-critical tasks performed by the MCU.

[0033] FIG. 2 is another diagram of an exemplary hardware configuration of a utility meter 100, according to some embodiments of the present invention. As described above, the metering engine 105 performs the primary metering functions of the meter 100. As shown in FIG. 2, in some embodiments, the metering engine 105 includes a metering processor, specifically, an MCU 210 running an RTOS. The metering engine 105 may be embedded within the meter 100 and communicate with the MPU 110. However, the metering engine 105 may include a separate processor and separate memory, such that the processor and memory of the metering engine 105 have separate hardware components from the MPU 210 and the memory 120 associated with the MPU 210. For example, the MCU 210 of the metering engine 105 may include integrated memory dedicated to the metering engine 105. In one example, the MCU 210 of the metering engine 105 is a Cortex-M7 600 MHz processor with an RTOS such as Real-Time Linux. As a further example, the MPU 110 may be quad-core and capable of operating at 1.5 GHz per core, such as the exemplary MPU 110 shown in Figure 5. However, it will be understood that other types of processing units may be used in place of the MCU 210 shown in Figure 2 or in place of the MPU 110.

[0034] In some embodiments, metrology engine 105 runs on MPU 110 and does not utilize a separate processor. For example, and without limitation, a separate logical partition may be implemented within memory 120 and storage 130, and an RTOS or other configuration that performs real-time functions may be installed on this logical partition to implement metrology engine 105.

[0035] In some jurisdictions, certain aspects of the metrology process are required by law to meet specific security and data protection requirements. These requirements may require separately partitioned memory and separate processing, and embodiments of the present invention meet such requirements by using separately partitioned memory and separate processors or processing cores. Due to such requirements, special procedures must be used for firmware upgrades, security, and verification; such procedures do not need to be performed for applications running on MPU 110, but may be performed on metrology engine 105.

[0036] 2, the RF radio 160 also includes an RTOS. Like the metrology engine 105, the RF radio 160 may include its own processor, such as an MCU, on which the respective RTOS runs. Either or both of the metrology engine 105 and the RF radio 160 may be integrated with the MPU 110 as a single chip, or the metrology engine 105 and the RF radio may each include a separate MCU 210 that communicates with the MPU 110 via a driver.

[0037] Functions other than those requiring an RTOS may run on MPU 110. In some embodiments, only time-critical functions run on an RTOS, with other functions executed on MPU 110. More specifically, these other functions may be executed as one or more applications running on MPU 110 via an operating system that does not necessarily need to be an RTOS, such as Linux®. These other applications may be remotely updatable, such as over the air, via communications device 150.

[0038] FIG. 3 is a diagram of an exemplary hardware and software configuration of meter 100, according to some embodiments of the present invention. As shown in FIG. 3, in some embodiments, operating system (OS) 310 runs on MPU 110 and may support multithreading or multiprocessing, while RTOS 320 runs on MCU 210 or another processor of metering engine 105. As previously mentioned, RTOS 320 enables metering engine 105 to perform time-critical operations. OS 310 and RTOS 320 may be different, for example, the RTOS may be a different operating system than OS 310 of MPU 210, or the RTOS may be different installations of the same operating system. In cases where OS 310 and RTOS 320 are different installations of the same operating system, both OS 310 and RTOS 320 may be real-time operating systems. However, in certain embodiments, Linux® is OS 310 of MPU 110, while Real-Time Linux® is RTOS 320 of metering engine 105. However, it will be understood that different operating systems may be used for each of the processors, and that the OS 310 of the MPU 110 may, but need not, be an RTOS 320 as well.

[0039] In some embodiments, the meter 100 includes a set of defined software interfaces (i.e., application programming interfaces) for interaction between time-critical operations running on the RTOS 320 and non-time-critical operations running outside the RTOS 320. In one example, the meter 100 may implement a defined first application programming interface (API) for sending data from the meter 100 to other devices and a second API for receiving data from other devices in the meter 100. To send data from an application executed by the MPU 110 or from some other non-time-critical component, the OS 310 may call a function of the first API to send the data to a head-end system, another meter, or elsewhere. In some embodiments, the RTOS 320 receives the function call and schedules the operation to transmit the data over the RF radio 160 during a subsequent available time slot. When the next available time slot arrives, an embodiment of RTOS 320 ensures that the data indicated in the function call is transmitted on the appropriate channel, as indicated by an established channel hopping policy that defines which channel to use in each time slot. If the data does not fit within a single time slot, RTOS 320 may split the data and transmit it in different time slots, and potentially across different channels, as necessary.

[0040] Additionally or alternatively, the OS 310 may utilize an API for controlling maximum transmit power levels or for indicating average signal strength for the RF radio 160. The RF radio 160 may collect various summary statistics, such as the number of bit errors during transmission and reception, the number of dropped packets, or other statistics, and the OS 310 may utilize one or more APIs to request this or other data from the RF radio 160. Additionally or alternatively, in some embodiments, the meter 100 may implement one or more APIs for communication between the OS 310 and the metering engine 105. The RTOS 320 of the metering engine 105 may handle the time-critical generation of metering data (e.g., consumption data or other data generated or collected by the metering engine 105) and associated high-speed processing of that metering data, and the RTOS 320 may use one or more APIs to send metrics of such metering data (e.g., kilowatt-hours, power factor, peach voltage, or current measurements) to the OS 310.

[0041] As shown in FIG. 3 , in some embodiments, each core 220 of the MPU 110 is responsible for a particular function of the meter, e.g., the core 220 executes a thread of an application that implements that function. In this example, the MPU 110 has four cores 220, also referred to as processor cores, although it will be understood that the number of cores 220 in the MPU 110 may vary. In this example, a first core 220 is responsible for running the OS 310 and legacy code (e.g., traditional meter code), a second core 220 is responsible for running Java applications or other types of applications, a third core 220 is responsible for running metering applications, such as non-time-critical metering applications, and a fourth core 220 is responsible for all other operations of the meter 100.

[0042] Additionally, as shown, one or more drivers 330 may be installed on the operating system 310 to enable expansion, and more specifically, to provide support for peripherals 145. In this example, the peripherals 145 include an NFC chip 170, an RF radio 160, a metering engine 105, and additional peripherals 145. In general, the NFC chip 170 may communicate with nearby external devices as needed by the meter 100. For example, as described in more detail below, the NFC chip 170 may communicate with a smartphone used in place of a display, such that the meter 100 itself need not include a display.

[0043] It will be understood that Figure 3 represents an illustrative example and does not limit the scope of various embodiments of the present invention. For example, core 220 may alternatively not be assigned a specific role, but may instead share the load of various functions of meter 100. As another example, different roles may be assigned than those shown and described herein.

[0044] FIG. 4 illustrates another exemplary hardware and software configuration of meter 100, according to some embodiments of the present invention. In this example, first core 220 implements a Device Control Word (DCW) Virtual Machine (VM) utilizing Internet Protocol version 6 (IPv6) (6LowPan) over a power-saving wireless personal area network. More specifically, as shown in FIG. 4, the DCW VM may utilize User Datagram Protocol (UDP) over IPv6 Routing Protocol (RPL) for power-saving or lossy networks. The DCW VM provides an environment for executing coded legacy operations, specifically legacy DCWs. In this manner, some embodiments of meter 100 enable the use of new, complex applications leveraging multithreading while also providing backward compatibility with functionality embedded in legacy firmware. In this example, second core 220 is responsible for providing one or more services and a MicroEJ VM for software utilizing the MicroEJ platform, as well as one or more applications running on the MicroEJ VM or one or more services. A third core 220 of the MPU 110 is dedicated to a metering application 420 that utilizes the consumption data determined by the metering engine 105. A fourth core 220 is available for other applications 420 that may or may not utilize the consumption data. Furthermore, in this example, the OS running on the MPU 110 is Linux®, while the RTOS 320 running on the MCU 210 (i.e., in the metering engine 105) is Real-Time Linux®. However, it will be understood that this example is for illustrative purposes only.

[0045] In some embodiments, meter 100 is configured to connect directly to an external device, such as a smartphone or other device. Figure 5 illustrates an example of meter 100 wirelessly connected to external device 510, according to some embodiments of the present invention. More specifically, while the example of Figure 5 illustrates external device 510 as a smartphone, it will be understood that external device 510 may alternatively be a tablet, notebook computer, or other external device 510 available as described herein.

[0046] As previously mentioned, meter 100 need not include a display. More specifically, according to some embodiments, exemplary meter 100 does not include a screen, such as an LCD screen, for displaying text or other information. Furthermore, in some embodiments, meter 100 does not include buttons or an optical port. Conventionally, one or more buttons are included on meters to initiate a test mode, initiate a reset, toggle the content shown on the display, or perform other functions, and an optical port is used to enable a local connection for receiving firmware upgrades or configuration parameters. Eliminating such components can reduce the manufacturing costs of meter 100, while these functions can be maintained through the use of one or more communication devices 150 as described herein.

[0047] In some embodiments, one or more communication devices 150 included in the meter 100 includes an NFC chip 170. The NFC chip 170 in the meter 100 may connect the meter 100 to an external device 510 via NFC. For example and without limitation, the range of the NFC chip 170 may be approximately 0-4 inches, such that the external device 510 is within 4 inches of the meter 100 during connection. This short range may be useful for reducing the ability of a remote device to connect to the meter 100 for malicious purposes. Additionally, in some embodiments, the meter 100 verifies the authorization of the external device 510, such as by verifying a signature or certificate of the external device 510, to ensure that the external device 510 is authorized to access the meter 100.

[0048] It will be appreciated that alternative communication devices 150 may be used in place of the NFC chip 170 to provide for communication with the external device 510. For example, a radio frequency identification (RFID) device, Bluetooth, or WiFi may be used to connect the meter 100 to a smartphone or other external device 510 used as a display, or the meter 100 may include a port (e.g., optical or universal serial bus (USB)) that allows for a wired connection with the external device 510 for communication.

[0049] In some embodiments, the external device 510 has an integrated or attached display 520 that is utilized in place of the display of the meter 100 itself. Instead of rendering information on the meter 100's integrated display, as is conventionally done, the information to be rendered is transmitted by the meter 100 to the external device 510, which then displays such information. In other words, the external device 510 provides a user interface to the meter 100 through which a user can manually provide commands to or receive data from the meter 100. For example and without limitation, the meter 100 may transmit one or more types of display information to the external device 510, such as consumption data describing the amount of resource consumed (e.g., in kilowatt-hours), real-time or historical demand for the resource (e.g., in kilowatts), log files, internal time, service hours, information regarding load balancing, power factor, and billing estimates.

[0050] Conventionally, meter 100 joins a mesh network, thereby transmitting consumption data to a head-end system, typically indirectly via one or more intermediate nodes. The head-end system may then make the consumption data accessible via the cloud only after the consumption data has been stored in a centralized location. However, in some embodiments, external device 510 receives consumption data directly from meter 100 without waiting for the consumption data to be received at the head-end system or stored in the cloud. Meter 100 is configured to transmit real-time or near-real-time consumption data describing consumption measured or otherwise collected by meter 100 directly to external device 510. In some embodiments, the transmission of real-time or near-real-time consumption data occurs before the consumption data is available in the head-end system or the cloud. In some embodiments, in addition to or instead of transmitting consumption data to external device 510, meter 100 may transmit other data to meter 100. For example, the meter 100 may implement a policy, established by a service provider or other entity associated with the meter, regarding what data is accessible by the external device 510. The policy may dictate the data that the meter 100 can send to the external device 510, which may or may not be different from, or more restricted than, the data sent from the meter 100 to the head-end system.

[0051] In some embodiments, the external device 510 performs analysis or other data processing based on the information received from the meter 100. Because the external device 510 is likely to have a higher quality display 520 than conventional meters, the external device 510 may render the consumption data or other information in a visualization that is intuitive to the user, such as a graphical display in the form of a table or graph, or the external device 510 may recognize patterns in the consumption data or perform other complex processing.

[0052] To this end, in some embodiments, a metering application 530 may be executable by the external device 510 and configured to provide a graphical user interface to the meter 100 and perform other tasks related to consumption data. In some embodiments, access to the meter 100 via the metering application 530 is limited to authorized users, and further, the type of access allowed may vary from user to user.

[0053] For example, a customer may connect an external device 510 to the meter 100, and during that connection, the meter 100 may grant read-only access to the external device 510. In some embodiments, before read-only access is granted, the external device 510 may be required to authenticate itself to the meter 100, and the meter 100 may require the customer to provide authentication information (e.g., username and password, biometric data) to the external device 510. To authenticate itself, the external device 510 may transmit this authentication information provided by the customer to the meter 100 by verifying the authentication information; additionally or alternatively, after the external device 510 authenticates the user, the external device 510 may provide other appropriate authentication data (e.g., a signature or authorization certificate) to the meter 100 in response to authenticating the user to authenticate the external device 510.

[0054] Upon providing access to the external device 510, the meter 100 may receive instructions manually entered by a user of the external device 510. Additionally, the meter 100 may transmit data to the external device (e.g., via NFC), which may include, for example, an indication of consumption data over a predetermined period of time. In some embodiments, the utility meter 100 transmits such data to the external device in response to an instruction entered by a user at the external device 510, where such an instruction is a request for consumption data. The external device 510 may be configured to analyze the consumption data provided by the meter 100 to provide further details or to render a visualization (e.g., a graph, table, or chart). The external device 510 may perform one or more of such tasks in response to a user request received at the interface of the external device 510. For example, upon receiving a request for a particular form of visualization of the consumption data, the external device 510 may analyze the consumption data as needed and display the resulting visualization via the display 520 of the external device 510.

[0055] In some embodiments, the external device 510 can perform analytics and render advanced graphics based on consumption data received directly from the meter 100. By way of example and not limitation, the external device 510 analyzes consumption data to determine consumption trends over a predetermined or selected period of time, thereby making predictions regarding future usage. In some embodiments, the external device 510 performs segmentation to identify which appliances are being used on the premises. In some embodiments, such analysis requires the use of artificial intelligence implemented in the external device 510 via the metering application 530.

[0056] In some embodiments, the external device 510 is configured to calculate a bill to be paid by a user based on consumption data representing utilities consumed by the customer. The calculated amount may be applied to a prepayment meter, in which case the amount may be a suggestion based on past consumption. Alternatively, the calculated amount may be applied to a postpayment meter, in which case the amount may be a prediction of a future bill based on actual consumption incurred. Additionally, the external device 510 may determine consumption trends, such as through artificial intelligence, and calculate an estimated bill based on expected future consumption. The external device 510 may initiate a payment to an account associated with the customer's utility consumption in the calculated amount or another amount selected by the user. In some embodiments, the received payment is processed at the meter 100 upon request of the external device 510, and a confirmation is sent to a centralized location (e.g., a head-end system or the cloud) via the RF radio 160 or via another communication device 150. Additionally or alternatively, the meter 100 or the external device 510 may transmit payment information to a centralized payment processing source (e.g., a payment server) for processing; in some embodiments, a head-end system may serve as the payment processing source. In that case, the payment processing source, such as the head-end system, processes the payment and sends an acknowledgment back to the meter 100 or the external device 510. The external device 510 may display an indication of the acknowledgment to the customer to confirm that payment has been made. In this way, the customer can view their consumption data and pay before receiving their bill, which may be based on estimates according to their consumption habits. In other words, the customer can make a prepayment initiated by the external device 510 based on consumption data transmitted directly from the meter 100 to the external device 510.

[0057] In some embodiments, the metering application 530 may connect to other applications on the external device 510 to enable such other applications to utilize the consumption data. For example and without limitation, the connected application (e.g., the application to which the metering application 530 is connected) may generate a PDF or initiate a print job that renders the consumption data or other information received from the meter 100. As another example, the metering application 530 may connect to a calendar or task manager on the external device 510 to set a reminder to make a payment or perform some other meter-related task. It will be appreciated that the metering application 530 may connect to various other applications to provide additional or alternative services based on the information received from the meter 100.

[0058] In some embodiments, a hierarchy of access exists, with authorized technicians' external devices 510 additionally or alternatively accessing information on the meter 100. For example, after the metering application 530 authenticates the technician, or the meter 100 itself authenticates the external device 510 being used by the technician, the metering application 530 may provide the external device 510 with both read and write access to the meter 100, where the write access may or may not be restricted in some manner. By way of example and not limitation, a technician may be able to initiate a test mode, program, or reset the meter 100 by entering commands or other data into the external device 510. Such commands or other data may be transmitted from the external device 510 to the meter 100. For example, the external device 510 may push field firmware or software updates wirelessly to the meter 100 without the use of a physical adapter.

[0059] Despite the lack of a display, the exemplary meter 100 includes one or more light sources that can be used during calibration or for other purposes. By way of example and not limitation, the meter 100 includes a light-emitting diode (LED) device 540 configured to flash or pulse during the process of calibrating the meter or performing other tasks. In some embodiments, the timing or pattern of the pulses follows an established pattern so that a technician can calibrate the meter or perform some other task based on the information conveyed by the pulses. In this case, the various states of the light source (a state being a combination of color and the pattern in which that color is displayed (e.g., solid or flashing at a certain frequency)) are mapped to specific messages that convey information about the meter 100. Thus, given the state of the light source, a technician can interpret that state as an indication that the meter 100 is providing an associated specific message and can act accordingly. By way of example and not limitation, the LED device 540 flashes once when a predetermined amount of kilowatt-hour (e.g., 1 kilowatt-hour) has been consumed, which provides guidance during calibration. Additionally or alternatively, if meter 100 includes an optical port, LED device 540 may function as a transmitting LED for the optical port, which may also include a photodiode as a receiving transducer. In this manner, the lack of an integrated display within meter 100 does not necessarily degrade the performance of meter 100 with respect to enabling calibration with conventional calibration equipment.

[0060] In addition to the above features, not including a display on the meter 100 itself offers various advantages. For example, not including a display may increase the reliability of the meter 100 by eliminating display-related failures. Conventional meter displays can experience long-term contrast and electrochemical failures, as well as other failures, over time, sunlight, heat, or humidity. Eliminating such a display from the meter 100 eliminates such failures. Furthermore, eliminating the display may be a cost-effective option because including an NFC chip 170 in place of a display is likely to be less expensive than the cost of a display, the mechanical design of the meter 100 can be simplified without a display, and the elimination of the display increases available printed circuit board (PCB) area.

[0061] In some embodiments, by eliminating the display and light port of meter 100, the remaining hardware described herein can be configured to fit onto a smaller PCB than traditionally used, thereby significantly reducing costs and providing additional space on the PCB for other functions. More specifically, for example, meter embodiments eliminate the display, which likely requires numerous traces; the light port, along with its associated phototransistor and signal conditioning hardware; and the pushbutton and corresponding reed switch, along with the associated traces leading to the button and signal conditioning hardware for the button. Typically, a meter display includes 36 traces running between the display and the processing unit, which together require over 2 square inches of PCB area. In some embodiments, these traces are eliminated from meter 100 by eliminating the display itself. Meter 100 embodiments retain the power supply, memory 120, storage 130, MPU 110, metering engine 105, and communications device 150, which likely fit onto a smaller PCB than traditionally used.

[0062] Numerous specific details are described herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter may be practiced without these specific details. The features described herein are not limited to a particular hardware architecture or configuration. A utility meter may include any suitable configuration of components that operate as described herein. Any suitable programming, scripting, or other type or combination of languages ​​may be used to implement the teachings contained herein in software used to program or configure a utility meter or other device. Methods, devices, or systems that would be known to those skilled in the art have not been described in detail so as not to obscure the claimed subject matter.

[0063] The use of "adapted to" or "configured to" means open and inclusive language that does not exclude devices adapted or configured to perform additional tasks or steps. Furthermore, the use of "based on" means open and inclusive in that a process, step, calculation, or other action that is "based on" one or more recited conditions or values ​​may in fact be based on additional conditions or values ​​other than the recited conditions or values. The headings, lists, and numbering provided herein are for ease of description and are not intended to be limiting.

[0064] Although the subject matter of the present invention has been described in detail above with reference to specific embodiments thereof, it will be understood that those skilled in the art, upon understanding the foregoing, can easily produce modifications, variations, and equivalents to such embodiments. It is therefore understood that the present disclosure is presented for purposes of illustration and not limitation, and does not exclude modifications, variations, or additions to the subject matter that would be readily apparent to those skilled in the art.

Claims

1. measuring resource consumption with a utility meter; generating consumption data, including real-time consumption data, based on measuring consumption of the resource with the utility meter; directly and wirelessly connecting the utility meter to an external device having a display via a short-range wireless communication device; receiving, by the external device, authentication information entered by a user; authenticating the user by the external device, the authentication information including transmitting the authentication information by the external device to the utility meter; authenticating the external device to the utility meter before allowing read-only access to the external device; transmitting, by the utility meter, the consumption data to the external device and utilizing a display of the external device as an interface to the utility meter, authenticating the external device includes authenticating information provided by the user to the external device, the authentication including transmission of the information by the external device to the utility meter; The step of authenticating the external device includes: In response to authenticating the user, providing a signature or authentication certificate of the external device to the utility meter to authenticate the external device; verifying the authenticity of the external device by verifying the signature or authentication certificate of the external device to ensure that the external device is authorized to access the utility meter; a metering application running on the external device configured to calculate a payment based on the consumption data; The method further includes transmitting, by a second communication device of the utility meter, the consumption data to a head-end system in communication with a plurality of utility meters; the step of transmitting the consumption data to the external device occurs before the step of transmitting the consumption data to the head-end system; the utility meter is configured to enforce a policy regarding data accessible by the external device, the policy being established by a service provider managing the utility meter; The above policy is: indicating data that the utility meter is capable of transmitting to the external device; determining whether the data differs from data transmitted from the utility meter to the head-end system; determining that the data is more restricted or less restricted than data transmitted from the utility meter to the head-end system; The method comprises: receiving, by the utility meter, payment information from the external device for paying a payment amount calculated based on the consumption data; transmitting, by the utility meter, the payment information to a remote payment processing server; receiving, by the utility meter, a payment confirmation for display on the external device; transmitting, by the utility meter, the payment confirmation to the external device for display on the external device; A method comprising:

2. The method of claim 1 , wherein the utility meter does not include an integrated display.

3. the utility meter being aware of an authorization hierarchy; The step of verifying that the external device is authorized to access the utility meter comprises: verifying that the user is authorized to have write access to the utility meter based on the authentication information; permitting the external device to have write access to the utility meter based on verification of the authentication information; The method of claim 1 , comprising:

4. the utility meter includes a light source; The method comprises: determining a status of the utility meter; mapping the state of the utility meter to a color and pattern corresponding to the state of the utility meter; activating the light source of the utility meter with the color and pattern corresponding to the state of the utility meter; The method of claim 1 further comprising:

5. The method of claim 4 , wherein the light source on the utility meter indicates the amount of kilowatt-hours stored in the utility meter.

6. an external device having a display; a utility meter without an integrated display; A system comprising: The utility meter a metering engine configured to measure consumption of a resource and generate consumption data, including real-time consumption data, based on the measurement of the consumption of the resource; a near field communication device configured to directly and wirelessly connect the utility meter to the external device; the utility meter is configured to receive authentication information from the external device, the authentication information being received by the external device from a user, and the user being authenticated by the external device; the utility meter is configured to authenticate the external device to the utility meter before allowing read-only access to the external device; authenticating the external device includes authenticating information provided by the user to the external device, the authentication including transmission of the information by the external device to the utility meter; authenticating the external device In response to authenticating the user, providing a signature or authentication certificate of the external device to the utility meter to authenticate the external device; verifying the authenticity of the external device by verifying the signature or authentication certificate of the external device to ensure that the external device is authorized to access the utility meter; The utility meter transmitting the consumption data to the external device and utilizing a display of the external device as an interface to the utility meter; configured to receive instructions by manual input on the external device; the utility meter is configured to execute the instructions received from the external device; a metering application configured to run on the external device, the metering application configured to calculate a payment based on the consumption data; The utility meter receiving, from the external device, payment information for paying the payment amount calculated based on the consumption amount data; transmitting the payment information to a remote payment processing server; receiving a payment confirmation from the remote payment processing server; transmitting said payment confirmation for display on said external device; configured to transmit the consumption data by a second communication device of the utility meter to a head-end system in communication with a plurality of utility meters; transmitting the consumption data to the external device occurs before transmitting the consumption data to the head-end system; the utility meter is configured to enforce a policy regarding data accessible by the external device, the policy being established by a service provider managing the utility meter; The above policy is: indicating data that the utility meter is capable of transmitting to the external device; determining whether the data differs from data transmitted from the utility meter to the head-end system; providing that the data is more restricted or less restricted than data transmitted from the utility meter to the head-end system; system.

7. a head-end system communicating with the utility meter and a plurality of other utility meters via a wireless mesh network; a second communication device of the utility meter configured to transmit the consumption data to the head-end system; The system of claim 6.

8. the utility meter further comprising a light source; The utility meter determining an internal state of the utility meter; mapping the state of the utility meter to a color and pattern corresponding to the state of the utility meter; configured to activate the light source of the utility meter in the color and pattern corresponding to the state of the utility meter. The system of claim 6.

9. the utility meter being aware of an authorization hierarchy; To verify that the external device is authorized to access the utility meter, the utility meter further comprises: verifying that the user is authorized to have write access to the utility meter based on the authentication information; the external device is configured to grant write access to the utility meter based on verification of the authentication information; the instructions request the utility meter to perform a firmware upgrade. The system of claim 6.

10. 1. A computer program product for receiving and executing instructions in a utility meter without a display, comprising: The computer program product comprises a computer-readable recording medium having program instructions embodied therein; 10. A computer program product, wherein the program instructions are executable by a processor of the utility meter to cause the processor to perform the method of claim 1.

11. The method comprises: determining a status of the utility meter; mapping the state of the utility meter to a color and pattern corresponding to the state of the utility meter; activating a light source of the utility meter with the color and pattern corresponding to the state of the utility meter; The computer program product of claim 10, further comprising:

Images