Multiprocessor utility meter featuring a measurement processor connected to an application processor

Abstract

The utility meter has a multiprocessor architecture that includes a microprocessing unit (MPU) that runs multiple software applications and another processing unit that performs core metering functions in real time. The utility meter includes a metering engine, the MPU, and one or more metering applications. The metering engine measures resource consumption and generates consumption data based thereon. The metering engine includes a metering processor, dedicated memory, and a real-time operating system executed by the metering processor that enables the metering engine to perform time-critical metering functions in real time. The MPU is connected to the metering processor and includes one or more processor cores. The MPU runs one or more metering applications on the MPU's primary operating system, and the metering applications utilize the consumption data.

Description

[Technical field]

[0001] SUMMARY OF THE DISCLOSURE The embodiments described herein relate to utility meters, and more particularly to multi-processor utility meters featuring a metering processor coupled to an application processor. [Background technology]

[0002] In general, utility meters measure the consumption of resources such as electricity, water, or gas. Typically, utility meters are installed in or near a premises and measure the consumption in the premises. Utility meters are typically provided by a service provider, which manages them as needed to ensure that they are fully operational and accurate consumption measurements are obtained. In some cases, utility meters have integrated radios, thereby participating in a wireless mesh network. Through the wireless mesh network, utility meters communicate with and report consumption to a remote centralized head-end system that is responsible for servicing multiple utility meters. Since consumers are billed based on their consumption measured at the utility meters, high accuracy is required in the measurement and reporting of consumption.

[0003] Existing utility meters typically utilize a microcontroller that incorporates a central processing unit that integrates random access memory (RAM) and read-only memory (ROM) in a single chip. Firmware installed in the hardware performs operations such as sampling and reporting consumption. Due in part to the limited storage space available in utility meters, the firmware is monolithic such that most or all aspects of the meter functionality are encoded in and interdependent on the firmware.

[0004] Utility meters also include displays that are useful for providing data to a technician or for reporting data locally, where maintenance is typically performed locally, where a technician reads a display integrated into the utility meter or attaches a physical tool to the utility meter for servicing. Summary of the Invention [Problem to be solved by the invention]

[0005] The present disclosure provides a multi-processor utility meter featuring a metering processor coupled to an application processor. [Means for solving the problem]

[0006] In one embodiment, a utility meter includes a metering engine, a microprocessing unit (MPU), and one or more metering applications. The metering engine measures resource consumption and generates consumption data based on the resource consumption. The metering engine includes a metering processor, a dedicated memory, and a real-time operating system (RTOS) executed by the metering processor to enable the metering engine to perform time-critical metering functions in real time. The MPU is coupled to the metering processor and includes one or more processor cores. The MPU executes one or more metering applications on the primary operating system of the MPU, and the one or more metering applications utilize the consumption data.

[0007] In another embodiment, a utility meter includes a metering engine, an MPU, a primary memory, a primary operating system, and one or more metering applications. The metering engine measures a consumption of a resource and generates consumption data based on the consumption of the resource. The metering engine includes a microcontroller unit (MCU) including a metering processor and a dedicated memory, and an RTOS executed by the MCU to enable the metering engine to perform time-critical metering functions in real time. The MPU is connected to the metering processor and includes one or more processor cores. The primary memory is associated with the MPU and is separate from the dedicated memory of the metering engine. The MPU executes a primary operating system that is separate from the RTOS of the metering unit. Furthermore, the MPU executes one or more metering applications on the primary operating system of the MPU, and the one or more metering applications utilize the consumption data.

[0008] In yet another embodiment, a method includes installing an MPU having one or more processor cores in a utility meter. The method further includes installing a metering engine in the utility meter, the metering engine coupled to the MPU, the metering engine configured to measure a consumption of a resource and generate consumption data based on the consumption of the resource. The metering engine includes a metering processor and a dedicated memory. The method further includes installing an RTOS in the metering processor to enable the metering engine to perform time-critical metering functions in real-time. Additionally, the method includes installing one or more metering applications on a primary operating system of the MPU, where the one or more metering applications utilize the consumption data.

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

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

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

[0012] Current utility meter hardware and firmware have several shortcomings. A single microcontroller unit (MCU), as used in most utility meters, is not capable of true multithreading to efficiently execute complex applications. Additionally, the firmware is a single code for all operations of the meter. The code may contain parts that perform different tasks, but those parts are dependent on each other within the firmware. As a result, firmware upgrade times are long, as each firmware upgrade affects all operations represented in the firmware code. If the code is corrupted, the corruption affects the entire utility meter, not just a single function.

