Patent Application
20200280771
Many of today's energy metering systems such as residential and commercial electric and gas meters are bulky and not conveniently mounted or integrated with new or existing infrastructure. Mounting pedestals for self-contained meters are also bulky and costly, and are generally difficult to integrate with adjoining systems.
With the accelerating growth of distributed energy systems and mobile transportation and infrastructure, it would be desirable to provide energy metering systems that can be easily and unobtrusively integrated with existing infrastructure to provide convenient energy delivery, and real time consumption monitoring and transactions.
Table 1 is a list of acronyms used throughout this disclosure in descriptions of some embodiments.
In some embodiments, terms and acronyms as used herein have the following meanings: TLS (new name for SSL as in HTTPS). XSD/WADL—XML Schema Definition and Web Application Description Language (define XML format and Web Service interface). DER: Distributed Energy Resource—Any device that can put energy onto grid (Smart Inverters, Batteries, etc.). DRLC: Demand Response Load Control—A means for communicating to devices to control energy consumption. SIWG—Smart Inverter Working Group—Joint CPUC/CEC group looking at issues around increase in proliferation of DER and CA Rule 21 revisions. SunSpec Alliance—Group creating/promoting system interoperability in DER domain. CSEP—Consortium for SEP2 Interoperability—Produced certification plan for IEEE 2030.5. POST—Power-On Self-Test, a diagnostic testing sequence that a is run by a computer system's starting program to determine if one or more hardware and/or software components are testing properly. GET—a data retrieval process where the Client downloads data from the Server.
In some embodiments, the following are IEEE 2030.5 Terms: Discovery—The process by which Clients identify Resources on the network. Resources—A URI-addressable object that a client can GET from or POST to the Server. Function Sets—A logical grouping of resources that cooperate to implement IEEE 2030.5 features (e.g. Metering, DER). Function Set Assignment—A “label” applied to End Devices for the purposes of issuing commands to groups of devices. EXI—Efficient XML Interchange (compressed XML payload). xmDNS—Extended Multicast DNS (For service discovery like Apple's® “bonjour”). SFDI/LFDI—Short Form/Long Form Device Identifiers—Both are derived from hashing the device certificate.
In some embodiments, the system includes one or more of the following technology stacks:
Server: Operating System—Linux® (ubuntu); Languages—Java®, Groovy®, Javascript®; Frameworks—Grails®; Persistence—MySQL®.
Client: Operating System—Linux® (ubuntu core); Languages—Java®, Groovy®; Frameworks—SpringBoot®; Persistence—Filesystem® (or SQLite®); Servlet Container—Apache Tomcat®.
In some embodiments, the system includes one or more of the following open source libraries for the Server and/or Client: jlibmodbus—open source software for reading and writing to hardware registers using the MODBUS protocol; opendnp3—open source software for decoding and forming DNP3 requests; openssl—open source software for performing SSL functions; bouncycastle—open source software that contains the elliptic curve secp256r1 cipher suite required by IEEE 2030.5 for hashing the TLS certificate; openEXI—open source library for converting XML to/from the EXI (compressed) format; llrp-toolkit—open source library for Low-Level Reader Protocol (LLRP) used with RFID Readers.
Some embodiments of the energy metering system (hereafter, the “system”) include an electric meter assembly comprising a support platform including at least one transformer coupled to the support platform, where the socket housing is coupled to the support platform. The socket housing comprises a socket interface extending from a top side of the socket housing, and a secondary housing at least partially enclosed within the socket housing, wherein the secondary housing includes at least one CT shunt and at least one switch assembly including an actuator extending through the top side of the socket housing.
Some embodiments further comprise a removable or portable meter coupled to the socket interface. In some embodiments, the actuator includes at least one actuator shaft extending through the top side of the socket housing. In some embodiments, the at least one actuator shaft is configured and arranged to be coupled to at least one shunt via at least one roller contact. In some embodiments, the at least one actuator shaft is supported within a spring in a plunger housing, and the spring is positioned in a cavity of the plunger housing and extends coupled to a contact of the at least one actuator shaft.
In some embodiments, the shunts include a plurality of electrical contacts. In some embodiments of the system, the at least one at least one actuator shaft is configured and arranged to electrically couple and decouple from the plurality of electric contacts based on the movement of the at least one actuator shaft.
Some embodiments include an electric meter assembly comprising a socket housing including a socket interface extending from a top side of the socket housing, and a removable or portable meter coupled to the socket interface. Further, the electric meter assembly comprises at least one strap coupled at one end to at least one side of the socket housing. The at least one strap is configured and arranged to extend over at least a portion of the meter from one side of the socket to an opposite side of the socket.
In some embodiments, the at least one strap is pre-bent. In some embodiments, the socket housing includes at least one strap latch configured to couple to a second end of the at least one strap. Some embodiments include a tamper-resistant seal coupled to a side of the socket housing. In some embodiments, the tamper-resistant seal is configured and arranged to be threaded through an aperture in the at least one strap. In some embodiments, the at least one strap comprises metal or metal alloy. In other embodiments, the at least one strap comprises polymer.
Some embodiments include at least one bracket coupled to at least one side of the socket housing. Some embodiments include at least one power receptacle extending through one side of the socket housing. In some embodiments, the socket housing is coupled to a support platform including a coupled transformer.
In some embodiments, the system includes a Customer and Distribution Automation Open Architecture. In some embodiments, an IoT router facilitates communication between one or more remote electronics (e.g., electric meter assembly described herein). As used herein, references made to remote “electrical devices”, “end devices,” and/or “electronics” include structure that at least includes one or more circuits to allow a directed flow of electricity. In some embodiments, the system leverages one or more conventional advanced metering infrastructure (AMI) networks to control the one or more remote electronics. In some embodiments, one or more remote electronics comprise consumer electronics, RFID electronics, distribution-grid electronics, and solar aggregator-managed/individual-managed electronics.
In some embodiments, the system software is divided between a server (Server) and client (Client). In some embodiments, the Server software is designed for and deployed on a virtual machine. In some embodiments, the virtual machine includes an operating system. In some embodiments, the operating system is a conventional operating system (e.g., a Linux-based operating system). In some embodiments, the Client software is configured to be deployed on the IoT router. In some embodiments, the IoT router has limited RAM (e.g., 1 GB), disk space (e.g., 4 GB), CPU power, and/or some root-level capabilities due to the Ubuntu core operating system. In some embodiments, communication between the Client and Server is over a bandwidth-constrained or other AMI network. In some embodiments, design considerations limit the amount of communication between client and server as well as the bandwidth used by each communication occurrence.
In some embodiments, the Server and Client applications are deployed on a conventional Apache Tomcat application container. In some embodiments, the Server is deployed directly through an application web archive (WAR) file while the Client software is deployed through an Ubuntu core SNAP container.
In some embodiments, both the Server and Client HTTP communication are secured with conventional Transport Layer Security (e.g., TLS v 1.2). In some embodiments, access to the web interface of the Server is controlled by user login and password credentials. In some embodiments, one or more administrative accounts are configured by default with full read/write access to all server domains. In some embodiments, additional user accounts default to full administrative access but can be configured to have restricted visibility to specific data and read/write capabilities on a per user and per data type basis. In some embodiments, administration of the Client is performed directly through the application account on the IoT router.
In some embodiments, the system uses conventional third-party software. In some embodiments, one or more conventional third-party software the system uses is shown below in Table 2.
In some embodiments, the Server is a web-based, java application utilizing an open source web application framework (e.g., the Grails® framework) and a syntax-compatible object-oriented programming language (e.g., the Java-based Groovy® dynamic language). In some embodiments, the Server application runs in a conventional Tomcat® application container. In some embodiments, data for the application is persisted to an open-source relational database management system (e.g., MySQL®) database that is also hosted on the same virtual server as the application. In some embodiments, example conventional third-party applications compatible with the system are: Java®: 1.8.0_144; Grails®: 3.3.0.M2; Groovy®: 2.4.7; Tomcat®: 8.5.14, and/or MySQL®: 5.7.20-0ubuntu0.17.04.1.
In some embodiments, the Server and/or Client run a diagnostic testing sequence that is run by each system's starting program to determine if one or more hardware and/or software components are testing properly. In some embodiments, one or more Clients is configured to send a diagnostic testing sequence to one or more Servers that are configured to receive a diagnostic testing sequence.
Some embodiments provide GUIs that are designed to facilitate specific types of requests. In some embodiments, the Server contains one or more web Graphical User Interfaces (GUIs). In some embodiments, one or more GUIs initiate test requests with user-configurable parameters. In some embodiments, one or more GUIs are configured to perform CRUD (Create/Read/Update/Delete) operations against Domain elements stored in the Server database.
In some embodiments, the Server makes available a web service API configured to receive an external DNP3 request from the RT SCADA (Real-Time Supervisory Control and Data Acquisition) system for a remote electrically controlled device being managed by a Client. In some embodiments, the web service receives and interprets the inbound DNP3 message from the RT SCADA to determine which IoT router is hosting the device for which the message is intended. In some embodiments, the message is then forwarded to the Client on the appropriate IoT router either as the original DNP3 message via the DNP3 interface or via an IEEE 2030.5 Subscription Notification message depending on the desired OTA protocol. In some embodiments, the Server logs details for the inbound request and performs any necessary translation required before forwarding the request to the proper Client.
In some embodiments, the system includes at least one IEEE 2030.5 interface. In some embodiments, the Server supports all IEEE 2030.5 specification model elements and processes required to support one or more remote electronics.
In some embodiments, the system includes one or more RESTful Web Services (REST stands for Representational State Transfer, and RESTful Web Services are web services that are REST based). In some embodiments, IEEE 2030.5 specifications are described in the IEEE 2030.5 standard. In some embodiments, the Server implements a REST-based web service model conforming to the WADL and XSD provided with the specification. In some embodiments, Uniform Resource Identifiers (URIs) are used to make HTTP requests to the Server. In some embodiments, URIs also conform to the specification standards including those used for performing queries as defined in Section 6.6.1.
In some embodiments, the system includes one or more security methods and/or technologies. In some embodiments, IEEE 2030.5 requires one or more processes and technologies to provide security at the application layer. In some embodiments, one or more non-limiting processes implemented in the Server include Access Control List, Device Credentials, and/or Transport Layer Security (TLS) over HTTP:
Access Control List (ACL): The ACLs are configured on the server to grant/deny access to specific services by multiple criteria including down to a specific client/device according to some embodiments.
Device Credentials: The server supports electronic device authentication by all of the IEEE 2030.5 standard identifiers (SFDI/LFDI) requiring hashing of the device certificate and the optional PIN code according to some embodiments.
TLS over HTTP: Both Server and Client support TLS over HTTP using the required cipher suite elliptic curve secp256r1 according to some embodiments.
In some embodiments, the system includes Discovery. In some embodiments, the server responds to any IEEE 2030.5 client discovery requests made to the server's Device Capabilities Resource as described in the IEEE 2030.5 specification. In some embodiments, based on the server's ACL configuration and the device making the request, the Device Capabilities response contains the URI's for the Resources for which the device is allowed access.
In some embodiments, the system includes Registration. In some embodiments, In IEEE 2030.5, End Device Registration is facilitated by out-of-band communication of the End Device's SFDI and an optional PIN. In some embodiments, the Server supports persisting of these in advance of an IEEE 2030.5 Client's initial discovery or Resource request.
In some embodiments, the system includes Resources and Functions Sets. In some embodiments, The IEEE 2030.5 specification groups associated data model objects (“Resources”) and functions (“Function Sets”) into three Resource groups called Support, Common, and Smart Energy. In some embodiments, all the supported Resources and Function Sets are persisted to the database and entries for each are viewable and editable through a web-based interface by any user with administrative rights. In some embodiments, the system includes the Resources and Function Sets listed in Table 3:
In some embodiments, the system includes background processes. In some embodiments, the Server has one or more background processes that executes every five minutes to perform necessary IEEE 2030.5 server functions. In some embodiments, server functions include deleting Client Subscriptions that have not been renewed within a specified time (e.g., the last 36 hours (10.6.3.4)).
In some embodiments, the system includes proprietary extensions. In some embodiments, the IEEE 2030.5 specification allows for proprietary extensions to support additional, manufacturer-specific Device Capabilities and Resources. In some embodiments, Device Capabilities and Resources are used to support any Server-Client communication not defined within the 2013 version of the IEEE 2030.5 specification (SCADA, LLRP, etc.).
In some embodiments, the system includes at least one DPN3 Interface. In some embodiments, the Server DNP3 Interface is responsible for forwarding DNP3 messages from the Server to the Client DNP3 Interface. In some embodiments, the session is secured using user credentials shared between the Server and Client.
In some embodiments, the Client Technology stack includes Client software that is a web-based, Java application utilizing the java-based Groovy® dynamic language. In some embodiments, to reduce the size of the application footprint and save on processor utilization, the Client is configured directly from flat files and application data is persisted directly to the files ystem instead of using a separate database server. In some embodiments, the term “Client” should not be confused with the term “client” when used to represent an IEEE 2030.5 End Device. In some embodiments, the Client software is designed to support multiple End Devices per single instance of the Client software and IoT router hardware. In some embodiments, the Client implements conventional HTTP server design principles found in server-based systems for security and authentication including SSL/TLS and password-secured user accounts. In some embodiments, the system uses conventional third-party applications (e.g., Java: 1.8.0_144; Spring Boot: 1.5.7; Groovy: 2.4.10; Tomcat: 8.5.20).
In some embodiments, the Client includes one or more object models.
In some embodiments, the Client includes device polling. In some embodiments, the Client has a background process that is able to perform scheduled actions against the connected End Devices. In some embodiments, the process is configurable via a configuration (e.g., flat file).
In some embodiments, the Client includes at least one IEEE 2030.5 Server Interface. In some embodiments, the IEEE 2030.5 Server Interface includes Discovery. In some embodiments, to facilitate discovery of the IEEE 2030.5 Server by the Client, the Client uses one or more extensible Domain Name System (DNS) management schemes that uses XML to store data (e.g., xmDNS).
In some embodiments, the IEEE 2030.5 Server Interface includes Registration & Authentication. In some embodiments, for one or more launches of the Client process, the client performs one or more of the following standard IEEE 2030.5 functions: End Device registration process; discover the Server for the end device's allowed Device Capabilities; perform time sync of the Client with the Server; query all available Device Capabilities; and/or Subscribe to all allowed subscribable Resources and Function Sets.
In some embodiments, the IEEE 2030.5 Server Interface includes one or more scheduled processes. In some embodiments, the Client has a background process for performing one or more of the following necessary scheduled IEEE 2030.5 Client actions: issuing commands to the End Devices to perform DER Control; sending Subscription renewals to the Server; and or ending Mirrored Metering data to Server.
In some embodiments, the Client includes at least one DPN3 interface. In some embodiments, the Client DNP3 Interface is responsible for receiving forwarded DNP3 messages from the Server's DNP3 Interface and forwarding them to the appropriate End Device connected to the IoT router. In some embodiments, the Client DNP3 Interface supports physical layer connections both via TCP/IP and Serial over USB.
In some embodiments, the sequence diagrams shown in
Before any embodiments of the system are explained in detail, it is to be understood that the system is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The system is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings.
The following discussion is presented to enable a person skilled in the art to make and use embodiments of the system. Various modifications to the illustrated embodiments will be readily apparent to those skilled in the art, and the generic principles herein can be applied to other embodiments and applications without departing from embodiments of the system. Thus, embodiments of the system are not intended to be limited to embodiments shown, but are to be accorded the widest scope consistent with the principles and features disclosed herein. The following detailed description is to be read with reference to the figures, in which like elements in different figures have like reference numerals. The figures, which are not necessarily to scale, depict selected embodiments and are not intended to limit the scope of embodiments of the system. Skilled artisans will recognize the examples provided herein have many useful alternatives and fall within the scope of embodiments of the system.
The attachment of traditional self-contained meters to power infrastructure is usually accomplished using a pedestal mount. For example,
Some embodiments of the system described herein include improvements over the traditional self-contained meters and mounting solutions described above. For example, some embodiments include an electric meter end point hardware assembly including an electric meter socket and removable or portable meter. Some embodiments include a panel socket that in some instances can be a customer-owned device. The socket provides a coupling point for at least one electric meter end point hardware assembly. For example, some embodiments include a meter socket that can function as a hub, receptacle, and/or contact point for one or more further components of an electric metering system. In some embodiments, the meter socket can contain voltage and/or current sensors. Further, the meter socket can provide DC and/or induction power supply and female connection for other metrology and communication devices such as electric, gas, water, data, etc. In some embodiments, the meter socket can include at least one standard connection known in the art, at least one of which can be replaceable. The meter socket can include sensing of AC and/or DC values of phase voltage, phase current, and phase angle.
In some embodiments, at least one hold-down strap can be implemented for securing the meter 100 to a meter socket 210. In some embodiments, a hold-down strap can be positioned over the meter 100, with each end of the strap secured to opposite sides of the socket. In some embodiments, the hold-down strap can be pre-bent to an approximate final shape for ease of installation. In some embodiments, the socket 210 can include a strap-latch for securing one end of the hold-down strap to one side of the socket 210. In some embodiments, two strap latches can be used, one positioned on each side of the meter socket. In some embodiments, the strap latch can be riveted to the enclosure of the socket. In some embodiments, a tamper-resistant seal location can be coupled to the strap latch. In some embodiments, the opposite end of the hold-down strap can be secured to the meter socket using a riveted weather sealed metal plate. In some embodiments, a pole bracket can be coupled to one side of the enclosure. The bracket can be used as an attachment structure enabling the meter socket and meter to be mounted to another structure or surface. For example, referring to
In some embodiments, the tie-down strap 220 can extend over the meter 100 and couple to a strap-latch 230 (shown in
In some embodiments, the strap-latch 230 can comprise a tamper-resistant seal. For example, some embodiments include a seal 232 that can be threaded through an aperture in the tie-down strap 220. The non-limiting embodiment of
In one non-limiting embodiment, the smart pole meter 99 of
In one non-limiting embodiment, the smart pole meter 99 of
In some embodiments, the smart pole meter can be coupled in close proximity to a transformer. In some embodiments, the transformer-rated smart pole meter socket can comprise an assembly that can be used to mount a transformer-rated meter, typically used in smart pole applications. In some embodiments, the assembly can comprise a current transformer with a ratio of between 50:5 and 200:5, an electrical box, a custom 4 pole meter socket with automatic current transformer (“CT”) shunt circuit, and a mounting plate, which can be adapted to any mounting hole pattern. In some embodiments of the system, the current transformer can be mounted directly to the mounting plate, above the meter socket electrical box. The CT is used to step down the service current from up to 200 A to 5 A. The 5 A secondary is required to bring the measured current down to a level suitable for the meter to measure. The electrical box houses the wiring required to get the voltage and current to the meter socket, and then to the meter. In some embodiments, the meter socket comprises a modified ANSI 19-20 twist-lock female four pole connector. The connector is physically modified on the upper section to allow clearance for the bottom face of the meter. It is also mechanically modified to allow for two redundant custom designed plunger switches to protrude through the top of the connector. The connector can be rated for 480 VAC and 20 AAC or other voltage ranges.
In some embodiments, an assembly, such as a meter socket assembly, can be used to mount a transformer-rated meter (e.g., such as a smart meter typically used in smart pole applications). In some embodiments, the assembly can be made up of a current transformer, having a ratio of between 50:5 and 200:5; an electrical box; a custom 4 pole meter socket with automatic current transformer shunt circuit, and a mounting plate, which can be adapted to any mounting hole pattern. In some embodiments, the current transformer can be mounted directly to the mounting plate, above the meter socket electrical enclosure. In some embodiments, the current transformer can be used to step down the service current from up to 200 A to 5 A. The 5 A secondary is required to bring the measured current down to a level suitable for the meter to measure. In some embodiments, the electrical box can house the wiring required to get the voltage and current to the meter socket, and then to the meter. In some embodiments, the meter socket can be made up of a modified ANSI 19-20 twist-lock female four pole connector. In some embodiments, the connector can be physically modified on the upper section to allow clearance for the bottom face of the meter. Further, in some embodiments, it can be mechanically modified to allow for two redundant custom designed plunger switches to protrude through the top of the connector. In some embodiments, the connector can be rated for 480 VAC and 20 AAC. For example,
In some embodiments of the system, the meter 100 can comprise the smart meter shown in
Table 4 outlines the technical specifications for one embodiment of the transformer-rated meter 400 shown in
74%
77%
82%
82%
82%
In some embodiments, the meter 400 can be configured for remote monitoring enabling an RF network to send captured meter data back to a central monitoring system. In some embodiments, the meter 400 can include a NIC 451 board from Silver Spring Networks, Redwood City, Calif. In some embodiments, the smart pole meter 400 can include a network communication card to remotely send energy usage back to a head-end system (e.g., such as a network communication card from American Megatrends, Inc.)
In some embodiments, the meter 400 can include power metering. In some embodiments, the meter 400 can monitor electrical parameters such as current, voltage, frequency, power factor, kW and kWh with an accuracy of 0.2%. For example, some embodiments include an on-chip metering engine that can provide a value to the NIC 451 board upon request. Some embodiments include instant power measurement where the meter starts measuring power parameters the moment it is powered on. Some embodiments include over-the-air upgrade capability, where the meter's host controller firmware can be upgraded over the air. In some embodiments, the meter's microcontroller can be a 16-bit microcontroller with the following specifications: a modified “Harvard Architecture” with up to 16 MIPS operation @ 32 MHz, 8 MHz internal oscillator, 4× PLL option, multiple divide options, 17-bit×17-bit single-cycle hardware, fractional/integer multiplier, 32-bit by 16-bit hardware divider, 16×16-bit working register array, C compiler optimized instruction set architecture, 76 base instructions, flexible addressing modes, linear program memory addressing up to 8 Mbytes with unlimited number of ota-programmable data channels until memory is exhausted, linear data memory addressing up to 64 Kbytes with unlimited number of OTA-programmable data channels until memory is exhausted, and two address generation units for separate read and write addressing of data memory.
In some embodiments, a transformer-rated pole meter socket and transformer assembly can include a CT shunt circuit. The purpose of this mechanism is to allow for the safe removal of the meter from the socket. If this circuit were not in place, dangerous voltages could be present at the socket/meter connection at the point of first contact breakage (up to 4800V), caused by an open CT secondary. In normal socket based meter applications, this function is performed with mechanical test switches. In some embodiments, the CT shunt circuit can comprise two redundant plunger switches, each of which are spring loaded to allow an plunger actuator shaft to protrude through the top of the connector housing and make contact with the plastic base of the meter. In some embodiments, when the meter is seated into the connector, the plunger switch actuators can be pushed into the switch assembly, causing the springs to be compressed. In some embodiments, the actuator motion can cause machined cams in the shaft of the plunger to be pushed down and off spring loaded roller arms on two redundant electrical switches. In some embodiments, as the cams move off the roller arms of the switches, the contacts on the two switches can move from a closed to an open state. In some embodiments, the switch contacts are wired in parallel for redundant safety purposes. In some embodiments, when the switch contacts open, current can flow from the CT secondary to the meter current elements. In some embodiments of the system, when the meter is being removed (e.g., by an electrical technician), the technician will first rotate the meter, and then lift the meter up and out of the socket. As the meter is raised off the top face of the connector, but before the connector contacts of the meter disengage from the contacts of the meter socket, the plunger cam can move up to the point where the roller arms of the switches are pushed back to the position that causes the switch contacts to close, shunting the secondary current from the CT safely to ground.
Referring to
Some embodiments of the system include one or more safety devices. For example,
In some embodiments, when force is applied to the end 721 of a plunger actuator shaft 720, the plunger actuator shaft 720 can be forced towards the cavity 737 compressing the spring 725 through contact with the contacts 715. In some embodiments, when force is released or lessened from the end 721 of a plunger actuator shaft 720, the plunger actuator shaft 720 can be forced away from the cavity 737 as the spring 725 applies force to contacts 715. In some embodiments, as the meter 100 is coupled to socket interface 355 of adaptor socket 359 (e.g., see exploded assembly view of
In some embodiments, one or more components, modules or assemblies of a smart pole meter system can be configured as a stand-alone unit capable of integrating externally or internally with various devices and applications. In some embodiments of the system, one or more components, modules or assemblies of a smart pole meter system can be integrated with various other systems to provide additional and augmented functions. For example,
In some embodiments, transformer-rated pole meter systems as shown in
Further,
In some embodiments, through one or more web-enabled applications and/or a cloud service system, customer access to various metering services can be provided, including, but not limited to billing, energy (and/or gas, water, data, information, etc.) usage and statistics, current energy (and/or gas, water, data, information, etc.) use and system/device status. Once integrated or coupled to a client's infrastructure, energy use (kWh and kVARh) and operational function such as real time (or substantially real time) voltages and current, and grid awareness such as the physical location of the meter can be processed through the cloud resource linked with a utility data management system. Some embodiments can include provisions for phase voltage, current and phase angle in real (or substantially real) time. In some embodiments, computation of kWh consumption and other power metrics can be processed by cloud computing with various communication back-haul options. In some embodiments, the customer can deploy at least one smart pole energy meter at, for example, a fixed location (such as a residential or commercial building or business), and monitor any of the aforementioned parameters at the location or at a remote location using a mobile device. For example, in some embodiments, the customer can use a mobile laptop computer and/or mobile phone or smart phone to monitor at least one parameter of the energy meter. Personal digital assistants, pagers, digital tablets, or other processor-based devices can be used to access the cloud resource either through a wireless (e.g., a cellular or WiFi signal) or through a wired link coupled to the cloud resource.
In some embodiments, a customer can deploy at least smart pole meter system with a temporary or seasonal residential or commercial building or business, or with a remote charging station for an electric vehicle, and monitor any of the aforementioned parameters at the location or at a remote location. In the latter example embodiments, smart pole meter system can be used to guide customers when and where to plug in either to charge or discharge, and potentially lower operating/maintenance cost of an EV. This can enable customers and utilities to better manage EV loads (when charging) and generations (when discharging), and help lower costs of the grid construction, maintenance and operation. Thus, EVs with embodiments of the smart pole meter systems described herein can support and benefit the electrical grid system, and customers can be provided with real time charging/discharging cost and kWh quantity. Furthermore, because the cloud-based system can be managed by and/or coupled to at least one utility data management system, the system can be used to guide customers when and where to plug in either to charge or discharge based on location, charging station status, local and area-wide grid loads, etc., providing real time location based charge/discharge updates, operating with real time data on the grid. Some embodiments can include a two-way inverter safety switch for inverter application for charge/discharge.
In some other embodiments, the smart pole metering system can include a gas metering system, multi-color streetlight, electric vehicle induction charging, data and information metering systems, streetlight metering and/or telecom data metering, and vehicle telemetry. Thus the electrical outages, gas/water leakage, and usage information/data can be monitored and detected in real or near real time. Further, in some embodiments, the smart pole meter system can function as a telecommunication conduit for other services such as internet, video, TV, advertisements, etc. Moreover, in some embodiments, using customer identification information, the smart pole meter system can function as a telecommunication conduit for services (i.e., internet, video, TV, advertisements, etc.) that are tailored or targeted to the customer's needs, preferences, or geographic location. In some embodiments, the system can generate licensing fees for revenues that can help lower the customer's energy rate. Further, in some embodiments, the system can enable customers to be informed about commercial services, public safety (i.e., shopping, police, fire, hospital, etc.), and can be used to improve public and personal safety (i.e., an emergency situation, such as accidents, stranded vehicle, etc.). Some embodiments can also include electrical outage and gas/water leakage monitoring and/or call notifications and identifications. Further, some embodiments can function as or couple to telecom hubs that can provide improved bandwidth for field personnel communications and provide mobile telemetry. In some embodiments, the system can provide local, area-wide, and/or global Internet services. Further, in some embodiments, the smart pole meter system can function to provide vehicle telemetry and/or form part of a self-driving infrastructure. In some embodiments, using a combination of smart poles and/or micro cell sites, the smart pole meter system relay vehicle telemetry information, and provide remote monitoring of charge/discharge within an electric vehicle route.
Some embodiments of the system include at least one RFID module that provides tracking and asset management capability. For example, in some embodiments, the meter socket 350 and/or meter 100 can include at least one RFID module. In some embodiments, the RFID module can comprise a variety of modules types, including common RF protocols and standards. For example, in some embodiments, the RFID module can include class 1 including a simple, passive, read-only backscatter tag with one-time, field-programmable non-volatile memory. Other embodiments can utilize class 2, a passive backscatter tag with up to 65 KB of read-write memory. Other embodiments can use a class 3: a semi-passive backscatter tag, with up to 65 KB read-write memory; essentially, and with a built-in battery. Some embodiments include a class 4: an active tag with built-in battery, an internal transmitter for transmitting to the reader. Some embodiments can implement a class 5: an active RFID tag that can communicate with other class 5 tags and/or other devices. Some embodiments include RFID standards for automatic identification and item management (ISO 18000 series standards). Some embodiments of the system include an 18000-1 standard that uses generic parameters for air interfaces for globally accepted frequencies. Some embodiments can use an 18000-2 standard with an air interface for 135 KHz. Some embodiments can use a 18000-3 standard with an air interface for 13.56 MHz. In some embodiments of the system, standard 18000-4 can use an air interface for 2.45 GHz. In other embodiments of the system, standard 18000-5 with an air interface for 5.8 GHz can be used. In some other embodiments, 18000-6 with an air interface for 860 MHz to 930 MHz can be used. In some alternative embodiments, standard 18000-7 with an air interface at 433.92 MHz can be used. Some embodiments include RF components operating at a 2.4 GHz-ISM frequency band. Some embodiments include an RF system and method of operation compatible with Bluetooth® and IEEE 802.11x within a mobile device. Bluetooth is a registered trademark owned by Bluetooth® SIG.
In some embodiments, the meter socket 350 and/or meter 100 can be equipped with various radio frequency communication technologies that can switch between, receive and provide, including but not limited to, Cellular 4G/LTE, WiFi, WiMAX, WiSun, 400 MHz RF, 900 MHz RF, etc. In some embodiments of the system, the meter socket can be replaceable, interchangeable and/or upgradeable depending on the energy needs and requirements of the customer or the utility company. For example, some embodiments of the system also include an RF module that can provide sub-metering and communication interconnections between sub-meters and main meters, and interconnectivities with other sub-meters. Moreover, in some embodiments of the system, the system can provide services such as Internet, home phone, TV, and video. In some embodiments, the RF module can be coupled to a fixed energy meter. For example, in some embodiments, the RF module can be mounted or otherwise coupled to a fixed energy meter. In some other embodiments, the RF module can be mobile and not mounted or otherwise physically coupled to an energy meter. In some embodiments, the RF module can be removably mounted or coupled to an energy meter. In some embodiments, when the RF module is mounted or coupled to the energy meter, information can be transferred between the energy meter and the RF module. In some embodiments, a user can move the RF module to within a specific distance from the energy meter to enable transfer of information between the RF module and the energy meter. The specific distance includes distances that are known in the art for RF data transmission distances for known RF standards.
In some embodiments, the energy and data/information metering system can include an energy and data/information meter including at least one sensor and power supply. The system can include a socket based—ANSI (CL 200, CL20), a disconnect switch, and a communication Module with display and switchable multi-communication technologies (4G/LTE, WiFi, WiMAX, WiSun, 400 MHz & 900 MHz RF, etc.) Standard male/female pins can be used to make connection to the meter, and can comprise neutral, phase a+b+c voltage ac signals, phase a+b+c current ac signals, as well as +/−dc power supply connections to electric, gas, water, data/information meters/metering systems. The system can be modular and enable mobility, and be configured for multi-network and cloud computing (described earlier). Further, the energy meter can include an internal-meter temperature monitoring system. When coupled to the cloud system, billing information can be processed and billing data transferred to the utility MDM. The system can be utilized across a wide variety of application including fixed premises, circuit breakers, appliances, EVs, PVs, electric charging stations, battery storage, Microcell Tower/Pole, etc., capable of monitoring phase voltage, current and angle real time. In some embodiments, the system can provide hotspot services (Internet, home/car/cell phone, TV, Video, etc.) In some embodiments, the voltage and current sensors of the system can include potential and current transformers and/or Hall Effect technology. In some embodiments, the system can implement a 200 Amp disconnect switch for residential systems, and an AC/DC power supply for utility block. Standard male/female pins can be used to make connection to the block: Neutral, Phase A+B+C voltage AC signals, Phase A+B+C current AC signals, AC or +/−DC Power Supply.
In some embodiments of the system, any of the meters or assemblies described herein can be mounted or coupled to multiple applications such as buildings, homes, appliances, circuit breakers, PVs, battery storages, EVs, charging stations, microcell tower/pole, etc. Applications can include parking lot lighting, mobile home power, residential/commercial, electric vehicle charging station at streetlight poles, photovoltaic (PV), PV inverter, distribution capacitor monitoring.
In some embodiments, any of the meters or assemblies described here can perform, provide, store, and poll/communicate/transfer routinely, on demand, and ad-hoc the telecommunication bits/bytes metrology in utility cloud computing and/or in the meter. In some embodiments of the system, power quality information voltage, current and phase angle values at a user-specified interval, and/or sampling technique on phase voltage and current wave forms can be used by the system to provide a variety of energy metrics. For example, in some embodiments, the system can calculate the energy usage, and/or interval temperature, electric energy kWh and kVARh values in a user-specified period, and/or electric service analyses and information to detect wrong meter socket installations, and/or electric service analyses and information to detect tampering and provide potential tampering leads. In some embodiments, the system can include communication that can switch between technologies or not switch (are fixed). Some embodiments include communication that can utilize and/or provide any one of telecommunication technologies as designated or programmed. In some embodiments, communications can be bidirectional between the meter and the cloud platform, and live monitoring/display can occur in the office. In some embodiments, communications frequency is user-specified in milliseconds, shorter, or longer, on demand, ad-hoc, etc.
In some embodiments, any of the meters or assemblies described herein can assemble data for a graphical presentation of electric phase voltage and current waveforms, and provide access to display of voltage, current and phase angle values real time. Further, some embodiments can provide and store voltage, current and phase angle values at a user-specified interval, and transfer the interval data to other utility applications coupled to the network (e.g., the cloud network). Some embodiments provide a user with the capability to provide and store power quality information voltage, current and phase angle values at a user-specified interval. Moreover, in some embodiments, the system can perform sampling techniques on phase voltage and current wave forms to calculate the energy usage.
In some embodiments, any of the meters or assemblies described herein, the RF module, the RFID module and/or the meter component of the system can include one or more security protocols. For example, some embodiments include advanced encryption standard (AES). Some embodiments can include performance of cryptographic challenge and response protocols, including dynamic challenge-response protocols.
In some embodiments of the system, any of the meters or assemblies described herein can incorporate various semiconductor technologies that enable mobility metering and broadband metering within an integrated device with reduced size compared with conventional metering systems. For example, some embodiments utilize various system-on-chip technologies that can integrate a variety functions that would normally reside in separate modules and/or coupled devices. In some embodiments, the system-on-chip systems can incorporate an operating system, and a host interface along with data collection and error control processing. Further, the system-on-chip can integrate mobility and communications modules, with seamless integration with the operating system, data collection, and host interface.
Some embodiments of the energy metering system include and/or communicate with the electric meter assembly described herein and shown in
The following is an overview of the Use Cases (UCs) described herein according to some embodiments. In some embodiments, UC 2 includes DER devices (such as, but not limited to, a Smart Inverter); UC 3 includes Environmental Sensor Communication; UC 4 includes smart Thermostat Control; UC 5 includes communications and control of remote SCADA devices; UC 6 includes data acquisition and control telemetry; UC 7 includes data acquisition and control telemetry.
In some embodiments, UC 2 End Devices include SolarEdge SE5000A and Fronius Primo 5.0-1 208-240. In some embodiments, UC 2 End Device Connectivity and Protocols include MODBUS on TCP/IP over ethernet. In some embodiments, UC 2 Server-Client Communication includes IEEE 2030.5. In some embodiments, UC 2 Server Functions include UI for creation of DER Programs and sending IEEE 2030.5 Notifications to the Client.
In some embodiments, UC 2 Client Functions include Scheduled polling of devices; DER Program Management (Primacy, Overlapping Events, Randomization) and POSTing to Server of MirroredMetering and LogEvent messages. In some embodiments, UC 2 included scheduled reactive power dispatch; scheduled real power curtailment; DER curve set/change; data collection (scheduled and on demand); firmware updates; time sync; and asynchronous notifications of diagnostic, alarm, or errors on inverter.
In some embodiments,
In some embodiments,
In some embodiments, Use Case 2 included DER Communications. In some embodiments, For Use Case 2, the Server and Client facilitates communication between the Server and two different makes and models of Smart Inverter. In some embodiments, the primary method of reading data from and performing control on the Smart Inverter was through a MODBUS interface. In some embodiments, MODBUS register maps for each of the Smart Inverters can be found in the appendix. In some embodiments, the device details were as follows: SolarEdge SE5000A, Software ver. 3.1803; Fronius Primo 5.0-1 208-240, Software ver. 3.3.5-22. In some embodiments, each inverter was connected directly to separate IoT routers staged in the ATS lab via direct Ethernet cable. In some embodiments, the inverters were configured to either pull an IP from the IoT router via DHCP or assigned a static IP on the subnet of the IoT router. In some embodiments, each Client was configured with details for each device including the TLS certificate, PIN, and local IP address of the End Device. In some embodiments, the Server was configured with End Device details required for registration including the SFDI and PIN as well as FunctionSetAssignment associations, ACLs, and Device Capabilities. In some embodiments, with regard to End Device Protocol, all messaging to the End Device was forwarded by or translated locally within the Client to MODBUS for communication to the End Device. In some embodiments, the Client had an End Device polling process that began automatically to poll the Smart Inverter registers on a configurable schedule. In some embodiments, the polling process read, translated, and recorded to a flat file database in a plain text file from the registers. In some embodiments, the register addresses, size, and type are configurable, but by default the polling process polled the standard model SunSpec 111—Inverter registers.
In some embodiments, Use Case 2 IEEE 2030.5 Interface included Subscription/Response, DER Program/Control, Firmware Update, Metering, and/or Events. In some embodiments, upon device registration, the Client was configured to subscribe to the DER Program Function Set to receive Notifications of changes to DERPrograms that affect the End Device. In some embodiments, the Server GUI is configured to allow a user to specify the details of a DERProgram (primacy, start/end times, DERControls, FunctionSetAssignments, etc.). In some embodiments, the DERProgram details were sent to all appropriate Clients based on the FunctionSetAssignments. In some embodiments, the Clients managed the schedule of Events and issued commands to the End Devices as required. In some embodiments, End Device Firmware updates are configured to be managed by the FileDownload Function Set. In some embodiments, the firmware files were uploaded to and hosted on the Server for retrieval by the Client. In some embodiments, once the files were retrieved to the Client, they were be pushed to the End Device using a device-specific process and/or protocol. In some embodiments, the system was configured to post metering data (Voltage, Current, Power, Reactive Power, etc.) that is polled by the Client from the End Device to the Server via the Mirrored Metering Function Set. In some embodiments, polling and translation of asynchronous events (alarms, etc.) was performed against the MODBUS registers and posted to the Server via the Log Event Common Resource.
In some embodiments, Use Case 3 included Environmental Sensor Communications. In some embodiments, UC 3 End Devices include Kinemetrics (seismic); Raspberry Shake (seismic); and/or Raspberry Pi+Gas Sensor. In some embodiments, UC 3 End Device Connectivity and Protocols include HTTP/SeedLink on TCP/IP over ethernet. In some embodiments, UC 3 Server-Client Communication IEEE 2030.5. In some embodiments, Server Functions include UI to initiate commands to Sensor and to view data and/or sending IEEE 2030.5 Notifications to Client.
In some embodiments, UC 3 Client Functions include translating IEEE 2030.5 messages to SeedLink/HTTP requests and send to the End Device; polling End Device regularly to record data over time; and/or sending Notification Responses and collecting data back to Server. In some embodiments, UC 3 testing included Earthquake Sensor—Real time magnitude query; Earthquake Sensor—Telemetry (Display data collected over time); Gas Sensor—Real time gas concentration query; and/or Gas Sensor—Telemetry (Display data collected over time).
In some embodiments, for UC 3 the Server and Client was configured to facilitate communication between the Server and three different sensor End Devices. In some embodiments, the Server provided a web-based GUI for which to initiate the desired command sent to the sensor End Devices and displayed response data. In some embodiments, communication between the Server and Client used IEEE 2030.5 as the OTA protocol. In some embodiments, with regard to device details, the following were the sensor devices that were staged for testing of the environmental sensors: Kinemetrics® Etna, Raspberry Shake®; Gas Sensor (attached to Raspberry Pi®). In some embodiments, each sensor device was connected directly to an IoT router staged in the ATS lab via direct Ethernet cable. In some embodiments, each sensor device was configured to either pull an IP from the IoT router via DHCP or assigned a static IP on the subnet of the IoT router. In some embodiments, with regard to End Device protocol, all messaging to the End Devices was translated locally within the Client to HTTP for communication to the End Devices. In some embodiments, data retrieval from the seismic devices (e.g., Raspberry Shake®) was supported locally by the SeedLink® protocol. In some embodiments, each Client was configured with details for each device including the TLS certificate, PIN, and local IP address of the End Device. In some embodiments, the Server was configured with End Device details required for registration including the SFDI and PIN as well as FunctionSetAssignment associations, ACLs, and Device Capabilities. In some embodiments, the Client had an End Device polling process that began automatically to poll the sensor devices on a configurable schedule. In some embodiments, the polling process read, translated, and recorded to a flat file database data from the devices. In some embodiments, the Client process also included the business logic to identify events or conditions required to generate asynchronous alerts to the Server.
In some embodiments, Use Case 3 IEEE 2030.5 Interface included Subscription/Response and Log Events. In some embodiments, upon device registration, the Client subscribed to the Proprietary Extension for sensor communication to receive Notifications of inbound sensor commands. In some embodiments, upon communication of the sensor command to the End Device by the Client, communication back to the Server was facilitated by the Response Function Set. In some embodiments, any events or conditions identified by the Client polling process that required an asynchronous message sent to the Server was facilitated by the Log Event Function Set.
In some embodiments, Use Case 4 included Smart Thermostat Communications. In some embodiments, the UC 4 End Devices include at least one Raspberry Pi Thermostat. In some embodiments, UC 3 End Device Connectivity and Protocols include HTTP on TCP/IP over ethernet. In some embodiments, UC 3 Server-Client Communication include IEEE 2030.5. In some embodiments, UC 3 Server Functions include UI for creation of DRLC Events and sending IEEE 2030.5 Notifications to the Client.
In some embodiments, UC 4 Client Functions include translating IEEE 2030.5 messages to HTTP requests and sending to End Device; polling the End Device regularly to record data over time; and sending Notification Responses and collected data back to Server. In some embodiments, UC 4 testing includes Demand Response Functionality; Energy Efficiency Functionality (setting duty cycle and temperature set points); and/or Read device information.
In some embodiments, for UC 4, the Server and Client facilitated communication between the Server and one Smart Thermostat End Device. In some embodiments, the Server provided a web-based GUI to initiate the desired command sent to the Smart Thermostat End Device and displayed response data. In some embodiments, communication between the Server and Client used IEEE 2030.5 as the OTA protocol. In some embodiments, the Smart Thermostat devices were Honeywell® brand thermostats including T6, WiFi 9000, Lyric TH, and T5. In some embodiments, the Smart Thermostat device was connected directly to an IoT router staged in the ATS lab via direct Ethernet cable. In some embodiments, the Smart Thermostat device was configured to either pull an IP from the IoT router via DHCP or was assigned a static IP on the subnet of the IoT router. In some embodiments, all messaging to the End Devices was translated locally within the Client to a corresponding HTTP request for communication to the End Devices. In some embodiments, each Client was configured with details for each device including the TLS certificate, PIN, and local IP address of the End Device. In some embodiments, the Server was configured with End Device details required for registration including the SFDI and PIN as well as FunctionSetAssignment associations, ACLs, and Device Capabilities. In some embodiments, the Client had an End Device polling process that began automatically to poll the End Device on a configurable schedule. In some embodiments, the polling process read, translated, and recorded to flat file data from the End Device.
In some embodiments, Use Case 4 IEEE 2030.5 Interface included Subscription/Response. In some embodiments, upon device registration, the Client subscribed to the DRLC Function Set to receive Notifications of inbound Smart Thermostat commands. In some embodiments, upon communication of the DRLC command to the End Device by the Client, communication back to the Server was facilitated by the Response Function Set.
In some embodiments, UC 5 includes SCADA devices. In some embodiments, UC 5 End Devices include Form 6 Line Recloser; Intellicap 2000 Controller; and/or 5802 Underground Switch Controller. In some embodiments, UC 5 End Device Connectivity and Protocols include DNP3 on Serial over USB. In some embodiments, UC 5 Server-Client Communication include DNP3 over IEEE 2030.5 and/or DNP3 over HTTP. In some embodiments, UC 5 Server Functions include receiving and decoding DNP3 from RT SCADA and returning responses and/or wrapping and sending DNP3 message to Client and receiving responses.
In some embodiments, UC 5 Client Functions include forwarding DNP3 messages to the End Device and/or returning Response to Server. In some embodiments, UC 5 testing includes Binary points (all 3 devices); Analog points (all 3 devices); and/or Control points (all 3 devices).
In some embodiments, Use Case 5 included SCADA Communications. In some embodiments, the Server and Client facilitated communication between an instance of DC Systems SCADA management software, RT SCADA, and three different types of SCADA devices. In some embodiments, the Server performed two functions: communicating with RT SCADA via the DNP3 API and forwarding messages to the appropriate Clients. In some embodiments, SCADA communications Use Case was configured to support the use of both IEEE 2030.5 and DNP3 as the OTA protocol. In some embodiments, the following were the three SCADA device types that were staged in the TicNet lab for testing of the Use Case: Cooper Form 6 Line Recloser (Ethernet); S&C Intellicap Plus Cap Bank Controller (Serial); and S&C 5802 Underground Switch Controller (Serial). In some embodiments, Each SCADA End Device supported either serial or TCP/IP connectivity and were connected to the IoT router via a serial or Ethernet over USB cable. In some embodiments, with regard to End Protocol, all messaging to the End Device was forwarded by or translated locally within the Client to DNP3 for communication to the End Device. In some embodiments, each Client was configured with details for each device including the TLS certificate, PIN, and local IP address of the End Device. In some embodiments, the Server was configured with End Device details required for registration including the SFDI and PIN as well as FunctionSetAssignment associations, ACLs, and Device Capabilities. In some embodiments, no background processes were required for the SCADA Use Case. In some embodiments, the DNP3 API was used in the SCADA Use Case to receive DNP3 control commands from the SCADA Master software, RT SCADA.
In some embodiments, Use Case 5 IEEE 2030.5 Interface included Subscription/Response. n some embodiments, upon device registration, the Client subscribed to the Proprietary Extension for SCADA communication to receive Notifications of inbound DNP3 messages. In some embodiments, upon communication of the DNP3 message to the End Device by the Client, communication back to the Server was facilitated by the Response Function Set.
In some embodiments, UC 6 End Devices include Zebra FX9600 and/or Impinj xArray. In some embodiments, UC 6 End Device Connectivity and Protocols includes LLRP on TCP/IP over ethernet. In some embodiments, UC6 Server-Client Communication includes IEEE 2030.5. In some embodiments, UC 6 Server Functions include UI to initiate commands to RFID Reader and to view data and/or sending IEEE 2030.5 Notifications to the Client.
In some embodiments, UC 6 Client Functions Client Functions include Translating IEEE 2030.5 messages to LLRP and sending to the End Device and return Response to Server. In some embodiments, UC 6 testing include Reader Management; Radio Management; Firmware Updates; and/or retrieving tag data.
In some embodiments, Use Case 6 included RFID Reader Communications. In some embodiments, for Use Case 6 the Server and Client facilitated communication between the Server and two different RFID reader End Devices. In some embodiments, the Server provided a web-based GUI for which initiate the desired command sent to the RFID reader End Devices and for display of response data. In some embodiments, Communication between the Server and Client used IEEE 2030.5 as the OTA protocol. In some embodiments, the following were the two RFID reader devices for testing of the RFID reader Use Case: Zebra® FX9500; and Impinj® xArray. In some embodiments, each RFID reader was connected directly to an IoT router via direct Ethernet cable. In some embodiments, Each RFID reader was configured to either pull an IP from the IoT router via DHCP or assigned a static IP on the subnet of the IoT router. In some embodiments, with regard to End Device Protocol, all messaging to the End Device was translated locally within the Client to LLRP for communication to the End Device. In some embodiments, each Client was configured with details for each device including the TLS certificate, PIN, and local IP address of the End Device. In some embodiments, the Server was configured with End Device details required for registration including the SFDI and PIN as well as FunctionSetAssignment associations, ACLs, and Device Capabilities. In some embodiments, no background processes are required for the RFID Use Case.
In some embodiments, the Use Case 6 IEEE 2030.5 Interface included Subscription/Response and Firmware Update functionality. In some embodiments, End Device firmware updates were managed by the FileDownload Function Set. The files containing the firmware were uploaded to and hosted on the Server for retrieval by the Client. Once the files are retrieved to the Client, they were pushed to the End Device using a device-specific process and/or protocol.
In some embodiments, UC 7 End Devices include Bloom Energy® Storage. In some embodiments, UC 7 End Device Connectivity and Protocols include DNP3 on TCP/IP over ethernet. In some embodiments, UC 7 Server-Client Communication include IEEE 2030.5. In some embodiments, UC 7 Server Functions include receiving and decoding DNP3 from RT SCADA and return responses and/or wrapping and sending DNP3 message to Client and receiving responses.
In some embodiments, UC 7 Client Functions include forwarding DNP3 messages to the End Device and/or returning the Response to the Server.
In some embodiments, Use Case 7 included Data Acquisition and Control Telemetry Communications. In some embodiments, for Use Case 7, the Server and Client facilitated communication between an instance of DC Systems SCADA management software, RT SCADA, and a DG (Distributed Generator). In some embodiments, due to the physical size of the DG under test, only the control module of the DG was staged for testing. In some embodiments, the Server was configured to perform two functions: communicating with RT SCADA via the DNP3 API and forwarding of messages to the Client. In some embodiments, a Bloom Energy® Fuel Cell was the DG whose controller was staged for testing. In some embodiments, the DG controller was connected directly to an IoT router staged in the ATS lab via direct Ethernet cable. In some embodiments, the DG controller was configured to either pull an IP from the IoT router via DHCP or assigned a static IP on the subnet of the IoT router. In some embodiments, with regard to End Device Protocol, all messaging to the End Device was forwarded by or translated locally within the Client to DNP3 for communication to the End Device. In some embodiments, the Client was configured with details for the End Device which included the TLS certificate, PIN, and local IP address. In some embodiments, the Server was configured with End Device details required for registration including the SFDI and PIN as well as FunctionSetAssignment associations, ACLs, and Device Capabilities. In some embodiments, no background processes were required for this Use Case. In some embodiments, The DNP3 API was used to receive DNP3 control commands from the SCADA Master software, RT SCADA.
In some embodiments, the Use Case 7 IEEE 2030.5 Interface included Subscription/Response functionality. In some embodiments, upon device registration, the Client subscribed to the Proprietary Extension for SCADA communication to receive Notifications of inbound DNP3 messages. In some embodiments, upon communication of the DNP3 message to the End Device by the Client, communication back to the Server was facilitated by the Response Function Set.
Field test and non-functional requirements for one or more use cases are described further below. In some embodiments, the term “require” and its plurals, tenses, and derivatives do not denote limitations for the system and are only meant to convey that components, methods, and/or connections associated with the word “require” were included for that particular example and/or Use Case.
In some embodiments, the following section describes requirements for both the IEEE 2030.5 Server and Client software that were required to perform field testing across Use Cases: 2 (Smart Inverter), 6 (RFID), and 7 (Telemetry).
In some embodiments, the field testing occurred following the completion of successful lab testing and involved deploying the IEEE 2030.5 Server and Client software on virtual servers and IoT routers deployed with the production network. In some embodiments, two zones within the production environment (CD03) were created as follows: Pre-Test Zone: Used for end-to-end field test deployment in demonstration zone; and Demonstration Zone: Used by business owners to demonstrate business use cases.
In some embodiments, field testing included Use Case 2: DER Communications. In some embodiments, for Use Case 2 field testing, a customer was chosen that had in their home a compatible Inverter supported by the lab testing. In some embodiments, the customer was provided with a pre-configured IoT router that needed to be connected to the Smart Inverter under test by an Ethernet cable (3 ft. max length) and powered using an AC adapter. In some embodiments, the networking configuration of the Smart Inverter may also have to be changed manually after connecting to the IoT router.
In some embodiments, field testing included Use Case 6: RFID Reader. In some embodiments, for Use Case 6 field testing, two RFID readers of differing vendors (Zebra and Impinj) were used. In some embodiments, each RFID reader was physically connected to their own IoT router and the IoT routers were connected to a new AP on the CD03 AMI network. In some embodiments, basic connectivity tests were performed to validate end-to-end connectivity through the AMI network followed by tests to assess network performance metrics for latency, throughput, and packet loss.
In some embodiments, field testing included Use Case 7: Data Acquisition and Control Telemetry. In some embodiments, for Use Case 7 field testing, a pre-configured Smart Inverter and the hardware to convert a Smart Inverter's CAN protocol to DNP3 were required by the test. In some embodiments, Bloom Energy® was provided with a pre-configured IoT router that needed to be connected to the DNP3 to CAN protocol converter by an Ethernet cable and powered using an AC adapter. In some embodiments, the networking configuration of the DNP3 to CAN converter also had to be changed manually after connecting to the IoT router. In some embodiments, for comparison, the over the air protocol used between the IEEE 2030.5 Server and Client was tested using both DNP3 over a simple HTTP channel as well as DNP3 embedded within IEEE 2030.5 messaging.
In some embodiments, the system includes field test deployment requirements. In some embodiments, to support the field tests, the following deployment requirements were included within the network. In some embodiments, the IEEE 2030.5 Server deployed in the head end was hosted on virtual servers within a Virtual Private Cloud (VPC) dedicated to EPIC 2.26 and created in an Amazon Web Services (AWS) environment. Both Development and Test zones reside within the EPIC 2.26 VPC and were connected to the AMI network, a Smart Meter Operations Center (SMOC) Code Drop 03 (CD-03), and the Utility Data Network (UDN) via another “Transit” AWS VPC.
In some embodiments, the system includes virtual hardware. The server instance sizing according to some embodiments are shown in Table 5:
In some embodiments, the required 3rd party software applications and version included for each server are shown in Table 6:
In some embodiments, the TCP/IP port and protocol information for communication to and from each server used to configure the firewall exception rules are shown in Tables 7-9:
In some embodiments, non-functional requirements for user authentication and authorization on the IEEE 2030.5 Server, integration with an Active Directory using the Lightweight Directory Access (LDAP) protocol is included. In some embodiments, this allows Server users to log in using their existing corporate LAN ID credentials. In some embodiments, to facilitate testing of this functionality during the lab testing phase, internal networks allow LDAP traffic from the TicNet (DMZ) environment to the corporate LDAP server.
In some embodiments, the system includes Asset Management Interface (AMI) requirements. In some embodiments, the goal of the system is to extend the basic RFID reader functionality with additional functionality, data processing capability, and improved data visualization. In some embodiments, the additional functionality allowed field testing that validated the use of the AMI network and the EPIC 2.26 Server and Client software for the purposes of managing a network of RFID readers across a service area.
In some embodiments, the system includes a data model. In some embodiments, as the initial EPIC 2.26 UC6 development was only focused on collecting raw RFID tag read data from multiple types and vendors of RIFD reader, the scope of these enhancements required additions to the data model to relate the RFID tag reads to physical assets and to track them both geographically and over time.
In some embodiments, as new, raw RFID tag read data (i.e., Electronic Product Codes; EPCs) are read into the Server, they are processed to determine if they can be associated to assets that should be tracked. In some embodiments, if an RFID EPC can be correlated to an asset to be tracked, a new instance of “Tag” is created. In some embodiments, during lab and field testing, this is accomplished by a lookup table that can be used to correlate the RFID EPC to an asset's unique identifier (badge #). In some embodiments, the asset unique identifier is used to lookup additional information about the asset (asset type) from another imported external data source (CC&B). In some embodiments, for subsequent tag reads of existing “Tag”s, new TagStatus instances are created and stored to create a history of the Tag's movement throughout the Asset Management system.
In some embodiments, this data model introduces the concept of RFID reader location, and each location can support one or more RFID readers. In some embodiments, each location has a configurable type with the three main types: Distribution Center (“warehouse”); Service Center (“yard”); Truck. In some embodiments, each location contains configurable parameters for name, internal ID, street address, latitude, and longitude.
In some embodiments, the system includes software development. In some embodiments, software development includes multiple RFID reader per IoT router support. In some embodiments, to more efficiently manage multiple RFID readers at a single location, both Client and Server are updated and able to send commands and collect data from multiple RFID readers attached to a single IoT router. In some embodiments, IoT router is put into “client” mode which turns its ethernet port into a DHCP client which allows it to talk to all RFID readers on the location's local network. In some embodiments, polling of readers by the Client is configurable per RFID reader. In some embodiments, polling of RFID data by the Server to the Clients collects RFID data for all readers attached to the Client at once (not per RFID reader). In some embodiments, commands issued by the Server is directed to a single RFID reader rather than all readers attached to an IoT router.
In some embodiments, the system includes reader health and status. In some embodiments, to provide more information about the health and status of each RFID reader across the network, additional information is collected by the Client for each individual reader. In some embodiments, for Network connectivity, the Client performs a “ping” to ensure that the RFID reader is reachable on the local network. In some embodiments, the resulting status is pass or fail based on receiving a single successful response out of 5 attempts. In some embodiments, for Reader Operation, the Client performs an LLRP command (GET ROSPEC) to retrieve details of the reader's operation specification. In some embodiments, the status of the reader operation is one of:
Active—Reader operation exists, is enabled, and running.
Inactive—Reader operation exists, is enabled, but not running.
Disabled—Reader operation exists but is not enabled.
Non-existent—No reader operations exist.
In some embodiments, the polling frequency of the Client to the managed readers is configurable through the Router Config file and the RFID reader health information is stored in a Client-side cache. In some embodiments, the Client-side cache is pollable from the Server on-demand and only the most current status for each reader is stored.
In some embodiments, the system includes handheld reader support. In some embodiments, support is added to the system for managing and collecting data from a handheld reader (e.g., the Alien® ALR-H450). In some embodiments, the handheld reader uses an Android® device and does not support LLRP directly, so custom Android software was developed and deployed on the reader. In some embodiments, the Android® software collects the RFID tag read data and transfer it to the EPIC 2.26 Client via a Bluetooth and/or WiFi connection established between the reader and the IoT router.
In some embodiments, the system includes a business intelligence engine. In some embodiments, to be able to translate the RFID tag read data being collected by the platform to usable, business data a Business Intelligence (BI) engine is added. In some embodiments, the BI engine is configured to managing external data and processing the raw RFID tag read data as it enters the system.
In some embodiments, the system includes data import. In some embodiments, at least two external data sources are supported for import into the Server. In some embodiments, one external data source is a Systems Applications and Products (SAP) Export. In some embodiments, the export from the SAP asset management database contains the weekly cycle count information (manual meter counts) as well as the threshold and quantities for reordering of meters. In some embodiments, data is maintained per meter type and per location. In some embodiments, the Server is configured to maintain cycle count data over time (one set of data per week).
In some embodiments, another external data source is a Customer Care & Billing (CC&B) Export. In some embodiments, this data contains meter information from the system database for meters that have been received at a Distribution Center and provide information about the specific meter asset such as meter type, manufacturer, and installation status for meters both installed and not installed, as non-limiting examples. In some embodiments, each new load of the CC&B data overwrites the existing data, and data is not maintained over time. See appendix B for a sample of the CC&B data according to some embodiments.
In some embodiments, the system includes Tag processing. In some embodiments, as new RFID tag read data are read into the system, they are processed to determine details of the underlying asset. In some embodiments, example asset details that are determined from the RFID tag are: Meter vs Pallet; Meter manufacturer & meter type; and Meter/Badge number. See appendix C for an example of EPCs from which all of the above information could be parsed according to some embodiments.
In some embodiments, the system includes asset tracking. In some embodiments, for tag read data that is processed for assets that already exist in the system, the new tag read information is compared to the existing status of the tag. In some embodiments, new tag reads that represent the underlying asset that has “moved” between areas of a single location or between two locations will update the status of the asset and record the new status to the asset's status history.
In some embodiments, the system includes meter count. In some embodiments, for each location, a user-editable script is defined to perform the meter count calculation for that location. In some embodiments, for locations that have RFID tag read data, this meter count data replaces the cycle count data imported from the SAP import sheet.
In some embodiments, the system includes data exporting. In some embodiments, Server interfaces are added for search and export of both asset tracking history and raw tag read data in CSV format.
In some embodiments, the system includes one or more meter data maps. In some embodiments, a Meter Data Map user interface provides information about the quantity of meters at each location and/or geographically within a map-based user interface as a display on a proprietary and/or conventional map (e.g., Google Maps; Waze). In some embodiments, an API works in conjunction with a conventional map to display information about the quantity of meters at each location and/or geographically within a map-based user interface. In some embodiments, different icons on the map will represent each location type and the icons are color-coded (Red/Amber/Green) based on the meter count compared to High and Low as follows:
Green: meter count>=High
Amber: Low<=meter count<High
Red: meter count<Low
In some embodiments, each location supports separate High and Low thresholds per meter type. In some embodiments, the initial default High and Low settings for each location are:
High=reorder point
Low=20% of reorder point
In some embodiments, the map has filters for selecting the location type to display on the map and meter type which adjusts the icon color based on the current meter counts and thresholds. In some embodiments, selecting a specific location on the map will provide additional information (primarily meter count) for that specific location. In some embodiments, this map-based interface is configured for use on mobile devices with regards to size and layout of elements.
In some embodiments, the system includes output APIs. In some embodiments, the EPIC 2.26 Server will be updated to support at least two types of output APIs for exporting RFID data programmatically to external applications as described below:
REST APIs—In some embodiments, a REST API allows external applications to “pull” RFID data from the Server on demand. In some embodiments, two separate APIs are created for exporting tag transaction data based on a location and timeframe and for exporting current asset information by location. In some embodiments, the API will support export of data by XML or JSON.
Kafka API—In some embodiments, a Kafka API will “push” data from the Server to an external Kafka messaging server. In some embodiments, upon completion of the processing of raw tag read data into transactions, all new asset transaction data are pushed to the configured Kafka topic. In some embodiments, Kafka server configuration properties will be added to the EPIC 2.26 Server configuration file.
In some embodiments, the system includes data feed monitoring requirements. In some embodiments, the is Server is configured to allow a user to create thresholds within the system Server (e.g., EPIC 2.26 Server) and apply them against a set of metering data imported into the Server. In some embodiments, after execution, all values identified as not within the selected thresholds are flagged and reported to the user. In some embodiments, this functionality is configured to be expanded to apply to different data sources and trigger different notification processes. In some embodiments, each threshold consists of a set of three components:
property—The specific category of metering data to evaluate.
operator—The comparator to apply (“<”, “=”, “>”, etc.)
value—The threshold value to compare the measured value against.
In some embodiments, the system includes Server requirements. In some embodiments, Server requirements include security including one or more of security for basic HTTP and user account security; device security using TLS certificates and PIN; and/or Access Control List (ACL) that allows for device-specific privileges. In some embodiments, Server requirements include discovery, where discovery includes the Server managing and communicating the device's capabilities. In some embodiments, Server requirements include one or more background process threads used for routing processes (subscription cleanup, etc.) In some embodiments, Server requirements include Client communication that broker connectivity to Clients via both IEEE 2030.5 and HTTP and support 2030.5 Subscription/Notification to reduce network traffic. In some embodiments, Server requirements include at least one DPN3 API that receives and decodes inbound DNP3 messages to find “Destination Address”. In some embodiments, DNP3 API includes the Server identifying an End Device and IoT Router and forwarding an original message.
In some embodiments, the system includes one or more Client requirements. In some embodiments, Client requirements include security, which includes Spring Security for user accounts and Server communication secured with TLS and device/user authentication. In some embodiments, Client requirements include discovery which includes the Client autonomously registering with the Server, discover available Resources on Server, Subscribe to Notifications, perform time sync, etc., where the Client is designed to support multiple End Devices per IoT router. In some embodiments, Client requirements include at least on background process thread that is used for routine processes (Reading device data, sending device commands, etc.). In some embodiments, Client requirements include Server communication that receives messages from server via both IEEE 2030.5 Notifications and HTTP and supports 2030.5 Subscription/Notification to reduce network traffic. In some embodiments, Client requirements include at least one DPN3 Interface that receives message from server and forward to appropriate End Device.
In some embodiments of the system, any of the meters or assemblies described herein uses at least one computing system within a networked metering or power network. For example,
Some embodiments of the system relate to or include a device or an apparatus for performing these operations of the operating system 1834 and/or the software modules 1838. The apparatus can be specially constructed for the required purpose, such as a special purpose computer. When defined as a special purpose computer, the computer can also perform other processing, program execution or routines that are not part of the special purpose, while still being capable of operating for the special purpose. Alternatively, the operations can be processed by a general purpose computer selectively activated or configured by one or more computer programs stored in the computer memory, cache, or obtained over a network. When data are obtained over a network the data can be processed by other computers on the network, e.g. a cloud of computing resources.
With the above embodiments in mind, it should be understood that the system can employ various computer-implemented operations involving smart meter system and method 100 data stored in computer systems. Moreover, the above-described databases and models throughout the smart meter system and method 100 can store analytical models and other data on computer-readable storage media within the system 1830 and on computer-readable storage media coupled to the system 1830. In addition, the above-described applications of the smart meter system and method 100 system can be stored on computer-readable storage media within the system 1830 and on computer-readable storage media coupled to the system 1830. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, electromagnetic, or magnetic signals, optical or magneto-optical form capable of being stored, transferred, combined, compared and otherwise manipulated.
Some embodiments include the system 1830 comprising at least one computer readable medium 1836 coupled to at least one data storage device 1837b, and/or at least one data source 1837a, and/or at least one input/output device 1837c. In some embodiments, the system embodied by the smart meter system and method 100 can be embodied as computer readable code on a computer readable medium 1836. The computer readable medium 1836 can be any data storage device that can store data, which can thereafter be read by a computer system (such as the system 1830). Examples of the computer readable medium 1836 can include hard drives, network attached storage (NAS), read-only memory, random-access memory, FLASH based memory, CD-ROMs, CD-Rs, CD-RWs, DVDs, magnetic tapes, other optical and non-optical data storage devices, or any other physical or material medium which can be used to tangibly store the desired information or data or instructions and which can be accessed by a computer or processor (including processors 1832).
In some embodiments of the system, the computer readable medium 1836 can also be distributed over a conventional computer network via the network interface 1835a so that the smart meter system and method 100 embodied by the computer readable code can be stored and executed in a distributed fashion. For example, in some embodiments, one or more components of the system 1830 can be tethered to send and/or receive data through a local area network (“LAN”) 1839a. In some embodiments, one or more components of the system 1830 can be tethered to send or receive data through an internet 1839b (e.g., a wireless internet). In some embodiments, at least one software application 1838 running on one or more processors 1832 can be configured to be coupled for communication over a network 1839a, 1839b. In some embodiments, one or more components of the network 1839a, 1839b can include one or more resources for data storage, including any other form of computer readable media beyond the media 1836 for storing information and including any form of computer readable media for communicating information from one electronic device to another electronic device.
In some embodiments, the network 1839a, 1839b can include wide area networks (“WAN”), direct connections (e.g., through a universal serial bus port) or other forms of computer-readable media 1836, or any combination thereof. Further, in some embodiments, one or more components of the network 1839a, 1839b can include a number of client devices which can be personal computers 1840 including for example desktop computers 1840d, laptop computers 1840a, 1840e, digital assistants and/or personal digital assistants (shown as 1840c), cellular phones or mobile phones or smart phones (shown as 1840b), pagers, digital tablets, internet appliances, and other processor-based devices. In general, a client device can be any type of external or internal devices such as a mouse, a CD-ROM, DVD, a keyboard, a display, or other input or output devices 1837c. In some embodiments, various other forms of computer-readable media 1836 can transmit or carry instructions to a computer 1840, including a router, private or public network, or other transmission device or channel, both wired and wireless. The software modules 1838 can be configured to send and receive data from a database (e.g., from a computer readable medium 1836 including data sources 1837a and data storage 1837b that can comprise a database), and data can be received by the software modules 1838 from at least one other source. In some embodiments, at least one of the software modules 1838 can be configured within the system to output data to a user 1831 via at least one smart meter (e.g., to a computer 1840 comprising a smart meter).
In some embodiments, the system 1830 as described above can enable one or more users 1831 to receive, analyze, input, modify, create and send data to and from the system 1830, including to and from one or more enterprise applications 1838 running on the system 1830. Some embodiments include at least one user 1831 coupled to a computer 1840 accessing one or more modules of the smart meter system and method 100 including at least one enterprise applications 1838 via a stationary I/O device 1837c through a LAN 1839a. In some other embodiments, the system 1830 can enable at least one user 1831 (through computer 1840) accessing enterprise applications 1838 via a stationary or mobile I/O device 1837c through an internet 1839a.
The embodiments of the present system can also be defined as a machine that transforms data from one state to another state. The data can represent an article, that can be represented as an electronic signal and electronically manipulate data. The transformed data can, in some cases, be visually depicted on a display, representing the physical object that results from the transformation of data. The transformed data can be saved to storage generally or in particular formats that enable the construction or depiction of a physical and tangible object. In some embodiments, the manipulation can be performed by a processor. In such an example, the processor thus transforms the data from one thing to another. Still further, the methods can be processed by one or more machines or processors that can be connected over a network. Each machine can transform data from one state or thing to another, and can also process data, save data to storage, transmit data over a network, display the result, or communicate the result to another machine. Computer-readable storage media, as used herein, refers to physical or tangible storage (as opposed to signals) and includes without limitation volatile and non-volatile, removable and non-removable storage media implemented in any method or technology for the tangible storage of information such as computer-readable instructions, data structures, program modules or other data.
Although method operations can be described in a specific order, it should be understood that other housekeeping operations can be performed in between operations, or operations can be adjusted so that they occur at slightly different times, or can be distributed in a system which allows the occurrence of the processing operations at various intervals associated with the processing, as long as the processing of the overlay operations are performed in the desired way.
It will be appreciated by those skilled in the art that while the system has been described above in connection with particular embodiments and examples, the system is not necessarily so limited, and that numerous other embodiments, examples, uses, modifications and departures from the embodiments, examples and uses are intended to be encompassed by the description herein.
Acting as Applicant's own lexicographer, Applicant defines the use of and/or, in terms of “A and/or B,” to mean one option could be “A and B” and another option could be “A or B.” Such an interpretation is consistent with ex parte Gross, where the Board established that “and/or” means element A alone, element B alone, or elements A and B together.
Simultaneously as used herein includes lag and or latency times associated with a conventional computer attempting to process multiple types of data at the same time.
This application is a continuation-in-part of U.S. application Ser. No. 15/586,093, filed May 2, 2017, entitled “Smart Energy Metering System and Method”, which claims the benefit of and priority to U.S. Provisional Application No. 62/408,260, filed Oct. 14, 2016, entitled “Smart Energy Metering System and Method”, the entire contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62408260 | Oct 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15586093 | May 2017 | US |
| Child | 16878239 | US |