[0013] However, according to some embodiments described herein, the utility meter has a multi-processor architecture that utilizes a microprocessing unit (MPU) connected to (i.e., in communication with) an additional metrology processor. The MPU may have multiple cores. The metrology processor may be an MCU and is configured to perform time-critical metrology functions in real-time, while the MPU executes various applications using multithreading or multiprocessing. In some embodiments, the metrology processor executes a real-time operating system to ensure real-time processing of the metrology functions. Applications for functions other than the core metrology functions may be executed on the MPU, which do not need to have a real-time operating system and do not need to have enhanced 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.

[0014] Additionally or alternatively, according to some embodiments described herein, the utility meter does not have 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, thereby allowing a user to view such data on the smartphone or other device.

[0015] The embodiments of the utility meters described herein, also referred to as meters, provide various technical advantages over conventional utility meters. By including multiple cores in the MPU, the speed of instruction processing can be increased, for example, by 4-12 times. By utilizing separate memory rather than just memory embedded in the MCU, the memory space can be increased, for example, by more than 2 times. In some embodiments, individual applications may be installed. This modularity supports the creation of independent applications that can be selectively used across multiple utility meters so that each utility meter can be configured in a customized manner. More specifically, in some embodiments, a utility meter can be tailored with applications that are suited to the particular use of that utility meter. In some embodiments, the utility meter architecture allows for applications to be deployed as needed once the utility meter is in use. Additionally, the modularity of applications in the utility meter allows users to create, modify, or install their own applications for custom management of the utility meter. For example, a user can install applications to manipulate, process, or manage meter or metering data, which is data generated or collected by the meter.

[0016] As a result, in some embodiments, real-time capabilities continue to be supported in utility meters according to some embodiments, and the utility meters also have broader and more complex functionality running efficiently on a high-performance MPU that acts as an application engine where each application can be upgraded, installed, or uninstalled separately as needed. The utility meter embodiments described herein provide a more robust platform for standard protocols and interfaces, in addition to new or custom functionality. The hardware and software described herein together provide a set of features that are scalable, secure, and easily maintained.

[0017] The meter embodiments described herein have powerful decision-making capabilities that allow for the redistribution of tasks within a network of meters and other nodes. For example, conventionally, meters report consumption to other nodes in the network, which is ultimately delivered to a head-end system responsible for centralized decision-making. However, according to some embodiments, the meter includes appropriate intelligent functionality in the form of hardware or software applications as described herein to enable decision-making execution in the meter itself. For example, and not by way of limitation, the meters described herein may monitor power quality and take corrective action. Thus, the meter embodiments provide edge intelligent functionality that can reduce network communication overhead, reduce bottlenecks between endpoints and head-end systems, or ease the workload at the head-end system or other nodes. Distributed intelligent functionality is enabled by utilizing a group of meters described herein connected via a network, such that a centralized source (e.g., a head-end system) is no longer responsible for all or most of the analysis and decision-making.

[0018] FIG. 1 is a diagram of an example hardware architecture of a utility meter 100, according to some embodiments of the present invention. The utility meter 100, also referred to herein as meter 100, can be used to measure the consumption of one or more resources, such as electricity, water, or gas. In some embodiments, the meter incorporates a metering function (e.g., measuring consumption) 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 a core metering function 105, a MPU 110 having one or more cores, a memory 120, and a storage device 130, which may be connected together by a system bus 101. Each peripheral device 145 is, for example, built into the meter 100 or connected by an auxiliary slot. In some embodiments, a communication bus 140 similarly integrates one or more peripheral devices 145, including one or more communication devices 150, into the meter 100. However, it will be appreciated that the communications bus 140 is not required, and instead each peripheral 145 is connected to the MPU 110 by a respective interface, such as a software driver.

[0019] 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 functions of the meter 100 are performed by the embedded or connected metering engine 105 or in one or more peripherals 145. The time-critical functions include, for example, the determination and over-the-air reporting of consumption data, which is data describing the amount of resource (i.e., utility) consumed in each of various time intervals associated with the consumption. More specifically, for example, the accumulation and calculation of measurements are determined by the metering engine 105, which is capable of performing operations in real-time. For example, and not by way of limitation, the metering engine 105 utilizes a real-time operating system (RTOS) and the over-the-air functions run on the same RTOS or on a different RTOS in the peripherals 145. In some embodiments, higher level applications that are less time-critical run on the MPU 110, which do not require enhanced real-time capabilities. These aspects and others are described in further detail below.

[0020] The MPU 110 has one or more cores. In some embodiments, an operating system in 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 subset of the functionality in the meter. Additionally or alternatively, multiple cores may operate on the same functionality, allowing multiple tasks to be performed in parallel (e.g., multithreading). Exemplary uses of multiple cores are provided in further detail below, particularly with respect to FIGS. 3 and 4.

[0021] According to some embodiments, a wide range of functionality may be implemented as applications supported by the MPU 110. For example, and not by way of limitation, one or more of the following functionality may be implemented as applications supported by the MPU 110 and therefore operate on the MPU 110: time-of-use enablement, load-specific profiling of how resources are consumed, cryptocurrency transactions for payment or other purposes, automated outage reporting, crowd-sourcing information associated with utility usage, detection of usage patterns, enablement or detection of electric vehicle charging, enablement of solar or other renewable energy source connection, solar power detection, enablement or detection of battery management, inverter management, load control, and connection to a home automation or control system.

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

[0023] More specifically, in some embodiments, a machine learning (ML) model may be implemented in the meter 100 that is trained to recognize events such as operation of a given appliance, improper power factor, or loss of power in a nearby meter 100. The ML model may be, for example, a neural network, a decision tree, a classification model, or some other ML model. For example, before being loaded into the utility meter, such an ML model is trained based on training data that includes a set of tuples, each of which 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 occurrence of an object of interest. The features may include, for example, a usage pattern of the consumption of electricity or some other resource being measured. Specifically, for example, the feature vector may include a set of values ​​that correspond to the amount of resource (e.g., kilowatt-hours) used in various intervals. The labels may indicate, for example, which appliances are in use, whether the power factor is improper, or whether the meter or a nearby meter has lost power. Given the training data, the ML model learns to map the feature vectors to labels. Thus, during operation of a utility meter, an ML model for the utility meter can receive as input features that describe the state of the meter at a given time and can therefore predict labels such as an indication of which equipment is in use, an indication of whether the power factor is improper, or an indication that the meter or a nearby meter has experienced a power outage.

[0024] In some embodiments, the meter 100 performs one or more of the tasks described above as being performed by an ML model, but may do so by a technique in addition to or instead of using an ML model. For example, an embodiment of the meter 100 maintains a decision tree, which need not be based on machine learning. The meter 100 may input the current state of the meter 100 (e.g., a feature vector describing the state) into the decision tree, and by using the decision tree, the meter 100 may decide which action to take. Such actions may include one or more of those described above, such as sending a notification or initiating activation of a capacitor bank. It will be appreciated that various techniques can be used to provide edge intelligence capabilities in the meter 100.

[0025] Additionally or alternatively, some embodiments of the meter 100 may run one or more virtual machine or container applications not traditionally supported by utility meters. Furthermore, in addition to or instead of running local applications, the meter 100 may utilize the communication device 150 to access and use cloud-based applications. For example, a customer using the meter 100 may be associated with a private cloud within the customer's control. The meter 100 may then access the cloud, e.g., via a gateway, and run any applications installed in the cloud. Cloud-based applications accessible from the meter 100 may include, for example, applications that perform power quality monitoring, grid topology or mapping, phase identification, AI-based functions, or energy breakdown estimation. The meter 100 may be connected to the cloud by a wireless mesh network, a cellular connection, or some other communication technology.

[0026] Applications may be installed on the meter 100 by a variety of mechanisms. For example, and not by way of limitation, applications may be installed from a remote system, such as a head-end system or a cloud server, may be installed locally via a wired connection to the meter, or may be 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 clouds, the meter 100 may be able to run applications that are not supported by the native operating system of the meter 100, for example.

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

[0028] 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, for example, to report consumption data to the head-end system or for communication of other data related to the network of meters and other devices. In some embodiments, the RF radio 160 utilizes a physical layer (PHY) and a media access control (MAC) layer, where the PHY connects the MAC to a physical medium capable of data transmission. In some embodiments, the MAC and PHY perform time-critical functions that must be performed in real time. The MAC and PHY layers may therefore 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 into a peripheral device 145 that is integrated into or otherwise connected to the MPU 110. If used, the WiFi device may enable networking with nearby devices, such as other meters 100 or smart devices in close proximity to the meter 100. For example, and not by way of 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.

[0029] In some embodiments, meter 100 utilizes communication device 150 to collect consumption data from external sources. For example, and not by way of limitation, peer meters or submeters may directly measure consumption not directly measured by meter 100 itself, and from such peer meters or submeters meter 100 may receive consumption data 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.

[0030] As shown in FIG. 1, an embodiment of the meter 100 incorporates an NFC chip 170. For example, and not by way of limitation, the NFC chip 170 may have a range of up to 4 centimeters, about 4 centimeters, 3 feet, 3-5 feet, or various other ranges. The NFC chip 170 may have various uses in the meter 100. For example, the NFC chip 170 may be used during the manufacture or construction of the meter to enable tracking of the meter 100 itself during manufacture or construction. As will be described in more detail below, the 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 directly connect to the meter 100 via the NFC chip 170 of the meter 100, allowing the smartphone to display a user interface of the meter 100. Thus, the smartphone may display consumption data or other information related to the meter 100 on demand. As described in more detail below, some embodiments of the meter 100 do not have a display, which is traditionally an integrated component of a utility meter. A meter 100 without a display is potentially less expensive to manufacture than a utility meter with a display. Through the use of the NFC chip 170, the exemplary meter 100 can utilize an external device, such as a smartphone, instead of a traditional display. Further examples of the usefulness of a meter without a display are described in more detail below.

[0031] Each peripheral 145 may extend the capabilities of meter 100. For example, and not by way of limitation, the auxiliary slot may allow a service tool to be attached, thereby becoming a peripheral 145. In another embodiment, if hardware (e.g., RF radio 160) malfunctions, an additional or updated version of that hardware may be connected via the auxiliary slot, thereby becoming a peripheral 145. It will be appreciated that various possible uses of peripheral 145 are supported according to embodiments of the present invention.

[0032] 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 time period. For example, in the case of an electric meter, the metering engine 105 calculates the accumulated consumption in units of kilowatt-hours (kWh). As will be 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 certain response time in the hardware and therefore ensures that the resulting consumption data is calculated accurately. Additional details about the metering engine 105 are described in more detail below.

[0033] In some embodiments, by handling real-time tasks with the MCU and allowing the MPU 110 to handle higher level applications (i.e., applications that are not time critical), 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 are modular and separate from the underlying firmware. As a result, the meter 100 can be a system with a variety of non-conventional functions implemented as applications running on the MPU without interfering with the time-critical tasks being executed by the MCU.

[0034] FIG. 2 is another diagram of an exemplary hardware architecture of a utility meter 100, according to some embodiments of the present invention. As previously described, the metering engine 105 performs the core metering functions of the meter 100. As shown in FIG. 2, in some embodiments, the metering engine 105 includes a metering processor, and in particular, in some embodiments, includes an MCU 210 running an RTOS. The metering engine 105 may be embedded in the meter 100 and may communicate with the MPU 110. However, the metering engine 105 may include a separate processor and separate memory, e.g., the processor and memory of the metering engine 105 may have separate hardware from the MPU 210 and the memory 120 associated with the MPU 210, respectively. For example, the MCU 210 of the metering engine 105 may include integrated memory dedicated to the metering engine 105. In one embodiment, the MCU 210 of the metering engine 105 is a Cortex-M7 600 MHz with an RTOS such as Real-Time Linux (Linux®). In a further embodiment, 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 MCU 210 or in place of MPU 110 shown in Figure 2.

[0035] In some embodiments, metrology engine 105 runs on MPU 110 rather than utilizing a separate processor. For example, and not by way of limitation, a separate logical partition may be implemented in memory 120 and storage 130, and an RTOS, or other mechanism for enforcing real-time functionality, may be installed in this logical partition to implement metrology engine 105.

[0036] In some jurisdictions, certain aspects of metrology processing are required by law to meet certain security and data protection requirements that may require separately partitioned memories and separate processing, and embodiments of the present invention comply with such requirements through the use of separately partitioned memories and separate processors or processing cores. Due to such requirements, special procedures must be used for firmware upgrades, security, and validation, and such procedures do not need to be forced on applications running on MPU 110, but may be forced on metrology engine 105.

[0037] In some embodiments, RF radio 160 also incorporates an RTOS, as shown in Figure 2. Like metrology engine 105, RF radio 160 may include its own processor, such as an MCU, on which each RTOS runs. Either or both of metrology engine 105 and RF radio 160 may be integrated into MPU 110 as a single chip, or metrology engine 105 and RF radio may each incorporate a separate MCU 210 that communicates with MPU 110 via a driver.

[0038] Functionality other than functionality requiring an RTOS may run on MPU 110. In some embodiments, only time-critical functionality runs on an RTOS, while other functionality is implemented on MPU 110. More specifically, such other functionality may be implemented as one or more applications running on MPU 110 with an operating system such as Linux that does not require an RTOS. Such other applications may be updated remotely, for example over the air by communications device 150.

[0039] FIG. 3 is a diagram of an example hardware and software architecture of meter 100, according to some embodiments of the 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 on 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 separate, e.g., RTOS is a different operating system than OS 310 of MPU 210, or RTOS are different installations of the same operating system. If 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 a variety of 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.

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

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

[0042] 3, in some embodiments, each core 220 of the MPU 110 is responsible for a certain function of the meter, such as, for example, one core 220 executing a thread of an application that implements the given function. In this embodiment, 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 embodiment, a first core 220 is responsible for running the OS 310 and legacy code (e.g., applications traditionally embedded in the meter's firmware), 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 metering applications that are not time critical, and a fourth core 220 is responsible for all other operations of the meter 100.

[0043] 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 embodiment, 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 will be described in more detail below, the NFC chip 170 may communicate with a smartphone that is used in place of a display, such that the meter 100 itself need not incorporate a display.

[0044] It will be understood that Figure 3 illustrates an example embodiment 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 instead share the load of various functions of meter 100. In another embodiment, core 220 may be assigned roles different from those illustrated and described herein.

[0045] FIG. 4 illustrates another exemplary hardware and software architecture of the meter 100, according to some embodiments of the present invention. In this embodiment, the first core 220 implements a Device Control Word (DCW) virtual machine (VM) that utilizes Internet Protocol Version 6 (IPv6) over Low-Power Wireless Personal Area Networks (6LowPan). More specifically, as shown in FIG. 4, the DCW VM may utilize User Datagram Protocol (UDP) over IPv6 with Routing Protocol for Low-Power or Lossy Networks (RPL). The DCW VM provides an environment for executing encoded legacy operations, specifically legacy DCWs. Thus, some embodiments of the meter 100 enable the use of new and complex applications that utilize multithreading, while providing backward compatibility with features built into legacy firmware. In this embodiment, the second core 220 is responsible for providing one or more services and a MicroEJ VM for software utilizing the MicroEJ® platform, and is also responsible for providing one or more applications running on the MicroEJ VM or one or more services. The third core 220 of the MPU 110 is dedicated to a metering application 420, which utilizes the consumption data determined by the metering engine 105. The fourth core 220 is available for use by other applications 420 that may or may not utilize the consumption data. Furthermore, in this embodiment, 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.

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

[0047] As mentioned above, the meter 100 need not incorporate a display. More specifically, according to some embodiments, the exemplary meter 100 does not have a screen, such as an LCD screen, for displaying textual or other information. Furthermore, in some embodiments, the meter 100 does not have buttons or an optical port. Traditionally, a meter includes one or more buttons 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 allow a local connection to receive firmware upgrades or configuration parameters. Removing such components can reduce the cost of manufacturing the meter 100, while these functions can be retained through the use of one or more communication devices 150, as described herein.

[0048] In some embodiments, one or more communication devices 150 incorporated into the meter 100 include an NFC chip 170. The NFC chip 170 of the meter 100 may connect the meter 100 to the external device 510 via NFC. For example, and not by way of limitation, the communication range of the NFC chip 170 may be approximately 0-4 inches (0-10.16 centimeters), such that the external device 510 is within 4 inches of the meter 100 during connection. This short distance may be useful to reduce the possibility of a maliciously connecting a remote device to the meter 100. Additionally, in some embodiments, the meter 100 verifies the authorization of the external device 510, for example, by verifying a signature or certificate of the external device 510, thereby ensuring that the external device 510 is authorized to access the meter 100.

[0049] It will be appreciated that alternative communication devices 150 may be used in place of the NFC chip 170 to communicate 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 to the external device 510 for communication.

[0050] 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 outputting information on the integrated display of the meter 100, as is conventionally done, the output information is transmitted by the meter 100 to the external device 510, which displays such information. In other words, the external device 510 provides a user interface to the meter 100. Through that user interface, a user can manually provide instructions to the meter 100 or receive data from the meter 100. For example, and not by way of limitation, the meter 100 may transmit one or more of the following types of information to the external device 510 for display: consumption data describing the amount of resources consumed (e.g., kilowatt-hours), real-time or historical demand for resources (e.g., kilowatts), log files, internal time, service time, information about the load breakdown, power factor, and billing estimates.

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

[0052] In some embodiments, the external device 510 performs analysis or other data processing based on the information received from the meter 100. Since the external device 510 possibly has a higher quality display 520 than conventional meters have, the external device 510 can output the consumption data or other information in an intuitive visualization for the user, for example graphically in the form of a table or graph, or the external device 510 can recognize patterns in the consumption data or perform other complex processing.

[0053] To this end, in some embodiments, the meter measurement application 530 may be executable by the external device 510, where the meter measurement application 530 may be configured to provide a graphical user interface to the meter 100 and also perform other tasks associated with the consumption data. In some embodiments, access to the meter 100 by the meter measurement application 530 may be restricted to authorized users, and further, the type of access allowed may vary across multiple users.

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

[0055] When given access to the external device 510, the meter 100 may receive instructions manually entered by a user of the external device 510. Furthermore, the meter 100 may transmit data (e.g. via NFC) to the external device, where the data may include, for example, a display of consumption data over a predefined 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, which is a request for consumption data. The external device 510 may be configured to provide further details, analyze the consumption data provided by the meter 100, or output 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 an interface of the external device 510. For example, when receiving a request to visualize the consumption data in a particular format, the external device 510 may analyze the consumption data as necessary and display the resulting visualization via the display 520 of the external device 510.

[0056] In some embodiments, the external device 510 can perform analysis and output advanced graphics based on the consumption data received directly from the meter 100. For example, and not by way of limitation, the external device 510 can analyze the consumption data to determine trends in consumption over a predefined or selected period of time, thereby making predictions regarding future usage. In some embodiments, the external device 510 can extrapolate the breakdown to identify which appliances are in use in a home or the like. In some embodiments, such analysis requires the use of artificial intelligence implemented in the external device 510 through the meter measurement application 530.

[0057] In some embodiments, the external device 510 is configured to calculate a bill to be paid by the user based on the consumption data, which represents the utility consumed by the customer. The calculated amount may be applied to a prepaid meter, where the amount may be a suggestion based on past consumption, or the calculated amount may be applied to a postpaid meter, where the amount may be a prediction of an upcoming amount based on actual consumption accrued. Furthermore, the external device 510 may determine a consumption trend, for example by artificial intelligence, to calculate an estimated bill based on expected future consumption. The external device 510 may initiate a payment, with the calculated amount or any other amount selected by the user, against an account associated with the customer's utility consumption. In some embodiments, the received payment is processed in the meter 100 when requested by the external device 510, and a confirmation is sent to a centralized location (e.g., a head-end system or a cloud) via the RF wireless device 160 or other communication device 150. Additionally or alternatively, the meter 100 or the external device 510 may send the payment information to a centralized payment processing source (e.g., a payment server) for processing, and in some embodiments a head-end system may act as the payment processing source. In that case, the payment processing source, such as the head-end system, processes the payment and sends an acknowledgement back to the meter 100 or the external device 510. The external device 510 may display information indicating the acknowledgement to the customer as confirmation that the payment has been made. Thus, the customer may be enabled to view the consumption data and pay before receiving the bill. In this case, the payment may be based on an estimate according to the consumption trends. In other words, a customer may be enabled to perform prepayment initiated by the external device 510 based on consumption data transmitted directly from the meter 100 to the external device 510 .

[0058] In some embodiments, the meter measurement application 530 may connect to other applications in the external device 510, which allows the consumption data to be made available by such other applications. For example, and not by way of limitation, the connected application (e.g., the application to which the meter measurement application 530 is connected) may generate a PDF or initiate a print job rendering the consumption data or other information received from the meter 100. In another embodiment, the meter measurement application 530 may connect to a calendar or task manager of the external device 510 to set a reminder to pay a bill or to perform some other task related to the meter measurement. It will be appreciated that the meter measurement application 530 may connect to various other applications to provide additional or alternative services based on the information received from the meter 100.

[0059] In some embodiments, there is a hierarchy of access, where an authorized technician's external device 510 has additional or alternative access to information about the meter 100. For example, after the meter measurement application 530 authenticates the technician, or after the meter 100 itself authenticates the external device 510 as being in use by the technician, the meter measurement 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 any way. For example, and not by way of limitation, the technician may be allowed to initiate a test mode, program, or reset the meter 100 by commands or other data entered 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 wirelessly push on-site firmware or software updates to the meter 100 without the use of a physical adapter.

[0060] Despite not having a display, the exemplary meter 100 includes one or more lights that can be used during calibration or for other purposes. For example, and not by way of 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, which allows a technician to calibrate the meter or perform some other task based on the information conveyed by the pulsations. The various states of the light are then mapped to specific messages that indicate information about the meter 100. Here, a state is a combination of a color and a pattern in which that color is presented (e.g., a steady light, or flashing at a predetermined frequency). Thus, given a state of the light, a technician can interpret the state as an indication that the meter 100 can provide an associated specific message and act accordingly. For example, and not by way of limitation, the LED device 540 flashes once when a predetermined amount of kilowatt-hours (e.g., 1 kilowatt-hour) has been consumed, which provides a guideline during calibration. Additionally or alternatively, if meter 100 includes an optical port, LED device 540 may act as a transmitting LED for the optical port, which may include a photodiode as a receiving transducer. Thus, the lack of an integrated display in meter 100 does not necessarily diminish the capabilities of meter 100 with respect to enabling calibration using conventional calibration equipment.

[0061] In addition to the above features, there are various advantages to eliminating a display on the meter 100 itself. For example, not having a display may increase the reliability of the meter 100 since display-related failures will not occur. Long-term contrast and electrochemical failures, in addition to other failures, that may occur over time, sunlight, heat, or humidity in a conventional meter's display may not occur by eliminating such a display. Furthermore, eliminating the display may be a cost-effective option because including the NFC chip 170 instead of a display may be less costly than a display, not using a display simplifies the mechanical design of the meter 100, and eliminating the display increases available printed circuit board (PCB) area.

[0062] In some embodiments, due to the elimination of the display and optical port in meter 100, the remaining hardware described herein can be configured to fit onto a smaller PCB than traditionally used, thereby significantly reducing costs and allocating additional space on the PCB for other functions. More specifically, for example, meter embodiments exclude the following: a display, which would require numerous traces; an optical port with phototransistors and signal conditioning hardware; a push button and corresponding reed switch with traces to the button and signal conditioning hardware for the button. Typically, a meter display includes 36 traces that extend between the display and the processing unit, which together require more than 2 square inches (12.9 square centimeters) of PCB area. In some embodiments, by eliminating the display itself, these traces are eliminated from meter 100. Meter 100 embodiments retain the power supply, memory 120, storage 130, MPU 110, metrology engine 105, and communications unit 150, which likely fit onto a smaller PCB than traditionally used.

[0063] Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, one of ordinary skill in the art will appreciate that the claimed subject matter may be practiced without these specific details. The features discussed herein are not limited to any particular hardware architecture or configuration. A utility meter may include any suitable configuration of components that behave as described herein. Any suitable programming, scripting, or other type of language, or combination of languages, may be used to implement the disclosure contained herein in software used to program or configure a utility meter or other device. Methods, devices, or systems that would be known by one of ordinary skill in the art have not been described in detail so as not to obscure the claimed subject matter.

[0064] Use of "adapted to" or "configured to" herein is intended to be open and inclusive, not excluding apparatus adapted or configured to perform additional tasks or steps. Additionally, use of "based on" is intended to be open and inclusive, in that a process, step, calculation, or other action "based on" one or more recited conditions or values ​​may in fact be based on additional conditions or values ​​beyond those recited. Headings, lists, and numbers contained in this application are for ease of description only and are not intended to be limiting.

[0065] While the subject matter of the present application has been described in detail with respect to certain embodiments thereof, it will be recognized that those skilled in the art, upon understanding the foregoing, may readily make modifications, variations, and equivalents of such embodiments. It is therefore to be understood that the present disclosure has been presented for purposes of illustration and not limitation, and is not intended to exclude inclusion of such modifications, variations, or additions to the subject matter of the present application as would be readily apparent to those skilled in the art.

Claims

1. A utility meter comprising a metering engine, a microprocessing unit (MPU), and one or more metering applications, the metering engine is configured to measure consumption of resources and generate consumption data based on the consumption of resources; The measurement engine is A measurement processor; Dedicated memory and a first operating system, the first operating system being a real-time operating system (RTOS) executed on the utility meter by the metering processor to enable the metering engine to perform time-critical metering functions in real time; the microprocessing unit (MPU) is connected to the measurement processor and includes one or more processor cores; the utility meter includes a second operating system separate from the first operating system, the second operating system being executed on the utility meter by the MPU; the one or more measurement applications are executed by the MPU on a second operating system of the MPU; said one or more metering applications utilising said consumption data; Supply and demand meter.

2. the MPU executes the one or more measurement applications using multithreading; 2. The utility meter of claim 1.

3. Each processor core of the MPU is assigned to a respective subset of the functions of the utility meter; Each processor core performs a respective subset of the functions described above.

2. The utility meter of claim 1.

4. a first processor core of the MPU is assigned to execute the second operating system; a second processor core of the MPU is assigned to execute the one or more measurement applications; 4. A utility meter as claimed in claim 3.

5. the utility meter further comprising a primary memory associated with the MPU; the dedicated memory of the metrology engine comprises a logical partition of the primary memory; 2. The utility meter of claim 1.

6. the utility meter further comprising a primary memory associated with the MPU; the dedicated memory of the metrology engine comprises separate hardware from the primary memory; 2. The utility meter of claim 1.

7. The metrology processor is a microcontroller unit.

7. A utility meter as claimed in claim 6.

8. the utility meter further comprises a wireless device configured to transmit the consumption data to a head-end system; a media access layer and a physical layer of the wireless device are executed by a second RTOS connected to the MPU; 2. The utility meter of claim 1.

9. The MPU is configured to run a virtual machine.

2. The utility meter of claim 1.

10. The MPU is configured to communicate with a cloud and execute cloud-based applications.

2. The utility meter of claim 1.

11. the MPU is configured to collect additional consumption data from the peer meter; 2. The utility meter of claim 1.

12. 10. The utility meter of claim 1, wherein the utility meter does not have an integrated display.

13. A utility meter having a metering engine, a microprocessing unit (MPU), a primary memory, and one or more metering applications, the metering engine is configured to measure consumption of resources and generate consumption data based on the consumption of resources; The measurement engine is a microcontroller unit (MCU) having a metrology processor and dedicated memory; a first operating system, the first operating system being a real-time operating system (RTOS) executed on the utility meter by the MCU to enable the metering engine to perform time-critical metering functions in real time; the microprocessing unit (MPU) is connected to the measurement processor and includes one or more processor cores; the primary memory is associated with the MPU and is separate from dedicated memory of the metrology engine; the utility meter includes a second operating system separate from the first operating system, the second operating system being executed on the utility meter by the MPU; the second operating system being separate from the RTOS of the measurement unit; the one or more measurement applications are executed by the MPU on a second operating system of the MPU; the one or more metering applications utilize the consumption data generated by the metering engine; Supply and demand meter.

14. The second operating system supports multithreading; The MPU executes the one or more measurement applications using multithreading.

14. The utility meter of claim 13.

15. Each processor core of the MPU is assigned to a respective subset of the functions of the utility meter; Each processor core performs a respective subset of the functions described above; a first processor core of the MPU is assigned to execute the second operating system; a second processor core of the MPU is assigned to execute the one or more measurement applications; 14. The utility meter of claim 13.

16. 14. The utility meter of claim 13, wherein the utility meter does not have an integrated display.

17. Installing a microprocessing unit (MPU) having one or more processor cores in a utility meter; installing a metering engine connected to the MPU at the utility meter, the metering engine being configured to measure a consumption of a resource and generate consumption data based on the consumption of the resource, the metering engine comprising a metering processor and a dedicated memory; installing a first operating system on the utility meter, the first operating system being a real-time operating system configured to be executed by the metering processor to enable the metering engine to perform time-critical metering functions in real time; installing a second operating system on the utility meter, the second operating system being separate from the first operating system, the second operating system being configured for execution by the MPU; and installing one or more measurement applications on the second operating system of the MPU; said one or more metering applications utilising said consumption data; method.

18. further comprising associating the MPU with a primary memory; the dedicated memory of the metrology engine comprises a logical partition of the primary memory; 20. The method of claim 17.

19. further comprising associating the MPU with a primary memory; the dedicated memory of the metrology engine comprises separate hardware from the primary memory; 20. The method of claim 17.

20. The second operating system supports multithreading.

20. The method of claim 17.

Images